[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #57233|0   |1
is obsolete||

--- Comment #12 from H.J. Lu  ---
Created attachment 57237
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57237&action=edit
An updated patch

[Bug libgomp/113627] Detached tasks released without call to omp_fulfill_event

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

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

--- Comment #1 from Andrew Pinski  ---
My gut feeling is there is some variable is not being treated as atomic. 

That is there is a race condition somewhere. I am not saying you example code
has a race condition in it but rather that seems like the cause of the bug.

[Bug preprocessor/105608] [11/12/13/14 Regression] ICE: in linemap_add with a really long defined macro on the command line r11-338-g2a0225e47868fbfc

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Lewis Hyatt :

https://gcc.gnu.org/g:5200ef26ac1771a75596394c20c5f1a348694d5e

commit r14-8465-g5200ef26ac1771a75596394c20c5f1a348694d5e
Author: Lewis Hyatt 
Date:   Tue Dec 5 11:33:39 2023 -0500

c-family: Fix ICE with large column number after restoring a PCH [PR105608]

Users are allowed to define macros prior to restoring a precompiled header
file, as long as those macros are not defined (or are defined identically)
in the PCH.  However, the PCH restoration process destroys all the macro
definitions, so libcpp has to record them before restoring the PCH and then
redefine them afterward.

This process does not currently assign great locations to the macros after
redefining them. Some work is needed to also remember the original
locations
and get the line_maps instance in the right state (since, like all other
data structures, the line_maps instance is also reset after restoring a
PCH).
The new testcase line-map-3.C contains XFAILed examples where the locations
are wrong.

This patch addresses a more pressing issue, which is that we ICE in some
cases since GCC 11, hitting an assert in line-maps.cc. It happens if the
first line encountered after the PCH restore requires an LC_RENAME map,
such
as will happen if the line is sufficiently long.  This is much easier to
fix, since we just need to call linemap_line_start before asking libcpp to
redefine the stored macros, instead of afterward, to avoid the unexpected
need for an LC_RENAME before an LC_ENTER has been seen.

gcc/c-family/ChangeLog:

PR preprocessor/105608
* c-pch.cc (c_common_read_pch): Start a new line map before asking
libcpp to restore macros defined prior to reading the PCH, instead
of afterward.

gcc/testsuite/ChangeLog:

PR preprocessor/105608
* g++.dg/pch/line-map-1.C: New test.
* g++.dg/pch/line-map-1.Hs: New test.
* g++.dg/pch/line-map-2.C: New test.
* g++.dg/pch/line-map-2.Hs: New test.
* g++.dg/pch/line-map-3.C: New test.
* g++.dg/pch/line-map-3.Hs: New test.

[Bug libgomp/113627] New: Detached tasks released without call to omp_fulfill_event

[schuchart at icl dot utk.edu via Gcc-bugs]

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

Bug ID: 113627
   Summary: Detached tasks released without call to
omp_fulfill_event
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: schuchart at icl dot utk.edu
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57236
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57236&action=edit
Pre-processed reproducer

We saw a problem in a benchmark OpenMP application that executes a loop in
which two tasks are created per iteration. Each pair of tasks in an iteration
is chained through a dependency on an array element and the first task is being
detached. We found that the second (dependent) task is executed after the
dependee is executed even though the even has not been fulfilled.

I'm attaching the preprocessed sources of a reproducer (that's as small as I
could get, apologies if it's still too complex). If the execution is correct
the program will hang because none of the events are fulfilled. If the
execution is incorrect an assert will trigger because the second task is
executed and the array value is not set properly (it is set by an outside
entity in our benchmark before the event is released). It is important to note
that the issue occurs only with more than 64 iterations when running on a
single thread. Starting from 65 iterations the dependent task is executed
without the event being fulfilled. If OMP_NUM_THREADS is set to 2 the crossover
is 128/129 iterations.

To build the example:

$ gcc -g -O0 -fopenmp example_detach.c -o example

To run the example (will hang due to the event not being fulfilled):

$ OMP_NUM_THREADS=1 ./example -t 64

To run the example and trigger the assert because the dependent task is
executed prematurely:

$ OMP_NUM_THREADS=1 ./example -t 64


I'm running on an AMD Epyc Rome machine on a GNU/Linux system. I see this
behavior with a system-wide gcc 12.2.0 installed through spack and a gcc 13.2.0
I built myself using this configure:

$ ../configure --prefix=$INSTALLDIR --enable-languages=c --disable-multilib
--with-pic --disable-bootstrap

Please let me know if I can provide anything else.

[Bug tree-optimization/113622] [11/12/13/14 Regression] ICE with vectors in named registers

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||chenglulu at loongson dot cn

--- Comment #7 from Andrew Pinski  ---
*** Bug 113626 has been marked as a duplicate of this bug. ***

[Bug c/113626] The r14-8450 commit causes the loongarch [x]vfcmp-{d/f}.c test case to fail

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
Dup.

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

[Bug c/113626] New: The r14-8450 commit causes the loongarch [x]vfcmp-{d/f}.c test case to fail

[chenglulu at loongson dot cn via Gcc-bugs]

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

Bug ID: 113626
   Summary: The r14-8450 commit causes the loongarch
[x]vfcmp-{d/f}.c test case to fail
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chenglulu at loongson dot cn
  Target Milestone: ---

The r14-8450 commit causes the loongarch [x]vfcmp-{d/f}.c test case to fail

[Bug rtl-optimization/113533] [14 Regression] Code generation regression after change for pr111267

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

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

--- Comment #13 from Oleg Endo  ---
(In reply to Roger Sayle from comment #12)
> It should be mentioned that the fwprop fix for PR11267 also resolved several
> FAILs in gcc.target/sh/pr59533.c.  I mention this as tweaking the cost of
> SIGN_EXTEND in sh_rtx_costs interacts with the (redundant) extensions
> mentioned in the initial description of PR59533.

Good to know, thanks!  I'll try to look into it.


> It's still not entirely clear to me why we would want to squash the costs
> of addresses to 0 when optimizing for size?  What does effect does it have
> on the generated code?  I can't imagine how it would be possibly making
> any smaller code?

Roger, could you please comment on that?  I'm still somewhat puzzled...

[Bug target/113625] New: Interesting behavior with and without -mcpu=generic

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

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

Bug ID: 113625
   Summary: Interesting behavior with and without -mcpu=generic
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Take:
```
void f(unsigned short * __restrict a, long long * __restrict b)
{
int t = 0;
t += a[0];
t += a[1];
t += a[2];
t += a[3];
b[0] = t;
}
```
Compile this with `-O3 -fno-vect-cost-model` (no extra configure options), GCC
produces:
```
f:
ldr d31, [x0]
sub sp, sp, #16
uaddlv  s31, v31.4h
str s31, [sp, 12]
ldrsw   x0, [sp, 12]
str x0, [x1]
add sp, sp, 16
```

And then add -mcpu=generic (or -mtune=generic), GCC produces:
```
f:
ldr d31, [x0]
uaddlv  s31, v31.4h
fmovw0, s31
sxtwx0, w0
str x0, [x1]
ret
```

I would have expected -mtune=generic be the same as without it but nope.

Maybe I don't understand what the default tuning settings are now vs what
-mtune=generic is supposed to do but also it is not obvious from documentation
either.  So this is at min a documentation issue.

[Bug fortran/104908] [11/12/13/14 Regression] incorrect Fortran out-of-bound runtime error.

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #8 from Jerry DeLisle  ---
(In reply to anlauf from comment #7)
> (In reply to anlauf from comment #6)
> > This is currently regtesting.
> 
> Regtesting succeeded.

Simple enough to just commit.

[Bug c++/113624] New: FAIL: g++.dg/ext/dllimport4.C, ICE on windows targets

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 113624
   Summary: FAIL: g++.dg/ext/dllimport4.C, ICE on windows targets
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

Created attachment 57235
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57235&action=edit
output of -freport-bug

A test from the testsuite is failing for extra errors, but it also ICE's, so
this PR is to document the ICE.  This is the reduced dllimport4.C:

void faz() {
  __attribute__((dllimport)) int faa = 1;
  faa++;
}


$ x86_64-w64-mingw32-g++ -c dllimport4.C 
dllimport4.C: In function 'void faz()':
dllimport4.C:2:34: error: variable 'faa' definition is marked dllimport
2 |   __attribute__((dllimport)) int faa = 1;
  |  ^~~
dllimport4.C:4:1: internal compiler error: Segmentation fault
4 | }
  | ^
0x138a72f crash_signal
../../gcc/toplev.cc:317
0xb1287b cp_genericize_r
../../gcc/cp/cp-gimplify.cc:1620
0x16bddbc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.cc:11420
0xdae64f c_genericize_control_stmt(tree_node**, int*, void*, tree_node*
(*)(tree_node**, int*, void*), tree_node* (*)(tree_node**, int*, tree_node*
(*)(tree_node**, int*, void*), void*, hash_set >*))
../../gcc/c-family/c-gimplify.cc:557
0xb12aab cp_genericize_r
../../gcc/cp/cp-gimplify.cc:2225
0x16bddbc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.cc:11420
0xb13e9f cp_genericize_r
../../gcc/cp/cp-gimplify.cc:1836
0x16bddbc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.cc:11420
0xb12091 cp_genericize_tree
../../gcc/cp/cp-gimplify.cc:2258
0xb12409 cp_genericize(tree_node*)
../../gcc/cp/cp-gimplify.cc:2400
0xb62716 finish_function(bool)
../../gcc/cp/decl.cc:18800
0xc695b7 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.cc:32699
0xc6a74e cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.cc:32613
0xc6a74e cp_parser_init_declarator
../../gcc/cp/parser.cc:23356
0xc3dcd4 cp_parser_simple_declaration
../../gcc/cp/parser.cc:15890
0xc770ba cp_parser_declaration
../../gcc/cp/parser.cc:15563
0xc77f9a cp_parser_toplevel_declaration
../../gcc/cp/parser.cc:15584
0xc77f9a cp_parser_translation_unit
../../gcc/cp/parser.cc:5276
0xc77f9a c_parse_file()
../../gcc/cp/parser.cc:51174
0xdc6531 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1301
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.


$ x86_64-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/tmp/rt/mingw14/bin/../libexec/gcc/x86_64-w64-mingw32/14.0.1/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --disable-multilib --disable-nls
--target=x86_64-w64-mingw32 --prefix=/tmp/rt/mingw14
--with-sysroot=/tmp/rt/mingw14
--enable-languages=c,ada,c++,d,fortran,lto,m2,objc,obj-c++,rust
Thread model: win32
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240126 (experimental) (GCC)

[Bug testsuite/109705] [14 regression] gcc.dg/vect/pr25413a.c fails after r14-333-g6d4b59a9356ac4

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

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

--- Comment #21 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #20)
> vect_long_mult is wrong again for powerpc (32bit).
> 
> vect_long_mult should return true for ILP32 powerpc still. Because long is
> 32bit there ...

See https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644098.html for a
patch to test. I cannot test it fully; I tried doing a simple cross build but
that failed.

[Bug c++/103524] [meta-bug] modules issue

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 113580, which changed state.

Bug 113580 Summary: -Wunused-parameter in template imported from module causes 
segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113580

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug c++/113580] -Wunused-parameter in template imported from module causes segmentation fault

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

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

Nathaniel Shead  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Blocks||103524
 CC||nshead at gcc dot gnu.org
   Target Milestone|--- |14.0
   Assignee|unassigned at gcc dot gnu.org  |nshead at gcc dot 
gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Nathaniel Shead  ---
Fixed for GCC 14.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue

[Bug testsuite/109705] [14 regression] gcc.dg/vect/pr25413a.c fails after r14-333-g6d4b59a9356ac4

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL|https://gcc.gnu.org/piperma |
   |il/gcc-patches/2024-January |
   |/644004.html|
   Keywords|patch   |

--- Comment #20 from Andrew Pinski  ---
vect_long_mult is wrong again for powerpc (32bit).

vect_long_mult should return true for ILP32 powerpc still. Because long is
32bit there ...

[Bug c++/113580] -Wunused-parameter in template imported from module causes segmentation fault

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

https://gcc.gnu.org/g:ec57d183d35412aa5e0bcd7a448ccb75a4e1eab7

commit r14-8462-gec57d183d35412aa5e0bcd7a448ccb75a4e1eab7
Author: Nathaniel Shead 
Date:   Fri Jan 26 16:55:52 2024 +1100

c++: Stream additional fields for DECL_STRUCT_FUNCTION [PR113580]

Currently the DECL_STRUCT_FUNCTION for a declaration is always
reconstructed from scratch. This causes issues though, as some fields
used by other parts of the compiler (in this case, specifically
'function_{start,end}_locus') are then not correctly initialised. This
patch makes sure that these fields are also read and written.

PR c++/113580

gcc/cp/ChangeLog:

* module.cc (struct post_process_data): Create.
(trees_in::post_decls): Use.
(trees_in::post_process): Return entire vector at once.
Change overload to take post_process_data instead of tree.
(trees_out::write_function_def): Write needed flags from
DECL_STRUCT_FUNCTION.
(trees_in::read_function_def): Read them and pass to
post_process.
(module_state::read_cluster): Write flags into cfun.

gcc/testsuite/ChangeLog:

* g++.dg/modules/pr113580_a.C: New test.
* g++.dg/modules/pr113580_b.C: New test.

Signed-off-by: Nathaniel Shead 

[Bug rtl-optimization/105314] [12 Regression] ifcvt regression in noce_try_store_flag_mask

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

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Maciej W. Rozycki :

https://gcc.gnu.org/g:3e3b9b708d390074f7825401b808e0ed41552c1d

commit r14-8459-g3e3b9b708d390074f7825401b808e0ed41552c1d
Author: Maciej W. Rozycki 
Date:   Fri Jan 26 21:47:40 2024 +

RISC-V/testsuite: Also verify if-conversion runs for pr105314.c

Verify that if-conversion succeeded through noce_try_store_flag_mask, as
per PR rtl-optimization/105314, tightening the test case and making it
explicit.

gcc/testsuite/
* gcc.target/riscv/pr105314.c: Scan the RTL "ce1" pass too.

[Bug other/113575] [14 Regression] memory hog building insn-opinit.o (i686-linux-gnu -> riscv64-linux-gnu)

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

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

--- Comment #15 from GCC Commits  ---
The master branch has been updated by Robin Dapp :

https://gcc.gnu.org/g:861997a9c7088da25ed4dc0bd339060ca063514f

commit r14-8457-g861997a9c7088da25ed4dc0bd339060ca063514f
Author: Robin Dapp 
Date:   Wed Jan 24 17:28:31 2024 +0100

genopinit: Split init_all_optabs [PR113575].

init_all_optabs initializes > 1 patterns for riscv targets.  This
leads to pathological situations in dataflow analysis (which can occur
with many adjacent stores).
To alleviate this this patch makes genopinit split the init_all_optabs
function into several init_optabs_xx functions that each initialize 1000
patterns.

With this change insn-opinit.cc's compilation time is reduced from 4+
minutes to 1:30 and memory consumption decreases from 1.2G to 630M.

gcc/ChangeLog:

PR other/113575

* genopinit.cc (main): Split init_all_optabs into functions
of 1000 patterns each.

[Bug target/113623] [14 Regression] ICE in aarch64_pair_mem_from_base since r14-6605

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

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

Alex Coplan  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Known to fail||14.0
 Target||aarch64-*-*
   Assignee|unassigned at gcc dot gnu.org  |acoplan at gcc dot 
gnu.org

--- Comment #2 from Alex Coplan  ---
Confirmed, mine.

[Bug testsuite/109705] [14 regression] gcc.dg/vect/pr25413a.c fails after r14-333-g6d4b59a9356ac4

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

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

--- Comment #19 from Andrew Pinski  ---
(In reply to seurer from comment #17)
> This still fails on power.

Just so I can start to trying to reproduce it, how was your compiler
configured? I want to make sure the testsuite choices are done correctly.

[Bug testsuite/109705] [14 regression] gcc.dg/vect/pr25413a.c fails after r14-333-g6d4b59a9356ac4

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

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

--- Comment #18 from Andrew Pinski  ---
Hmm. this loop should almost definitely get vectorized if vect_double is true:
  for (i=0;ic+i) = num__infty;

I wonder why it is not on powerpc.

vect_double for powerpc does:
 || ([istarget powerpc*-*-*] && [check_vsx_hw_available])

[Bug rtl-optimization/113533] [14 Regression] Code generation regression after change for pr111267

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=59533

--- Comment #12 from Roger Sayle  ---
It should be mentioned that the fwprop fix for PR11267 also resolved several
FAILs in gcc.target/sh/pr59533.c.  I mention this as tweaking the cost of
SIGN_EXTEND in sh_rtx_costs interacts with the (redundant) extensions mentioned
in the initial description of PR59533.

[Bug testsuite/109705] [14 regression] gcc.dg/vect/pr25413a.c fails after r14-333-g6d4b59a9356ac4

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #17 from seurer at gcc dot gnu.org ---
This still fails on power.

Previously it was:

g:d40b3c1e439db05c835b6bd4fd5bba58fda71dd6, r14-8442-gd40b3c1e439db0
make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
vect.exp=gcc.dg/vect/pr25413a.c"
FAIL: gcc.dg/vect/pr25413a.c scan-tree-dump-times vect "vectorized 2 loops" 1
FAIL: gcc.dg/vect/pr25413a.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"vectorized 2 loops" 1


Now it is:

g:bfd6b36f08021f023e0e9223f5aea315b74a5c56, r14-8443-gbfd6b36f08021f
make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
vect.exp=gcc.dg/vect/pr25413a.c"
FAIL: gcc.dg/vect/pr25413a.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/pr25413a.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"vectorized 1 loops" 1

[Bug target/113623] [14 Regression] ICE in aarch64_pair_mem_from_base since r14-6605

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[14 Regression] ICE in  |[14 Regression] ICE in
   |aarch64_pair_mem_from_base  |aarch64_pair_mem_from_base
   ||since r14-6605

--- Comment #1 from Jakub Jelinek  ---
Started with r14-6605-gc0911c6b357ba916ae24926b7d8b9ca35234f33c
-O3 -mno-early-ldp-fusion fixes it.
Obviously in the range when these options were disabled by default it needs -O3
-mearly-ldp-fusion to reproduce.

[Bug fortran/104908] [11/12/13/14 Regression] incorrect Fortran out-of-bound runtime error.

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

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #6)
> This is currently regtesting.

Regtesting succeeded.

[Bug fortran/113621] New test case gfortran.dg/optional_absent_10.f90 from r14-8400-g186ae6d2cb93ad fails

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
I guess the following reduced testcase shows the same crash:

program test
  implicit none
  character(4) :: c(7) = "*"
  call three_val (c)
contains
  subroutine three_val (i, j)
character(4), intent(in)   :: i(7)
character(4), value,  optional :: j
if (present (j)) stop 7
call four (i, j)
call four_val (i, j)
  end

  elemental subroutine four (i, j)
character(4), intent(in)   :: i
character(4), intent(in), optional :: j
if (present (j)) error stop 13
  end

  elemental subroutine four_val (i, j)
character(4), intent(in)   :: i
character(4), value,  optional :: j
if (present (j)) error stop 14
  end
end

[Bug tree-optimization/113622] [11/12/13/14 Regression] ICE with vectors in named registers

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

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

--- Comment #6 from Andrew Pinski  ---
The assert by the way:
```
  if (!MEM_P (to_rtx))
{
  /* We can get constant negative offsets into arrays with broken
 user code.  Translate this to a trap instead of ICEing.  */
  gcc_assert (TREE_CODE (offset) == INTEGER_CST);
  expand_builtin_trap ();
  to_rtx = gen_rtx_MEM (BLKmode, const0_rtx);
}

```

Yes this is obvious is wrong when used with global registers ...

[Bug target/113623] [14 Regression] ICE in aarch64_pair_mem_from_base

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||acoplan at gcc dot gnu.org
   Priority|P3  |P1
   Last reconfirmed||2024-01-26
 Ever confirmed|0   |1
   Target Milestone|--- |14.0

[Bug target/113623] New: [14 Regression] ICE in aarch64_pair_mem_from_base

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

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

Bug ID: 113623
   Summary: [14 Regression] ICE in aarch64_pair_mem_from_base
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57234
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57234&action=edit
rh2260560.i

The following testcase ICEs at -O3:
./cc1 -quiet -nostdinc -O3 rh2260560.i -W -Wall
during RTL pass: ldp_fusion
rh2260560.i: In function ‘qux’:
rh2260560.i:137:1: internal compiler error: in aarch64_pair_mem_from_base, at
config/aarch64/aarch64.cc:8257
  137 | }
  | ^
0x1bc8c3e aarch64_pair_mem_from_base
../../gcc/config/aarch64/aarch64.cc:8257
0x1bc8cee aarch64_gen_load_pair(rtx_def*, rtx_def*, rtx_def*, rtx_code)
../../gcc/config/aarch64/aarch64.cc:8285
0x1dc2d50 ldp_bb_info::fuse_pair(bool, unsigned int, int, rtl_ssa::insn_info*,
rtl_ssa::insn_info*, base_cand&, rtl_ssa::insn_range_info const&)
../../gcc/config/aarch64/aarch64-ldp-fusion.cc:1883
0x1dc539e ldp_bb_info::try_fuse_pair(bool, unsigned int, rtl_ssa::insn_info*,
rtl_ssa::insn_info*)
../../gcc/config/aarch64/aarch64-ldp-fusion.cc:2782
0x1dc5627 ldp_bb_info::merge_pairs(std::__cxx11::list >&, std::__cxx11::list >&, bool, unsigned int)
../../gcc/config/aarch64/aarch64-ldp-fusion.cc:2871
0x1dc5816 ldp_bb_info::transform_for_base(int, access_group&)
../../gcc/config/aarch64/aarch64-ldp-fusion.cc:2904
0x1dc801c void
ldp_bb_info::traverse_base_map,
int_hash >, access_group,
simple_hashmap_traits,
int_hash > >, access_group> >
>(ordered_hash_map, int_hash >, access_group,
simple_hashmap_traits,
int_hash > >, access_group> >&)
../../gcc/config/aarch64/aarch64-ldp-fusion.cc:2963
0x1dc5a75 ldp_bb_info::transform()
../../gcc/config/aarch64/aarch64-ldp-fusion.cc:2971
0x1dc01fb ldp_fusion_bb(rtl_ssa::bb_info*)
../../gcc/config/aarch64/aarch64-ldp-fusion.cc:3209
0x1dc0285 ldp_fusion()
../../gcc/config/aarch64/aarch64-ldp-fusion.cc:3218
0x1dc0398 execute
../../gcc/config/aarch64/aarch64-ldp-fusion.cc:3268
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.

[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #11 from H.J. Lu  ---
Created attachment 57233
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57233&action=edit
An untested patch

[Bug tree-optimization/113622] [11/12/13/14 Regression] ICE with vectors in named registers

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

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

--- Comment #5 from Andrew Pinski  ---
Here is a "valid" x86_64 testcase:

```
typedef float __attribute__ ((vector_size (64))) vec;
register vec a asm("zmm2"), b asm("zmm0"), c asm("zmm1");

void
test (void)
{
  for (int i = 0; i < 8; i++)
c[i] = a[i] < b[i] ? 0.1 : 0.2;
}
```
Which fails with `-O2  -g0 -mavx512f` which started in GCC 4.9 when -mavx512f
support was added.

[Bug tree-optimization/113622] [11/12/13/14 Regression] ICE with vectors in named registers

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|ICE with vectors in named   |[11/12/13/14 Regression]
   |registers   |ICE with vectors in named
   ||registers
   Priority|P3  |P2
   Target Milestone|--- |11.5
 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
typedef double __attribute__ ((vector_size (16))) vec;
register vec a asm("xmm12"), b asm("xmm13"), c asm("xmm14");

void
test (void)
{
  for (int i = 0; i < 4; i++)
c[i] = a[i] < b[i] ? 0.1 : 0.2;
}

ICEs with -O2 -mavx -ffixed-xmm{12,13,14} -std=gnu99 starting with
r0-104000-g30cd1c5d04c18770e8688d7199c20c2d528df1cd
when the vector indexing support has been added.

[Bug tree-optimization/113622] ICE with vectors in named registers

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

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

--- Comment #3 from Xi Ruoyao  ---
(In reply to Andrew Pinski from comment #2)
> x86_64 Testcase (which invokes undefined behavior) which has been failing
> since at least 4.9.1 even:
> ```
> typedef double __attribute__ ((vector_size (16))) vec;
> register vec a asm("ymm2"), b asm("ymm0"), c asm("ymm1");
> 
> void
> test (void)
> {
>   for (int i = 0; i < 4; i++)
> c[i] = a[i] < b[i] ? 0.1 : 0.2;
> }
> ```

Phew.  Then maybe I should refactor the LoongArch test cases to avoid using
named registers...

[Bug fortran/113621] New test case gfortran.dg/optional_absent_10.f90 from r14-8400-g186ae6d2cb93ad fails

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

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
(In reply to seurer from comment #0)
> This appears to be a problem just on big endian.

This is only for -m32, right?

> Program received signal SIGSEGV: Segmentation fault - invalid memory
> reference.
> 
> Backtrace for this error:
> #0  0xf7f803f3 in ???
> #1  0x1c68 in __m_char_MOD_three_val
>   at
> /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/optional_absent_10.
> f90:97
> #2  0x10001bcb in __m_char_MOD_test_char
>   at
> /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/optional_absent_10.
> f90:19
> #3  0x1000269b in p
>   at
> /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/optional_absent_10.
> f90:218
> #4  0x100026f3 in main
>   at
> /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/optional_absent_10.
> f90:214
> Segmentation fault

We likely mishandle the passing-by-value for character(len=4).

There previously was an issue with character(len=1), see pr110419,
fixed by Mikael.  This also occurred only on Power big endian for -m32.

[Bug tree-optimization/113622] ICE with vectors in named registers

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||4.9.1
Summary|r14-8450 regression: ICE|ICE with vectors in named
   |with vectors in named   |registers
   |registers   |

--- Comment #2 from Andrew Pinski  ---
x86_64 Testcase (which invokes undefined behavior) which has been failing since
at least 4.9.1 even:
```
typedef double __attribute__ ((vector_size (16))) vec;
register vec a asm("ymm2"), b asm("ymm0"), c asm("ymm1");

void
test (void)
{
  for (int i = 0; i < 4; i++)
c[i] = a[i] < b[i] ? 0.1 : 0.2;
}
```

[Bug target/113526] [14 Regression] gcc.target/arm/asm-flag-1.c fails since gcc-14-7248-g76bc70387d9

[thiago.bauermann at linaro dot org via Gcc-bugs]

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

--- Comment #2 from Thiago Jung Bauermann  
---
I verified the fix here.

Thank you!

[Bug tree-optimization/113622] r14-8450 regression: ICE with vectors in named registers

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-26
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Xi Ruoyao  ---
On x86_64 it's reproducible likewise:

typedef double __attribute__ ((vector_size (32))) vec;
register vec a asm("ymm2"), b asm("ymm0"), c asm("ymm1");

void
test (void)
{
  for (int i = 0; i < 4; i++)
c[i] = a[i] < b[i] ? 0.1 : 0.2;
}

$ gcc/cc1 t.c -mavx2

t.c:8:10: internal compiler error: in expand_assignment, at expr.cc:6073
8 | c[i] = a[i] < b[i] ? 0.1 : 0.2;
  | ~^
0x10d9759 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.cc:6073
0xf2e9c0 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.cc:3992
0xf2ed4e expand_gimple_stmt
../../gcc/gcc/cfgexpand.cc:4071
0xf377be expand_gimple_basic_block
../../gcc/gcc/cfgexpand.cc:6127
0xf39f72 execute
../../gcc/gcc/cfgexpand.cc:6866

Self-confirming.

[Bug fortran/104908] [11/12/13/14 Regression] incorrect Fortran out-of-bound runtime error.

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

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Studying the cases that ICE (CLASS array dummy) and testcase PR95331.f90
which fixes an unlimited polymorphic problem, I tried the following change:

diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index f6ddce2d023..be7d42ff847 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -4097,7 +4097,10 @@ gfc_conv_array_ref (gfc_se * se, gfc_array_ref * ar,
gfc_expr *expr,
 }

   decl = se->expr;
-  if (IS_CLASS_ARRAY (sym) && sym->attr.dummy && ar->as->type != AS_DEFERRED)
+  if (UNLIMITED_POLY(sym)
+  && IS_CLASS_ARRAY (sym)
+  && sym->attr.dummy
+  && ar->as->type != AS_DEFERRED)
 decl = sym->backend_decl;

   cst_offset = offset = gfc_index_zero_node;


This is currently regtesting.

[Bug tree-optimization/113622] New: r14-8450 regression: ICE with vectors in named registers

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

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

Bug ID: 113622
   Summary: r14-8450 regression: ICE with vectors in named
registers
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xry111 at gcc dot gnu.org
  Target Milestone: ---

Start from r14-8450 "tree-optimization/113602 - datarefs of non-addressables",
various LoongArch target tests fail.  Reduced test case:

typedef double __attribute__ ((vector_size (32))) vec;
register vec a asm("f25"), b asm("f26"), c asm("f27");

void
test (void)
{
  for (int i = 0; i < 4; i++)
c[i] = a[i] < b[i] ? 0.1 : 0.2;
}

$ ./gcc/cc1 t.c -O2 -msimd=lasx -fno-ident -o xvfcmp-f.s -nostdinc
t.c: In function ‘test’:
t.c:8:10: internal compiler error: in expand_assignment, at expr.cc:6073
8 | c[i] = a[i] < b[i] ? 0.1 : 0.2;
  | ~^
0x102029b expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.cc:6073
0xe7a76b expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.cc:3992
0xe7aaf9 expand_gimple_stmt
../../gcc/gcc/cfgexpand.cc:4071
0xe8355b expand_gimple_basic_block
../../gcc/gcc/cfgexpand.cc:6127
0xe85b0d execute
../../gcc/gcc/cfgexpand.cc:6866

[Bug fortran/113621] New: New test case gfortran.dg/optional_absent_10.f90 from r14-8400-g186ae6d2cb93ad fails

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

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

Bug ID: 113621
   Summary: New test case gfortran.dg/optional_absent_10.f90 from
r14-8400-g186ae6d2cb93ad fails
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:186ae6d2cb93ad2e07117cff7e11def21fe285ae, r14-8400-g186ae6d2cb93ad
make  -k check-gcc-fortran RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
dg.exp=gfortran.dg/optional_absent_10.f90"
FAIL: gfortran.dg/optional_absent_10.f90   -O0  execution test
# of expected passes11
# of expected passes12
# of expected passes23
# of unexpected failures1
# of unexpected failures1

This appears to be a problem just on big endian.

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0xf7f803f3 in ???
#1  0x1c68 in __m_char_MOD_three_val
at
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/optional_absent_10.f90:97
#2  0x10001bcb in __m_char_MOD_test_char
at
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/optional_absent_10.f90:19
#3  0x1000269b in p
at
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/optional_absent_10.f90:218
#4  0x100026f3 in main
at
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/optional_absent_10.f90:214
Segmentation fault


commit 186ae6d2cb93ad2e07117cff7e11def21fe285ae (HEAD)
Author: Harald Anlauf 
Date:   Wed Jan 24 20:27:36 2024 +0100

Fortran: passing of optional dummies to elemental procedures [PR113377]

[Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled

[kacper.slominski72 at gmail dot com via Gcc-bugs]

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

Kacper Słomiński  changed:

   What|Removed |Added

 CC||kacper.slominski72 at gmail 
dot co
   ||m

--- Comment #26 from Kacper Słomiński  ---
Created attachment 57232
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57232&action=edit
reduced standalone failing part of the libgcrypt test

I've isolated the failing part of the test, inlined the relevant libgcrypt code
and reduced it.

Worth noting is that in the bad output, limbs 1-8 (inclusive) are all off by 1
vs the good output (limbs 0 and 9-15 stay the same). This is because, when
computing the carry, the faulty code adds a whole 8-element vector of 1s to the
output, instead of only a single 1 to the output limb (because the carry loop
terminates early after one iteration).

The faulty generated code is:

 8049280:   b8 01 00 00 00  mov$0x1,%eax
 ...
x = *s1_ptr++ + 1;
 804928d:   c5 f9 6e c0 vmovd  %eax,%xmm0
 ...
x = *s1_ptr++ + 1;
 8049296:   c4 e2 7d 58 c0  vpbroadcastd %xmm0,%ymm0
 804929b:   c5 fd fe 42 e0  vpaddd -0x20(%edx),%ymm0,%ymm0
*res_ptr++ = x;
 80492a0:   c5 fe 7f 42 e0  vmovdqu %ymm0,-0x20(%edx)

While in the working binary (produced by gcc 13) the relevant code is:

x = *s1_ptr++ + 1;
1270:   8b 54 81 04 mov0x4(%ecx,%eax,4),%edx
1274:   42  inc%edx
*res_ptr++ = x;
1275:   89 54 81 04 mov%edx,0x4(%ecx,%eax,4)

[Bug c++/109419] [modules] ICE: Segmentation fault when using -fmodules-ts and -g

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |14.0
 Depends on||104234
 CC||ppalka at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Patrick Palka  ---
This seems fixed for GCC 14 after r14-6394.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104234
[Bug 104234] ICE with -fmodules-ts and std::map/_Rb_tree

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

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

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

--- Comment #27 from Jerry DeLisle  ---
(In reply to anlauf from comment #26)
> (In reply to Jerry DeLisle from comment #24)
> > Currently gfortran does the following:
> > 
> > character(20) :: fmt
> > character(9) :: buffer
> > fmt = "(1a1,d0.2,1a1)"
> > write(buffer,fmt) ">", 3.0, "<"
> >  print *, buffer
> > fmt = "(1a1,e0.2,1a1)"
> > write(buffer,fmt) ">", 3.0, "<"
> >  print *, buffer
> > end
> > 
> > 
> > $ gfc question.f90 
> > $ ./a.out 
> >  >0.30D+1<
> >  >0.30E+1<
> > 
> > Why not:
> > 
> > $ ./a.out 
> >  >3.00D+0<
> >  >3.00E+0<
> 
> It seems the Fortran standard changed here between F2018 and F2023.
> 
> F2018, Table 13.1:
> 
> Ew.d   |exp| ≤ 99E±z1z2 or ±0z1 z2
>   99 < |exp| ≤ 999   ±z1 z2z3
> 
> So Intel implements this.
> 
> 
> 
> F2023, Table 13.1:
> 
> Ew.d E0 or E0.dany   E±z1 z2 . . . zs
> 
Yes it changed. I am looking at a lot of different cases here as I have time
and intuitively the 0.30D+1 caught my attention. Its not necessarily related to
this bug. I also have the latest standard (2023) in front of me here.

[Bug c++/113620] ICE with inner class template speciailization and depdent NSDMI

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Patrick Palka from comment #5)
> Seems to be a name lookup issue ultimately:
> 
> struct A {
>   template
>   struct B;
> 
>   template
>   struct B {
> int x = V::value; // error: 'V' has not been declared
> int y = T::value; // no error!
> int z = U::value; // no error!
>   };
> };

That would make sense on why it was rejected before GCC 4.9 even.

Now I wonder if this is related to the diagnostic issue mentioned in
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643811.html even.

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

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

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

--- Comment #26 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #24)
> Currently gfortran does the following:
> 
> character(20) :: fmt
> character(9) :: buffer
> fmt = "(1a1,d0.2,1a1)"
> write(buffer,fmt) ">", 3.0, "<"
>  print *, buffer
> fmt = "(1a1,e0.2,1a1)"
> write(buffer,fmt) ">", 3.0, "<"
>  print *, buffer
> end
> 
> 
> $ gfc question.f90 
> $ ./a.out 
>  >0.30D+1<
>  >0.30E+1<
> 
> Why not:
> 
> $ ./a.out 
>  >3.00D+0<
>  >3.00E+0<

It seems the Fortran standard changed here between F2018 and F2023.

F2018, Table 13.1:

Ew.d   |exp| ≤ 99E±z1z2 or ±0z1 z2
  99 < |exp| ≤ 999   ±z1 z2z3

So Intel implements this.



F2023, Table 13.1:

Ew.d E0 or E0.dany   E±z1 z2 . . . zs

with footnote:

(1) where each z is a digit, and s is the minimum number of digits required to
represent the exponent. A plus sign is produced if the exponent value is zero.

[Bug target/113600] [14 regression] 525.x264_r run-time regresses by 8% with PGO -Ofast -march=znver4

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

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

--- Comment #4 from Martin Jambor  ---
(In reply to Hongtao Liu from comment #2)
> A patch is posted at
> https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640276.html
> 
> Would you give a try to see if it fixes the regression, I don't currently
> have a znver4 machine for testing.

Unfortunately it does not.

(In reply to Richard Biener from comment #3)
> I think we need to figure out what exactly gets slower (and hope it's not
> scattered all over the place)

I have collected some profiles:

r14-5602-ge6269bb69c0734

# Samples: 516K of event 'cycles:u'
# Event count (approx.): 468008188417
# Overhead   Samples  Command  Shared Object   
  Symbol   
#     ... 
. 
.
#
13.55% 69886  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] mc_chroma
11.05% 57017  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] x264_pixel_satd_16x16
 9.24% 47693  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] x264_pixel_satd_8x8
 8.67% 44733  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] get_ref
 4.84% 24984  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] sub16x16_dct
 4.16% 21484  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] x264_me_search_ref
 3.30% 17033  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] x264_pixel_hadamard_ac_16x16
 2.28% 11770  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] x264_pixel_satd_4x4
 2.10% 10824  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] quant_trellis_cabac
 2.07% 10694  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] hpel_filter
 2.05% 10616  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] sub8x8_dct
 1.86%  9593  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] refine_subpel
 1.70%  8788  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] quant_4x4
 1.57%  8077  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] x264_pixel_sad_16x16
 1.16%  6324  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] frame_init_lowres_core
 1.14%  5867  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] x264_pixel_sa8d_8x8
 1.11%  5738  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] x264_cabac_encode_decision_c
 1.08%  5736  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] x264_pixel_var_16x16



