[Bug c/105120] New: __OPTIMIZE__ macro incorrectly defined when using pragma(optimize) with push_options/pop_options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105120 Bug ID: 105120 Summary: __OPTIMIZE__ macro incorrectly defined when using pragma(optimize) with push_options/pop_options Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: andrey.turkin at gmail dot com Target Milestone: --- Created attachment 52730 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52730&action=edit Sample code The code contains a "GCC optimize" pragma and some inline functions which are supposed to be optimized (that section is surrounded by push_options/pop_options which is supposed to protect following code from this pragma) and then some code which is using MMX intrinsics (see attached minified example). File is compiled with -O0 (or no optimization options at all - so "gcc sample.c" should suffice to reproduce this). The code following pop_options pragma should be unaffected by optimize pragma but it sees __OPTIMIZE__ macro defined even though optimization options are unaffected; this breaks the build because the source includes intrinsic headers which use this macro to select between intrinsic implementations. I put this bug into C component, not sure if that's exactly right. C++ is affected by this also though it is harder to reproduce. __OPTIMIZE__ is still incorrectly defined when compiling C++ but we can't see it because of bug 48026 (which makes it seem as if __OPTIMIZE__ is not defined at all). However if we put that entire push_options/pop_options section, and just it, in a separate header file and we PCH it then PCH state will still contain __OPTIMIZE__ macro defined and intrinsic headers will still use wrong implementation and everything still fails the same way. I tried gcc 9, 10, 11 and current trunk of 12 and results are the same for all of them.
[Bug rtl-optimization/105119] the division in x / (1 << y) is optimized away when x has unsigned type, but not when it's signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105119 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from Richard Biener --- I think it's because arithmetic right-shift of negative values is undefined?
[Bug c++/90448] [8/9/10/11 Regression] decltype-based lambda parameter pack is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90448 --- Comment #16 from Kewen Lin --- *** Bug 90226 has been marked as a duplicate of this bug. ***
[Bug target/90226] ICE in expand_expr_addr_expr_1, at expr.c:7994
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90226 Kewen Lin changed: What|Removed |Added Resolution|--- |DUPLICATE CC||linkw at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #2 from Kewen Lin --- The bisection shows r11-7579 fixed it. As the symptom of one duplicated PR99392 which is also powerpc64 -m32 only, I think this one is also duplicated of PR90448. *** This bug has been marked as a duplicate of bug 90448 ***
[Bug c++/100052] [11/12 regression] ICE in compiling g++.dg/modules/xtreme-header-3_b.C after r11-8118
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100052 Jiu Fu Guo changed: What|Removed |Added CC||guojiufu at gcc dot gnu.org --- Comment #9 from Jiu Fu Guo --- On the latest trunk, these failures seems to disappear again. ./gcc/testsuite/g++/g++.sum:PASS: g++.dg/modules/xtreme-header-3_b.C -std=c++17 (test for excess errors) ./gcc/testsuite/g++/g++.sum:PASS: g++.dg/modules/xtreme-header-3_b.C -std=c++2a (test for excess errors) ./gcc/testsuite/g++/g++.sum:PASS: g++.dg/modules/xtreme-header-3_b.C -std=c++2b (test for excess errors) ./gcc/testsuite/g++/g++.log:PASS: g++.dg/modules/xtreme-header-3_b.C -std=c++17 (test for excess errors) ./gcc/testsuite/g++/g++.log:PASS: g++.dg/modules/xtreme-header-3_b.C -std=c++2a (test for excess errors) ./gcc/testsuite/g++/g++.log:PASS: g++.dg/modules/xtreme-header-3_b.C -std=c++2b (test for excess errors)
[Bug c++/99910] [11/12 Regression] g++.dg/modules/xtreme-header-2_b.C ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99910 Jiu Fu Guo changed: What|Removed |Added CC||guojiufu at gcc dot gnu.org --- Comment #10 from Jiu Fu Guo --- ./gcc/testsuite/g++/g++.sum:PASS: g++.dg/modules/xtreme-header-2_b.C -std=c++17 (test for excess errors) ./gcc/testsuite/g++/g++.sum:PASS: g++.dg/modules/xtreme-header-2_b.C -std=c++2a (test for excess errors) ./gcc/testsuite/g++/g++.sum:PASS: g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors) ./gcc/testsuite/g++/g++.log:PASS: g++.dg/modules/xtreme-header-2_b.C -std=c++17 (test for excess errors) ./gcc/testsuite/g++/g++.log:PASS: g++.dg/modules/xtreme-header-2_b.C -std=c++2a (test for excess errors) ./gcc/testsuite/g++/g++.log:PASS: g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors) . ./gcc/testsuite/g++/g++.sum:PASS: g++.dg/modules/xtreme-tr1_b.C -std=c++17 (test for excess errors) ./gcc/testsuite/g++/g++.sum:PASS: g++.dg/modules/xtreme-tr1_b.C -std=c++2a (test for excess errors) ./gcc/testsuite/g++/g++.sum:PASS: g++.dg/modules/xtreme-tr1_b.C -std=c++2b (test for excess errors) ./gcc/testsuite/g++/g++.log:PASS: g++.dg/modules/xtreme-tr1_b.C -std=c++17 (test for excess errors) ./gcc/testsuite/g++/g++.log:PASS: g++.dg/modules/xtreme-tr1_b.C -std=c++2a (test for excess errors) ./gcc/testsuite/g++/g++.log:PASS: g++.dg/modules/xtreme-tr1_b.C -std=c++2b (test for excess errors) It would pass with the latest trunk. (I tested on ppc64le)
[Bug c++/101853] [12 Regression] g++.dg/modules/xtreme-header-5_b.C ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101853 Jiu Fu Guo changed: What|Removed |Added CC||guojiufu at gcc dot gnu.org --- Comment #10 from Jiu Fu Guo --- On the trunk, this would be fixed: ./gcc/testsuite/g++/g++.sum:PASS: g++.dg/modules/xtreme-header-5_b.C -std=c++17 (test for excess errors) ./gcc/testsuite/g++/g++.sum:PASS: g++.dg/modules/xtreme-header-5_b.C -std=c++2a (test for excess errors) ./gcc/testsuite/g++/g++.sum:PASS: g++.dg/modules/xtreme-header-5_b.C -std=c++2b (test for excess errors) ./gcc/testsuite/g++/g++.log:PASS: g++.dg/modules/xtreme-header-5_b.C -std=c++17 (test for excess errors) ./gcc/testsuite/g++/g++.log:PASS: g++.dg/modules/xtreme-header-5_b.C -std=c++2a (test for excess errors) ./gcc/testsuite/g++/g++.log:PASS: g++.dg/modules/xtreme-header-5_b.C -std=c++2b (test for excess errors) > grep -r xtreme-. > ~/22.4.1aaf3a5993ae.log grep -i FAIL ~/22.4.1aaf3a5993ae.log |wc 0 0 0 grep -i PASS ~/22.4.1aaf3a5993ae.log |wc 3602232 41904
[Bug c++/105104] [coroutines] ICE during GIMPLE pass: coro-early-expand-ifns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105104 --- Comment #5 from John Eivind Helset --- Created attachment 52729 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52729&action=edit Patch with testcase. Tried adding a testcase to the g++.dg/coroutines testsuite. Used dg-ice, but it seems to complain about excess errors anyways: FAIL: g++.dg/coroutines/pr105104.C (test for excess errors) Excess errors: during GIMPLE pass: coro-early-expand-ifns
[Bug c++/47634] Incorrect checking of attribute format printf on constructor of derived class with virtual base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47634 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-03-31
[Bug target/104004] [12 Regression] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104004 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||segher at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Segher Boessenkool --- Fixed now.
[Bug target/104004] [12 Regression] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104004 --- Comment #3 from CVS Commits --- The master branch has been updated by Segher Boessenkool : https://gcc.gnu.org/g:aaf3a5993ae49f1ae6792800e5161a1d51436ed3 commit r12-7945-gaaf3a5993ae49f1ae6792800e5161a1d51436ed3 Author: Bill Schmidt Date: Fri Jan 28 11:50:26 2022 -0600 rs6000: Fix some missing built-in attributes [PR104004] PR104004 caught some misses on my part in converting to the new built-in function infrastructure. In particular, I forgot to mark all of the "nosoft" built-ins, and one of those should also have been marked "no32bit". 2022-01-27 Bill Schmidt gcc/ PR target/104004 * config/rs6000/rs6000-builtins.def (MFFSL): Mark nosoft. (MTFSB0): Likewise. (MTFSB1): Likewise. (SET_FPSCR_RN): Likewise. (SET_FPSCR_DRN): Mark nosoft and no32bit.
[Bug c++/101833] [9/10/11/12 Regression] ICE with -Wformat on a constructor with a virtual base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101833 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/105104] [coroutines] ICE during GIMPLE pass: coro-early-expand-ifns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105104 --- Comment #4 from John Eivind Helset --- It seems a non-void return-type from await-resume of a final awaitable, combined with at least -O1 causes a segfault: https://godbolt.org/z/rzq8dM7Pr Not sure if it's the same as the one I initially encountered yet.
[Bug fortran/102312] [9/10/11 Regression] ICE in gfc_get_dtype_rank_type, at fortran/trans-types.c:1558 since r9-5424-g92f3a180aaf6f3cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102312 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||12.0 Summary|[9/10/11/12 Regression] ICE |[9/10/11 Regression] ICE in |in gfc_get_dtype_rank_type, |gfc_get_dtype_rank_type, at |at |fortran/trans-types.c:1558 |fortran/trans-types.c:1558 |since |since |r9-5424-g92f3a180aaf6f3cd |r9-5424-g92f3a180aaf6f3cd | --- Comment #2 from anlauf at gcc dot gnu.org --- Works for me on mainline (gcc-12). Example z1 prints 0.
[Bug rtl-optimization/105091] RTL dse1 remove stack mem storing incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091 --- Comment #17 from Ian Lance Taylor --- Thanks.
[Bug fortran/105117] automatic deallocation of objects in procedures with heap arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105117 --- Comment #2 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #1) > There seems to be a threshold at -fmax-stack-var-size=64. The threshold is 64 for -m64, and 36 for -m32. Could it be that the limit applies to the array descriptor instead of the array?
[Bug fortran/104949] [OpenMP] omp target: firstprivate of allocatable array – only descriptor firstprivatized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104949 --- Comment #1 from Tobias Burnus --- The following addition to testcase is needed. ! --- !$omp parallel default(A) !$omp master if (any (A /= [1,2,3,4,5])) error stop A(:) = [99,88,77,66,55] !$omp end master !$omp end parallel if (any (A /= [1,2,3,4,5])) error stop !$omp target defaultmap(firstprivate) if (any (A /= [1,2,3,4,5])) error stop A(:) = [99,88,77,66,55] !$omp end target if (any (A /= [1,2,3,4,5])) error stop ! --- Reason: A different code path for (a) defaultmap(firstprivate) and default(firstprivate) For them gfc_omp_finish_clause is invoked (b) explicit firstprivate(a) Handled via gfc_trans_omp_clauses -> gfc_trans_omp_variable_list. but gfc_omp_finish_clause is not called (should it?) The 'parallel' variant works – and for both variants the gfc_omp_clause_copy_ctor is invoked for both via lower_rec_input_clauses()'s the block which follows the 'do_firstprivate:' label. Both 'target' variants only create 'firstprivate(a)' - but additionally 'firstprivate(a.data)' is needed, including doing a pointer attach. * * * Currently, we support either code using attach like: map(force_to:var) map(force_to:*var.data [len...]) map(attach_detach:var.data [bias: 0]) or pointer-set/pointer assign like for map(to:var.data [len:...]) map(to:var [pointer set, len: 64]) map(alloc: var.data [pointer assign, bias: 0]) In my understanding, either code requires that 'var.data' can be found as host->device lookup, which does not work for firstprivate. And just internally adding 'a' to the host->device mapping for firstprivate purpose internally does not handle the following. a = 5 !$omp target enter data map(to: a) a = 7 ! adding internally 'a' (host)->'a'(firstprivate) mapping to find the 'a.var' ! for the usage in attach/pointer assign does not work as 'a' already exists. !$omp target firstprivate(a) ! a should be now 7 !$omp end firstprivate !$omp target ! a is 5 !$omp end target For the usage in type t integer, allocatable :: a, b end type t type(t) :: var !$omp target firstprivate(var) ... multiple attachments are needed, i.e. just using firstprivate(a) firstprivate(b) pointer_attach (a.data) and working with index i, i+1, i+2 does not work.
[Bug rtl-optimization/105119] New: the division in x / (1 << y) is optimized away when x has unsigned type, but not when it's signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105119
Bug ID: 105119
Summary: the division in x / (1 << y) is optimized away when x
has unsigned type, but not when it's signed
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
For the following on x86_64 with -O2
int f(int x, int y) {
return x / (1 << y);
}
GCC generates an idiv instruction:
movl%esi, %ecx
movl$1, %edx
movl%edi, %eax
sall%cl, %edx
movl%edx, %ecx
cltd
idivl %ecx
ret
But I believe this is equivalent to the division-less
int g(int x, int y) {
return (x + (x < 0) * ((1 << y) - 1)) >> y;
}
(which basically generalizes the existing x / (1 << y) -> x >> y transformation
that we perform for unsigned x). For this latter function, we generate
movl%esi, %ecx
movl$1, %eax
xorl%edx, %edx
sall%cl, %eax
subl$1, %eax
testl %edi, %edi
cmovns %edx, %eax
addl%edi, %eax
sarl%cl, %eax
ret
which seems to be significantly faster according to some rough benchmarks.
[Bug libstdc++/105118] New: Why is unexpected::value() named error() in libstdc++?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105118 Bug ID: 105118 Summary: Why is unexpected::value() named error() in libstdc++? Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- In libstdc++'s implementation of std::expected, std::unexpected gets the _M_val through error(), but in [expected.un.object.general], unexpected uses value() to access val. In my opinion, error() should be a better member function name, but the standard currently uses value(). So I wonder why libstdc++ uses error()? Is there any information about this?
[Bug fortran/105117] automatic deallocation of objects in procedures with heap arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105117 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-03-31 --- Comment #1 from anlauf at gcc dot gnu.org --- There seems to be a threshold at -fmax-stack-var-size=64.
[Bug other/105114] [12 regression] contrib/gcc_update hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #12 from Jakub Jelinek --- Now fixed, thanks Joseph.
[Bug other/105114] [12 regression] contrib/gcc_update hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114 --- Comment #11 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:562d014efadfef6628ae670049c2d92ff6b166f0 commit r12-7941-g562d014efadfef6628ae670049c2d92ff6b166f0 Author: Jakub Jelinek Date: Thu Mar 31 19:21:00 2022 +0200 contrib: Fix up spelling of loongarch-str.h dependency [PR105114] As found by Joseph, the dependency of gcc/config/loongarch/loongarch-str.h is spelled incorrectly, it should be gcc/config/loongarch/genopts/loongarch-strings but was using gcc/config/loongarch/genopts/loongarch-string 2022-03-31 Jakub Jelinek Joseph Myers PR other/105114 * gcc_update: Fix up spelling of gcc/config/loongarch/genopts/loongarch-strings dependency.
[Bug other/105114] [12 regression] contrib/gcc_update hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-03-31 Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #10 from Jakub Jelinek --- Sharp eyes...
[Bug other/105114] [12 regression] contrib/gcc_update hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114 --- Comment #9 from joseph at codesourcery dot com --- The dependencies in gcc_update refer to gcc/config/loongarch/genopts/loongarch-string which doesn't exist (should be loongarch-strings not loongarch-string, I suppose). Maybe that's causing the problem?
[Bug debug/105108] incomplete/incorrect DWARF information at -O1 and -Og after inlining a function returning a constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108 --- Comment #9 from Cristian Assaiante --- Created attachment 52728 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52728&action=edit Executable file at -Og with l_144 = 8
[Bug debug/105108] incomplete/incorrect DWARF information at -O1 and -Og after inlining a function returning a constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
--- Comment #8 from Cristian Assaiante ---
(In reply to Jakub Jelinek from comment #3)
> And I certainly can't reproduce the wrong-debug issue you're talking about.
> If I change it to char l_144 = 8;
> then optimized dump has:
>[local count: 1073741824]:
> # DEBUG BEGIN_STMT
> # DEBUG l_144 => 8
> # DEBUG BEGIN_STMT
> # DEBUG l_165 => 128
> # DEBUG BEGIN_STMT
> # DEBUG l_144 => NULL
> # DEBUG BEGIN_STMT
> a = 1;
> return 0;
> and in the debugger it correctly says that
> (gdb) p l_144
> $1 =
> because at the a = 1 store the value is unknown.
I have tested again the C example with l_144 = 8 and in gdb l_144 is not marked
as optimized out, instead it has 8 as value:
$ cat a.c
int a;
char b() { return 0; }
int main() {
char l_144 = 8;
short l_165 = 128;
l_144 = b();
a = l_144 != l_165;
}
$ gcc -Og -g a.c -o opt
DWARF info for l_144:
0x006b: DW_TAG_variable
DW_AT_name("l_144")
DW_AT_decl_file ("/home/stepping/a.c")
DW_AT_decl_line (4)
DW_AT_decl_column (0x07)
DW_AT_type(0x008d "char")
DW_AT_location(0x000e:
[0x0040048c, 0x0040048c): DW_OP_lit8,
DW_OP_stack_value)
DW_AT_GNU_locviews(0x000c)
GDB trace:
Reading symbols from opt...
(gdb) b 6
Breakpoint 1 at 0x40048c: file a.c, line 6.
(gdb) r
Starting program: /home/stepping/opt
Breakpoint 1, main () at a.c:7
7a = l_144 != l_165;
(gdb) p l_144
$1 = 8 '\b'
I will add the executable file as an attachment.
[Bug c++/102629] [10/11/12 Regression] ICE: tree check in lookup_base, at cp/search.c:233 since r10-2194-g10acaf4db9f8b54b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102629 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Last reconfirmed||2022-03-31 Priority|P3 |P2 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Confirmed, but even GCC 9 ICEs for me.
[Bug ipa/102513] [10/11/12 Regression] Many false positive warnings with recursive function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513 Martin Jambor changed: What|Removed |Added Assignee|jamborm at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #13 from Martin Jambor --- Mitigated using value-range on master (soon to be GCC 12). On 11 and earlier, the determined IPA value-range is "variable" - I have not looked at why - so the same approach cannot be taken there. I am un-assigning myself so that whoever wants to explore other options how to prevent/mitigate this issue does not feel hindered. (But I'll keep the issue on my list to ponder about.)
[Bug gcov-profile/105063] [GCOV] Ability to map .gcda paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063 --- Comment #14 from vit9696 --- I have just tested this patch after rebasing it on 10.3.x branch, and can confirm it works as intended. Thank you!
[Bug ipa/103171] [12 Regression] ICE Segmentation fault since r12-2523-g13586172d0b70c9d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103171 Martin Jambor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Martin Jambor --- Fixed.
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772 --- Comment #43 from Jakub Jelinek --- Created attachment 52727 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52727&action=edit gcc12-pr102772.patch Another patch. This one changes (for now on 32-bit x86 solaris only) malloc_alignment () value, which is used in 2 places, to initialize aligned_new_threshold value if user used -falignment-new or -falignment-new=1 or -std=c++17 or later and -falignment-new=SOMETHING_BIGGER_THAN_ONE wasn't used, and for -Waligned-new= warning (we warn when non-align_t operator new is used on types that need bigger alignment than malloc_alignment ()).
[Bug ipa/103083] [10/11/12 Regression] Wrong code due to ipa-cp's bits value propagation since r10-5538-gc7ac9a0c7e3916f1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103083 --- Comment #6 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:7ea3a73c195a79e6740ae594ee1a14c8bf7a938d commit r12-7939-g7ea3a73c195a79e6740ae594ee1a14c8bf7a938d Author: Martin Jambor Date: Thu Mar 31 17:22:34 2022 +0200 ipa: Careful processing ANCESTOR jump functions and NULL pointers (PR 103083) IPA_JF_ANCESTOR jump functions are constructed also when the formal parameter of the caller is first checked whether it is NULL and left as it is if it is NULL, to accommodate C++ casts to an ancestor class. The jump function type was invented for devirtualization and IPA-CP propagation of tree constants is also careful to apply it only to existing DECLs(*) but as PR 103083 shows, the part propagating "known bits" was not careful about this, which can lead to miscompilations. This patch introduces a flag to the ancestor jump functions which tells whether a NULL-check was elided when creating it and makes the bits propagation behave accordingly, masking any bits otherwise would be known to be one. This should safely preserve alignment info, which is the primary ifnormation that we keep in bits for pointers. (*) There still may remain problems when a DECL resides on address zero (with -fno-delete-null-pointer-checks ...I hope it cannot happen otherwise). I am looking into that now but I think it will be easier for everyone if I do so in a follow-up patch. gcc/ChangeLog: 2022-02-11 Martin Jambor PR ipa/103083 * ipa-prop.h (ipa_ancestor_jf_data): New flag keep_null; (ipa_get_jf_ancestor_keep_null): New function. * ipa-prop.cc (ipa_set_ancestor_jf): Initialize keep_null field of the ancestor function. (compute_complex_assign_jump_func): Pass false to keep_null parameter of ipa_set_ancestor_jf. (compute_complex_ancestor_jump_func): Pass true to keep_null parameter of ipa_set_ancestor_jf. (update_jump_functions_after_inlining): Carry over keep_null from the original ancestor jump-function or merge them. (ipa_write_jump_function): Stream keep_null flag. (ipa_read_jump_function): Likewise. (ipa_print_node_jump_functions_for_edge): Print the new flag. * ipa-cp.cc (class ipcp_bits_lattice): Make various getters const. New member function known_nonzero_p. (ipcp_bits_lattice::known_nonzero_p): New. (ipcp_bits_lattice::meet_with_1): New parameter drop_all_ones, observe it. (ipcp_bits_lattice::meet_with): Likewise. (propagate_bits_across_jump_function): Simplify. Pass true in drop_all_ones when it is necessary. (propagate_aggs_across_jump_function): Take care of keep_null flag. (ipa_get_jf_ancestor_result): Propagate NULL accross keep_null jump functions. gcc/testsuite/ChangeLog: 2021-11-25 Martin Jambor * gcc.dg/ipa/pr103083-1.c: New test. * gcc.dg/ipa/pr103083-2.c: Likewise.
[Bug ipa/102513] [10/11/12 Regression] Many false positive warnings with recursive function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513 --- Comment #12 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:cf68f5a6d20db2aee2f3e674ad3f10e1c458edf9 commit r12-7937-gcf68f5a6d20db2aee2f3e674ad3f10e1c458edf9 Author: Martin Jambor Date: Thu Mar 31 17:14:42 2022 +0200 ipa-cp: Do not create clones for values outside known value range (PR 102513) PR 102513 shows we emit bogus array access warnings when IPA-CP creates clones specialized for values which it deduces from arithmetic jump functions describing self-recursive calls. Those can however be avoided if we consult the IPA-VR information that the same pass also has. The patch below does that at the stage when normally values are only examined for profitability. It would be better not to create lattices describing such bogus values in the first place, however that presents an ordering problem, the pass currently propagates all information, and so both constants and VR, in no particular order when processing SCCs, and so this approach seemed much simpler. I plan to rearrange the pass so that it clones in multiple passes over the call graph (or rather the lattice dependence graph) and it feels natural to only do propagation for these kinds of recursion in the second or later passes, which would fix the issue more elegantly. gcc/ChangeLog: 2022-02-14 Martin Jambor PR ipa/102513 * ipa-cp.cc (decide_whether_version_node): Skip scalar values which do not fit the known value_range. gcc/testsuite/ChangeLog: 2022-02-14 Martin Jambor PR ipa/102513 * gcc.dg/ipa/pr102513.c: New test.
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772 --- Comment #42 from Jonathan Wakely --- It should really depend on -faligned-new which can be set for C++14 and C++11 too (and I guess C++98 in theory, but that would break when you include because you can't have 'enum class align_val_t' in C++98). So cxx_dialect isn't right. Does -faligned-new get processed already before the hook? If so, can you just check if the threadshold is already non-zero and change if so? If it's zero, leave it as zero.
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #34 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #33)
> > So in struct B { int : 0; double a, b; }; it will go into GPR and FPR
>
> GCC trunk puts "a" into FPR, not GPR! So the "leading" zero-width
> bit-fields are ignored (GCC does not think it's a part of any "64-bit
> chunk"), but other zero-width bit-fields are accounted... This is just
> puzzling to me.
Remove this: I just forgot to rename ".C" to ".c" when I tested this with GCC
11. But still I think clang's behavior is better.
> I'll make a patch to match the behavior of clang.
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #33 from Xi Ruoyao ---
(In reply to Segher Boessenkool from comment #31)
> Well, what do other compilers do? It's not such a good idea to break ABI
> compatibility with the 1990's compilers ;-)
Does someone have access to a Greenhills compiler here?
(In reply to Jakub Jelinek from comment #32)
> I think best would be to ignore them altogether, especially if other
> compilers do that too.
I agree the behavior of clang (or previous G++) is more "rational". To make
things more "interesting":
> So in struct B { int : 0; double a, b; }; it will go into GPR and FPR
GCC trunk puts "a" into FPR, not GPR! So the "leading" zero-width bit-fields
are ignored (GCC does not think it's a part of any "64-bit chunk"), but other
zero-width bit-fields are accounted... This is just puzzling to me.
I'll make a patch to match the behavior of clang.
[Bug analyzer/105112] Speed up -fanalyzer on big-code.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105112 --- Comment #3 from David Malcolm --- Possible simplification: don't try to model floating-point operations e.g. any binop on a floating point value has unknown_svalue as the result, so that complicated floating-point computations can be quickly handled with a "we don't care" value. (though do we care about tainted divisors for floating-point?)
[Bug ipa/103171] [12 Regression] ICE Segmentation fault since r12-2523-g13586172d0b70c9d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103171 --- Comment #6 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:f6d65e803623c7ba6c8eb92ce5975fc1b90cd91e commit r12-7936-gf6d65e803623c7ba6c8eb92ce5975fc1b90cd91e Author: Martin Jambor Date: Thu Mar 31 16:50:24 2022 +0200 ipa: Create LOAD references when necessary during inlining (PR 103171) in r12-2523-g13586172d0b70c ipa-prop tracking of jump functions during inlining got the ability to remove ADDR references when inlining discovered that they were not necessary or turn them into LOAD references when we know that what was a function call argument passed by reference will end up as a load (one or more). Unfortunately, the code only creates the LOAD references when replacing removed ADDR references and PR 103171 showed that with some ordering of inlining, we need to add the LOAD reference before we know we can remove the ADDR one - or the reference will be lost, leading to link errors or even ICEs. Specifically in testcase gcc.dg/lto/pr103171_1.c added in this patch, if foo() is inlined to entry(), we need to create the LOAD reference so that when later bar() is inlined into foo() and we discover that the paameter is unused, we can remove the ADDR reference and still keep the varaible around for the load. Martin gcc/ChangeLog: 2022-01-28 Martin Jambor PR ipa/103171 * ipa-prop.cc (propagate_controlled_uses): Add a LOAD reference always when an ADDR_EXPR constant is known to reach a load because of inlining, not just when removing an ADDR reference. gcc/testsuite/ChangeLog: 2022-01-28 Martin Jambor PR ipa/103171 * gcc.dg/ipa/remref-6.c: Adjust dump scan string. * gcc.dg/ipa/remref-7.c: New test. * gcc.dg/lto/pr103171_0.c: New test. * gcc.dg/lto/pr103171_1.c: Likewise.
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772 --- Comment #41 from Jakub Jelinek --- (In reply to Jonathan Wakely from comment #39) > (In reply to r...@cebitec.uni-bielefeld.de from comment #37) > > AFAICS, alignof is C++ >= 11 only. I've used the attached patch to > > use __alignof__ instead, although I don't know if that's the best fix. > > Yes, alignof is C++11 only, but the reason it's OK to use there is that > __STDCPP_DEFAULT_NEW_ALIGNMENT__ is C++17 only, and alignof is guarded by: > > #if __cpp_aligned_new > if (alignof(_Tp) > __STDCPP_DEFAULT_NEW_ALIGNMENT__) > > Strictly speaking, this code is enabled when -faligned-new is active, which > is true for C++17 by default. > > It appears that Jakub's patch makes -faligned-new always active for Solaris > x86, which we don't want. Ah, indeed, I thought the threshold is separate from it being enabled, but it is not. So, we want to change it in the option override handling only if cxx_dialect >= cxx17, but that is something only defined in c-family, while the backend option overriding is in code linked with all FEs. Thus, we'd need to override it instead somewhere in i386-c.cc. But nothing in that file is called early enough, from what I can see, the sequence of initialization is: cxx_dialect set to the default (cxx17 now) possibly cxx_dialect changed if -std= used on command line SUBTARGET_OVERRIDE_OPTIONS invoked cxx_init_decl_processing 4645 if (aligned_new_threshold == -1) 4646aligned_new_threshold = (cxx_dialect >= cxx17) ? 1 : 0; 4647 if (aligned_new_threshold == 1) 4648aligned_new_threshold = malloc_alignment () / BITS_PER_UNIT; code invoked ix86_register_pragmas from i386-c.cc called ix86_target_macros from i386-c.cc called Also, the -Waligned-new= warning uses malloc_alignment () rather than aligned_new_threshold, so if we want to override something for 32-bit x86 solaris, mingw and vxworks, we probably need something to hook into malloc_alignment rather than to tweak aligned_new_threshold. I think we need a target macro for it though rather than target hook, because it needs to be invoked from the C++ FE and implemented in config/*-c.cc
[Bug other/105114] [12 regression] contrib/gcc_update hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114 --- Comment #8 from Jakub Jelinek --- One possibility would be 32-bit make binary using 32-bit stat syscalls and the new files having non-representable ino_t values, so stat on those would appear to fail. But that is just a wild guess...
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772 --- Comment #40 from Jonathan Wakely --- N.B. I don't think we want to replace alignof with __alignof__ because they're not identical. For x86 alignof(long long) != __alignof__(long long).
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772 --- Comment #39 from Jonathan Wakely --- (In reply to r...@cebitec.uni-bielefeld.de from comment #37) > AFAICS, alignof is C++ >= 11 only. I've used the attached patch to > use __alignof__ instead, although I don't know if that's the best fix. Yes, alignof is C++11 only, but the reason it's OK to use there is that __STDCPP_DEFAULT_NEW_ALIGNMENT__ is C++17 only, and alignof is guarded by: #if __cpp_aligned_new if (alignof(_Tp) > __STDCPP_DEFAULT_NEW_ALIGNMENT__) Strictly speaking, this code is enabled when -faligned-new is active, which is true for C++17 by default. It appears that Jakub's patch makes -faligned-new always active for Solaris x86, which we don't want.
[Bug other/105114] [12 regression] contrib/gcc_update hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114 --- Comment #7 from Andreas Schwab --- contrib/gcc_update is supposed to work with any make, even non-GNU ones, though.
[Bug other/105114] [12 regression] contrib/gcc_update hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114 seurer at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from seurer at gcc dot gnu.org --- On a system where things were working I built and installed make 3.81. Using that I now get the same failure. I will just use the newer make on the old system where things were failing.
[Bug other/105114] [12 regression] contrib/gcc_update hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114 --- Comment #5 from seurer at gcc dot gnu.org --- The makefiles between systems were the same. One thing that is different is make itself. On another system where this was working make was a later release. So I grabbed the latest release of make on the failing system, built and installed it, and the problem went away. The failing make was 3.81. I am going to try make 3.81 on a working system to see if it then fails.
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772 --- Comment #38 from Rainer Orth --- Created attachment 52726 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52726&action=edit Use __alignof__ in several allocator headers.
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #37 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #36 from Jakub Jelinek ---
> Created attachment 52719
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52719&action=edit
> gcc12-pr102772.patch
>
> So like this?
Mostly. There were some issues, though:
* Initially, the patch caused the bootstrap to fail:
In file included from
/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/i386-pc-solaris2.11/bits/c++allocator.h:33,
from
/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/bits/allocator.h:46,
from
/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/memory:64,
from
/vol/gcc/src/hg/master/local/libstdc++-v3/src/c++98/allocator-inst.cc:29:
/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/bits/new_allocator.h:
In member function '_Tp* std::__new_allocator<_Tp>::allocate(size_type, const
void*)':
/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/bits/new_allocator.h:130:24:
error: expected primary-expression before ')' token
130 | if (alignof(_Tp) > __STDCPP_DEFAULT_NEW_ALIGNMENT__)
|^
| ^~~
/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/bits/new_allocator.h:130:13:
note: (if you use '-fpermissive', G++ will accept your code, but allowing the
use of an undeclared name is deprecated)
/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/bits/new_allocator.h:132:54:
error: there are no arguments to 'alignof' that depend on a template parameter,
so a declaration of 'alignof' must be available [-fpermissive]
132 | std::align_val_t __al = std::align_val_t(alignof(_Tp));
| ^~~
/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/bits/new_allocator.h:132:53:
error: expected primary-expression before '(' token
132 | std::align_val_t __al = std::align_val_t(alignof(_Tp));
| ^
/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/bits/new_allocator.h:132:65:
error: expected primary-expression before ')' token
132 | std::align_val_t __al = std::align_val_t(alignof(_Tp));
| ^
and several more, affecting
include/ext/bitmap_allocator.h
include/ext/mt_allocator.h
include/ext/pool_allocator.h
AFAICS, alignof is C++ >= 11 only. I've used the attached patch to
use __alignof__ instead, although I don't know if that's the best fix.
* With that, the build completed and g++.dg/torture/pr80334.C PASSes.
And yes, my tree did include
changeset: 259338:c7f332059508
bookmark:trunk
tag: qparent
user:Jakub Jelinek
date:Wed Mar 30 16:47:10 2022 +0200
summary: Revert "testsuite: Change pr80334.C testcase to dg-do compile
[PR102772]"
* However, there were quite a number of 32-bit regressions:
+FAIL: g++.dg/cpp1z/aligned-new4.C(test for warnings, line 11)
+FAIL: g++.dg/cpp1z/aligned-new4a.C(test for warnings, line 11)
+FAIL: g++.dg/diagnostic/recur-align.C -std=gnu++14 (test for warnings, line
13)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C -std=gnu++14 (test for
warnings, line 132)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C -std=gnu++14 (test for
warnings, line 136)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C -std=gnu++14 (test for
warnings, line 140)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C -std=gnu++14 (test for
warnings, line 155)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C -std=gnu++14 (test for
warnings, line 180)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C -std=gnu++14 (test for
warnings, line 210)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C -std=gnu++14 (test for
warnings, line 233)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C -std=gnu++14 (test for
warnings,
line 241)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C -std=gnu++14 (test for
warnings, line 41)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C -std=gnu++14 (test for
warnings, line 43)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C -std=gnu++14 (test for excess
errors)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C -std=gnu++14 note (test for
warnings, line 178)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C -std=gnu++14 note (test for
warnings, line 208)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C -std=gnu++14 note (test for
warnings, line 231)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C -std=gnu++14 note (test for
warnings, line 238)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C -std=gnu++98 (test for
warnings, line 132)
+FAIL: g++.dg/warn/Wmismatched-new-
[Bug ipa/104303] [12 regression] gnatmake is miscompiled by IPA/modref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104303 --- Comment #4 from Jan Hubicka --- What happens to the by-value parameter should get merged from concat5_pkg2.compare (s); I will take a look now - sorry for not handling this bug earlier. Honza
[Bug tree-optimization/104645] [12 Regression] i ? i % 2 : 0 not optimized anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104645 --- Comment #4 from Jakub Jelinek --- The first GCC 13 should have been GCC 12 of course.
[Bug tree-optimization/104645] [12 Regression] i ? i % 2 : 0 not optimized anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104645 --- Comment #3 from Jakub Jelinek --- Created attachment 52725 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52725&action=edit gcc12-pr104645.patch I wonder if at least for GCC 13 we just can't treat even that cast stmt as a preparation statement. This won't handle say shifts etc. with casts after them, but will at least fix this regression. And for GCC 13 perhaps we can throw away all the separation of "preparation" and assign statements and natural_element_p and absorbing_element_p and instead just try to constant evaluate all the middle_bb statements and see if that doesn't trigger traps/overflows/other UB and yields the expected PHI arg constant from the original comparison constant.
[Bug other/105114] [12 regression] contrib/gcc_update hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114 --- Comment #4 from Jakub Jelinek --- Mar 30 15:14 is certainly much newer than Mar 30 10:16. Perhaps try make -d -f Makefile.28475 all ?
[Bug ipa/104303] [12 regression] gnatmake is miscompiled by IPA/modref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104303
--- Comment #3 from Richard Biener ---
The store
D.5010.P_BOUNDS = &D.5011;
is
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set 9 canonical-type
0x7653bf18 fields Ada size
pointer_to_this chain >
public unsigned DI size unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set 4 canonical-type
0x7653b150>
arg:0
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type
0x7653b348 fields context
unconstrained array
pointer_to_this chain >
used ignored TI concat5_pkg1.adb:15:5 size unit-size
align:128 warn_if_not_align:0 context
chain
addressable used ignored DI concat5_pkg1.adb:15:5 size unit-size
align:32 warn_if_not_align:0 context chain >>
arg:1
visited unsigned DI :0:0 size
unit-size
align:64 warn_if_not_align:0 offset_align 128
offset bit-offset context >>
and the issue is that somehow the summary for
concat5_pkg1.make_failed (D.5010);
only has an base/ref/access node for MODREF_GLOBAL_MEMORY_PARM and
nothing else. In .modref2 this function is just
void concat5_pkg1.make_failed (struct s)
{
struct string___XUB * s$P_BOUNDS;
[local count: 1073741824]:
concat5_pkg2.compare (s);
return;
but we do
modref analyzing 'Concat5_Pkg1.Make_Failed/0' (ipa=0)
Past summary:
loads:
Every base
stores:
Every base
Side effects
Nondeterministic
Global memory read
Global memory written
- Analyzing load: s
- Read-only or local, ignoring.
- Analyzing call:concat5_pkg2.compare (s);
- Function availability <= AVAIL_INTERPOSABLE.
- modref done with result: tracked.
loads:
Base 0: alias set 0
Ref 0: alias set 0
access: Base in global memory
stores:
Base 0: alias set 0
Ref 0: alias set 0
access: Base in global memory
Side effects
Nondeterministic
Global memory read
Global memory written
so it seems we fail to consider by-value escaping parameters. Something
like the following, but it does not reproduce with that, so there must
be sth special with the Ada testcase.
struct X { int i; };
void foo (struct X);
static void __attribute__((noinline))
bar (struct X x)
{
foo (x);
}
void baz ()
{
struct X x;
x.i = 1;
bar (x);
}
Btw, if we disable modref2 the testcase works - so somehow dropping that we
load/store all bases wrecks things.
Honza?
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #32 from Jakub Jelinek ---
One of the reasons we changed the ABI on various arches one way or another is
that we had this ABI incompatibility between C and C++, that just can't be
right.
At that time we can and should decide if we go for compatibility with C or C++.
The MIPS n64 wording I could find:
"Regardless of the struct field structure, it is treated as a sequence of
64-bit chunks. If a chunk consists solely of a double float field (but not a
double, which is part of a union), it is passed in a floating point register.
Any other chunk is passed in an integer register."
is unclear for both the zero width bitfields and empty structure/union C
members,
members that have zero size and are on the 64-bit chunk boundaries can belong
to either previous or next chunk or can be ignored altogether.
I think best would be to ignore them altogether, especially if other compilers
do that too.
Also consider:
struct T {};
struct S { struct T t; double a; struct T u; double b; };
struct U { int a[0]; double b; int c[0]; double d; };
argument passing in C (etc.) - in C++ struct T will have size 1 and therefore
will be passed differently between C (which pedantically disallows empty
structures or zero length arrays) and C++.
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024 --- Comment #31 from Segher Boessenkool --- Well, what do other compilers do? It's not such a good idea to break ABI compatibility with the 1990's compilers ;-)
[Bug other/105114] [12 regression] contrib/gcc_update hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114 --- Comment #3 from seurer at gcc dot gnu.org --- I did look at the Makefile and didn't see anything that jumped out as weird. I will try comparing it to one that works. Those files all exist. -rwxr-xr-x 1 seurer users 2954 Mar 30 10:16 gcc/config/loongarch/genopts/genstr.sh -rw-r--r-- 1 seurer users 5231 Mar 30 10:16 gcc/config/loongarch/genopts/loongarch.opt.in -rw-r--r-- 1 seurer users 1756 Mar 30 15:14 gcc/config/loongarch/loongarch-str.h -rw-r--r-- 1 seurer users 5011 Mar 30 10:16 gcc/config/loongarch/loongarch.opt
[Bug gcov-profile/105063] [GCOV] Ability to map .gcda paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063 --- Comment #13 from Martin Liška --- Created attachment 52724 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52724&action=edit Tentative patch Can you please experiment with the following patch?
[Bug gcov-profile/105063] [GCOV] Ability to map .gcda paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063 --- Comment #12 from vit9696 --- It is an in-house airborne RTOS we develop in ISP RAS. There is a legacy paper in English telling a bit more about the project (https://www.ispras.ru/proceedings/docs/2016/28/2/isp_28_2016_2_181.pdf).
[Bug gcov-profile/105063] [GCOV] Ability to map .gcda paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063 --- Comment #11 from Martin Liška --- (In reply to vit9696 from comment #10) > I believe this is possible. Since we use both clang and gcc, I filed an > issue in llvm first to make sure both compilers can be updated in a similar > way (https://github.com/llvm/llvm-project/issues/54670). Thanks. Btw. what's the name of an embedded project where you need the functionality?
[Bug gcov-profile/105063] [GCOV] Ability to map .gcda paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063 --- Comment #10 from vit9696 --- I believe this is possible. Since we use both clang and gcc, I filed an issue in llvm first to make sure both compilers can be updated in a similar way (https://github.com/llvm/llvm-project/issues/54670).
[Bug debug/105108] incomplete/incorrect DWARF information at -O1 and -Og after inlining a function returning a constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108 --- Comment #7 from Jakub Jelinek --- There can be security concerns with that though if just print variable in a debugger lets you format your disk etc. though, while DWARF expressions can do a lot, they can't modify registers or memory of the debugged program, perform I/O etc., while this would allow it to be done under the hood without the user knowing it is happening.
[Bug debug/105108] incomplete/incorrect DWARF information at -O1 and -Og after inlining a function returning a constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108 --- Comment #6 from Jakub Jelinek --- Note, for computations expressible in DWARF expressions DWARF already has DW_OP_call* which doesn't actually mean a call in the inferior call sense, but a call in the DWARF expression evaluation sense, so one can create artificial DW_TAG_dwarf_procedure and have its location expression be some DWARF expression and use that to decrease size of emitted DWARF or even to emit code to evaluate optimized away simple functions. But what is missing is a way to request evaluation of an inferior call.
[Bug debug/105108] incomplete/incorrect DWARF information at -O1 and -Og after inlining a function returning a constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108 Jakub Jelinek changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Guess that would be certainly possible, but best would be to propose such an extension for inclusion into DWARF 6 because we are really tight in the DW_OP_GNU_* opcode space. BTW, if it would be IPA-VRP we could perhaps replace in debug stmts calls to the singleton value range (if any), but in this case it is removed purely because it is a const call and a signed char will never be equal to 128 (at least on most -fsigned-char targets).
[Bug debug/105108] incomplete/incorrect DWARF information at -O1 and -Og after inlining a function returning a constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108 --- Comment #4 from Richard Biener --- (In reply to Jakub Jelinek from comment #2) > Yeah, there is nothing we can do in the debug info about this. > We really can't inline just for the purposes of debug stmts or something > similar. > Another similar case would be if l_144 is assigned b() but isn't actually > used at all, if b() is pure (explicitly or implicitly detected), the call > will be DCEd and there is no way how to express it in the debug info. I wondered if one could extend DWARF to have an expression op that says 'call this abstract function described in DIE x [with arguments from stack] and push the result'. That could also be used to maybe abstract parts of DWARF expressions into DWARF expression functions and in theory we could compile functions into DWARF bytecode if there's no native copy emitted to be called from the debugger in inferior context (to some extent at least).
[Bug debug/105108] incomplete/incorrect DWARF information at -O1 and -Og after inlining a function returning a constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108 --- Comment #3 from Jakub Jelinek --- And I certainly can't reproduce the wrong-debug issue you're talking about. If I change it to char l_144 = 8; then optimized dump has: [local count: 1073741824]: # DEBUG BEGIN_STMT # DEBUG l_144 => 8 # DEBUG BEGIN_STMT # DEBUG l_165 => 128 # DEBUG BEGIN_STMT # DEBUG l_144 => NULL # DEBUG BEGIN_STMT a = 1; return 0; and in the debugger it correctly says that (gdb) p l_144 $1 = because at the a = 1 store the value is unknown.
[Bug debug/105108] incomplete/incorrect DWARF information at -O1 and -Og after inlining a function returning a constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Yeah, there is nothing we can do in the debug info about this. We really can't inline just for the purposes of debug stmts or something similar. Another similar case would be if l_144 is assigned b() but isn't actually used at all, if b() is pure (explicitly or implicitly detected), the call will be DCEd and there is no way how to express it in the debug info.
[Bug ada/61027] gnatcmd gets SIGABRT during exception handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61027 Arnaud Charlet changed: What|Removed |Added Target Milestone|--- |11.0 CC||charlet at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Arnaud Charlet --- Closing
[Bug ada/89583] GNAT.Sockets.Bind_Socket fails with IPv4 address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89583 Arnaud Charlet changed: What|Removed |Added Target Milestone|--- |12.0 CC||charlet at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Arnaud Charlet --- Closing then!
[Bug gcov-profile/105063] [GCOV] Ability to map .gcda paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063 Martin Liška changed: What|Removed |Added Status|WAITING |NEW --- Comment #9 from Martin Liška --- Ok, so let's use the existing -fprofile-prefix-map and use it for the modification of where .gcda files are stored. Can you please prepare a patch that will fulfill your needs?
[Bug ada/63675] Non-confirming aspect doesn’t fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63675 Arnaud Charlet changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.0 CC||charlet at gcc dot gnu.org --- Comment #3 from Arnaud Charlet --- Closing then!
[Bug tree-optimization/105109] [12 Regression] False positive warning on complex float code since r12-155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105109 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/105109] [12 Regression] False positive warning on complex float code since r12-155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105109 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:97ad0b831386e56ecb125a25fff00b2cb0b1a2b9 commit r12-7934-g97ad0b831386e56ecb125a25fff00b2cb0b1a2b9 Author: Richard Biener Date: Thu Mar 31 09:21:27 2022 +0200 tree-optimization/105109 - bogus uninit diagnostic with _Complex When update_address_taken rewrites a _Complex into SSA it changes stores to real/imaginary parts to loads of the other component and a COMPLEX_EXPR. That matches what gimplification does but it misses suppression of diagnostics for the load of the other component. The following patch adds that, syncing up gimplification and update_address_taken behavior. 2022-03-31 Richard Biener PR tree-optimization/105109 * tree-ssa.cc (execute_update_addresses_taken): Suppress diagnostics on the load of the other complex component. * gcc.dg/uninit-pr105109.c: New testcase.
[Bug gcov-profile/105063] [GCOV] Ability to map .gcda paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063 --- Comment #8 from vit9696 --- > Sure, well, I can imagine introducing something similar to what we have for > gcov: > > $ gcov --help | grep hash > -x, --hash-filenamesHash long pathnames Yes, that would likely solve the issue, though in an unexpected way for me. However, while it is highly unlikely, I can expect collisions in this case, and would rather not risk it. > Well, I don't fully understand your needs. On one hand, you're unhappy about > the relative placement of the .gcda files. And on the other, you don't like -fprofile-dir=/path. Note you can copy the *.gcda files to an arbitrary location and use it for -fprofile-use=/some/path. That does not require knowledge of -fprofile-generate=/original/path. > I'm sorry for defensive argumentation, but believe me the .gcda filename > handling is very complex even in the current situation. Sorry. I guess there are multiple issues that arose on our side, which also made the report rather confusing. What we have here is a CI building code on different nodes at different paths (they are different, because multiple builds can run on the same node). Depending on various meta information like node name, branch name, and so on, which is present in the build prefix, the gcda files we get may be too long and randomly exceed the 200 byte path limitation we have. The thing is, our source paths do not exceed this limitation, and the problem is just with the prefix, which we would like to entirely strip. It would have worked fine if: (a) build directory relative paths were stored as the .gcda paths (/a/b/c/master/path/to/file.gcda becomes path/to/file.gcda) or (b) special prefix + build directory relative paths were stored as the .gcda paths (/a/b/c/master/path/to/file.gcda becomes /special/path/to/file.gcda). Thus the need for the option. Going this way also allows us to resolve a second issue. To speedup testing we prebuild most of the source code on one machine, and then distribute the resulting .o and .a files to other machines. Currently this is unimplemented for coverage, but we would also like to distribute .gcno files the same way, and avoid the need to compile on the node when doing coverage gathering. The issue here is that different processes on the target may share some object code (e.g. libraries). Dumping coverage for different processes means that we have to produce multiple .gcda files on the node from the same .gcda paths in the object code. I.e. they not only depend on the build node path, but also the process we are dumping the information from. To be able to produce an adequate .gcda tree on the node with the current implementation we would have to remember all the original build node prefixes of the library code. Otherwise we would be unable to remap build node path to a run node path for a particular process (to get the .gcno files for instance). However, if all userspace code is compiled with e.g. /special prefix, and the original build prefix is stripped, only one path needs to be handled: /special/lib1/path/to/file1.gcda /special/lib2/path/to/file2.gcda /special/lib3/path/to/file3.gcda /special/path/to/source.gcda Hope this makes the situation clearer, and helps to understand why the particular option is desired.
[Bug other/105114] [12 regression] contrib/gcc_update hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- This is just weird, all the files in question: gcc/config/loongarch/loongarch-str.h gcc/config/loongarch/genopts/genstr.sh gcc/config/loongarch/genopts/loongarch-string gcc/config/loongarch/loongarch.opt gcc/config/loongarch/genopts/loongarch.opt.in have been added in the same commit as contrib/gcc_update has been updated. So, if you still have a tree where it hangs, can you ls -l gcc/config/loongarch/loongarch-str.h gcc/config/loongarch/genopts/genstr.sh gcc/config/loongarch/genopts/loongarch-string gcc/config/loongarch/loongarch.opt gcc/config/loongarch/genopts/loongarch.opt.in ?
[Bug target/105069] [12 regression] sh-elf internal compiler errors and test failures with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069
--- Comment #7 from Martin Liška ---
(In reply to Jakub Jelinek from comment #6)
> While changing mdiv= from accepting a string to Enum(something) might be
> worth it, wouldn't that be GCC 13 material? I think right now -mdiv=
> accepts random garbage like -mdiv=foobar . There is also an enum already
> but there is no 1:1
> mapping between what is assigned to sh_div_strategy from what is in
> sh_div_str,
> and sh_div_strategy probably should be a TargetVariable.
>
> Anyway, wouldn't the following be enough for now to just do:
>
> 2022-03-31 Jakub Jelinek
>
> PR target/105069
> * config/sh/sh.opt (mdiv=): Add Save.
>
> --- gcc/config/sh/sh.opt.jj 2022-01-11 23:11:21.990295775 +0100
> +++ gcc/config/sh/sh.opt 2022-03-31 09:43:45.916244944 +0200
> @@ -207,7 +207,7 @@ Target RejectNegative Mask(ALIGN_DOUBLE)
> Align doubles at 64-bit boundaries.
>
> mdiv=
> -Target RejectNegative Joined Var(sh_div_str) Init("")
> +Target Save RejectNegative Joined Var(sh_div_str) Init("")
> Division strategy, one of: call-div1, call-fp, call-table.
>
> mdivsi3_libfunc=
>
> The testcase doesn't ICE with it anymore, and e.g. i386.opt has various Save
> strings too.
Yes, that's going to work as with the patch the target value is properly saved
and restored in cl_target_option_{save,restore}.
[Bug target/105069] [12 regression] sh-elf internal compiler errors and test failures with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069
Jakub Jelinek changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
||olegendo at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
While changing mdiv= from accepting a string to Enum(something) might be worth
it, wouldn't that be GCC 13 material? I think right now -mdiv= accepts random
garbage like -mdiv=foobar . There is also an enum already but there is no 1:1
mapping between what is assigned to sh_div_strategy from what is in sh_div_str,
and sh_div_strategy probably should be a TargetVariable.
Anyway, wouldn't the following be enough for now to just do:
2022-03-31 Jakub Jelinek
PR target/105069
* config/sh/sh.opt (mdiv=): Add Save.
--- gcc/config/sh/sh.opt.jj 2022-01-11 23:11:21.990295775 +0100
+++ gcc/config/sh/sh.opt2022-03-31 09:43:45.916244944 +0200
@@ -207,7 +207,7 @@ Target RejectNegative Mask(ALIGN_DOUBLE)
Align doubles at 64-bit boundaries.
mdiv=
-Target RejectNegative Joined Var(sh_div_str) Init("")
+Target Save RejectNegative Joined Var(sh_div_str) Init("")
Division strategy, one of: call-div1, call-fp, call-table.
mdivsi3_libfunc=
The testcase doesn't ICE with it anymore, and e.g. i386.opt has various Save
strings too.
[Bug gcov-profile/105063] [GCOV] Ability to map .gcda paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063 --- Comment #7 from Martin Liška --- (In reply to vit9696 from comment #6) > While true, this scenario is simply inconvenient in many cases. > > (1) When filesystem path limitations exist, they will unavoidably lead to > being unable to save data due to extra large resulting paths. To remind you, > even Windows, a desktop os, had 260 path length limit not so long ago. Sure, well, I can imagine introducing something similar to what we have for gcov: $ gcov --help | grep hash -x, --hash-filenamesHash long pathnames > (2) When analysing gcda files on a different machine one needs to be aware > of the original paths on the machine used for compilation, and we do not > want to require this knowledge. Well, I don't fully understand your needs. On one hand, you're unhappy about the relative placement of the .gcda files. And on the other, you don't like -fprofile-dir=/path. Note you can copy the *.gcda files to an arbitrary location and use it for -fprofile-use=/some/path. That does not require knowledge of -fprofile-generate=/original/path. I'm sorry for defensive argumentation, but believe me the .gcda filename handling is very complex even in the current situation.
[Bug target/105069] [12 regression] sh-elf internal compiler errors and test failures with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #5 from Martin Liška --- Well, the fix should be using TargetVariable for sh_div_str which will be then automatically saved/restore in cl_target_option. However, one would need to convert it from 'const char *' to an enum value. Leaving that to a port maintainer.
[Bug middle-end/103393] [12 Regression] Generating 256bit register usage with -mprefer-avx128 -mprefer-vector-width=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #25 from Richard Biener --- Should be fixed by means of reversion of r12-3482-g5f6a6c91d7c592
[Bug rtl-optimization/105091] RTL dse1 remove stack mem storing incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #16 from Richard Biener --- Fixed. Btw, this latent issue was likely exposed by r12-910-g35a16e4b38eb9f
[Bug rtl-optimization/105091] RTL dse1 remove stack mem storing incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091 --- Comment #15 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:b75f996e846d079251f3a6134617f0405c3ed535 commit r12-7932-gb75f996e846d079251f3a6134617f0405c3ed535 Author: Richard Biener Date: Thu Mar 31 08:20:43 2022 +0200 rtl-optimization/105091 - wrong DSE with missed TREE_ADDRESSABLE When expanding an aggregate copy into a memcpy call RTL expansion uses mark_addressable to ensure the base object is addressable but that function doesn't handle TARGET_MEM_REF bases. Fixed as follows. 2022-03-31 Richard Biener PR rtl-optimization/105091 * gimple-expr.cc (mark_addressable): Handle TARGET_MEM_REF bases.
[Bug gcov-profile/105063] [GCOV] Ability to map .gcda paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063 --- Comment #6 from vit9696 --- While true, this scenario is simply inconvenient in many cases. (1) When filesystem path limitations exist, they will unavoidably lead to being unable to save data due to extra large resulting paths. To remind you, even Windows, a desktop os, had 260 path length limit not so long ago. (2) When analysing gcda files on a different machine one needs to be aware of the original paths on the machine used for compilation, and we do not want to require this knowledge.
[Bug other/105114] [12 regression] contrib/gcc_update hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 --- Comment #1 from Richard Biener --- I suggest to ping the loongarch folks. Did you inspect the generated Makefile to see if there's anything obviously "odd"?
[Bug gcov-profile/105063] [GCOV] Ability to map .gcda paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063 --- Comment #5 from Martin Liška --- (In reply to vit9696 from comment #4) > Path length limitation in the current case is 200 bytes, but in general the > issue is that we would like _to be able to properly set the gcda path for > the target_.(In reply to vit9696 from comment #4) > Path length limitation in the current case is 200 bytes, but in general the > issue is that we would like _to be able to properly set the gcda path for > the target_. Currently the specified path may not even exist when > cross-compiling, and no approach to change it without prepending to the > build path is simply inconvenient. Well, if you do a cross-compilation, then you can use -fprofile-dir=/tmp/foobar and then use -fprofile-use on the same system where you run the instrumentation run.
