[Bug tree-optimization/102949] [12 regression] gcc.dg/vect/slp-reduc-1.c FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102949 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #7 from Richard Biener --- > Fixed (by inspecting assembly). Indeed: the execution tests PASS again. Thanks.
[Bug tree-optimization/102714] [10/11 Regression] A volatile-related problem cased by ipa inline pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102714 Richard Biener changed: What|Removed |Added Summary|[11 Regression] A |[10/11 Regression] A |volatile-related problem|volatile-related problem |cased by ipa inline pass|cased by ipa inline pass Target Milestone|11.3|10.4
[Bug target/102993] -fcf-protection=full produces segfaulting code when targeting 32-bit x86 (i686)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102993 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2021-10-29 --- Comment #4 from Eric Botcazou --- Nobody uses SJLJ exceptions these days though. Where does this compiler come from exactly?
[Bug driver/102803] Bug: -no-canonical-prefixes not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803 Carlos Galvez changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #9 from Carlos Galvez --- Ok I've built from source with a different configuration than Ubuntu's and the -no-canonical-prefixes works as expected! So indeed it must be something in the Ubuntu configuration. I will then go and diff the configs to get to the root of this. Closing the bug as it's definitely not on GCC side, sorry for the confusion and thanks a lot for the help!
[Bug c++/102820] [DR2351] Failure to compile void{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102820
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:eca767aa51d1f69614222ceb130ca6bb07713232
commit r12-4782-geca767aa51d1f69614222ceb130ca6bb07713232
Author: Jakub Jelinek
Date: Fri Oct 29 09:28:32 2021 +0200
c++: Implement DR2351 - void{} [PR102820]
Here is an implementation of DR2351 - void{} - where void{} after
pack expansion is considered valid and the same thing as void().
For templates, if CONSTRUCTOR_NELTS is 0, the CONSTRUCTOR is not dependent
and we can return void_node right away, if it is dependent and contains
only packs, then it is potentially zero element and so we need to build
CONSTRUCTOR_IS_DEPENDENT CONSTRUCTOR, while if it contains any non-pack
elts, we can diagnose it right away.
2021-10-29 Jakub Jelinek
PR c++/102820
* semantics.c (maybe_zero_constructor_nelts): New function.
(finish_compound_literal): Implement DR2351 - void{}.
If type is cv void and compound_literal has no elements, return
void_node. If type is cv void and compound_literal might have no
elements after expansion, handle it like other dependent compound
literals.
* g++.dg/cpp0x/dr2351.C: New test.
[Bug c++/102820] [DR2351] Failure to compile void{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102820 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Implemented now.
[Bug c++/94404] [meta-bug] C++ core issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
Bug 94404 depends on bug 102820, which changed state.
Bug 102820 Summary: [DR2351] Failure to compile void{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102820
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
[Bug c++/102995] New: Template friend class declaration of same class with different template parameters fails to allow private methods access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102995
Bug ID: 102995
Summary: Template friend class declaration of same class with
different template parameters fails to allow private
methods access
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jdapena at igalia dot com
Target Milestone: ---
Created attachment 51698
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51698&action=edit
Test case
Declaring a template friend class to the same class fails to resolve the access
to private members in its methods.
The provided example fails with this error:
$ g++ main.cc
main.cc: In instantiation of 'bool operator==(const First&, const
First&) [with C = void*; A = int; B = bool]':
main.cc:23:15: required from here
main.cc:13:61: error: 'int First::GetId() const [with A = void*; B =
bool]' is private within this context
13 | return lhs.GetId() == rhs.GetId();
|~^~
main.cc:6:9: note: declared private here
6 | int GetId() const {
| ^
The same case works in Clang (verified with Clang 9.0.1).
This issue is exposed in Chromium, compiling base/raw_ptr.h unit tests on GCC.
I created a simplified version of the problem. See:
https://chromium.googlesource.com/chromium/src/base/+/821f1e481ce7c51d31486f26a74d343ffe4cf70e/memory/raw_ptr.h#496
(declaration of the method that should have friend access to rhs private
methods).
https://chromium.googlesource.com/chromium/src/base/+/821f1e481ce7c51d31486f26a74d343ffe4cf70e/memory/raw_ptr.h#584
(the friend class declaration).
https://chromium.googlesource.com/chromium/src/base/+/821f1e481ce7c51d31486f26a74d343ffe4cf70e/memory/raw_ptr_unittest.cc#328
(failing test compilation).
[Bug c/102996] New: No warning on use dereferencing of uninitialized point in an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102996
Bug ID: 102996
Summary: No warning on use dereferencing of uninitialized point
in an array
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz1 at gmx dot com
Target Milestone: ---
Consider the following two functions:
void foo() {
int *as[2];
*(as[0])=1;
}
void bar() {
int i = 0;
int *as[2];
for(i=0;i<1;i++)
{
*(as[i])=i;
}
}
When compiling these with -Wall, we get warnings about the uninitialized use of
as in the first function, but not in the second one.
GodBolt: https://godbolt.org/z/Ta9fWYWs6
Inspired by this StackOverflow question:
https://stackoverflow.com/q/69764896/1593077
[Bug libstdc++/102984] strange alignment issues with std::vector::emplace/push_back and overaligned type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102984 Milian Wolff changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #8 from Milian Wolff --- Hey Jonathan, that's quite odd... Today I fail to reproduce this on my system too. Yesterday I also noticed that it worked on godbolt but forgot to mention it here - sorry about that. I also tried to reduce this issue to passing aligned temporaries in code outside of std::vector, but that didn't help either. And when I'm trying today, the issue suddenly vanished, maybe there was a system update which helped in that regard, mysterious. For the record, here's the requested information from today, which does _not_ show the broken behavior anymore. the exact version of GCC; g++ (GCC) 11.1.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. the system type; Linux milian-workstation 5.14.14-arch1-1 #1 SMP PREEMPT Wed, 20 Oct 2021 21:35:18 + x86_64 GNU/Linux ArchLinux with all latest updates the options given when GCC was configured/built; g++ --verbose Using built-in specs. COLLECT_GCC=/usr/bin/g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.1.0 (GCC) the complete command line that triggers the bug; the compiler output (error messages, warnings, etc.); and both specified in the original message already the preprocessed file (*.i*) that triggers the bug, generated by adding -save-temps to the complete compilation command, or, in the case of a bug report for the GNAT front end, a complete set of source files (see below). I'm going to close this report and will reopen it with more details once I can reproduce this again.
[Bug target/102993] -fcf-protection=full produces segfaulting code when targeting 32-bit x86 (i686)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102993 --- Comment #5 from Richard Biener --- I think we still default to those for 32bit unless you configure with --disable-sjlj-exceptions.
[Bug tree-optimization/102714] [10/11 Regression] A volatile-related problem cased by ipa inline pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102714 --- Comment #8 from Bo Duan --- (In reply to Richard Biener from comment #7) > (In reply to Bo Duan from comment #6) > > Hello, should we backport this patch to gcc-10? > > It's scheduled for a backport to GCC 11, I'm not aware that GCC 10 is > affected? At first, I found this problem on gcc10.2, so GCC 10 also be affected.
[Bug target/102993] -fcf-protection=full produces segfaulting code when targeting 32-bit x86 (i686)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102993 --- Comment #6 from Eric Botcazou --- > I think we still default to those for 32bit unless you configure with > --disable-sjlj-exceptions. Yes, everybody should configure with it.
[Bug libstdc++/102984] strange alignment issues with std::vector::emplace/push_back and overaligned type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102984 Jonathan Wakely changed: What|Removed |Added Resolution|FIXED |WORKSFORME --- Comment #9 from Jonathan Wakely --- Not FIXED then, because there was nothing to fix. WORKSFORME is the right resolution.
[Bug c/102985] [openmp] Bogus "error: lastprivate variable ‘n’ is private in outer context"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102985 --- Comment #2 from Jakub Jelinek --- Actually, I think 5.2 got this right and thus the testcase is not valid in 5.2. This is because of the introduction of work-distribution constructs term. For lastprivate the restriction now says: "A list item must not appear in a lastprivate clause on a work-distribution construct if the corresponding region binds to the region of a parallelism-generating construct in which the list item is private." This is violated in those testcases, the lastprivate original list item is private in teams there.
[Bug tree-optimization/102880] [12 Regression] Dead Code Elimination Regression at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102880 --- Comment #5 from Richard Biener --- Created attachment 51699 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51699&action=edit hack to make forwarders This is an overly simple attempt to make forwarders which works to restore the DCE. Given this it probably makes sense to at least move the early merge_phi pass after CD-DCE. That doesn't help this testcase since regular CFG cleanup performs the merging in our case. It's remove_forwarder_block will perform this. An alternative band-aid would be to resolve the regression by not running CFG cleanup after DSE (we're failing to run it when we empty a BB as well, something we might want to fix instead). Undoing PHI merging might be also a good thing to perform before going out of SSA. And merge_phi itself might do this as a 2nd step.
[Bug target/102991] [12 regression] gcc.dg/vect/vect-simd-17.c fails after r12-4757
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102991 --- Comment #1 from luoxhu at gcc dot gnu.org --- Couldn't reproduce on rain6p1 (P10): Test run by luoxhu on Fri Oct 29 04:08:49 2021 Native configuration is powerpc64le-unknown-linux-gnu === gcc tests === Schedule of variations: unix Running target unix Running /home/luoxhu/workspace/gcc/gcc/testsuite/gcc.dg/vect/vect.exp ... PASS: gcc.dg/vect/vect-simd-17.c (test for excess errors) PASS: gcc.dg/vect/vect-simd-17.c execution test PASS: gcc.dg/vect/vect-simd-17.c -flto -ffat-lto-objects (test for excess errors) PASS: gcc.dg/vect/vect-simd-17.c -flto -ffat-lto-objects execution test === gcc Summary === # of expected passes4 /home/luoxhu/workspace/build/gcc/xgcc version 12.0.0 20211029 (experimental) (GCC)
[Bug fortran/102966] size() returns 0 for an unallocated array, no error message or error exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102966 --- Comment #7 from Bastiaan Braams --- Pleased to see that the run-time error is properly diagnosed in version 11.2.1 and later, and agreed that the matter is outside the fortran language standard. Just one comment on the discussion in view of the WONTFIX label: the failure to generate a run-time error for this code may be viewed, I think, as a bug against the specification of the -fcheck=all option, which includes -fcheck=pointer with the description "Enable generation of run-time checks for pointers and allocatables." It appears that an appropriate run-time check was not generated.
[Bug fortran/102966] size() returns 0 for an unallocated array, no error message or error exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102966 --- Comment #8 from Jakub Jelinek --- What checks are emitted evolves over time...
[Bug c/102996] No warning on dereferencing of uninitialized pointer in an array, in a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102996 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-10-29 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Blocks||24639 Keywords||diagnostic --- Comment #1 from Richard Biener --- The foo form is handled by the early uninit pass but the bar form is optimized away as dead before we get to do a late warning. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug target/102991] [12 regression] gcc.dg/vect/vect-simd-17.c fails after r12-4757
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102991 Kewen Lin changed: What|Removed |Added CC||linkw at gcc dot gnu.org --- Comment #2 from Kewen Lin --- (In reply to luoxhu from comment #1) > Couldn't reproduce on rain6p1 (P10): > It's weird, I can reproduce this on rain6p1. FAIL: gcc.dg/vect/vect-simd-17.c execution test FAIL: gcc.dg/vect/vect-simd-17.c -flto -ffat-lto-objects execution test >--->---=== gcc Summary === # of expected passes>--->---2 # of unexpected failures>---2 Probably due to you still specified --with-cpu=power9 instead of --with-cpu=power10 in gcc configuration?
[Bug rtl-optimization/102986] [12 Regression] ICE: in expand_shift_1, at expmed.c:2671 with a negative shift of a vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102986
Jakub Jelinek changed:
What|Removed |Added
CC||sayle at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
/* PR target/102986 */
/* { dg-do compile } */
/* { dg-options "-O2" } */
typedef unsigned __int128 __attribute__((__vector_size__ (16))) V;
V v;
void
foo (int x)
{
v >>= x;
}
ICEs too.
The shift expanders aren't allowed to fail, at least when may_fail isn't set in
calls to expand_shift_1, but the new expanders only allow const_int_operand and
so ICE if the shift amount is not constant or it is an out of bounds shift (in
that case the code earlier forces the shift amount into a register).
I guess a way out of this would be to change the predicate from
"const_int_operand" to "nonmemory_operand" and if the last operand isn't
CONST_INT in ix86_expand_v1ti_shift, subreg the first operand to TImode,
expand_variable_shift it (unfortunately with make_tree on the second operand,
or
instead export expand_shift_1 and use that directly?) and then subreg to
V1TImode back.
[Bug libfortran/102992] Piping in a file does no longer work on macOS Monterey
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 --- Comment #5 from Jürgen Reuter --- I checked that the assembler code on macOS Big Sur and Monterey is identical (up to the date in the .ident line). So either the assembler works differently, or one of the routines from the libgfortran (_gfortrran_st_write, _gfortran_set_options, _gfortran_set_args, _gfortran_transfer_character_write) acts differently now.
[Bug rtl-optimization/102986] [12 Regression] ICE: in expand_shift_1, at expmed.c:2671 with a negative shift of a vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102986 --- Comment #3 from Jakub Jelinek --- Or tree-vect-generic.c would need to check the predicates of the vector shift and try to figure out if they accept REGs or not. But no idea how to do that cleanly, the predicate could be very well some target specific predicate...
[Bug middle-end/102997] New: 45% calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7 on Zen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997 Bug ID: 102997 Summary: 45% calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7 on Zen Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- This is seen on zen3 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=474.170.0 zen2 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=288.170.0 zen1 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=8.170.0 Changes in range: commit 6fca1761a16c68740f875fc487b98b6bde8e9be7 Author: Aldy Hernandez Date: Wed Oct 20 07:15:17 2021 +0200 Remove unused back_threader destructor. Tested on x86-64 Linux. gcc/ChangeLog: * tree-ssa-threadbackward.c (back_threader::~back_threader): Remove. commit 8b7f9c40ef42411b6f51b508d41a580d4682069e Author: Aldy Hernandez Date: Tue Oct 19 10:26:47 2021 +0200 Remove superflous debugging messages from the threading registry. These are some random obvious cleanups to the threading dumps, since it seems I'm not the only one looking at dumps these days. The "just threaded" debugging message is redundant since there's already an equivalent "Registering jump thread" message. The "about to thread" message is actually confusing, because the source block doesn't match the IL, since the CFG update is mid-flight. Tested on x86-64 Linux. gcc/ChangeLog: * tree-ssa-threadupdate.c (back_jt_path_registry::adjust_paths_after_duplication): Remove superflous debugging message. (back_jt_path_registry::duplicate_thread_path): Same. commit 18606d776642a876a787c37491c52b81c30ebc83 Author: Bob Duff Date: Sat Oct 16 15:30:45 2021 -0400 [Ada] Remove unnecessary call to No_Uint_To_0 gcc/ada/ * gcc-interface/decl.c (gnat_to_gnu_entity): Remove unnecessary call to No_Uint_To_0. commit 4afb464e1f76d63d89c4034f78d5ebb3400eaf3c Author: Richard Kenner Date: Thu Oct 14 15:31:38 2021 -0400 [Ada] Never treat intrinsic subprograms as nested gcc/ada/ * exp_unst.adb (Visit_Node, when N_Subprogram_Call): Never treat instrinsic subprograms as nested. commit bd2560b726fa93b61060a9f469ad288c512961f3 Author: Yannick Moy Date: Mon Aug 30 16:33:00 2021 +0200 [Ada] Proof of the runtime support for attribute 'Width gcc/ada/ * libgnat/s-widlllu.ads: Mark in SPARK. * libgnat/s-widllu.ads: Likewise. * libgnat/s-widuns.ads: Likewise. * libgnat/s-widthu.adb: Add ghost code and a pseudo-postcondition. commit c5742a0e1191365c57bc06fdbf1ff5da1028f127 Author: Yannick Moy Date: Fri Oct 15 12:00:16 2021 +0200 [Ada] Provide dummy body for big integers library used in reduced runtimes gcc/ada/ * libgnat/a-nbnbin__ghost.adb (Signed_Conversions, Unsigned_Conversions): Mark subprograms as not imported. * libgnat/a-nbnbin__ghost.ads: Provide a dummy body. commit 723d09e8895733f065200fa1b54c84243cf96f69 Author: Eric Botcazou Date: Thu Oct 14 15:44:48 2021 +0200 [Ada] Fix problematic conversion of real literal in static context gcc/ada/ * sem_eval.adb (Eval_Type_Conversion): If the target subtype is a static floating-point subtype and the result is a real literal, consider its machine-rounded value to raise Constraint_Error. (Test_In_Range): Turn local variables into constants. commit f6f8b3f95e55084b59ecc8fbe0f0cfd485d58c39 Author: Doug Rupp Date: Thu Oct 14 08:41:56 2021 -0700 [Ada] Delete unused runtime files gcc/ada/ * libgnat/g-io-put__vxworks.adb: Remove (unused) * libgnat/s-parame__ae653.ads: Likewise. * libgnat/s-thread.ads: Likewise. * libgnat/s-thread__ae653.adb: Likewise. commit 60440d3cf51acb9cb63543d5bb71fd50cfdd9470 Author: Eric Botcazou Date: Wed Oct 13 20:50:28 2021 +0200 [Ada] Factor out machine rounding operations gcc/ada/ * sem_eval.ads (Machine_Number): New inline function. * sem_eval.adb (Machine_Number): New function body implementing the machine rounding operation specified by RM 4.9(38/2). (Check_Non_Static_Context): Call Machine_Number and set the Is_Machine_Number flag consistently on the resulting node. * sem_attr.adb (Eval_Attribute) : Likewise. * checks.adb (Apply_Float_Conversion_Check): Call Machine_Number. (Round_Machine): Likewise. commit 931d4819f740ade970
[Bug c/102996] No warning on dereferencing of uninitialized pointer in an array, in a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102996 --- Comment #2 from Eyal Rozenberg --- (In reply to Richard Biener from comment #1) > The foo form is handled by the early uninit pass Since _none_ of `as` is initialized, one could argue that an early uninit pass could catch that as well.
[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7 on Z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 CC||rguenth at gcc dot gnu.org Target||x86_64-*-* Keywords||missed-optimization, ||needs-bisection Summary|45% calculix regression |[12 Regression] 45% |with LTO+PGO -march=native |454.calculix regression |-Ofast between |with LTO+PGO -march=native |ce4d1f632ff3f680550d3b186b6 |-Ofast between |0176022f41190 and |ce4d1f632ff3f680550d3b186b6 |6fca1761a16c68740f875fc487b |0176022f41190 and |98b6bde8e9be7 on Zen|6fca1761a16c68740f875fc487b ||98b6bde8e9be7 on Zen --- Comment #1 from Richard Biener --- Not seen on Haswell (but w/o PGO). Is this PGO specific? There's another large jump visible end of 2019.
[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7 on Z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997 --- Comment #2 from Richard Biener --- Btw, IIRC calculix train data and ref data do not match up wrt the hottest loops, so not sure whether any regression here is considered important. Maybe the profile is now preserved better. I can't reproduce any slowdown w/o PGO.
[Bug c/102998] New: Wrong documentation for -Warray-parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102998 Bug ID: 102998 Summary: Wrong documentation for -Warray-parameter Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html says: > For example, the warning triggers for the following redeclarations because > the first one allows an array of any size to be passed to f while the second > one with the keyword static specifies that the array argument must have at > least four elements. > > void f (int[static 4]); > void f (int[]); // warning (inconsistent array form) 1. The words 'first' and 'second' should be swapped. 2. Why should there be a warning? The array from malloc is large enough, it has exactly 4 elements.
[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7 on Z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997 --- Comment #3 from Richard Biener --- train data: Samples: 6K of event 'cycles', Event count (approx.): 7715838425 Overhead Samples Command Shared Object Symbol 5.68% 382 calculix_peak.a calculix_peak.amd64-m64-mine [.] insert.isra.0 3.89% 262 calculix_peak.a calculix_peak.amd64-m64-mine [.] isortii_ 2.36% 161 specperl specperl [.] Perl_hv_common 1.94% 132 calculix_peak.a calculix_peak.amd64-m64-mine [.] add_sm_st_ 1.69% 115 specperl specperl [.] S_regtry ref data: Samples: 601K of event 'cycles', Event count (approx.): 678304336437 Overhead Samples Command Shared Object Symbol 45.51%274231 calculix_peak.a calculix_peak.amd64-m64-mine [.] e_c3d_.constprop.0 16.59%100331 calculix_peak.a calculix_peak.amd64-m64-mine [.] DVdot33 7.91% 47070 calculix_peak.a calculix_peak.amd64-m64-mine [.] GPart_smoothYSep 3.54% 21391 calculix_peak.a calculix_peak.amd64-m64-mine [.] Chv_updateS 3.22% 19378 calculix_peak.a calculix_peak.amd64-m64-mine [.] add_sm_st_ 2.71% 16238 calculix_peak.a calculix_peak.amd64-m64-mine [.] SubMtx_sortColumnsUp 2.43% 14549 calculix_peak.a calculix_peak.amd64-m64-mine [.] IVqsortUp
[Bug c/102998] Wrong documentation for -Warray-parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102998 --- Comment #1 from Roland Illig --- > for the following redeclarations That's wrong. There is only 1 redeclaration in the code that follows.
[Bug target/102986] [12 Regression] ICE: in expand_shift_1, at expmed.c:2671 with a negative shift of a vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102986 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com Status|NEW |ASSIGNED Component|rtl-optimization|target Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com --- Comment #4 from Roger Sayle --- My apologies for the inconvenience. I'm already bootstrapping and regression testing a fix that I'd hoped to submit before anyone noticed the breakage.
[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7 on Z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997 --- Comment #4 from hubicka at kam dot mff.cuni.cz --- > Not seen on Haswell (but w/o PGO). Is this PGO specific? There's another > large jump visible end of 2019. This is kabylake LTO+PGO+march=native https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=5.170.0 seems there are no regressions. Does not seem to reproduce on zens with -flto -Ofast -march=native neighter with PGO but non-lto. It is indeed possible that we misbehave based on profile, but I do not see anything related to that in the revision range. Honza
Re: [Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7
> Not seen on Haswell (but w/o PGO). Is this PGO specific? There's another > large jump visible end of 2019. It is between 2019-11-15 and 18 but the revisions does not exist at git - perhaps they reffer to the old git mirror. Martin will know better. In that range there are many of Richard's vectorizer changes and my patch fixing calculation of ref time in inliner which may be culprints. Honza
[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7 on Z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997 --- Comment #5 from hubicka at kam dot mff.cuni.cz --- > Not seen on Haswell (but w/o PGO). Is this PGO specific? There's another > large jump visible end of 2019. It is between 2019-11-15 and 18 but the revisions does not exist at git - perhaps they reffer to the old git mirror. Martin will know better. In that range there are many of Richard's vectorizer changes and my patch fixing calculation of ref time in inliner which may be culprints. Honza
[Bug tree-optimization/102977] [12 Regression] vectorizer failed to use armv8.3-a complex fma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102977 --- Comment #9 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:ed3de62ac949c92ad41ef6de7cc926fbb2a510ce commit r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce Author: Tamar Christina Date: Fri Oct 29 12:45:41 2021 +0100 middle-end: Update the Arm complex numbers auto-vec detection to the new format of the SLP tree. The layout of the SLP tree has changed in GCC 12 which broke the detection of complex FMA and FMS. This patch updates the detection to the new tree shape and by necessity merges the complex MUL and FMA detection into one. This does not yet address the wrong code-gen PR which I will fix in a different patch as that needs backporting. gcc/ChangeLog: PR tree-optimization/102977 * tree-vect-slp-patterns.c (vect_match_call_p): Remove. (vect_detect_pair_op): Add crosslane check. (vect_match_call_complex_mla): Remove. (class complex_mul_pattern): Update comment. (complex_mul_pattern::matches): Update detection. (class complex_fma_pattern): Remove. (complex_fma_pattern::matches): Remove. (complex_fma_pattern::recognize): Remove. (complex_fma_pattern::build): Remove. (class complex_fms_pattern): Update comment. (complex_fms_pattern::matches): Remove. (complex_operations_pattern::recognize): Remove complex_fma_pattern
[Bug tree-optimization/102977] [12 Regression] vectorizer failed to use armv8.3-a complex fma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102977 --- Comment #10 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:4045d5fa42f2ee7b284977c8f2f0edc300a63e43 commit r12-4786-g4045d5fa42f2ee7b284977c8f2f0edc300a63e43 Author: Tamar Christina Date: Fri Oct 29 12:47:39 2021 +0100 middle-end: Add target independent tests for Arm complex numbers vectorization. This beefs up the complex numbers vectorization testsuite and adds target independent checks next to the target dependent ones. This allows regressions to the detection code to be found when running on any target, not just aarch64. gcc/testsuite/ChangeLog: PR tree-optimization/102977 * gcc.dg/vect/complex/bb-slp-complex-add-pattern-int.c: Updated. * gcc.dg/vect/complex/bb-slp-complex-add-pattern-long.c: Updated. * gcc.dg/vect/complex/bb-slp-complex-add-pattern-short.c: Updated. * gcc.dg/vect/complex/bb-slp-complex-add-pattern-unsigned-int.c: Updated. * gcc.dg/vect/complex/bb-slp-complex-add-pattern-unsigned-long.c: Updated. * gcc.dg/vect/complex/bb-slp-complex-add-pattern-unsigned-short.c: Updated. * gcc.dg/vect/complex/fast-math-bb-slp-complex-add-double.c: * gcc.dg/vect/complex/fast-math-bb-slp-complex-add-float.c: Updated. * gcc.dg/vect/complex/fast-math-bb-slp-complex-add-half-float.c: Updated. * gcc.dg/vect/complex/fast-math-bb-slp-complex-add-pattern-double.c: Updated. * gcc.dg/vect/complex/fast-math-bb-slp-complex-add-pattern-float.c: Updated. * gcc.dg/vect/complex/fast-math-bb-slp-complex-add-pattern-half-float.c: Updated. * gcc.dg/vect/complex/fast-math-bb-slp-complex-mla-double.c: Updated. * gcc.dg/vect/complex/fast-math-bb-slp-complex-mla-float.c: Updated. * gcc.dg/vect/complex/fast-math-bb-slp-complex-mla-half-float.c: Updated. * gcc.dg/vect/complex/fast-math-bb-slp-complex-mls-double.c: Updated. * gcc.dg/vect/complex/fast-math-bb-slp-complex-mls-float.c: Updated. * gcc.dg/vect/complex/fast-math-bb-slp-complex-mls-half-float.c: Updated. * gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-double.c: Updated. * gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-float.c: Updated. * gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-half-float.c: Updated. * gcc.dg/vect/complex/fast-math-complex-add-double.c: Updated. * gcc.dg/vect/complex/fast-math-complex-add-float.c: Updated. * gcc.dg/vect/complex/fast-math-complex-add-half-float.c: Updated. * gcc.dg/vect/complex/fast-math-complex-add-pattern-double.c: Updated. * gcc.dg/vect/complex/fast-math-complex-add-pattern-float.c: Updated. * gcc.dg/vect/complex/fast-math-complex-add-pattern-half-float.c: Updated. * gcc.dg/vect/complex/fast-math-complex-mla-double.c: Updated. * gcc.dg/vect/complex/fast-math-complex-mla-float.c: Updated. * gcc.dg/vect/complex/fast-math-complex-mla-half-float.c: Updated. * gcc.dg/vect/complex/fast-math-complex-mls-double.c: Updated. * gcc.dg/vect/complex/fast-math-complex-mls-float.c: Updated. * gcc.dg/vect/complex/fast-math-complex-mls-half-float.c: Updated. * gcc.dg/vect/complex/fast-math-complex-mul-double.c: Updated. * gcc.dg/vect/complex/fast-math-complex-mul-float.c: Updated. * gcc.dg/vect/complex/fast-math-complex-mul-half-float.c: Updated. * gcc.dg/vect/complex/vect-complex-add-pattern-byte.c: Updated. * gcc.dg/vect/complex/vect-complex-add-pattern-int.c: Updated. * gcc.dg/vect/complex/vect-complex-add-pattern-long.c: Updated. * gcc.dg/vect/complex/vect-complex-add-pattern-short.c: Updated. * gcc.dg/vect/complex/vect-complex-add-pattern-unsigned-byte.c: Updated. * gcc.dg/vect/complex/vect-complex-add-pattern-unsigned-int.c: Updated. * gcc.dg/vect/complex/vect-complex-add-pattern-unsigned-long.c: Updated. * gcc.dg/vect/complex/vect-complex-add-pattern-unsigned-short.c: Updated. * gcc.dg/vect/complex/bb-slp-complex-add-pattern-byte.c: Removed. * gcc.dg/vect/complex/bb-slp-complex-add-pattern-unsigned-byte.c: Removed.
[Bug tree-optimization/102977] [12 Regression] vectorizer failed to use armv8.3-a complex fma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102977 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Tamar Christina --- Fixed in current trunk.
[Bug libfortran/102992] Piping in a file does no longer work on macOS Monterey
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 --- Comment #6 from Iain Sandoe --- I had a brief look at some new fails on macOS12 / Darwin21 for gcov. It seems that .mod_term_funcs entries are not being run - so if libgfortran relies on something defined as __attribute__((destructor)) [e.g. to flush file output] that might explain the issue.
[Bug libfortran/102992] Piping in a file does no longer work on macOS Monterey
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 --- Comment #7 from Iain Sandoe --- (although , the output is fine when not redirected, so perhaps that's irrelevant)
[Bug tree-optimization/102058] [12 regression] 450.soplex regressed on x86_64 with -Ofast -march=generic (by 8-15%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102058 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Summary|450.soplex regressed on |[12 regression] 450.soplex |x86_64 with -Ofast |regressed on x86_64 with |-march=generic (by 8-15%) |-Ofast -march=generic (by ||8-15%) --- Comment #3 from Jan Hubicka --- This still shows comparing trunk to gcc11 on lnt, so marking as regression
[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 Iain Sandoe changed: What|Removed |Added Summary|Piping in a file does no|fortran: redirecting |longer work on macOS|standard out to a file does |Monterey|not work on macOS 12.0 --- Comment #8 from Iain Sandoe --- I have checked Ada, C++, C, Objective-C++ and Objective-C and they all behave as expected.
[Bug middle-end/71065] Missing diagnostic for statements between OpenMP 'target' and 'teams'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71065 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus --- >From IRC: "because many statements could be added by the compiler in between for whatever reasons (e.g. statements needed for the clauses of the teams construct) "so the checking would need to be done very early on the FE side before we start handling the clauses "bet easier done on the Fortran FE side..."
[Bug middle-end/71065] Missing diagnostic for statements between OpenMP 'target' and 'teams'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71065
--- Comment #4 from Tobias Burnus ---
>From IRC: "testcases where nothing should be diagnosed would include e.g.
lambdas in expressions inside of teams clauses and similar nastiness"
Simple examples:
#pragma omp target map(tofrom: b[0:100])
{
int n;
#pragma omp teams
#pragma omp distribute simd aligned(b: 8*sizeof(int))
for(int k=0; k
[Bug tree-optimization/101908] [12 regression] cray regression with -O2 -ftree-slp-vectorize compared to -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101908 --- Comment #16 from hubicka at kam dot mff.cuni.cz --- > It will only help for V2DF I think, so no, not really. But an IPA idea of > whether there's cross-call STLF issues might be nice. > > Generally doing wider stores is fine but of course if structs end up > "misaligned" then doing wide loads tends to run into these issues. Well, we don't do this kind of analysis intraprocedurally, doing it interprocedurally will be just harder. I guess intraprocedurally we copy propagate most of the obvious cases, which would correspond to IPA-SRAing the structure. > > But then - just fix the CPUs :P Seem to be hard problem for hardware architects :) Honza
[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 --- Comment #9 from Jürgen Reuter --- I also tried that for a Fortran program ./a.out | less (pipe to less) works. It's just the redirection that does not work. I'm waiting for the compilation to check whether gfortran 11.2 from Macports shares the same problem.
[Bug tree-optimization/102983] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102983 --- Comment #3 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:cb596fd43667f92c4cb037a4ee8b2061c393ba60 commit r12-4788-gcb596fd43667f92c4cb037a4ee8b2061c393ba60 Author: Andrew MacLeod Date: Thu Oct 28 13:31:17 2021 -0400 Perform on-entry propagation after range_of_stmt on a gcond. Propagation is automatically done by the temporal cache when defs are out of date from the names on the RHS, but a gcond has no LHS, and any updates on the RHS are never propagated. Always propagate them. gcc/ PR tree-optimization/102983 * gimple-range-cache.h (propagate_updated_value): Make public. * gimple-range.cc (gimple_ranger::range_of_stmt): Propagate exports when processing gcond stmts. gcc/testsuite/ * gcc.dg/pr102983.c: New.
[Bug tree-optimization/102983] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102983 Andrew Macleod changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Macleod --- Rather than trying to fix this after the fact in the VRP folder when something is simplified, I fixed it directly inside ranger when it is processing gcond statements. Ranger will now update the cache following any range_of_stmt calls on a gcond so we will always be up to date. This way non-vrp clients will also get the same updates.
[Bug tree-optimization/102996] No warning on dereferencing of uninitialized pointer in an array, in a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102996 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Component|c |tree-optimization --- Comment #3 from Martin Sebor --- The early uninit pass deliberately defers the conditional cases to the late pass to avoid false positives. It only handles straightforward unconditionally uninitialized reads. It could probably do better.
[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 --- Comment #10 from Jürgen Reuter --- Reassuringly, the gfortran 11.2 from Macports has the same problem as the gfortran 12.0.0 installed by hand: no redirecting into files.
[Bug c/91669] #pragma's and _Pragma's work but _Pragma's used in an equivalent macro don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91669 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus --- I note that preprocessing itself is working. That is using -save-temps which first preprocesses the file and then runs the result on the compiler works but doing everything in one step doesn't.
[Bug c++/102999] New: g++-11 regression: sorry, unimplemented: unexpected AST of kind nontype_argument_pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102999
Bug ID: 102999
Summary: g++-11 regression: sorry, unimplemented: unexpected
AST of kind nontype_argument_pack
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cantonios at google dot com
Target Milestone: ---
The following code works with g++ in versions prior to 11, as well as all
versions of clang, but fails as of at least 11.1 (according to godbolt).
---
#include
template
struct numeric_list {};
template struct concat;
template
struct concat, numeric_list > { typedef
numeric_list type; };
template struct take;
// The following fail in gcc-11.*.
template struct take> : concat, typename take>::type> {};
template struct take>
{ typedef numeric_list type; };
templatestruct take<0, numeric_list> { typedef numeric_list type; };
template struct take<0, numeric_list>
{ typedef numeric_list type; };
int main() {
typedef numeric_list a;
typedef typename take<6, a>::type b;
return 0;
}
---
: In instantiation of 'struct take<1, numeric_list >':
:13:50: recursively required from 'struct take<5, numeric_list >'
:13:50: required from 'struct take<6, numeric_list >'
:20:30: required from here
:13:50: sorry, unimplemented: unexpected AST of kind
nontype_argument_pack
13 | template struct take> : concat, typename take>::type> {};
|
---
https://godbolt.org/z/4fMafha3z
Local version info:
$ g++-11 --version
g++-11 (Debian 11.2.0-8) 11.2.0
The code is extracted from Eigen
(https://gitlab.com/libeigen/eigen/-/blob/master/unsupported/Eigen/CXX11/src/util/CXX11Meta.h).
We're trying to expand our CI coverage, and noticed that it fails to build for
gcc-11.
[Bug fortran/99250] [F2018] coshape intrinsic is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99250 --- Comment #2 from sandra at gcc dot gnu.org --- Hmmm. I've been going through the list at https://gcc.gnu.org/wiki/Fortran2018Status and there really are a large number of unimplemented F2018 features, not just this one. :-( Anyway, I added a link to this PR from that table.
[Bug c++/102980] [10/11/12 Regression] Fail to get an r-value from std::array::size in a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102980 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c/91669] #pragma's and _Pragma's work but _Pragma's used in an equivalent macro don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91669 --- Comment #3 from Tobias Burnus --- Comparing the two inside handle_pragma_visibility: * the no-save-temps version has as 'loc' the line pointing to _Pragma(#__VA_ARGS__) * with -save-temps, 'loc' == 'input_location'. But: control_warning_option is called with input_location and not 'loc', thus that should not be the reason for the issue. * * * However, if one does a deep dive into update_effective_level_from_pragmas, the difference seems to be only the column number. There is: if (!linemap_location_before_p (line_table, pragloc, loc)) continue; Without -save-temps, there is (with warnings + notes added for debugging): foo.c:29:1: warning: update_effective_level_from_pragmas - pragloc 29 | BX_retundef(}) | ^~~ foo.c:29:13: note: loc is here 29 | BX_retundef(}) | ^ thus loc > pragloc But -save-temps, i.e. working on the preprocessed input, there is: foo.c:29:9: warning: update_effective_level_from_pragmas - pragloc 29 | BX_retundef(}) | ^~~ foo.c:29:2: note: loc is here 29 | BX_retundef(}) | ^ That is: loc < pragloc
[Bug target/102993] -fcf-protection=full produces segfaulting code when targeting 32-bit x86 (i686)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102993 --- Comment #7 from Luke Dashjr --- It's the standard Ubuntu focal g++-mingw-w64-i686 package.
[Bug preprocessor/90400] _Pragma not always expanded in the right location within macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90400
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #4 from Tobias Burnus ---
If I look at the 'gcc -E' output, the order is reverted:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wall"
#pragma GCC diagnostic pop
else { b--; ; ; a--; ; }
this should be instead:
else { b--;
#pragma GCC diagnostic push
;
#pragma GCC diagnostic ignored "-Wall"
; a--;
#pragma GCC diagnostic pop
; }
I did observe the same in PR102409 – see analysis there. But contrary to the
issue in the other PR, the patch there does not solve the issue in this PR.
Additionally, for 'GCC diagnostic' there might be a column issue as discussed
in PR91669 comment 3.
[Bug middle-end/103000] New: Some updated test cases from r12-4786 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103000 Bug ID: 103000 Summary: Some updated test cases from r12-4786 fail Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:4045d5fa42f2ee7b284977c8f2f0edc300a63e43, r12-4786 make -k check-gcc RUNTESTFLAGS="complex.exp=gcc.dg/vect/complex/fast-math-bb-slp-complex-add-pattern-float.c" FAIL: gcc.dg/vect/complex/fast-math-bb-slp-complex-add-pattern-float.c scan-tree-dump slp1 "Found COMPLEX_ADD_ROT270" # of expected passes2 # of unexpected failures1 commit 4045d5fa42f2ee7b284977c8f2f0edc300a63e43 (HEAD, refs/bisect/bad) Author: Tamar Christina Date: Fri Oct 29 12:47:39 2021 +0100 middle-end: Add target independent tests for Arm complex numbers vectorization. There were actually 4 failures: FAIL: gcc.dg/vect/complex/fast-math-bb-slp-complex-add-float.c scan-tree-dump slp1 "Found COMPLEX_ADD_ROT270" FAIL: gcc.dg/vect/complex/fast-math-bb-slp-complex-add-float.c scan-tree-dump slp1 "Found COMPLEX_ADD_ROT90" FAIL: gcc.dg/vect/complex/fast-math-bb-slp-complex-add-pattern-float.c scan-tree-dump slp1 "Found COMPLEX_ADD_ROT270" FAIL: gcc.dg/vect/complex/fast-math-bb-slp-complex-add-pattern-half-float.c (test for excess errors) UNRESOLVED: gcc.dg/vect/complex/fast-math-bb-slp-complex-add-pattern-half-float.c scan-tree-dump slp1 "Found COMPLEX_ADD_ROT270" UNRESOLVED: gcc.dg/vect/complex/fast-math-bb-slp-complex-add-pattern-half-float.c scan-tree-dump slp1 "Found COMPLEX_ADD_ROT90"
[Bug fortran/103001] New: missing simplify of (CAF) get_team
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103001 Bug ID: 103001 Summary: missing simplify of (CAF) get_team Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: aldot at gcc dot gnu.org Target Milestone: --- As noted here: https://gcc.gnu.org/pipermail/fortran/2021-October/056793.html ---8<--- - delete unused gfc_simplify_get_team or wire it up in intrinsics, get_team handling (instead of the NULL..) Anyone who does coarrays might want to fill in the missing get_team() simplify and add an appropriate test. ---8<--- E.g. omp team is named properly. It would have been nice if caf would have used a _caf part for it's functions internally throughout too.
[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426 Bernhard Reutner-Fischer changed: What|Removed |Added CC||aldot at gcc dot gnu.org --- Comment #4 from Bernhard Reutner-Fischer --- I'm thinking about switching all these symbol lookups/symtree traversals (i.e. the whole fortran frontend) to pointer comparison which should _greatly_ speedup any symbol lookup, fyi.
[Bug tree-optimization/103002] New: Missed loop unrolling opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103002
Bug ID: 103002
Summary: Missed loop unrolling opportunity
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
#define C 3
struct node {
struct node *next;
int payload;
};
static int count_nodes(const node* p) {
int size = 0;
while (p) {
p = p->next;
size++;
}
return size;
}
bool has_one_node(const node* p) {
return count_nodes(p) == 1;
}
bool has_C_nodes(const node* p) {
return count_nodes(p) == C;
}
has_one_node(node const*):# @has_one_node(node const*)
testrdi, rdi
je .LBB0_1
mov eax, 1
.LBB0_3:# =>This Inner Loop Header: Depth=1
mov rdi, qword ptr [rdi]
add eax, -1
testrdi, rdi
jne .LBB0_3
testeax, eax
seteal
ret
.LBB0_1:
xor eax, eax
ret
has_C_nodes(node const*): # @has_C_nodes(node const*)
testrdi, rdi
je .LBB1_1
mov eax, 3
.LBB1_3:# =>This Inner Loop Header: Depth=1
mov rdi, qword ptr [rdi]
add eax, -1
testrdi, rdi
jne .LBB1_3
testeax, eax
seteal
ret
.LBB1_1:
xor eax, eax
ret
has_C_nodes is simple with some kind of loop deletion pass, but generally,
these loops can be unrolled for some reasonable C values.
https://godbolt.org/z/do656c17b
[Bug c++/102999] g++-11 regression: sorry, unimplemented: unexpected AST of kind nontype_argument_pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102999 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- Thanks for the bug report, this looks like a dup of PR102547 which has recently been fixed for GCC 11.3 and 12. *** This bug has been marked as a duplicate of bug 102547 ***
[Bug c++/102547] [11 Regression] g++ 11. ICE with NTTPs and partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102547 Patrick Palka changed: What|Removed |Added CC||cantonios at google dot com --- Comment #10 from Patrick Palka --- *** Bug 102999 has been marked as a duplicate of this bug. ***
[Bug c++/102409] _pragma ("omp ...") expansion issue - placed in the wrong scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102409
--- Comment #3 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:0078a058a569387153419876acca080142873b65
commit r12-4797-g0078a058a569387153419876acca080142873b65
Author: Tobias Burnus
Date: Fri Oct 29 22:55:32 2021 +0200
libcpp: Fix _Pragma expansion [PR102409]
Both #pragma and _Pragma ended up as CPP_PRAGMA. Presumably since
r131819 (2008, GCC 4.3) for PR34692, pragmas are not expanded in
macro arguments but are output as is before. From the old bug report,
that was to fix usage like
FOO (
#pragma GCC diagnostic
)
However, that change also affected _Pragma such that
BAR (
"1";
_Pragma("omp ..."); )
yielded
#pragma omp ...
followed by what BAR expanded too, possibly including '"1";'.
This commit adds a flag, PRAGMA_OP, to tokens to make the two
distinguishable - and include again _Pragma in the expanded arguments.
libcpp/ChangeLog:
PR c++/102409
* directives.c (destringize_and_run): Add PRAGMA_OP to the
CPP_PRAGMA token's flags to mark is as coming from _Pragma.
* include/cpplib.h (PRAGMA_OP): #define, to be used with token
flags.
* macro.c (collect_args): Only handle CPP_PRAGMA special if
PRAGMA_OP
is set.
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/pragma-1.c: New test.
* c-c++-common/gomp/pragma-2.c: New test.
[Bug c/102998] Wrong documentation for -Warray-parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102998 Eric Gallager changed: What|Removed |Added Keywords||diagnostic CC||egallager at gcc dot gnu.org, ||msebor at gcc dot gnu.org --- Comment #2 from Eric Gallager --- Martin Sebor added this warning; cc-ing him
[Bug preprocessor/90400] _Pragma not always expanded in the right location within macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90400 --- Comment #5 from Tobias Burnus --- The problem is that the pragma is not known/registered. In that case, when calling libcpp/directives.c's do_pragma, the result is p == NULL and thus: if (p) ... else if (pfile->cb.def_pragma) ... pfile->cb.def_pragma (pfile, pfile->directive_line); the latter immediately prints the '#pragma ...' I think what needs to be done is if (p == NULL && pfile->state.in_directive) to create a new pragma on the fly and store it in pfile->directive_result to use it later. * * * Side note: For 'gcc -E c-c++-common/gomp/pragma-1.c' the same issue occurs, but if one adds -fopenmp, p != NULL and everything is fine.
[Bug target/102953] Improvements to CET-IBT and ENDBR generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953
--- Comment #17 from Andrew Cooper ---
I think I've found a bug in the -fcf-check-attribute implementation.
$ cat fnptr-array-arg.c
static int __attribute__((cf_check)) foo(char a[], int b)
{
return 0;
}
int (*ptr)(char[], int) = foo;
$ gcc -Wall -fcf-protection=branch -mmanual-endbr -fcf-check-attribute=no -c
fnptr-array-arg.c -o tmp.o && objdump -d tmp.o
fnptr-array-arg.c:5:27: warning: initialization of 'int (*)(char *, int)'
from incompatible pointer type 'int (__attribute__((nocf_check)) *)(char *,
int)' [-Wincompatible-pointer-types]
5 | int (*ptr)(char[], int) = foo;
| ^~~
tmp.o: file format elf64-x86-64
Disassembly of section .text:
:
0: 31 c0 xor%eax,%eax
2: c3 retq
Despite the explicit cf_check, a diagnostic is raised complaining about
cf_check-ness of the pointer, and the generated code has no `endbr64`
instruction.
This issue only manifests when using array arguments in the function. When
switching `char[]` for `char*`, everything works as expected. Also, dropping
-fcf-check-attribute=no also causes things to work.
$ gcc -Wall -fcf-protection=branch -mmanual-endbr -c fnptr-array-arg.c -o
tmp.o && objdump -d tmp.o
tmp.o: file format elf64-x86-64
Disassembly of section .text:
:
0: f3 0f 1e fa endbr64
4: 31 c0 xor%eax,%eax
6: c3 retq
Something about the array type seems to cause the explicit cf_check attribute
to be lost.
[Bug preprocessor/90400] _Pragma not always expanded in the right location within macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90400 --- Comment #6 from Tobias Burnus --- Created attachment 51700 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51700&action=edit Draft patch for the 'gcc -E' / 'gcc -save-temps' issue This solves the -E / -save-temps preprocessing issue. For the non -E issue, it could be the issue described at PR 91669.
[Bug target/102953] Improvements to CET-IBT and ENDBR generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953 H.J. Lu changed: What|Removed |Added Attachment #51696|0 |1 is obsolete|| --- Comment #18 from H.J. Lu --- Created attachment 51701 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51701&action=edit The v5 patch to add -fcf-check-attribute=[yes|no]
[Bug target/102953] Improvements to CET-IBT and ENDBR generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953 --- Comment #19 from H.J. Lu --- (In reply to Andrew Cooper from comment #17) > I think I've found a bug in the -fcf-check-attribute implementation. > Please try the v5 patch. BTW, do you have a testcase to show how -fcf-check-attribute=yes is used?
[Bug target/102953] Improvements to CET-IBT and ENDBR generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953
--- Comment #20 from Andrew Cooper ---
(In reply to H.J. Lu from comment #19)
> (In reply to Andrew Cooper from comment #17)
> > I think I've found a bug in the -fcf-check-attribute implementation.
>
> Please try the v5 patch.
Thanks. That does fix the issue.
> BTW, do you have a testcase to show how
> -fcf-check-attribute=yes is used?
So, this was something I was going to leave until I'd got CET-IBT working, so
as to have time to consider all parts before proposing improvements.
I don't have a usecase for -fcf-check-attribute=yes, because it is almost
totally redundant with regular -fcf-protection in the first place.
When you are are applying control flow checks, every function is either checked
or not checked. But GCC currently has a 3-way model of {unknown, explicit yes,
explicit no} on which it builds its typechecking.
Furthermore, -mmanual-endbr is a gross hack which by default leaves you with a
broken binary.
If I were building this from scratch, I'd not have -mmanual-endbr or
-fcf-check-attribute at all, because they're exposing complexity which ought
not to exist.
I get why the default for -fcf-protection=branch puts an ENDBR* instruction
everywhere. It is the quick, easy and non-invasive way to make libraries
compatible with CET, which is a net improvement, even if not ideal.
The ideal way, and definitely future work, is for GCC to calculate the minimum
set of required ENDBR*. At a guess, all non-local symbols (except those LTO
can determine are not publicly visible), and any local symbols used by function
pointers.
What I'm trying to do is a stopgap in the middle. No ENDBR*'s by default, but
have the compiler tell me where I've got function pointers to a non-ENDBR'd
function, so when the result compiles, it stands a reasonable chance of
functioning correctly.
Personally, I'd suggest having these as sub-modes of -fcf-protection=branch,
instead of exposing all the internals on the command line.
[Bug testsuite/103000] Some updated test cases from r12-4786 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103000
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2021-10-30
Status|UNCONFIRMED |NEW
Component|middle-end |testsuite
--- Comment #1 from Andrew Pinski ---
Looks like these are missing { target { vect_complex_add_float } } in there.
confirmed.
[Bug testsuite/103000] Some updated test cases from r12-4786 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103000
--- Comment #2 from Tamar Christina ---
(In reply to Andrew Pinski from comment #1)
> Looks like these are missing { target { vect_complex_add_float } } in there.
>
No, that's not right, `vect_complex_add_float` is for when the target supports
code-gen for the the sequence. But detection should pass for any target that
can SLP vectorize the test case at all.
>From a quick look at the failures on -m32 it looks like SLP vectorization fails
completely but these targets declare vect_float so that's not enough to stop
it.
Will need to check monday but likely missing some option somewhere. And
https://godbolt.org/z/Pxs7dfj1a shows it detecting them, so something is up
with the options being passed.
Will look monday.
[Bug testsuite/103000] Some updated test cases from r12-4786 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103000 --- Comment #3 from Andrew Pinski --- (In reply to Tamar Christina from comment #2) > From a quick look at the failures on -m32 it looks like SLP vectorization > fails completely but these targets declare vect_float so that's not enough > to stop it. > > Will need to check monday but likely missing some option somewhere. And > https://godbolt.org/z/Pxs7dfj1a shows it detecting them, so something is up > with the options being passed. This is on powerpc64-linux-gnu and not x86_64-linux-gnu though.
[Bug target/102953] Improvements to CET-IBT and ENDBR generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953
--- Comment #21 from Andrew Cooper ---
Another possibly-bug, but possibly mis-expectations on my behalf.
I've found some code in the depths of Xen which is causing a failure on final
link due to a missing `__x86_indirect_thunk_nt_rax` symbol.
$ cat fnptr-typeof.c
extern void (*fnptrs[])(char);
void foo(int a)
{
typeof(foo) *bar = (void *)fnptrs[0];
bar(a);
}
I realise this is wildly undefined behaviour, and I will try to address it in
due course. However, the instruction generation is bizarre.
When I compile with -fcf-protection=branch -mmanual-endbr, I get a plain `jmp
*fnptrs(%rip)` instruction. (This is fine.)
When I compile with -fcf-check-attribute=no as well, then I get `notrack jmp
*fnptrs(%rip)`. I'm not sure why the notrack is warranted here; for all GCC
knows, the target does have a suitable ENDBR64 instruction.
When I compile with -mindirect-branch=thunk as well, I get a load into %rax and
a normal looking retpoline thunk. (This is as expected too.)
However, when I switch to -mindirect-branch=thunk-extern, I get the the same
load into %rax, and then a jump to `__x86_indirect_thunk_nt_rax`. Presumably
the nt is short for notrack.
Irrespective of whether there should be a notrack or not on the jmp form, it
weird for the retpoline thunk ABI to be changing based on extern or not. What
is the reasoning behind this?
[Bug target/93811] __builtin___clear_cache() is a noop on powerpc (which is incorrect)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93811 --- Comment #4 from Andrew Pinski --- Mono's implementation seems like the best so far: https://github.com/mono/mono/blob/main/mono/mini/mini-ppc.c#L759-L795
[Bug tree-optimization/102943] [12 Regression] VRP threader compile-time hog with 521.wrf_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943 --- Comment #6 from Aldy Hernandez --- Can this be re-checked now that the forward threader has been dropped post-VRP? BTW, please CC me on any compile-time hogs related to the threader, especially if it's not SPEC related, as I've yet to hunt down a copy. So far this is the only non-duplicate PR I'm CC'ed on with the threader as a suspect in compile speed.