r14-5603-g2b59e2b4dff421

# Samples: 550K of event 'cycles:u'
# Event count (approx.): 498834737657
# Overhead   Samples  Command  Shared Object   
  Symbol   
#     ... 
. 
.
#
18.21%100151  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] x264_pixel_satd_16x16
12.37% 68006  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] mc_chroma
 8.51% 46815  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] x264_pixel_satd_8x8
 7.56% 41560  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] get_ref
 4.53% 24901  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] sub16x16_dct
 3.92% 21561  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] x264_me_search_ref
 3.08% 16963  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] x264_pixel_hadamard_ac_16x16
 2.41% 13239  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] x264_pixel_satd_4x4
 1.99% 10931  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] quant_trellis_cabac
 1.96% 10801  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] hpel_filter
 1.95% 10764  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] sub8x8_dct
 1.56%  8587  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] quant_4x4
 1.49%  8166  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] refine_subpel
 1.48%  8124  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] x264_pixel_sad_16x16
 1.09%  6328  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] frame_init_lowres_core
 1.07%  5901  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] x264_pixel_sa8d_8x8
 1.04%  5703  x264_r_peak.min 
x264_r_peak.mine-pgo-Ofast-native-m64  [.] x264_cabac_encode_decision_c

[Bug tree-optimization/113614] wrong code with _BitInt() division at -O1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2024-01-26

