While testing the new upstream lynkeos.app release I found out that
the program is unusable since text is missing in most of the UI
elements.  Further investigation showed that the culprit is
gnustep-gui's GSXib5KeyedUnarchiver parsing the app's XIB files:

- (id) decodeFontSizeForElement: (GSXibElement*)element
{
  NSDictionary *attributes = [element attributes];
  CGFloat       size       = [[attributes objectForKey: @"size"] floatValue];

  if (size == 0)
    {
      ...

That's perfectly fine code, it relies on the semantics of the language
that invoking a method returning a scalar type on a nil receiver
should return 0.  But it returns a gigantic garbage value instead;
subsequently the condition (size == 0) is false and all goes havoc.

I was initially confused that this is a compiler bug since I could not
reproduce it with a simple test program built with clang-19 on a sid
system but *linked* with the GCC runtime.  Examining the assembly
revealed that clang generates code which is doing a check if the
receiver is nil, skipping the library call if that's the case.

If the patch for the frontend that is proposed upstream is committed,
we should binNMU all reverse dependencies when it propagates to the
default compiler and is available on all architectures.  A lot of
GNUstep methods return floating point types or "simple" structs with
two CGFloat members.  There are probably a ton of hidden bugs due to
this problem.

Control: tags -1 + moreinfo
please recheck with the latest Debian stable release, using GCC 14 as
the default, also Debian unstable defaulting to GCC 15. There also is
the gcc-snapshot package holding a snapshot from the trunk.

I assume, we will need a reproducer to report that upstream.

Matthias Klose wrote:

Already done; I'm reporting against the bookworm version since this is
the oldest supported release.  This bug is present since "the beginning".

It's already reported upstream, see the PR above.  There are four
reproducers that are part of the patch proposed for the frontend [1]:

pr121624-1.m: Exhibits the bug for methods returning float.
pr121624-2.m: Exhibits the bug for methods returning a "simple" struct.
pr121624-3.m: Exhibits the bug for methods returning a "complex" struct.
pr121624-4.m: Tests the evaluation order.

1, 2, 3 fail with all GCC versions (including gcc-snapshot) and -4
fails on amd64 and i386.  They all pass with the patch applied (see
the list of tested targets in the patch header).

[1] https://gcc.gnu.org/bugzilla/attachment.cgi?id=62434

Matthias Klose wrote:

Already done; I'm reporting against the bookworm version since this is
the oldest supported release.  This bug is present since "the beginning".

It's already reported upstream, see the PR above.  There are four
reproducers that are part of the patch proposed for the frontend [1]:

pr121624-1.m: Exhibits the bug for methods returning float.
pr121624-2.m: Exhibits the bug for methods returning a "simple" struct.
pr121624-3.m: Exhibits the bug for methods returning a "complex" struct.
pr121624-4.m: Tests the evaluation order.

1, 2, 3 fail with all GCC versions (including gcc-snapshot) and -4
fails on amd64 and i386.  They all pass with the patch applied (see
the list of tested targets in the patch header).

[1] https://gcc.gnu.org/bugzilla/attachment.cgi?id=62434