[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages

[iains at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352

--- Comment #24 from Iain Sandoe  ---
(In reply to Sergey Fedorov from comment #23)
> (In reply to Andrew Pinski from comment #22)
> > (In reply to Sergey Fedorov from comment #21)
> > > Any chance of having it fixed in gcc14?
> > 
> > It is too late to be included in GCC 14, GCC is in stage 3 already, that is
> > no new features can be included that was not posted before a specific date.
> > See https://gcc.gnu.org/pipermail/gcc/2023-November/242898.html and
> > https://gcc.gnu.org/develop.html about the timing there.
> 
> Oh…
> 
> Can new features be added into minor releases, like 14.x?

No. The general rule is that we only fix regressions and documentation/tests on
release branches.  As Darwin maintainer, I include fixes for build/ABI problems
in back-ports (where they only effect Darwin).

Any new feature like blocks support would be much more invasive than that, so
definitely have to wait for GCC-15.

Like other "vendors", I maintain external branches for Darwin that have more
relaxed rules - allowing port-critical back ports that would not be acceptable
upstream,

However, first we have to complete this work and bring it forward to trunk ..
then we can worry about back ports to older branched ;)

[Bug middle-end/113179] [11/12/13/14 Regression] MIPS: INS is used for long long, before SLL

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|middle-end
 Ever confirmed|0   |1
   Keywords||needs-bisection
   Last reconfirmed||2023-12-31
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
5.4 produced during expand:
```
(insn 10 7 11 2 (set (reg:QI 198 [ D.1502 ])
(truncate:QI (reg/v:DI 197 [ b ]))) /app/example.cpp:10 -1
 (nil))
(insn 11 10 12 2 (set (reg:SI 199)
(mem/j:SI (reg/v/f:DI 196 [ a ]) [1 a_5(D)->d+-3 S4 A32]))
/app/example.cpp:10 -1
 (nil))
(insn 12 11 13 2 (set (zero_extract:SI (reg:SI 199)
(const_int 1 [0x1])
(const_int 0 [0]))
(subreg:SI (reg:QI 198 [ D.1502 ]) 0)) /app/example.cpp:10 -1
 (nil))
```

But 11.2.0 produces:
```
(insn 10 7 11 2 (set (reg:SI 197)
(mem/j:SI (reg/v/f:DI 195 [ a ]) [1 a_4(D)->d+-3 S4 A32]))
"/app/example.cpp":10:14 -1
 (nil))
(insn 11 10 12 2 (set (zero_extract:SI (reg:SI 197)
(const_int 1 [0x1])
(const_int 0 [0]))
(subreg:SI (reg/v:DI 196 [ b ]) 4)) "/app/example.cpp":10:14 -1
 (nil))
```

The truncate is missing ...

Would be interesting to do a bisect here on what caused the wrong code ...

[Bug rtl-optimization/113179] [11/12/13/14 Regression] MIPS: INS is used for long long, before SLL

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.5
 Target||mips64-linux-gnu
Summary|MIPS: INS is used for long  |[11/12/13/14 Regression]
   |long, before SLL|MIPS: INS is used for long
   ||long, before SLL
  Known to work||5.4.0
  Known to fail||11.2.0
  Component|target  |rtl-optimization

--- Comment #1 from Andrew Pinski  ---
Confirmed, this is a regression. I think it used to work in GCC 7.3.0 also (but
I have around is modified octeon compiler).

[Bug middle-end/113180] MIPS: bitops on an long long struct uses ins instead dins (or with -mstrict-align on aarch64)

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113180

Andrew Pinski  changed:

   What|Removed |Added

 Target|mips aarch64*-*-*   |mips aarch64*-*-* arm*-*

--- Comment #2 from Andrew Pinski  ---
arm is just as bad:
```
xx:
@ args = 8, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
sub sp, sp, #8
mov r3, r0
strdr1, r2, [sp]
ldr r1, [sp, #8]
ldrbr2, [sp, #7]@ zero_extendqisi2
bfi r2, r1, #4, #4
strbr2, [sp, #7]
ldrdr0, r1, [sp]
stm r3, {r0, r1}
mov r0, r3
add sp, sp, #8
@ sp needed
bx  lr
```

Basically the variable a is stored to the stack and then modified and then
stored to the stack and then loaded and stored to the return location.

This is all due to STRICT alignment IIRC.

[Bug middle-end/113180] MIPS: bitops on an long long struct uses ins instead dins (or with -mstrict-align on aarch64)

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113180

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug middle-end/113180] MIPS: bitops on an long long struct uses ins instead dins (or with -mstrict-align on aarch64)

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113180

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Component|target  |middle-end
 Target|mips|mips aarch64*-*-*
 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
   Last reconfirmed||2023-12-31
Summary|MIPS: bitops on an long |MIPS: bitops on an long
   |long struct uses ins|long struct uses ins
   |instead dins|instead dins (or with
   ||-mstrict-align on aarch64)

--- Comment #1 from Andrew Pinski  ---
The same issue happens on aarch64 with -mstrict-align though it is not as bad
as mips but the underlying issue is the same:
```
sub sp, sp, #32
.cfi_def_cfa_offset 32
str x0, [sp, 8]
lsr x0, x0, 32
bfi w0, w1, 28, 4
str w0, [sp, 12]
ldr x0, [sp, 8]
add sp, sp, 32
ret
```

Confirmed. there might be other bug reports which are very similar too.

[Bug middle-end/113185] bad performance on big-endian&64bit port for struct 16 16

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113185

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-31
 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90864,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=45026,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=30271
 Ever confirmed|0   |1

[Bug middle-end/113185] bad performance on big-endian&64bit port for struct 16 16

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113185

--- Comment #1 from Andrew Pinski  ---
The issue is with the argument passing. I thought there was a dup of this bug
somewhere ...

[Bug rtl-optimization/113185] New: bad performance on big-endian&64bit port for struct 16 16

[syq at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113185

Bug ID: 113185
   Summary: bad performance on big-endian&64bit port for struct 16
16
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: syq at gcc dot gnu.org
  Target Milestone: ---

```
struct xx {
int a:16;
int b:16;
};

struct xx xx (struct xx a, long long b) {
a.b = b;
return a;
}
```

On little-endian&64, only 1 or 2 instructions are used, such as
on AARCH64el:

```
bfi w0, w1, 16, 16
ret
```
On MIPS64el
```
move$2,$4
sll $5,$5,0
jr  $31
ins $2,$5,16,16
```


While for 64EB
```
.cfi_startproc
sub sp, sp, #16
.cfi_def_cfa_offset 16
str x0, [sp, 8]
strhw1, [sp, 10]
ldr w0, [sp, 8]
add sp, sp, 16
.cfi_def_cfa_offset 0
lsl x0, x0, 32
ret
.cfi_endproc
```
```
daddiu  $sp,$sp,-16
sd  $4,0($sp)
sh  $5,2($sp)
lw  $2,0($sp)
daddiu  $sp,$sp,16
jr  $31
dsll$2,$2,32
```

[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages

[vital.had at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352

--- Comment #23 from Sergey Fedorov  ---
(In reply to Andrew Pinski from comment #22)
> (In reply to Sergey Fedorov from comment #21)
> > Any chance of having it fixed in gcc14?
> 
> It is too late to be included in GCC 14, GCC is in stage 3 already, that is
> no new features can be included that was not posted before a specific date.
> See https://gcc.gnu.org/pipermail/gcc/2023-November/242898.html and
> https://gcc.gnu.org/develop.html about the timing there.

Oh…

Can new features be added into minor releases, like 14.x?

P. S. On a side note, I delayed forever my fixes for gfortran on PowerPC, will
return to that soonish, so we can get in into the master in a reasonable time.

[Bug libstdc++/113175] [14 Regression] testsuite/std/ranges/iota/max_size_type.cc 5x times slower

[hp at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175

--- Comment #2 from Hans-Peter Nilsson  ---
Bisecting (native) has progressed beyond the r13 mark, i.e. this is indeed a
"[14 Regression]" only.

[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use

[dcb314 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178

David Binderman  changed:

   What|Removed |Added

 CC||tamar.christina at arm dot com

--- Comment #4 from David Binderman  ---
Reduced range seems to be g:0994ddd86f9c3d82 to g:a657c7e3518fcfc7.

All commits in this range are by Tamar.

[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use

[dcb314 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178

--- Comment #3 from David Binderman  ---
After some bisection, range seems to be g:2902300340928989
to g:ed60b2868abdb793, a range of 21 commits.

[Bug lto/113183] LTO crashes with Segmentation fault

[sebunger44 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183

--- Comment #13 from Sebastian Unger  ---
No worries, the constructor attribute is much better. I was aware of that, but
at the time had already several examples using .preinit_array and couldn't be
bothered to look it up. I later added the sort by priority and added priorities
to  the *init_array symbols that needed them, but not this one. Interestingly,
that was not when LTO started crashing (or I might have made the connection).
LTO only started crashing once I added the static global object NonTrivial!
Weird.

In any case, I have changed to the constructor attribute and learned my lesson
and am all good.

I'll leave this issue open in case someone wants to fix the crash in LD (or
wherever it comes from) so people running into this in the future will get a
nicer error message.

[Bug target/113184] [14 Regression] ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -frounding-math -fnon-call-exceptions

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113184

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||pinskia at gcc dot gnu.org

[Bug target/113184] New: [14 Regression] ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -frounding-math -fnon-call-exceptions

[zsojka at seznam dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113184

Bug ID: 113184
   Summary: [14 Regression] ICE: in extract_insn, at recog.cc:2812
(unrecognizable insn) with -O -frounding-math
-fnon-call-exceptions
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

Created attachment 56969
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56969=edit
reduced testcase

Compiler output:
$ aarch64-unknown-linux-gnu-gcc -O -frounding-math -fnon-call-exceptions
testcase.c
testcase.c: In function 'foo':
testcase.c:7:1: error: unrecognizable insn:
7 | }
  | ^
(insn 43 0 0 (set (reg:DI 120)
(subreg:DI (float:DF (reg:DI 114)) 0)) -1
 (nil))
during RTL pass: reload
testcase.c:7:1: internal compiler error: in extract_insn, at recog.cc:2812
0x85ed33 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x85edb0 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:116
0x84fdd1 extract_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2812
0x10d94c0 ira_remove_insn_scratches(rtx_insn*, bool, _IO_FILE*, rtx_def*
(*)(rtx_def*))
/repo/gcc-trunk/gcc/ira.cc:5381
0x112325d remove_insn_scratches
/repo/gcc-trunk/gcc/lra.cc:2154
0x112325d lra_emit_move(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/lra.cc:513
0x113be18 curr_insn_transform
/repo/gcc-trunk/gcc/lra-constraints.cc:4669
0x113dc37 lra_constraints(bool)
/repo/gcc-trunk/gcc/lra-constraints.cc:5414
0x11267a4 lra(_IO_FILE*, int)
/repo/gcc-trunk/gcc/lra.cc:2442
0x10d477f do_reload
/repo/gcc-trunk/gcc/ira.cc:5973
0x10d477f execute
/repo/gcc-trunk/gcc/ira.cc:6161
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-6868-20231230002732-g77f30e22f17-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-6868-20231230002732-g77f30e22f17-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231230 (experimental) (GCC)

[Bug lto/113183] LTO crashes with Segmentation fault

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183

--- Comment #12 from Andrew Pinski  ---
(In reply to Sebastian Unger from comment #11)
> I see. It was the SORT_BY_INIT_PRIORITY with the section name used not
> actually having a priority that triggered it, was it?! If I change the
> section name to .init_array.1 then it works.
> 
> But, yes, you suggestion using the constructor attribute is even better.
> 
> Thank you very much.
> 
> I suspect it would still be better to not crash though. ;-)

Changing the linker script to:
```
  .preinit_array : { KEEP(*(SORT_BY_INIT_PRIORITY(".preinit_array.*"))) KEEP
(*(.preinit_array)) } >"LOADER_REGION"
  __preinit_array_start = ADDR(.preinit_array);
  __preinit_array_end = ADDR(.preinit_array) + SIZEOF(.preinit_array);

  .init_array : { KEEP(*(SORT_BY_INIT_PRIORITY(".init_array.*"))) KEEP
(*(.init_array))  } >"LOADER_REGION"

```

Also fixes the ICE if you don't want to change to use the constructor
attribute.

[Bug lto/113183] LTO crashes with Segmentation fault

[sebunger44 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183

--- Comment #11 from Sebastian Unger  ---
I see. It was the SORT_BY_INIT_PRIORITY with the section name used not actually
having a priority that triggered it, was it?! If I change the section name to
.init_array.1 then it works.

But, yes, you suggestion using the constructor attribute is even better.

Thank you very much.

I suspect it would still be better to not crash though. ;-)

[Bug lto/113183] LTO crashes with Segmentation fault

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183

--- Comment #10 from Andrew Pinski  ---
Changing it into:
static void leon_initialise(void) __attribute__((constructor));

Fixes the ICE and fixes the code to be better and not depened on init_array
there either ...

[Bug lto/113183] LTO crashes with Segmentation fault

[sebunger44 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183

--- Comment #9 from Sebastian Unger  ---
(In reply to Sebastian Unger from comment #8)
> Not that on my target everything compiles and runs fine without -flto!

Not -> Note

[Bug lto/113183] LTO crashes with Segmentation fault

[sebunger44 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183

--- Comment #8 from Sebastian Unger  ---
Not that on my target everything compiles and runs fine without -flto!

[Bug lto/113183] LTO crashes with Segmentation fault

[sebunger44 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183

--- Comment #7 from Sebastian Unger  ---
How is it broken and how should it be rewritten?

[Bug lto/113183] LTO crashes with Segmentation fault

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183

--- Comment #6 from Andrew Pinski  ---
Note I suspect this part of the code example you gave:
```
static void const * const leon_init __attribute__((section (".init_array"),
retain, used)) = (void*)leon_initialise;
```

Is broken and should be rewritten anyways.
It is also what is causing the error and ICE (which is during the warning about
it) happening.

[Bug lto/113183] LTO crashes with Segmentation fault

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183

--- Comment #5 from Andrew Pinski  ---
Note I get the crash with a cross to aarch64 where both gcc and ld are from the
trunk.  So this does look like the crash was introduced by a ld change ...

[Bug lto/113183] LTO crashes with Segmentation fault

[sebunger44 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183

--- Comment #4 from Sebastian Unger  ---
I should have mentioned that for my TC I use binutils 2.41.

[Bug lto/113183] LTO crashes with Segmentation fault

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183

--- Comment #3 from Andrew Pinski  ---
LD that causes the crash:
```
GNU ld (GNU Binutils for Ubuntu) 2.38
Copyright (C) 2022 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
```

LD that works and gives an error:
```
GNU ld version 2.35.2-37.el9
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
```

[Bug lto/113183] LTO crashes with Segmentation fault

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183

--- Comment #2 from Andrew Pinski  ---
But changing env to Ubuntu, upstream GCC produces an ICE:
```
Segmentation fault
0xf370cf crash_signal
/home/apinski/src/upstream-gcc/gcc/gcc/toplev.cc:316
0x7f1bac5a351f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xf940b6 default_tree_printer(pretty_printer*, text_info*, char const*, int,
bool, bool, bool, bool*, char const**)
/home/apinski/src/upstream-gcc/gcc/gcc/tree-diagnostic.cc:274
0xf940b6 default_tree_printer(pretty_printer*, text_info*, char const*, int,
bool, bool, bool, bool*, char const**)
/home/apinski/src/upstream-gcc/gcc/gcc/tree-diagnostic.cc:251
0x21d2ef4 pp_format(pretty_printer*, text_info*, urlifier const*)
/home/apinski/src/upstream-gcc/gcc/gcc/pretty-print.cc:1602
0x21ad9cb diagnostic_context::report_diagnostic(diagnostic_info*)
/home/apinski/src/upstream-gcc/gcc/gcc/diagnostic.cc:1604
0x21b1dd7 diagnostic_impl
/home/apinski/src/upstream-gcc/gcc/gcc/diagnostic.cc:1767
0x21b1dd7 warning(int, char const*, ...)
/home/apinski/src/upstream-gcc/gcc/gcc/diagnostic.cc:1900
0x12bdd17 switch_to_section(section*, tree_node*)
/home/apinski/src/upstream-gcc/gcc/gcc/varasm.cc:7935
0x12c9cd2 assemble_variable(tree_node*, int, int, int)
/home/apinski/src/upstream-gcc/gcc/gcc/varasm.cc:2407
0x12ce2f9 varpool_node::assemble_decl()
/home/apinski/src/upstream-gcc/gcc/gcc/varpool.cc:596
0x12cee6e varpool_node::assemble_decl()
/home/apinski/src/upstream-gcc/gcc/gcc/varpool.cc:568
0x12cee6e symbol_table::output_variables()
/home/apinski/src/upstream-gcc/gcc/gcc/varpool.cc:764
0xa4865a symbol_table::compile()
/home/apinski/src/upstream-gcc/gcc/gcc/cgraphunit.cc:2402
0x9951d1 lto_main()
/home/apinski/src/upstream-gcc/gcc/gcc/lto/lto.cc:685
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: /home/apinski/upstream-gcc/bin/gcc returned 1 exit
status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

```

[Bug lto/113183] LTO crashes with Segmentation fault

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183

--- Comment #1 from Andrew Pinski  ---
GCC trunk fails with:
```
[apinski@xeond2 tt]$ ~/upstream-gcc/bin/gcc -nostartfiles -O2 -flto -T link.ld
tt.cpp -o tt
tt.cpp:18:90: warning: ‘retain’ attribute ignored [-Wattributes]
   18 | static void const * const leon_init __attribute__((section
(".init_array"), retain, used)) = (void*)leon_initialise;
  |
 ^
tt.cpp:18:27: error: ‘leon_init’ causes a section type conflict
   18 | static void const * const leon_init __attribute__((section
(".init_array"), retain, used)) = (void*)leon_initialise;
  |   ^
lto-wrapper: fatal error: /home/apinski/upstream-gcc/bin/gcc returned 1 exit
status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
```

RedHat's GCC 11.3.1 fails with the same:
```
[apinski@xeond2 tt]$ gcc -nostartfiles -O2 -flto -T link.ld tt.cpp -o tt
tt.cpp:18:90: warning: ‘retain’ attribute ignored [-Wattributes]
   18 | static void const * const leon_init __attribute__((section
(".init_array"), retain, used)) = (void*)leon_initialise;
  |
 ^
tt.cpp:18:27: error: ‘leon_init’ causes a section type conflict
   18 | static void const * const leon_init __attribute__((section
(".init_array"), retain, used)) = (void*)leon_initialise;
  |   ^
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

```

[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use

[dcb314 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178

--- Comment #2 from David Binderman  ---
The bug first seems to occur sometime between git:514ea1df444ca7f6
and git:f19ceb2d49afdfa5, a distance of 83 commits.

[Bug lto/113183] New: LTO crashes with Segmentation fault

[sebunger44 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183

Bug ID: 113183
   Summary: LTO crashes with Segmentation fault
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebunger44 at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56968
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56968=edit
Contains the LD and CPP files

I'm in the process of creating a tool-chain and porting FreeRTOS to our Leon2
based platform and ran into this with GCC 13.2. However, after reducing it to a
near trivial example, I can now also reproduce it on GCC 11.4 as shipped by
Ubuntu  22.04. So it probably has nothing to do with how I compiled my GCC etc.

Output:

$ gcc -nostartfiles -O2 -flto -T link.ld tt.cpp -o tt
‘
Segmentation fault
0x7f23ac64251f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7f23ac629d8f __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f23ac629e3f __libc_start_main_impl
../csu/libc-start.c:392
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

Note that I do not expect this example to run in any way. I have cut out all
the target specific stuff so only plain old C++ remained.

[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++

[eyalroz1 at gmx dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858

--- Comment #15 from Eyal Rozenberg  ---
Note that:

* in apt-based distributions such as Debian, the relevant package would be
lib32stdc++-dev , or a similar name with the GCC version, e.g.
lib32stdc++-11-dev .

* Even when this particular issue is worked-around, the GCC build may still
fail for another reason (e.g. incompatibility of the sanitizer library with
your newer system see bug 113181).

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[danglin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182

--- Comment #4 from John David Anglin  ---
Created attachment 56967
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56967=edit
Assembler output

There are no .type directives for _U_* libfuncs.

They are emitted by ASM_OUTPUT_EXTERNAL_LIBCALL:

/* We need set the type for external libcalls.  Also note that not all
   libcall names are passed to targetm.encode_section_info (e.g., __main).
   Thus, we also have to do the section encoding if it hasn't been done
   already.  */
#undef ASM_OUTPUT_EXTERNAL_LIBCALL
#define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, FUN)  \
do {\
  if (!FUNCTION_NAME_P (XSTR (FUN, 0))) \
pa_encode_label (FUN);  \
  ASM_OUTPUT_TYPE_DIRECTIVE (FILE, XSTR (FUN, 0), "function");  \
} while (0)

The .type directives that are emitted are now at the end:

.section.debug_str,"",@progbits
.ident  "GCC: (GNU) 14.0.0 20231128 (experimental)
[remotes/origin/trunk r14-6831-ged60b2868ab]"
.type   tanh, @function

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[danglin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182

--- Comment #3 from John David Anglin  ---
Created attachment 56966
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56966=edit
Preprocessed source

[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors

[bugzilla.gcc at me dot benboeckel.net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467

--- Comment #9 from Ben Boeckel  ---
> unless autoconf/automake started relying on the non-GNU `fdep` [1] project.

Gah, editing gone awry. This was about Fortran module support in
autoconf/autotools, not C++ module support (they have similar build graph
strategies required).

[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors

[bugzilla.gcc at me dot benboeckel.net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467

--- Comment #8 from Ben Boeckel  ---
> Some people even claim that properly supporting Make to build C++ modules is 
> not possible if you want to make it actually production quality and reliable.

It is possible, but, AFAIK, requires at least one level of recursive make (to
deal with the dynamic files). Note that CMake also generates POSIX Make and
only uses GNU-specific things to disable things like builtin rules.

> GNU make still is the most common usage for build systems out there.

Overall? Sure; I don't have data to say otherwise. For C++ modules? Highly
unlikely unless autoconf/automake started relying on the non-GNU `fdep` [1]
project.

My concerns include:

- tools have learned to read the *restricted* syntax historically used by `-MF`
output and would need to grow new logic to deal with the `+=` usage
- the variable name is hard-coded

I think the following flags make sense to add:

- `-Mmodules` to explicitly request this extra information
- `-Mno-modules` to suppress it
- `-MMV varname` to select the variable name used (though maybe
`-Mc++module-variable=` is better)

> Anyways gcc should work best with gnu software and cmake is not at all gnu 
> software and it competes with autoconf and automake which are gnu tools.

I eagerly await C++ module support in autoconf and automake in that case.
AFAIK, the support is in GNU make only and significant infrastructural support
is missing from autoconf/autotools to reliably support them (namely things like
installation assistance, enforcing visibility of modules between libraries, and
not using stale module files).

> Cmake is less portable than the autotools.

There is a significant set of platforms that CMake supports that autotools does
not, but yes…CMake certainly supports fewer total number platforms than
autotools (though when weighted by relevance…). I'd say there's not a total
ordering here.

[1] https://gitlab.mpcdf.mpg.de/elpa/elpa/-/tree/master/fdep

FD: CMake developer and primary implementer of C++ module support in it.

[Bug bootstrap/113181] When compiling sanitizer_printf.cc, getting error: multiple definition of ‘enum fsconfig_command’

[eyalroz1 at gmx dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113181

--- Comment #2 from Eyal Rozenberg  ---
(In reply to Andrew Pinski from comment #1)

Perhaps I should file a separate bug about collecting 'errata' for finalized
release lines, for when users of newer systems want to build them. That could
be placed on the website / FTP server, so that people downloading the older
releases are likely to find it.

[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||needs-bisection
 Ever confirmed|0   |1
   Last reconfirmed||2023-12-30

--- Comment #1 from Andrew Pinski  ---
More reduced testcase and converted into one is C code too:
```
struct PixelWeight {
  int m_SrcStart;
  int m_Weights[16];
};
char h;
void f(struct PixelWeight *pPixelWeights) {
int dest_g_m;
long tt;
for (int j = 0; j < 16; j++) {
  int *p = 0;
  if (j < pPixelWeights->m_SrcStart)
p = tt ? >m_Weights[0] : 0;
  int pWeight = *p;
  dest_g_m += pWeight;
}
h = dest_g_m;
}
```

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[dave.anglin at bell dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182

--- Comment #2 from dave.anglin at bell dot net ---
On 2023-12-30 1:30 p.m., pinskia at gcc dot gnu.org wrote:
> I figured it would be PA RISC which would have issues with this too.
It's only an issue on hpux.

[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
 Target||x86_64-linux-gnu
   Target Milestone|--- |14.0
Summary|ice in  |[14 Regression] ice in
   |find_uses_to_rename_use |find_uses_to_rename_use
   Keywords||ice-on-valid-code
  Component|c++ |tree-optimization

[Bug bootstrap/113181] When compiling sanitizer_printf.cc, getting error: multiple definition of ‘enum fsconfig_command’

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113181

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
The issue is libsanitizer does not like newer glibc. So either you disable it
(--disable-libsanitizer) or you manually fix it.

Closing as won't fix as GCC 8.x is no longer supported and there is no further
releases of GCC 8.x, 9.x nor 10.x.

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |14.0
  Component|other   |middle-end

--- Comment #1 from Andrew Pinski  ---
I figured it would be PA RISC which would have issues with this too.

[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467

--- Comment #7 from Andrew Pinski  ---
Anyways gcc should work best with gnu software and cmake is not at all gnu
software and it competes with autoconf and automake which are gnu tools. Cmake
is less portable than the autotools.

[Bug other/113182] New: [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[danglin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182

Bug ID: 113182
   Summary: [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C
-std=c++14 execution test
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: jemarch at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

Executing on host: /home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../xg++
-B/h
ome/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../  exceptions_enabled19821.cc
  -fdiagnostics-plain-output  -nostdinc++
-I/home/dave/gnu/gcc/objdir64/hppa64-h
p-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir
64/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v
3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/
gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0
-Wno-complain-wrong-l
ang  -S -o exceptions_enabled19821.s(timeout = 300)
spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../xg++
-B
/home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../ exceptions_enabled19821.cc
-fdiagnostics-plain-output -nostdinc++
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-h
pux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/
hppa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/l
ibsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu
/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0
-Wno-complain-wrong-lang
 -S -o exceptions_enabled19821.s
PASS: g++.dg/cpp0x/udlit-namespace.C  -std=c++14 (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/experimental/.libs:/home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../..:.:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/experimental/.libs:/home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../..
Execution timeout is: 300
spawn [open ...]
FAIL: g++.dg/cpp0x/udlit-namespace.C  -std=c++14 execution test

Similar fails:
FAIL: g++.dg/cpp0x/udlit-namespace.C  -std=c++17 execution test
FAIL: g++.dg/cpp0x/udlit-namespace.C  -std=c++20 execution test

(gdb) r
Starting program:
/home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/udlit-namespace.exe

Program received signal SIGSEGV, Segmentation fault.
0x83ffbfcd3000 in ?? ()
   from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs/libstdc++.sl.6
(gdb) bt
#0  0x83ffbfcd3000 in ?? ()
   from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs/libstdc++.sl.6
#1  0x83ffbfe5f3f4 in fmodl (x=, y=)
at ../../../../../gcc/libstdc++-v3/src/c++98/math_stubs_long_double.cc:117
Backtrace stopped: Cannot access memory at address 0x3323

This problem was introduced by the following commit:

bash-5.1$ git bisect bad
f31a019d1161ec78846473da743aedf49cca8c27 is the first bad commit
commit f31a019d1161ec78846473da743aedf49cca8c27
Author: Jose E. Marchesi 
Date:   Fri Nov 24 06:30:28 2023 +0100

Emit funcall external declarations only if actually used.

There are many places in GCC where alternative local sequences are
tried in order to determine what is the cheapest or best alternative
to use in the current target.  When any of these sequences involve a
libcall, the current implementation of emit_library_call_value_1
introduce a side-effect consisting on emitting an external declaration
for the funcall (such as __divdi3) which is thus emitted even if the
sequence that does the libcall is not retained.

This is problematic in targets such as BPF, because the kernel loader
chokes on the spurious symbol __divdi3 and makes the resulting BPF
object unloadable.  Note that BPF objects are not linked before being
loaded.

This patch changes asssemble_external_libcall to defer emitting
declarations of external libcall symbols, by saving the call tree
nodes in a temporary list pending_libcall_symbols and letting
process_pending_assembly_externals to emit them only if they have been
referenced.  Solution suggested and sketched by Richard Sandiford.

Regtested in x86_64-linux-gnu.
Tested with host x86_64-linux-gnu with target bpf-unknown-none.

gcc/ChangeLog

PR target/109253
* varasm.cc (pending_libcall_symbols): New variable.
   

[Bug libstdc++/113175] [14 Regression] testsuite/std/ranges/iota/max_size_type.cc 5x times slower

[hp at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Target|mmix-knuth-mmixware |mmix-knuth-mmixware,
   ||x86_64-linux-gnu
Summary|[14 Regression] MMIX:   |[14 Regression]
   |testsuite/std/ranges/iota/m |testsuite/std/ranges/iota/m
   |ax_size_type.cc 5x times|ax_size_type.cc 5x times
   |slower  |slower
  Component|target  |libstdc++

--- Comment #1 from Hans-Peter Nilsson  ---
I'm afraid this isn't target-specific.
I bootstrapped native x86_64-linux-gnu off the both source trees, and ran \time
env LD_LIBRARY_PATH=(long curse) ./max_size_type.exe

r12-2797-g307e0d40367996:
0.32user 0.00system 0:00.32elapsed 99%CPU (0avgtext+0avgdata 2620maxresident)k
0inputs+0outputs (0major+184minor)pagefaults 0swaps

r14-6859-gd1eacedc6d9b:
1.73user 0.00system 0:01.73elapsed 100%CPU (0avgtext+0avgdata 3564maxresident)k
0inputs+0outputs (0major+194minor)pagefaults 0swaps

...which is a factor of about 5.4, consistent with the MMIX observation.
Still unknown whether libstdc++ or code-generator of course, but I'm leaning
towards the latter, for the same reasons as in the precious comment.  Maybe the
test-case triggers peculiar details.

[Bug target/108640] ICE compiling busybox for m68k in change_address_1, at emit-rtl.cc:2283

[mikpelinux at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640

--- Comment #6 from Mikael Pettersson  ---
Created attachment 56965
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56965=edit
Preliminary patch, only tested on the test case so far.

[Bug target/108640] ICE compiling busybox for m68k in change_address_1, at emit-rtl.cc:2283

[mikpelinux at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #5 from Mikael Pettersson  ---
Further reduced test case:

> cat pr108640v2.i 
int x;
void iorsi3(void) { x |= (1 << 16); }
> gcc/xgcc -Bgcc -O1 -S pr108640v2.i
during RTL pass: final
../pr108640v2.i: In function 'iorsi3':
../pr108640v2.i:2:38: internal compiler error: in change_address_1, at
emit-rtl.cc:2299
2 | void iorsi3(void) { x |=  (1 << 16); }
  |  ^
0x40dc15 change_address_1
/mnt/scratch/other/mikpe-gcc.git/gcc/emit-rtl.cc:2299
0x668f79 adjust_address_1(rtx_def*, machine_mode, poly_int<1u, long>, int, int,
int, poly_int<1u, long>)
/mnt/scratch/other/mikpe-gcc.git/gcc/emit-rtl.cc:2433
0xd3ae93 output_iorsi3(rtx_def**)
/mnt/scratch/other/mikpe-gcc.git/gcc/config/m68k/m68k.cc:5513
...

In output_iorsi3() the m68k backend wants to change "x |= (1 << 16)" to
"*(((char *) ) + 1) |= 1". It calls adjust_address() to offset x by 1, but it
keeps the mode as SImode (4-byte). This address expr reaches
m68k_legitimate_constant_address_p(). On the uclinux target
M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P is 1 so it calls
offset_within_block_p(x, 4) which fails because that is out of bounds, causing
the assert in change_address_1() to fail.

The other m68k targets don't define M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P so
this works there.

The bug is that the adjust_address() call should have specified QImode as mode
since the resulting address is to be used in a 1-byte RMW operation. It gets it
right in the nearby code which rewrites to a HImode (2-byte) RMW.

output_andsi3() and output_xorsi3() have the exact same bug.

I have a patch.

[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors

[jpakkane at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467

--- Comment #6 from jpakkane at gmail dot com ---
According to C++ foundation's developer survey [1] the most popular build
system for C++ projects is CMake by quite a massive margin. Based on personal
experience almost everybody uses CMake's Ninja backend rather than the Make
backend on unixy platforms simply because it is so much faster 

CMake does not support modules in the Make backend [2]. Some people even claim
that properly supporting Make to build C++ modules is not possible if you want
to make it actually production quality and reliable.

Modules are very much a forward looking thing. People who still use plain Make
are most likely doing so on legacy projects that can not adopt modules in the
near future in any case.

Thus it would seem that the most probable ways C++ modules are going to be used
are a) VS projects b) whatever Xcode ends up implementing c) Ninja files.


[1] https://isocpp.org/files/papers/CppDevSurvey-2023-summary.pdf

[2] https://cmake.org/cmake/help/latest/manual/cmake-cxxmodules.7.html

[Bug middle-end/112662] missed-optimization: loop increment until wrap

[goon.pri.low at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112662

--- Comment #2 from gooncreeper  ---
I believe I got my initial optimized function wrong, it should actually be this


unsigned opt(unsigned a) {
if (++a > 999) a = 0;
return a;
}

opt:
lea eax, [rdi+1]
xor edx, edx
cmp eax, 1000
cmovnb  eax, edx
ret

Which is a bit more clear also.

[Bug bootstrap/113174] gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)

[gcc at octaforge dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174

--- Comment #7 from Daniel Kolesa  ---
I just tested this on big-endian ppc64 targeting power4/ppc970; I was able to
successfully bootstrap the compiler. It seems this is really specific to LE
after all (which makes sense I suppose, considering the affected code appears
to be related to VSX?)

[Bug bootstrap/113181] New: When compiling sanitizer_printf.cc, getting error: multiple definition of ‘enum fsconfig_command’

[eyalroz1 at gmx dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113181

Bug ID: 113181
   Summary: When compiling sanitizer_printf.cc, getting error:
multiple definition of ‘enum fsconfig_command’
   Product: gcc
   Version: 8.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eyalroz1 at gmx dot com
  Target Milestone: ---

I'm building GCC 8.5.0 on a Devuan GNU/Linux Excalibur machine (~= Debian
Trixie).

I've encountered, and worked around, the libstdc++ mixup bug (bug 87858), so
now I have my distribution's static 32-bit libstdc++ installed. Anyway, with a
build configured like so:

./configure --disable-bootstrap --enable-languages=c,c++

I get, at some point, the following warning + (unrelated?) error:


libtool: compile:  /usr/local/src/gcc-8.5.0/host-x86_64-pc-linux-gnu/gcc/xgcc
-shared-libgcc -B/usr/local/src/gcc-8.5.0/host-x86_64-pc-linux-gnu/gcc
-nostdinc++ -L/usr/local/src/gcc-8.5.0/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/usr/local/src/gcc-8.5.0/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/usr/local/src/gcc-8.5.0/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
-I../../.././libsanitizer/sanitizer_common -I.. -I
../../.././libsanitizer/include -isystem ../../.././libsanitizer/include/system
-Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC
-fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables
-fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/x86_64-pc-linux-gnu
-I../../.././libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11
-DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I
../../.././libsanitizer/../libbacktrace -I ../libbacktrace -I
../../.././libsanitizer/../include -include
../../.././libsanitizer/libbacktrace/backtrace-rename.h -g -O2 -D_GNU_SOURCE
-MT sanitizer_printf.lo -MD -MP -MF .deps/sanitizer_printf.Tpo -c
../../.././libsanitizer/sanitizer_common/sanitizer_printf.cc  -fPIC -DPIC -o
.libs/sanitizer_printf.o
In file included from
../../.././libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:160:
/usr/include/linux/cyclades.h:6:2: warning: #warning "Support for features
provided by this header has been removed" [-Wcpp]
 #warning "Support for features provided by this header has been removed"
  ^~~
/usr/include/linux/cyclades.h:7:2: warning: #warning "Please consider updating
your code" [-Wcpp]
 #warning "Please consider updating your code"
  ^~~
make[6]: Entering directory
'/usr/local/src/gcc-8.5.0/x86_64-pc-linux-gnu/32/libitm'
make  all-recursive
In file included from /usr/include/linux/fs.h:19,
 from
../../.././libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:68:
/usr/include/linux/mount.h:96:6: error: multiple definition of ‘enum
fsconfig_command’
 enum fsconfig_command {
  ^~~~
In file included from
../../.././libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:55:
/usr/local/src/gcc-8.5.0/host-x86_64-pc-linux-gnu/gcc/include-fixed/sys/mount.h:249:6:
note: previous definition here
 enum fsconfig_command
  ^~~~
In file included from /usr/include/linux/fs.h:19,
 from
../../.././libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:68:
/usr/include/linux/mount.h:130:8: error: redefinition of ‘struct mount_attr’
 struct mount_attr {
^~
make[7]: Entering directory
'/usr/local/src/gcc-8.5.0/x86_64-pc-linux-gnu/32/libitm'
In file included from
../../.././libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:55:
/usr/local/src/gcc-8.5.0/host-x86_64-pc-linux-gnu/gcc/include-fixed/sys/mount.h:219:8:
note: previous definition of ‘struct mount_attr’
 struct mount_attr
^~
Making all in testsuite
make[8]: Entering directory
'/usr/local/src/gcc-8.5.0/x86_64-pc-linux-gnu/32/libitm/testsuite'
make[8]: Nothing to be done for 'all'.
make[8]: Leaving directory
'/usr/local/src/gcc-8.5.0/x86_64-pc-linux-gnu/32/libitm/testsuite'
make[8]: Entering directory
'/usr/local/src/gcc-8.5.0/x86_64-pc-linux-gnu/32/libitm'
make[4]: *** [Makefile:539: sanitizer_platform_limits_posix.lo] Error 1

[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467

--- Comment #5 from Andrew Pinski  ---
(In reply to jpakkane from comment #4)
> As a build system developer I'd like that the most common usage (i.e. using
> Ninja) would be the default and work without extra compiler flags.

Ninja is not the most common usage. GNU make still is the most common usage for
build systems out there. Especially since gcc should work best with the gnu
software first.

[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors

[jpakkane at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467

--- Comment #4 from jpakkane at gmail dot com ---
As a build system developer I'd like that the most common usage (i.e. using
Ninja) would be the default and work without extra compiler flags.

[Bug target/113180] New: MIPS: bitops on an long long struct uses ins instead dins

[syq at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113180

Bug ID: 113180
   Summary: MIPS: bitops on an long long struct uses ins instead
dins
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: syq at gcc dot gnu.org
  Target Milestone: ---

```
struct yy {
int x:32;
int a:12;
int b:12;
int c:4;
int d:4;
};

struct yy xx (struct yy a, long long b) {
a.d = b;
return a;
}
```

One DINS is enough for this ops, while currently the result is:

```
dsra$2,$4,32
daddiu  $sp,$sp,-32
ins $2,$5,28,4
sd  $4,16($sp)
sw  $2,20($sp)
ld  $3,16($sp)
move$2,$0
sll $4,$3,0
dext$4,$4,0,32
dins$2,$4,0,32
dsrl$3,$3,32
dins$2,$3,32,32
jr  $31
daddiu  $sp,$sp,32
```

[Bug libstdc++/113160] Const valarray (g)slice and indirect_array fail to match valarray in template functions

[yihuajack at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113160

--- Comment #5 from Yihua Liu  ---
I see. Previous cppreference notes were misleading. Is there any plan to
support returning a std::valarray or matching a std::valarray? For example, if
it returns a std::valarray, it can be directly put in a pipe syntax.

[Bug tree-optimization/113104] Suboptimal loop-based slp node splicing across iterations

[rsandifo at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113104

Richard Sandiford  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-12-30
 Ever confirmed|0   |1
 CC||rsandifo at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org

--- Comment #4 from Richard Sandiford  ---
FWIW, we do get the desired code with -march=armv8-a+sve (even though the test
doesn't use SVE).  This is because of:

  /* Consider enabling VECT_COMPARE_COSTS for SVE, both so that we
 can compare SVE against Advanced SIMD and so that we can compare
 multiple SVE vectorization approaches against each other.  There's
 not really any point doing this for Advanced SIMD only, since the
 first mode that works should always be the best.  */
  if (TARGET_SVE && aarch64_sve_compare_costs)
flags |= VECT_COMPARE_COSTS;

The testcase in this PR is a counterexample to the claim in the final sentence.
 I think the comment might predate significant support for mixed-sized Advanced
SIMD vectorisation.

If we enable SVE (or uncomment the "if" line), the costs are 13 units per
vector iteration for 128-bit vectors and 4 units per vector iteration for
64-bit vectors (so 8 units per 128 bits on a parity basis).  The 64-bit version
is therefore seen as significantly cheaper and is chosen ahead of the 128-bit
version.

I think this PR is enough proof that we should enable VECT_COMPARE_COSTS even
without SVE.  Assigning to myself for that.

[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858

Xi Ruoyao  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||xry111 at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-12-30

--- Comment #14 from Xi Ruoyao  ---
Confirm as this has been asked via gcc-help multiple times.

A possible work around is to install the static libstdc++ (libstdc++.a)
provided by the distro.  But this is not documented anywhere and it's still
just a work around, not a fix.

Note that patches should be sent to gcc-patc...@gcc.gnu.org instead of (or in
addition to) posting here.  The patches in bugzilla generally do not get any
review seriously.

[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858

Xi Ruoyao  changed:

   What|Removed |Added

 CC||eyalroz1 at gmx dot com

--- Comment #13 from Xi Ruoyao  ---
*** Bug 113177 has been marked as a duplicate of this bug. ***

[Bug other/113177] GCC 8.5.0 build with libstdcxx gets library versions mixed up

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113177

Xi Ruoyao  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Xi Ruoyao  ---
Dup.

*** This bug has been marked as a duplicate of bug 87858 ***

[Bug other/113177] GCC 8.5.0 build with libstdcxx gets library versions mixed up

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113177

Xi Ruoyao  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-30
 CC||xry111 at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Xi Ruoyao  ---
Can you try installing the static library libstdc++.a provided by Devuan?  The
package containing it should be named "libstdc++-dev" or something.

[Bug target/113179] New: MIPS

[syq at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179

Bug ID: 113179
   Summary: MIPS
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: syq at gcc dot gnu.org
  Target Milestone: ---

```
struct xx {
int a:4;
int b:24;
int c:3;
int d:1;
};

void xx (struct xx *a, long long b) {
a->d = b;
}
```

When this code is built on -mabi=64, it generates asm like this:

```
lw  $2,0($4)
ins $2,$5,31,1
jr  $31
sw  $2,0($4)
```

Since the argument B is `long long`, we cannot be sure that it is well
sign-extended, while INS asks for it:

```
If either GPR rs or GPR rt does not contain sign-extended 32-bit values (bits
63..31 equal), then the result of the operation is UNPREDICTABLE.
```

[Bug c++/113178] New: ice in find_uses_to_rename_use

[dcb314 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178

Bug ID: 113178
   Summary: ice in find_uses_to_rename_use
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

This C++ source code:

struct PixelWeight {
  int m_SrcStart;
  int m_Weights[];
};
struct CWeightTable {
  int *GetValueFromPixelWeight(PixelWeight *, int) const;
};
char ContinueStretchHorz_dest_scan;
struct CStretchEngine {
  bool ContinueStretchHorz();
  CWeightTable m_WeightTable;
};
int *CWeightTable::GetValueFromPixelWeight(PixelWeight *pWeight,
   int index) const {
  long __trans_tmp_1;
  if (index < pWeight->m_SrcStart)
return __trans_tmp_1 ? >m_Weights[pWeight->m_SrcStart] : nullptr;
}
bool CStretchEngine::ContinueStretchHorz() {
  {
PixelWeight pPixelWeights;
int dest_g_m;
for (int j; j; j++) {
  int pWeight = *m_WeightTable.GetValueFromPixelWeight(, j);
  dest_g_m += pWeight;
}
ContinueStretchHorz_dest_scan = dest_g_m;
  }
}

when compiled by recent gcc trunk, does this:

cvise $ ~/gcc/results.20231227.asan.ubsan/bin/g++ -c -O3 -w  bug995.cc
cvise $ ~/gcc/results.20231227.asan.ubsan/bin/g++ -c -O3 -w -march=znver3
bug995.cc
during GIMPLE pass: vect
bug995.cc: In member function ‘bool CStretchEngine::ContinueStretchHorz()’:
bug995.cc:19:6: internal compiler error: Segmentation fault
   19 | bool CStretchEngine::ContinueStretchHorz() {
  |  ^~
0x11e1b39 crash_signal(int)
../../trunk.20210101/gcc/toplev.cc:316
0x1381b98 find_uses_to_rename_use(basic_block_def*, tree_node*, bitmap_head**,
bitmap_head*)
../../trunk.20210101/gcc/tree-ssa-loop-manip.cc:414

[Bug other/113177] New: GCC 8.5.0 build with libstdcxx gets library versions mixed up

[eyalroz1 at gmx dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113177

Bug ID: 113177
   Summary: GCC 8.5.0 build with libstdcxx gets library versions
mixed up
   Product: gcc
   Version: 8.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eyalroz1 at gmx dot com
  Target Milestone: ---

If I try to build GCC versions 8.5.0, or 6.5.0, on a recent GNU/Linux
distribution, e.g. Devuan Excalibur (~= Debian Trixie), with the following
config:

./configure  --enable-languages=c,c++

at some point in the build, I get:

libstdc++.so.6: version `GLIBCXX_3.4.30' not found

and it seems like the build either tries to use the host system's libstdc++, or
otherwise mixes up the versions of things it's using.

[Bug other/113147] Building a crosscompiler fails under MigW-W64/MSYS2 @ Windows 10

[jdx at o2 dot pl via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113147

--- Comment #2 from Jan Dubiec  ---
(In reply to Andrew Pinski from comment #1)
> Don't use `--disable-host-shared` basically.

OK, removal of this option seems to solve the problem, but... I had an
impression that the above set of options (including "--disable-host-shared")
used to work for me quite well earlier this year. I have checked out 13.1.0
(commit cc035c5d) and it has been built without problems. So, taking into
account your words, there used to be an issue then, or there is an issue *now*.

[Bug target/110625] [14 Regression][AArch64] Vect: SLP fails to vectorize a loop as the reduction_latency calculated by new costs is too large

[hliu at amperecomputing dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110625

--- Comment #26 from Hao Liu  ---
But for now, the patch should fix the regression.(In reply to Tamar Christina
from comment #25)
> Is still pretty inefficient due to all the extends.  If we generate better
> code here this may tip the scale back to vector.  But for now, the patch
> should fix the regression.

That's great. Thanks a lot!