--- Comment #2 from Jakub Jelinek  ---
Created attachment 57231
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57231&action=edit
gcc14-pr113614.patch

Untested fix.

[Bug tree-optimization/107946] [13/14 Regression] 507.cactuBSSN_r regresses by ~9% on znver3 with PGO since r13-3875-g9e11ceef165bc0

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

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

Martin Jambor  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-26
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #7 from Martin Jambor  ---
This regression is still there (as the graphs linked in the summary show).

[Bug target/113616] [14 Regression] ICE in process_uses_of_deleted_def, at rtl-ssa/changes.cc:252

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

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

--- Comment #3 from Alex Coplan  ---
Testing a patch.

[Bug c++/113620] ICE with inner class template speciailization and depdent NSDMI

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #5 from Patrick Palka  ---
Seems to be a name lookup issue ultimately:

struct A {
  template
  struct B;

  template
  struct B {
int x = V::value; // error: 'V' has not been declared
int y = T::value; // no error!
int z = U::value; // no error!
  };
};

[Bug tree-optimization/113568] ICE: definition in block 13 does not dominate use in block 15 with _BitInt() at -O1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Created attachment 57230
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57230&action=edit
gcc14-pr113568.patch

Untested fix.

[Bug c++/113620] ICE with inner class template speciailization and depdent NSDMI

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

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 57229
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57229&action=edit
Reduced testcase

I reduced the testcase slightly to show it is NSDMI related dealing with a
dependent value only with the specialization.

Note a workaround is to add a constructor which does the initialization instead
of using NSDMI.

[Bug c++/113620] ICE with missing "typename" and -std=c++20

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||4.9.0

--- Comment #3 from Andrew Pinski  ---
In GCC 4.8.5, it was rejected (incorrectly):
```
:19:25: error: 'DEF' has not been declared
 typename DEF::TYP r=DEF::INIT;
 ^

```

[Bug c++/113620] ICE with missing "typename" and -std=c++20

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
  Known to fail||5.1.0

--- Comment #2 from Andrew Pinski  ---
(In reply to Xi Ruoyao from comment #1)
> With -std=c++17 it's fine:
> 
> t1.c:19:5: error: need 'typename' before 'DEF::TYP' because 'DEF' is a
> dependent scope
>19 | DEF::TYP r=DEF::INIT;
>   | ^~~
>   | typename

Note once you add the typename (which is optional in C++20 by the way), the ICE
is back in C++11 mode even.

This has been ICEing from at least GCC 5.1.0.

[Bug target/113618] [14 Regression] AArch64: memmove idiom regression

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944

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

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

--- Comment #10 from Jakub Jelinek  ---
The difference with that revision is
--- pr113617-aux.s1 2024-01-26 11:00:05.532246309 -0500
+++ pr113617-aux.s  2024-01-26 11:00:36.291552459 -0500
@@ -80,22 +80,21 @@ _ZN3vtk6detail3smp15vtkSMPToolsImplILi1E
pushq   %r12
 .LCFI3:
movq%rdx, %r12
-   leaq   
_ZN4blah17_Function_handlerIFvvENS_5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTools_FunctorInternalIN12_GLOBAL__N_19CountUsesIxEELb0EEExxx10_M_managerERNS_9_Any_dataERKSI_NS_18_Manager_operationE(%rip),
%rdx
pushq   %rbp
 .LCFI4:
-   movq%rdx, %xmm0
movq%r8, %rbp
pushq   %rbx
 .LCFI5:
-   punpcklqdq  %xmm1, %xmm0
movq%rcx, %rbx
subq$40, %rsp
 .LCFI6:
movqFor_threadNumber@GOTPCREL(%rip), %rax
+   movq.LC0(%rip), %xmm0
leaq31(%rsp), %r13
-   movaps  %xmm0, (%rsp)
movl(%rax), %esi
+   punpcklqdq  %xmm1, %xmm0
movq%r13, %rdi
+   movaps  %xmm0, (%rsp)
call_ZN3vtk6detail3smp16vtkSMPThreadPoolC1Ei@PLT
movq(%rsp), %r14
.p2align 4,,10
@@ -218,6 +217,10 @@ _Z34vtkPolyDataPlaneClipperRequestDatav:
.size   _Z34vtkPolyDataPlaneClipperRequestDatav,
.-_Z34vtkPolyDataPlaneClipperRequestDatav
.local  _ZN12_GLOBAL__N_117GenerateCap_linesE
.comm   _ZN12_GLOBAL__N_117GenerateCap_linesE,1,1
+   .section.data.rel.ro.local,"aw"
+   .align 8
+.LC0:
+   .quad  
_ZN4blah17_Function_handlerIFvvENS_5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTools_FunctorInternalIN12_GLOBAL__N_19CountUsesIxEELb0EEExxx10_M_managerERNS_9_Any_dataERKSI_NS_18_Manager_operationE
.section.eh_frame,"aw",@progbits
 .Lframe1:
.long   .LECIE1-.LSCIE1
(pretty much the same as in the other assembler file).

I must say I'm completely lost in where symbols defined in comdat sections may
be referenced and where not, can one reference them in code sections and not
data sections, or only comdat code sections or what?  I thought it is pretty
much a normal thing to reference comdat functions in both code and data/rodata
sections, how else
could one do say:
__attribute__((noinline, noipa)) inline void foo () {}
void bar () { foo (); }
void (*p) () = foo;
void (*const q) () = foo;
void (*const *r) () = &q;

[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944

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

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

--- Comment #9 from Sam James  ---
Ah, this explains a failure I started seeing recently with folly/watchman/etc
too. I just hadn't looked at it yet.

[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944

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

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 57228
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57228&action=edit
pr113617-aux.cc

[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944

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

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 57227
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57227&action=edit
pr113617.C

[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944

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

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 57226
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57226&action=edit
pr113617.h

Reduced testcase:
./cc1plus -quiet -O2 -std=c++11 -fPIC pr113617.C; ./cc1plus -quiet -O2
-std=c++11 -fPIC pr113617-aux.cc; g++ -shared -o pr113617.so pr113617.s
pr113617-aux.s
`_ZN4blah17_Function_handlerIFvvENS_5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTools_FunctorInternalIN12_GLOBAL__N_19CountUsesIxEELb0EEExxx10_M_managerERNS_9_Any_dataERKSI_NS_18_Manager_operationE'
referenced in section `.data.rel.ro.local' of /tmp/ccecCY2H.o: defined in
discarded section
`.text._ZN4blah17_Function_handlerIFvvENS_5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTools_FunctorInternalIN12_GLOBAL__N_19CountUsesIxEELb0EEExxx10_M_managerERNS_9_Any_dataERKSI_NS_18_Manager_operationE[_ZN26vtkStaticCellLinksTemplateIxE18ThreadedBuildLinksExxP12vtkCellArray]'
of /tmp/ccecCY2H.o
collect2: error: ld returned 1 exit status

[Bug c++/113620] Specialized Template

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-invalid-code
 Ever confirmed|0   |1
   Last reconfirmed||2024-01-26

--- Comment #1 from Xi Ruoyao  ---
Confirmed.

t1.c:19:21: internal compiler error: tree check: accessed elt 2 of 'tree_vec'
with 1 elts in tsubst, at cp/pt.cc:16216
   19 | DEF::TYP r=DEF::INIT;
  | ^~~~
0x910d44 tree_vec_elt_check_failed(int, int, char const*, int, char const*)
../../gcc/gcc/tree.cc:9153
0x7a8e83 tree_vec_elt_check(tree_node*, int, char const*, int, char const*)
../../gcc/gcc/tree.h:3865
0x7a8e83 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.cc:16216
0xc3ada0 tsubst_scope
../../gcc/gcc/cp/pt.cc:16857
0xc3ada0 tsubst_qualified_id
../../gcc/gcc/cp/pt.cc:17133
0xc153cd tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.cc:20199
0xb03627 maybe_instantiate_nsdmi_init(tree_node*, int)
../../gcc/gcc/cp/init.cc:624
0xb03b0a maybe_instantiate_nsdmi_init(tree_node*, int)
../../gcc/gcc/cp/init.cc:679
0xb03b0a get_nsdmi(tree_node*, bool, int)
../../gcc/gcc/cp/init.cc:656
0xb34ed1 walk_field_subobs
../../gcc/gcc/cp/method.cc:2466
0xb35576 walk_field_subobs
../../gcc/gcc/cp/method.cc:2390
0xb35576 synthesized_method_walk
../../gcc/gcc/cp/method.cc:2835
0xb35eed get_defaulted_eh_spec(tree_node*, int)
../../gcc/gcc/cp/method.cc:2877
0xc1a078 maybe_instantiate_noexcept(tree_node*, int)
../../gcc/gcc/cp/pt.cc:26655
0xc19ee6 maybe_instantiate_noexcept(tree_node*, int)
../../gcc/gcc/cp/pt.cc:26645
0xae729a mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.cc:5811
0xa1af3e build_over_call
../../gcc/gcc/cp/call.cc:10524
0xa183bf build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.cc:11796
0xa1962a build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../gcc/gcc/cp/call.cc:11281
0xb07819 expand_default_init
../../gcc/gcc/cp/init.cc:2202

With -std=c++17 it's fine:

t1.c:19:5: error: need 'typename' before 'DEF::TYP' because 'DEF' is a
dependent scope
   19 | DEF::TYP r=DEF::INIT;
  | ^~~
  | typename

[Bug c++/113620] New: Specialized Template

[hans.buchmann.wantuch at gmail dot com via Gcc-bugs]

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

Bug ID: 113620
   Summary: Specialized Template
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hans.buchmann.wantuch at gmail dot com
  Target Milestone: ---

Created attachment 57225
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57225&action=edit
Bug report generated with: -freport-bug

Compiling the code bug-1.cc

--8<--8<--8<--8<--
class CRC
{
 public:
  template
  struct Def
  {
   using TYP=T;
   static const TYP INIT=0;
  };

  enum Method {MSB_FIRST,LSB_FIRST};

  template
  class BIT{};

  template
  struct BIT
  {
DEF::TYP r=DEF::INIT;
  };
};

int main(int argc,char** args)
{
 CRC::BIT> crc;
 return 0;
}
--8<--8<--8<--8<--

compiling with:

g++ -freport-bug -std=c++2a -c -o bug-1.o bug-1.cc

results in the following output:

see attached bug-report.txt

Sincerely

Hans Buchmann

[Bug target/113618] [14 Regression] AArch64: memmove idiom regression

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

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

Alex Coplan  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-26
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||acoplan at gcc dot gnu.org

--- Comment #1 from Alex Coplan  ---
Confirmed.

(In reply to Wilco from comment #0)
> A possible fix would be to avoid emitting LDP/STP in memcpy/memmove/memset
> expansions.

Yeah, so I had posted
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636855.html for that
but held off from committing it at the time as IMO there wasn't enough evidence
to show that this helps in general (and the pass could in theory miss
opportunities which would lead to regressions). 

But perhaps this is a good argument for going ahead with that change (of course
it will need rebasing).

[Bug analyzer/113619] New: -Wanalyzer-tainted-divisor false positive seen in Linux kernel's fs/ceph/ioctl.c

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

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

Bug ID: 113619
   Summary: -Wanalyzer-tainted-divisor false positive seen in
Linux kernel's fs/ceph/ioctl.c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106358
  Target Milestone: ---

Reduced from false positive in Linux kernel's kernel's fs/ceph/ioctl.c:

__extension__ typedef unsigned long long __u64;

struct ceph_ioctl_layout
{
  __u64 stripe_unit, object_size;
};
static long
__validate_layout(struct ceph_ioctl_layout* l)
{
  if ((l->object_size & ~(~(((1UL) << 12) - 1))) ||
  (l->stripe_unit & ~(~(((1UL) << 12) - 1))) ||
  ((unsigned)l->stripe_unit != 0 &&
   ((unsigned)l->object_size % (unsigned)l->stripe_unit)))
return -22;
  return 0;
}

long
__attribute__((tainted_args))
ceph_ioctl_set_layout_policy(struct ceph_ioctl_layout l)
{
  int err;
  err = __validate_layout(&l);
  if (err)
return err;
  return err;
}


t.c: In function ‘__validate_layout’:
t.c:13:34: warning: use of attacker-controlled value ‘l.stripe_unit’ as divisor
without checking for zero [CWE-369] [-Wanalyzer-tainted-divisor]
   13 |((unsigned)l->object_size % (unsigned)l->stripe_unit)))
  |~~^~~
  ‘ceph_ioctl_set_layout_policy’: event 1
|
|   20 | ceph_ioctl_set_layout_policy(struct ceph_ioctl_layout l)
|  | ^~~~
|  | |
|  | (1) function ‘ceph_ioctl_set_layout_policy’ marked with
‘__attribute__((tainted_args))’
|
+--> ‘ceph_ioctl_set_layout_policy’: events 2-3
   |
   |   20 | ceph_ioctl_set_layout_policy(struct ceph_ioctl_layout l)
   |  | ^~~~
   |  | |
   |  | (2) entry to ‘ceph_ioctl_set_layout_policy’
   |..
   |   23 |   err = __validate_layout(&l);
   |  | ~
   |  | |
   |  | (3) calling ‘__validate_layout’ from
‘ceph_ioctl_set_layout_policy’
   |
   +--> ‘__validate_layout’: events 4-11
  |
  |8 | __validate_layout(struct ceph_ioctl_layout* l)
  |  | ^
  |  | |
  |  | (4) entry to ‘__validate_layout’
  |9 | {
  |   10 |   if ((l->object_size & ~(~(((1UL) << 12) - 1))) ||
  |  |  ~~
  |  |  |   |
  |  |  (5) following ‘false’ branch... (7)
following ‘false’ branch...
  |   11 |   (l->stripe_unit & ~(~(((1UL) << 12) - 1))) ||
  |  |   ~
  |  | ||
  |  | (6) ...to here   (9)
following ‘true’ branch...
  |   12 |   ((unsigned)l->stripe_unit != 0 &&
  |  |   ~
  |  ||
  |  |(8) ...to here
  |   13 |((unsigned)l->object_size %
(unsigned)l->stripe_unit)))
  |  |   
~~
  |  | ||
  |  | (10) ...to here  (11) use of
attacker-controlled value ‘l.stripe_unit’ as divisor without checking for zero
  |

...whereas (unsigned)l->stripe_unit != 0 is checked at line 12.

Affects trunk: https://godbolt.org/z/3qfx6scT8

Might show up on earlier releases, but taint state machine required opt-in on
them.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
[Bug 106358] [meta-bug] tracker bug for building the Linux kernel with
-fanalyzer

[Bug target/113618] New: [14 Regression] AArch64: memmove idiom regression

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

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

Bug ID: 113618
   Summary: [14 Regression] AArch64: memmove idiom regression
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilco at gcc dot gnu.org
  Target Milestone: ---

The following is often used as an idiom for memmove since GCC mid-end and most
back-ends have no support for inlining memmove:

void move64 (char *a, char *b)
{
char temp[64];
memcpy (temp, a, 64);
memcpy (b, temp, 64);
}

On trunk this generates:

ldp q30, q31, [x0]
sub sp, sp, #64
ldp q28, q29, [x0, 32]
stp q30, q31, [sp]
ldp q30, q31, [sp]
stp q28, q29, [sp, 32]
ldp q28, q29, [sp, 32]
stp q30, q31, [x1]
stp q28, q29, [x1, 32]
add sp, sp, 64
ret

This is a significant regression from GCC13 which has redundant stores but
avoids load-after-store forwarding penalties:

ldp q2, q3, [x0]
sub sp, sp, #64
ldp q0, q1, [x0, 32]
stp q2, q3, [sp]
stp q2, q3, [x1]
stp q0, q1, [sp, 32]
stp q0, q1, [x1, 32]
add sp, sp, 64
ret

LLVM avoids writing to the temporary and removes the stackframe altogether:

ldp q1, q0, [x0, #32]
ldp q2, q3, [x0]
stp q1, q0, [x1, #32]
stp q2, q3, [x1]
ret

The reason for the regression appears to be the changed RTL representation of
LDP/STP. The RTL optimizer does not understand LDP/STP, so emitting LDP/STP
early in memcpy expansion means it cannot remove the redundant stack stores.

A possible fix would be to avoid emitting LDP/STP in memcpy/memmove/memset
expansions.

[Bug c++/113529] Incorrect result of requires-expression in case of function call ambiguity and `operator<=>`

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |13.3
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 13.3 / 14.

[Bug c++/113529] Incorrect result of requires-expression in case of function call ambiguity and `operator<=>`

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:663d9e168bc1f2649721436f5188563eda9d04f0

commit r13-8255-g663d9e168bc1f2649721436f5188563eda9d04f0
Author: Patrick Palka 
Date:   Wed Jan 24 17:11:09 2024 -0500

c++: ambiguous member lookup for rewritten cands [PR113529]

Here we handle the operator expression u < v inconsistently: in a SFINAE
context we accept it, and in a non-SFINAE context we reject it with

  error: request for member 'operator<=>' is ambiguous

as per [class.member.lookup]/6.  This inconsistency is ultimately
because we neglect to propagate error_mark_node after recursing in
add_operator_candidates, fixed like so.

PR c++/113529

gcc/cp/ChangeLog:

* call.cc (add_operator_candidates): Propagate error_mark_node
result after recursing to find rewritten candidates.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/spaceship-sfinae3.C: New test.

Reviewed-by: Jason Merrill 
(cherry picked from commit fecb45a936d62ca24dd8b4985ea0555c28edefa8)

[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to H.J. Lu from comment #3)
> > LEA is changed to load through an indirection. Isn't it a regression?
> 
> LEA + moving a GPR register to SSE register.
> So bet it depends on how costly the moving from GPR to SSE register is (and
> how costly we represent it in costs).

This makes senses.  In any case, we shouldn't reference a symbol defined
a different comdat group.

[Bug debug/29461] inconsistent variable output

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Richard Biener  ---
 <2><6c>: Abbrev Number: 8 (DW_TAG_formal_parameter)
<6d>   DW_AT_name: s_p
<71>   DW_AT_decl_file   : 1
<72>   DW_AT_decl_line   : 3
<73>   DW_AT_decl_column : 19
<74>   DW_AT_type: <0x8a>
<78>   DW_AT_location: 2 byte block: 91 58  (DW_OP_fbreg: -40)
 <2><7b>: Abbrev Number: 9 (DW_TAG_variable)
<7c>   DW_AT_name: ss
<7f>   DW_AT_decl_file   : 1
<80>   DW_AT_decl_line   : 5
<81>   DW_AT_decl_column : 20
<82>   DW_AT_type: <0x46>
<86>   DW_AT_location: 2 byte block: 91 68  (DW_OP_fbreg: -24)

so we can and do now make those equal.  With -O1 we have

 <2><6c>: Abbrev Number: 9 (DW_TAG_formal_parameter)
<6d>   DW_AT_name: s_p
<71>   DW_AT_decl_file   : 1
<72>   DW_AT_decl_line   : 3
<73>   DW_AT_decl_column : 19
<74>   DW_AT_type: <0xc0>
<78>   DW_AT_location: 0x12 (location list)
<7c>   DW_AT_GNU_locviews: 0xc
 <2><80>: Abbrev Number: 10 (DW_TAG_variable)
<81>   DW_AT_name: ss
<84>   DW_AT_decl_file   : 1
<85>   DW_AT_decl_line   : 5
<86>   DW_AT_decl_column : 20
<87>   DW_AT_type: <0x46>
<8b>   DW_AT_location: 0x2b (location list)
<8f>   DW_AT_GNU_locviews: 0x25

0012 v000 v000 views at 000c for:
  0008 (DW_OP_reg5 (rdi))
0017 v000 v000 views at 000e for:
 0008 0012 (DW_OP_reg3 (rbx))
001c v000 v000 views at 0010 for:
 0012 0013 (DW_OP_entry_value: (DW_OP_reg5
(rdi)); DW_OP_stack_value)
0024 

002b v001 v000 views at 0025 for:
 0004 0008 (DW_OP_reg5 (rdi))
0030 v000 v000 views at 0027 for:
 0008 0012 (DW_OP_reg3 (rbx))
0035 v000 v000 views at 0029 for:
 0012 0013 (DW_OP_entry_value: (DW_OP_reg5
(rdi)); DW_OP_stack_value)
003d 

which is nearly equivalent and I suppose "correct" in that we're not
showing it live during the prologue before the declaration/assignment

func2:
.LVL0:
.LFB0:
.file 1 "t.c"
.loc 1 4 1 view -0
.cfi_startproc
.loc 1 4 1 is_stmt 0 view .LVU1
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq%rdi, %rbx
.loc 1 5 3 is_stmt 1 view .LVU2
.LVL1:
.loc 1 6 3 view .LVU3
callfunc

-O0 vs -O is also -fno-var-tracking vs. -fvar-tracking of course.

[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944

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

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to H.J. Lu from comment #3)
> LEA is changed to load through an indirection. Isn't it a regression?

LEA + moving a GPR register to SSE register.
So bet it depends on how costly the moving from GPR to SSE register is (and how
costly we represent it in costs).

[Bug debug/27672] C frontend does not generate line information for multi-line conditions

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Richard Biener  ---
Yes, this particular form seems fixed.

[Bug ada/26827] "GNAT BUG DETECTED" on compile GPS 1.3.1/gtkada

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-26
 CC||dkm at gcc dot gnu.org
  Component|debug   |ada
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #6 from Richard Biener  ---
Is this still an issue?

[Bug tree-optimization/113614] wrong code with _BitInt() division at -O1

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

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

--- Comment #1 from Jakub Jelinek  ---
I guess the thing is that while using for a signed operand a positive precision
(if smaller than the precision of the signed operand) is always fine,
indicating zero extension from something narrower, for unsigned operand a
negative precision (if smaller in absolute value than the precision of the
unsigned operand) might be fine for __mulbitint3 (but even then perhaps only if
the result precision isn't higher than the precision of the operands), for
other libgcc _BitInt operations, including __divmodbitint4 but also the
conversions from _BitInt to binary/decimal floating point really consider an
operand with negative precision as signed with precision equal to the absolute
value of the argument, so there is no way to represent something that has been
sign extended from narrower precision and then cast to unsigned (we'd need to
tell libgcc two numbers somehow, from which smaller precision it is sign
extended and to which wider precision where it becomes unsigned).
But, guess this means we need to make sure such widening casts are not merged
with the libgcc operations.

[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #3 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #0)
> Since r14-4944-gf55cdce3f8dd8503e080e35be59c5f5390f6d95e the following
> testcase can't be linked anymore.
> for i in 1 2; do ./cc1plus -quiet -O2 -std=c++11 -fPIC -fvisibility=hidden
> -fvisibility-inlines-hidden $i.ii; done; g++ -shared -o 1.so 1.s 2.s
> `_ZNSt17_Function_handlerIFvvESt5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPToo
> ls_FunctorInternalIN12_GLOBAL__N_19CountUsesIxEELb0EEExxxEEE10_M_managerERSt9
> _Any_dataRKSH_St18_Manager_operation' referenced in section
> `.data.rel.ro.local' of /tmp/ccEORVfz.o: defined in discarded section
> `.text.
> _ZNSt17_Function_handlerIFvvESt5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTool
> s_FunctorInternalIN12_GLOBAL__N_19CountUsesIxEELb0EEExxxEEE10_M_managerERSt9_
> Any_dataRKSH_St18_Manager_operation[_ZN26vtkStaticCellLinksTemplateIxE18Threa
> dedBuildLinksExxP12vtkCellArray]' of /tmp/ccEORVfz.o
> `_ZNSt17_Function_handlerIFvvESt5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPToo
> ls_FunctorInternalIN12_GLOBAL__N_111InsertLinksIxEELb0EEExxxEEE10_M_managerER
> St9_Any_dataRKSH_St18_Manager_operation' referenced in section
> `.data.rel.ro.local' of /tmp/ccEORVfz.o: defined in discarded section
> `.text.
> _ZNSt17_Function_handlerIFvvESt5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTool
> s_FunctorInternalIN12_GLOBAL__N_111InsertLinksIxEELb0EEExxxEEE10_M_managerERS
> t9_Any_dataRKSH_St18_Manager_operation[_ZN26vtkStaticCellLinksTemplateIxE18Th
> readedBuildLinksExxP12vtkCellArray]' of /tmp/ccEORVfz.o
> 
> That change adds quite a few changes like:
> 
> -   leaq   
> _ZNSt17_Function_handlerIFvvESt5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTool
> s_FunctorInternalIN12_GLOBAL__N_19CountUsesIxEELb0EEExxxEEE10_M_managerERSt9_
> Any_dataRKSH
> _St18_Manager_operation(%rip), %rdx
> +   movq.LC73(%rip), %xmm3
> movq$0, (%rsp)
> movq%rax, 32(%rsp)
> leaq   
> _ZNSt17_Function_handlerIFvvESt5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTool
> s_FunctorInternalIN12_GLOBAL__N_19CountUsesIxEELb0EEExxxEEE9_M_invokeERKSt9_A
> ny_data(%rip), %rax
> -   movq%rdx, %xmm3
> ...
> +   .section.data.rel.ro.local,"aw"
> ...
> +.LC73:
> +   .quad  
> _ZNSt17_Function_handlerIFvvESt5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTool
> s_FunctorInternalIN12_GLOBAL__N_19CountUsesIxEELb0EEExxxEEE10_M_managerERSt9_
> Any_dataRKSH_St18_Manager_operation
> but as the symbol is defined in a comdat section, that results in the linker
> error.
> Dunno if this was just latent before, or whether we need to force such
> constants also into comdat sections in the same comdat group, etc.

LEA is changed to load through an indirection. Isn't it a regression?

[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f

[fkastl at suse dot cz via Gcc-bugs]

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

--- Comment #9 from Filip Kastl  ---
(In reply to Richard Biener from comment #8)
> Does this still happen after r14-8413-g578c7b91f418eb?

I think it doesn't happen anymore.

I can confirm that both on aarch64 and zen3, both the SPEC2006 and SPEC2017,
with -Ofast -march=native -mtune=native -flto perlbench compiles correctly now.

[Bug debug/103047] Inconsistent arguments ordering for inlined subroutine

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-01-26
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
  Known to fail||13.2.1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Richard Biener  ---
Confirmed, still happens.  But maybe this is a also gdb issue as we have for
the similar case

static inline int foo (int a, int b)
{
  volatile int x = a + b;
  return x;
}

int main()
{
  int c = 1;
  int d = 2;
  int res = foo (c, d);
  return res;
}


 <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
<2e>   DW_AT_external: 1
<2e>   DW_AT_name: (indirect string, offset: 0x6f): main
...
 <2><79>: Abbrev Number: 5 (DW_TAG_inlined_subroutine)
<7a>   DW_AT_abstract_origin: <0xca>
<7e>   DW_AT_entry_pc: 0
<86>   DW_AT_GNU_entry_view: 4
<87>   DW_AT_low_pc  : 0
<8f>   DW_AT_high_pc : 0xc
<97>   DW_AT_call_file   : 1
<98>   DW_AT_call_line   : 11
<99>   DW_AT_call_column : 13
 <3><9a>: Abbrev Number: 6 (DW_TAG_formal_parameter)
<9b>   DW_AT_abstract_origin: <0xe1>
<9f>   DW_AT_location: 0x27 (location list)
   DW_AT_GNU_locviews: 0x25
 <3>: Abbrev Number: 6 (DW_TAG_formal_parameter)
   DW_AT_abstract_origin: <0xd7>
   DW_AT_location: 0x4d (location list)
   DW_AT_GNU_locviews: 0x4b
...
 <1>: Abbrev Number: 10 (DW_TAG_subprogram)
   DW_AT_name: foo
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 1
   DW_AT_decl_column : 19
   DW_AT_prototyped  : 1
   DW_AT_type: <0xbe>
   DW_AT_inline  : 3(declared as inline and inlined)
 <2>: Abbrev Number: 11 (DW_TAG_formal_parameter)
   DW_AT_name: a
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 1
   DW_AT_decl_column : 28
   DW_AT_type: <0xbe>
 <2>: Abbrev Number: 11 (DW_TAG_formal_parameter)
   DW_AT_name: b
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 1
   DW_AT_decl_column : 35
   DW_AT_type: <0xbe>

so it could look at the actual function for determining the order.

The order of the formal parameters are reversed because the fake
scope BLOCK the inliner adds has those as variables in that reverse order.
We output them via decls_for_scope.

static gimple *
setup_one_parameter (copy_body_data *id, tree p, tree value, tree fn,
 basic_block bb, tree *vars)
{ 
...
  /* Declare this new variable.  */
  DECL_CHAIN (var) = *vars;
  *vars = var;


I have a patch.

[Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled

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

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

--- Comment #25 from Tamar Christina  ---
So I think probably what's miscompiled is this loop

  for (s=string; *s; s +=2 )

I think we currently incorrectly vectorize that.  i.e. I think it's the same as
PR113588.  I'm finishing testing for that atm.

Sorry for the delay, a busy couple of days.

[Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled

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

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

--- Comment #24 from Sam James  ---
just checked trunk too

[Bug debug/23551] dwarf records for inlines appear incomplete

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #21 from Richard Biener  ---
There is PR103047 for that now.

[Bug debug/19954] Compiler emits incomplete structure type

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to work||13.2.1, 7.5.0
 Status|NEW |RESOLVED

--- Comment #4 from Richard Biener  ---
(gdb) n
6float* pt = d1.getData(1); /* set breakpoint here */
(gdb) ptype d1
type = class Derived1 {
  private:
int mySize;
int myId;
float *myPointer;

  public:
Derived1(int);
~Derived1();
virtual int getId(void);
virtual float * getData(int);
}

works now as also verified in PR12385.  Verified with GCC 7 and GCC 13.

[Bug debug/14169] Unneeded base types output in dwarf2

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2005-12-28 06:11:40 |2024-1-26

--- Comment #2 from Richard Biener  ---
Re-confirmed.  With -fno-eliminate-unused-debug-types we output everything.

I think we never prune unused base types, nor do we prune unused namespaces.

[Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled

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

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

--- Comment #23 from Sam James  ---
I last tried around r14-8422-gc3de14ba1ba0e7 without that workaround patch
applied and it still failed.

[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f

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

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

--- Comment #8 from Richard Biener  ---
Does this still happen after r14-8413-g578c7b91f418eb?

[Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled

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

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

--- Comment #22 from Richard Biener  ---
Is this fixed meanwhile?

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #48 from Vincent Lefèvre  ---
(In reply to Alexander Cherepanov from comment #35)
> DR 260 allows one to argue that representation of these pointers could
> change right between the checks but IMHO this part of DR 260 is just wrong
> as it makes copying objects byte-by-byte impossible. See
> https://bugs.llvm.org/show_bug.cgi?id=44188 for a nice illustration.

Note that the behavior of GCC with your testcase is unrelated to the LLVM issue
and DR 260. And it is even reversed: here with GCC, the result of the
comparison is *incorrect before* the (potentially invalid) copy of the pointer,
and it is *correct after* the copy.

It seems that the reason why the result incorrect before the copy is that GCC
optimizes based on the fact that p and q points to distinct objects (or past to
them), i.e. GCC considers that the pointers are necessarily different in such a
case, without needing a further analysis. For repr and val2, I assume that GCC
gives the correct result because it does not optimize: it just compares the
representations of p and q, which are the same.

> While at it, the testcase also demonstrates that the comparison `p == q` is
> unstable.

p == p would also be unstable: What could happen is that:
1. The implementation evaluates the first p.
2. The representation of p changes.
3. The implementation evaluates the second p.
4. Due to the different representations, the comparison returns false.

[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||nickc at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
   Last reconfirmed||2024-01-26
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944

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

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 57224
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57224&action=edit
2.ii.xz

Unreduced second source.

[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944

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

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 57223
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57223&action=edit
1.ii.xz

Not reduced first source.

[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |14.0

[Bug rtl-optimization/113617] New: [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944

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

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

Bug ID: 113617
   Summary: [14 Regression] Symbol ... referenced in section
`.data.rel.ro.local' of ...: defined in discarded
section ... since r14-4944
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Since r14-4944-gf55cdce3f8dd8503e080e35be59c5f5390f6d95e the following testcase
can't be linked anymore.
for i in 1 2; do ./cc1plus -quiet -O2 -std=c++11 -fPIC -fvisibility=hidden
-fvisibility-inlines-hidden $i.ii; done; g++ -shared -o 1.so 1.s 2.s
`_ZNSt17_Function_handlerIFvvESt5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTools_FunctorInternalIN12_GLOBAL__N_19CountUsesIxEELb0EEExxxEEE10_M_managerERSt9_Any_dataRKSH_St18_Manager_operation'
referenced in section `.data.rel.ro.local' of /tmp/ccEORVfz.o: defined in
discarded section
`.text._ZNSt17_Function_handlerIFvvESt5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTools_FunctorInternalIN12_GLOBAL__N_19CountUsesIxEELb0EEExxxEEE10_M_managerERSt9_Any_dataRKSH_St18_Manager_operation[_ZN26vtkStaticCellLinksTemplateIxE18ThreadedBuildLinksExxP12vtkCellArray]'
of /tmp/ccEORVfz.o
`_ZNSt17_Function_handlerIFvvESt5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTools_FunctorInternalIN12_GLOBAL__N_111InsertLinksIxEELb0EEExxxEEE10_M_managerERSt9_Any_dataRKSH_St18_Manager_operation'
referenced in section `.data.rel.ro.local' of /tmp/ccEORVfz.o: defined in
discarded section
`.text._ZNSt17_Function_handlerIFvvESt5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTools_FunctorInternalIN12_GLOBAL__N_111InsertLinksIxEELb0EEExxxEEE10_M_managerERSt9_Any_dataRKSH_St18_Manager_operation[_ZN26vtkStaticCellLinksTemplateIxE18ThreadedBuildLinksExxP12vtkCellArray]'
of /tmp/ccEORVfz.o

That change adds quite a few changes like:

-   leaq   
_ZNSt17_Function_handlerIFvvESt5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTools_FunctorInternalIN12_GLOBAL__N_19CountUsesIxEELb0EEExxxEEE10_M_managerERSt9_Any_dataRKSH
_St18_Manager_operation(%rip), %rdx
+   movq.LC73(%rip), %xmm3
movq$0, (%rsp)
movq%rax, 32(%rsp)
leaq   
_ZNSt17_Function_handlerIFvvESt5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTools_FunctorInternalIN12_GLOBAL__N_19CountUsesIxEELb0EEExxxEEE9_M_invokeERKSt9_Any_data(%rip),
%rax
-   movq%rdx, %xmm3
...
+   .section.data.rel.ro.local,"aw"
...
+.LC73:
+   .quad  
_ZNSt17_Function_handlerIFvvESt5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTools_FunctorInternalIN12_GLOBAL__N_19CountUsesIxEELb0EEExxxEEE10_M_managerERSt9_Any_dataRKSH_St18_Manager_operation
but as the symbol is defined in a comdat section, that results in the linker
error.
Dunno if this was just latent before, or whether we need to force such
constants also into comdat sections in the same comdat group, etc.

[Bug ada/113605] Fixed-point declaration using an integer where a real is expected causes a crash

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
   Target Milestone|--- |13.0
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Eric Botcazou  ---
Confirmed in GCC 12.x, but fixed in GCC 13.x and later:

p.ads:3:51: error: expected type universal integer
p.ads:3:51: error: found type universal real

[Bug c/85800] A miscompilation bug with unsigned char

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Richard Biener  ---
Yeah.  I think we have enough duplicates that show cases where conditional
equivalence propagation introduces these issues.  Here it's already present in
the source.

[Bug tree-optimization/112687] missed-optimization: switch statement does not simplify to it's expression

[fkastl at suse dot cz via Gcc-bugs]

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

--- Comment #2 from Filip Kastl  ---
Created attachment 57222
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57222&action=edit
WIP patch to fix the missed optimization, version 0

I'm working on a patch. The problem (as Richard stated in pr112645) is that the
testcase gets optimized into

switch (v & 3) {
default:
return 0;
case 1:
return 1;
case 2:
return 2;
case 3:
return 3;
}

so the information that there are only 4 possible values of the expression 'v &
3' is lost.

I add capability for switch conversion to recover from this. With my patch,
before processing the switch, switch conversion finds out if the default case
only corresponds to one possible value of the index expression. If so, it
creates a case for this value and marks default as unreachable.

With the patch applied, functions opt() and unopt() compile into the same
sequence of assembly instructions. I've attached the patch. Do you think this
is a good approach? I'll also appreciate any suggestions/comments for the
patch.

[Bug target/113616] [14 Regression] ICE in process_uses_of_deleted_def, at rtl-ssa/changes.cc:252

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

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

--- Comment #2 from Alex Coplan  ---
I think the problem is this loop (and others that iterate over debug
uses in this way):

  // Now that we've characterized the defs involved, go through the
  // debug uses and determine how to update them (if needed).
  for (auto use : set->debug_insn_uses ())
{
  if (*pair_dst < *use->insn () && defs[1])
// We're re-ordering defs[1] above a previous use of the
// same resource.
update_debug_use (use, defs[1], writeback_pats[1]);
  else if (*pair_dst >= *use->insn ())
// We're re-ordering defs[0] below its use.
update_debug_use (use, defs[0], writeback_pats[0]);
}

because `update_debug_use` can remove uses from the list of debug uses,
we can't use a for-range loop as the iterator will become invalidated
before getting advanced.

Should be fairly straightforward to fix, sorry for the oversight.

[Bug c++/112899] odr-using constexpr static data member of class exported from module results in linker error

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

https://gcc.gnu.org/g:a0dde47f84f17cbe7fa2fb41c14c5a2db8c4d63a

commit r14-8451-ga0dde47f84f17cbe7fa2fb41c14c5a2db8c4d63a
Author: Nathaniel Shead 
Date:   Wed Jan 3 09:27:06 2024 +1100

c++: Emit definitions of ODR-used static members imported from modules
[PR112899]

Static data members marked 'inline' should be emitted in TUs where they
are ODR-used.  We need to make sure that inlines imported from modules
are correctly added to the 'pending_statics' map so that they get
emitted if needed, otherwise the attached testcase fails to link.

PR c++/112899

gcc/cp/ChangeLog:

* cp-tree.h (note_variable_template_instantiation): Rename to...
(note_vague_linkage_variable): ...this.
* decl2.cc (note_variable_template_instantiation): Rename to...
(note_vague_linkage_variable): ...this.
* pt.cc (instantiate_decl): Rename usage of above function.
* module.cc (trees_in::read_var_def): Remember pending statics
that we stream in.

gcc/testsuite/ChangeLog:

* g++.dg/modules/init-4_a.C: New test.
* g++.dg/modules/init-4_b.C: New test.
* g++.dg/modules/init-6_a.H: New test.
* g++.dg/modules/init-6_b.C: New test.

Signed-off-by: Nathaniel Shead 
Reviewed-by: Patrick Palka 
Reviewed-by: Jason Merrill 

[Bug target/113616] [14 Regression] ICE in process_uses_of_deleted_def, at rtl-ssa/changes.cc:252

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

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

Alex Coplan  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Last reconfirmed||2024-01-26
  Known to fail||14.0
 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=113089
 Target||aarch64-*-*
   Assignee|unassigned at gcc dot gnu.org  |acoplan at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Alex Coplan  ---
Confirmed, mine.

[Bug target/113616] [14 Regression] ICE in process_uses_of_deleted_def, at rtl-ssa/changes.cc:252

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||acoplan at gcc dot gnu.org
   Target Milestone|--- |14.0
   Priority|P3  |P1

[Bug target/113616] New: [14 Regression] ICE in process_uses_of_deleted_def, at rtl-ssa/changes.cc:252

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

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

Bug ID: 113616
   Summary: [14 Regression] ICE in process_uses_of_deleted_def, at
rtl-ssa/changes.cc:252
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

struct A { struct A *a; } foo ();
struct B { long b; };
struct C { struct B c; struct A d; } *e;

void
bar (void)
{
  int f;
  struct C *g;
  struct A *h;
  for (g = 0, g = e ? (void *) e - (char) (__SIZE_TYPE__) &g->d : 0, h = g ?
(&g->d)->a : 0; g;
   g = 0, g = h ? (void *) h - (char) (__SIZE_TYPE__) &g->d : 0, h = h ?
h->a : 0)
{
  f = (int) (__SIZE_TYPE__) g;
  foo (((struct B *) g)->b);
}
}

ICEs with -g -O2 on aarch64-linux:
during RTL pass: ldp_fusion
rh2260449.i: In function ‘bar’:
rh2260449.i:17:1: internal compiler error: in process_uses_of_deleted_def, at
rtl-ssa/changes.cc:252
   17 | }
  | ^
0x2c6f609
rtl_ssa::function_info::process_uses_of_deleted_def(rtl_ssa::set_info*)
../../gcc/rtl-ssa/changes.cc:252
0x2c718e1
rtl_ssa::function_info::change_insns(array_slice)
../../gcc/rtl-ssa/changes.cc:839
0x1dc3cbb ldp_bb_info::fuse_pair(bool, unsigned int, int, rtl_ssa::insn_info*,
rtl_ssa::insn_info*, base_cand&, rtl_ssa::insn_range_info const&)
../../gcc/config/aarch64/aarch64-ldp-fusion.cc:2063
0x1dc539e ldp_bb_info::try_fuse_pair(bool, unsigned int, rtl_ssa::insn_info*,
rtl_ssa::insn_info*)
../../gcc/config/aarch64/aarch64-ldp-fusion.cc:2782
0x1dc5627 ldp_bb_info::merge_pairs(std::__cxx11::list >&, std::__cxx11::list >&, bool, unsigned int)
../../gcc/config/aarch64/aarch64-ldp-fusion.cc:2871
0x1dc5816 ldp_bb_info::transform_for_base(int, access_group&)
../../gcc/config/aarch64/aarch64-ldp-fusion.cc:2904
0x1dc801c void
ldp_bb_info::traverse_base_map,
int_hash >, access_group,
simple_hashmap_traits,
int_hash > >, access_group> >
>(ordered_hash_map, int_hash >, access_group,
simple_hashmap_traits,
int_hash > >, access_group> >&)
../../gcc/config/aarch64/aarch64-ldp-fusion.cc:2963
0x1dc5a75 ldp_bb_info::transform()
../../gcc/config/aarch64/aarch64-ldp-fusion.cc:2971
0x1dc01fb ldp_fusion_bb(rtl_ssa::bb_info*)
../../gcc/config/aarch64/aarch64-ldp-fusion.cc:3209
0x1dc0285 ldp_fusion()
../../gcc/config/aarch64/aarch64-ldp-fusion.cc:3218
0x1dc0398 execute
../../gcc/config/aarch64/aarch64-ldp-fusion.cc:3268
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.

[Bug target/113615] New: internal compiler error: in extract_insn, at recog.cc:2812

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

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

Bug ID: 113615
   Summary: internal compiler error: in extract_insn, at
recog.cc:2812
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

I'm seeing a lot of ICEs like this when running libgomp testsuite with
offloading for gfx1030.

/space/rguenther/src/gcc-autopar_devel/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-4.f90:
In function 'accum_._omp_fn.1':^M
/space/rguenther/src/gcc-autopar_devel/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-4.f90:20:38:
error: unrecognizable insn:^M
(insn 108 107 109 6 (set (reg:V8SF 849)^M
(unspec:V8SF [^M
(reg:V8SF 844 [ vect__43.12_106 ]) repeated x2^M
(const_int 1 [0x1])^M
] UNSPEC_PLUS_DPP_SHR))
"/space/rguenther/src/gcc-autopar_devel/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-4.f90":22:29
discrim 1 -1^M  
 (nil))^M
during RTL pass: vregs^M
/space/rguenther/src/gcc-autopar_devel/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-4.f90:20:38:
internal compiler error: in extract_insn, at recog.cc:2812^M

other ones:

(insn 93 92 94 7 (set (reg:V64DF 805)^M
(unspec:V64DF [^M
(reg:V64DF 802 [ vect__31.53_89 ])^M
(const_int 1 [0x1])^M
] UNSPEC_MOV_DPP_SHR))
"/space/rguenther/src/gcc-autopar_devel/libgomp/testsuite/libgomp.fortran/examples-4/target_data-3.f90":51:41
-1^M

[Bug c/85800] A miscompilation bug with unsigned char

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
To me the testcase looks invalid.
int B[4], A[4];
...
store_10_to_p(A, &B[4]);
...
memcpy((unsigned char*)arr2, (unsigned char *)&q, sizeof(q));

Constructing &B[4] is valid, it is a pointer to one past the last element of
the array object.  But C99 6.5.6/8
"If the result points one past the last element of the array object, it
shall not be used as the operand of a unary * operator that is evaluated."
then triggers during the memcpy when the pointer is dereferenced.
Doesn't matter that the A array starts at the same address, you'd need to use A
or &A[0] etc. instead of &B[4] to make it valid.