[Bug c++/95455] ICE in capture with initializer in requires block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95455 Egor Pugin changed: What|Removed |Added CC||egor.pugin at gmail dot com --- Comment #6 from Egor Pugin --- 10.5 - ice 11.4 - ice 12.3 - ok 13.2 - ok 14.x - ice
[Bug analyzer/109802] [13 Regression] ICE using dubious flexible arrays in unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109802 --- Comment #6 from Alejandro Colomar --- Thanks for fixing it! Would you mind showing which commit fixed this? I'm curious about it. I searched in the git log, but nothing mentioned this bug number. Now I can come to my original intent, which is asking if this code is supported by GCC, as in Does this code have defined behavior under GCC? Does it need and -f flags to be defined? Or is it just undefined behavior? I ask because this code exists in a real project.
[Bug c/90253] no warning for cv-qualified selectors in _Generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90253 uecker at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-04-14 CC||uecker at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from uecker at gcc dot gnu.org --- Confirmed. Note that typeof preserves qualifiers in C23. Clang has an extension for _Generic that allows the use of a typename, which allows testing for qualifiers more easily: https://godbolt.org/z/K5hGP9cYn
[Bug lto/114713] New: incorrect TBAA for struct with flexible array member or GNU zero size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114713
Bug ID: 114713
Summary: incorrect TBAA for struct with flexible array member
or GNU zero size
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
If one mixes a struct with FAM and one with zero size at the end, then TBAA
considers them incompatible for aliasing purposes when using LTO. One could
decide that those are incompatible types, but this would break code that mixes
both, e.g. during a transition time to standard FAMs. Also affects old versions
of GCC.
https://godbolt.org/z/xodMK9sqE
struct foo { int x; char a[]; };
void test_bar(void* b);
__attribute__((noinline))
int test_foo(struct foo* a, void* b)
{
a->x = 1;
test_bar(b);
return a->x;
}
int main()
{
struct foo y;
if (2 != test_foo(&y, &y))
__builtin_abort();
return 0;
}
// TU2
struct foo { int x; char a[0]; };
void test_bar(void* b)
{
struct foo *p = b;
p->x = 2;
}
[Bug target/114714] New: [RISC-V][RVV] ICE: insn does not satisfy its constraints (postreload)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714
Bug ID: 114714
Summary: [RISC-V][RVV] ICE: insn does not satisfy its
constraints (postreload)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sch...@linux-m68k.org
Target Milestone: ---
Target: riscv64-*-*
Created attachment 57945
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57945&action=edit
widen_mul_test.cc.ii
$ c++ -O2 -std=c++17 -fPIE -march=rv64gcv1p0 -S widen_mul_test.cc.ii
../hwy/tests/widen_mul_test.cc: In function 'void
hwy::N_RVV::TestAllReorderWidenMulAccumulate()':
../hwy/tests/widen_mul_test.cc:348:1: error: insn does not satisfy its
constraints:
348 | }
| ^
(insn 1205 1214 5405 69 (set (reg:RVVM1SI 97 v1 [orig:687 _1177 ] [687])
(if_then_else:RVVM1SI (unspec:RVVMF32BI [
(const_vector:RVVMF32BI repeat [
(const_int 1 [0x1])
])
(reg:DI 25 s9 [orig:539 _889 ] [539])
(const_int 2 [0x2]) repeated x2
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(zero_extend:RVVM1SI (reg:RVVMF2HI 97 v1 [orig:654 _1100 ] [654]))
(unspec:RVVM1SI [
(reg:DI 0 zero)
] UNSPEC_VUNDEF))) "../hwy/ops/rvv-inl.h":1964:386 discrim 1
8360 {pred_zero_extendrvvm1si_vf2}
(nil))
during RTL pass: postreload
../hwy/tests/widen_mul_test.cc:348:1: internal compiler error: in
extract_constrain_insn, at recog.cc:2713
[Bug c++/106820] [modules] ICE in function_and_variable_visibility with modules and weakref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106820 --- Comment #10 from Patrick Palka --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:62a0ef0d02cbb74cd865c1db2ecb7ca1b11f87cd commit r14-9959-g62a0ef0d02cbb74cd865c1db2ecb7ca1b11f87cd Author: Nathaniel Shead Date: Sat Feb 17 23:10:49 2024 +1100 c++: Setup aliases imported from modules [PR106820] I wonder if more generally we need to be doing more work when importing definitions from header units especially to handle all the work that 'make_rtl_for_nonlocal_decl' and 'rest_of_decl_compilation' would have been performing. But this patch fixes at least one missing step. PR c++/106820 gcc/cp/ChangeLog: * module.cc (trees_in::decl_value): Assemble alias when needed. gcc/testsuite/ChangeLog: * g++.dg/modules/pr106820_a.H: New test. * g++.dg/modules/pr106820_b.C: New test. Signed-off-by: Nathaniel Shead
[Bug libfortran/114618] Format produces incorrect output when contains 1x, ok when uses " "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
--- Comment #5 from Jerry DeLisle ---
A further reduction:
program tryit
implicit none
integer, parameter :: wp = kind(0d0)
real(kind=wp) :: pi =
3.14159265358979323846264338327950288419716939937510582097494459230_wp
character(40) gen1
character(40) gen2
gen1 = '(19("."),t1,g0,1x,t21,g0)'
gen2 = '(19("."),t1,g0," ",t21,g0)'
write (*, gen1) 'RADIX', radix(pi)
write (*, gen1) 'RANGE', range(pi)
write (*,'(80("-"))')
write (*, gen2) 'RADIX', radix(pi)
write (*, gen2) 'RANGE', range(pi)
end program tryit
This is indeed ugly. Note the embedded NULLs.
$ ./a.out >newdata
$ xxd newdata
: 5241 4449 582e 2e2e 2e2e 2e2e 2e2e 2e2e RADIX...
0010: 2e2e 2e00
0020: 0020 320a 5241 4e47 452e 2e2e 2e2e 2e2e . 2.RANGE...
0030: 2e2e 2e2e 2e2e 2e00
0040: 0020 3330 370a 2d2d 2d2d 2d2d . 307.--
0050: 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d
0060: 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d
0070: 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d
0080: 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d
0090: 2d2d 2d2d 2d2d 2d2d 2d2d 0a52 4144 4958 --.RADIX
00a0: 202e 2e2e 2e2e 2e2e 2e2e 2e2e 2e2e 2032 . 2
00b0: 0a52 414e 4745 202e 2e2e 2e2e 2e2e 2e2e .RANGE .
00c0: 2e2e 2e2e 2033 3037 0a 307.
[Bug libfortran/114618] Format produces incorrect output when contains 1x, ok when uses " "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618 Jerry DeLisle changed: What|Removed |Added Status|REOPENED|NEW Depends on||113897, 109358 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 [Bug 109358] Wrong formatting with T-descriptor during stream output https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113897 [Bug 113897] Consecutive tab and/or nX edits in format are not processed correctly.
[Bug c++/103511] __builtin_bit_cast requires a constructor call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103511 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-04-14 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #6 from Andrew Pinski --- Confirmed. Both clang and MSVC accept this.
[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393 --- Comment #9 from Patrick Welche --- Thank you! $ /usr/local/gcc/bin/g++ --version g++ (GCC) 14.0.1 20240414 (experimental) $ ./readme_ex 0 1 4
[Bug target/114656] [15 Regression] ~5% slowdown of 538.imagick_r on aarch64 since r14-9692
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114656 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0 Ever confirmed|0 |1 Last reconfirmed||2024-04-14 Summary|~5% slowdown of |[15 Regression] ~5% |538.imagick_r on aarch64|slowdown of 538.imagick_r |since r14-9692 |on aarch64 since r14-9692 Status|UNCONFIRMED |NEW --- Comment #3 from Andrew Pinski --- . Patch weas reverted but it will be added back after branching so ...
[Bug gcov-profile/114115] xz-utils segfaults when built with -fprofile-generate (bad interaction between IFUNC and binding?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115 --- Comment #17 from H.J. Lu --- (In reply to Jan Hubicka from comment #15) > > Fixed for GCC 14 so far > It is simple patch, so backporting is OK after a week in mainline. These are patches which I am backporting: https://patchwork.sourceware.org/project/gcc/list/?series=32823
[Bug bootstrap/56623] Can't build GCC due to tar: ./ssl: Cannot utime: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56623
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Andrew Pinski ---
This works for many other people even back then.
What is failing is tar while fixincludes is doing a copying:
(cd `${PWDCMD-pwd}`/include-fixed ; \
tar -cf - .; exit 0) | (cd
/tmp/WebKit/WebKitBuild/Dependencies/Source/gcc-4.7.2/host-x86_64-unknown-linux-gnu/prev-gcc/../gcc/./include-fixed;
tar xpf - )
So if it is failing, either there is something wrong with the kernel you were
using or filesystem that is at fault (or ssl got created incorrectly which I
doubt it but it might have been an issue with your /usr/include in the first
place).
Nothing GCC build system is doing wrong.
[Bug bootstrap/51450] configure's test for -fno-rtti -fno-exceptions broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51450 --- Comment #6 from Andrew Pinski --- configure:18495: checking if gcc supports -fno-rtti -fno-exceptions configure:18513: gcc -c -g -fno-rtti -fno-exceptions conftest.c >&5 cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C configure:18517: $? = 0 configure:18530: result: no It should have used g++ here ... Note the previous one works though: configure:7500: checking whether gcc supports -fno-rtti configure:7517: gcc -c -fno-rtti conftest.c >&5 cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C configure:7517: $? = 0 configure:7526: result: yes https://lists.gnu.org/archive/html/libtool/2003-08/msg3.html Looks like the issue upstream in libtool now the question comes is this fixed upstream or not. Note the test here is not an issue for GCC's builds in general due to the extra testing for -fno-rtti -fno-exceptions that gcc does but still an issue for the libtool that is included with gcc.
[Bug bootstrap/64271] Minimal patches to bootstrap on NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64271 Andrew Pinski changed: What|Removed |Added Severity|blocker |normal
[Bug bootstrap/64271] Minimal patches to bootstrap on NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64271 Andrew Pinski changed: What|Removed |Added Target||*-*-netbsd --- Comment #18 from Andrew Pinski --- Yes libgfortran still needs this patch. Currently it has: case "$host" in *-*-darwin* | *-*-hpux* | *-*-cygwin* | *-*-mingw* | *-*-musl* ) AC_DEFINE(GTHREAD_USE_WEAK, 0, [Define to 0 if the target shouldn't use #pragma weak]) ;; esac]) I wonder if we should not put this code in a config/*.m4 file in the toplevel instead of different acinclude.m4.
[Bug bootstrap/64271] Minimal patches to bootstrap on NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64271 --- Comment #19 from Andrew Pinski --- Note libgcc uses t-gthr-noweak to get the define.
[Bug debug/47292] Violation of DWARF-3 spec for DW_FORM_strp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47292 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- case dw_val_class_str: form = AT_string_form (a); if (form == DW_FORM_strp || form == DW_FORM_line_strp) size += dwarf_offset_size; if (a->dw_attr_val.v.val_str->form == DW_FORM_strp) dw2_asm_output_offset (dwarf_offset_size, a->dw_attr_val.v.val_str->label, debug_str_section, "%s: \"%s\"", name, AT_string (a)); if (node->form == DW_FORM_strp) dw2_asm_output_offset (dwarf_offset_size, node->label, debug_str_section, "The macro: \"%s\"", ref->info); >This version of the compiler marks its debug information as dwarf-3 >This version of the compiler is generating 32 bit integers for both 32 and 64 >bit formats. Actually it outputs dwarf3 32bit by default. So this is a misunderstanding here. Even if gcc is outting for 64bit, GCC defaults to outputting 32bit dwarf[2-5]. GCC 11 (r11-5742-g65312dfc647444) adds an option to change to outputting 64bit dwarf[2-5] though. (note only powerpc-aix defaults to 64bit dwarf output; all other targets use 32bit dwarf).
[Bug testsuite/49375] Target libstdc++.so used by host cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49375 --- Comment #5 from Andrew Pinski --- ppl support was removed with r0-117618-g33ad93b9f4cb21 for GCC 4.8.0. I Have not looked if ISL requires libstdc++ or is only statically linked yet.
[Bug bootstrap/32497] (const_int INT_MIN) can cause warnings to show up while building insn-emit.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497 Andrew Pinski changed: What|Removed |Added Summary|Crosscomiling native sh3|(const_int INT_MIN) can |gcc on a 64-bit host fails |cause warnings to show up ||while building insn-emit.c Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #19 from Andrew Pinski --- Let me take a look into fix this issue for GCC 15. It might be already fixed when GCC moved over to requiring a C++11 compiler ...
[Bug libgomp/71646] incompability between ptx code and GPU hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71646 --- Comment #1 from Andrew Pinski --- sm_30 is definitely the min target for offloading for GCC to nvptx . What I don't know if `nvidia geforce gt 430` support is still existant in cuda. Maybe someone who knows the offloading support for Nvidia GPUs should comment here really.
[Bug c++/71333] Broken Python extension produced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71333 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- I see the code inside pteros was removed in commit 6cacaa4e20dfacd131f885389ebf64336ca1aa6a in September 2017. Since there is no way to reproduce the issue I am going to close it as invalid.
[Bug target/114714] [RISC-V][RVV] ICE: insn does not satisfy its constraints (postreload)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714 Li Pan changed: What|Removed |Added CC||pan2.li at intel dot com --- Comment #1 from Li Pan --- Confirmed from riscv64-unknown-elf-g++ (GCC) 14.0.1 20240415 (experimental).
[Bug debug/78322] Debug info still present for fully optimized away functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78322 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=107513 --- Comment #4 from Andrew Pinski --- (In reply to David Blaikie from comment #2) > (In reply to Richard Biener from comment #1) > > We produce an abstract copy for use by repeated inline copies. > > Yep! Is it still reasonable to consider it a bug (or at least a feature > request) that this is still produced even when no inline copies are emitted? Not really. Sounds like what you are aiming for is the nodebug attribute that you can use with always_inline. Basically in dwarf inline functions are still represented as functions (calls) and most folks want that for their debugability of their program but in this case you specific inlined functions not to have debug info which is exactly what nodebug would do ...
[Bug debug/78322] Debug info still present for fully optimized away functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78322 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2024-04-15
[Bug target/77344] Internal Compiler Error with arch knl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77344 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 71559 ***
[Bug target/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71559 Andrew Pinski changed: What|Removed |Added CC||matthew.thompson at nasa dot gov --- Comment #22 from Andrew Pinski --- *** Bug 77344 has been marked as a duplicate of this bug. ***
[Bug target/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71559 Andrew Pinski changed: What|Removed |Added Known to work||6.2.0, 7.1.0 Known to fail||6.1.0 Target Milestone|--- |6.2
[Bug middle-end/114700] middle-end optimization generates causes -fsanitize=undefined not to happen in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700 --- Comment #17 from Hu Lin --- (In reply to Jakub Jelinek from comment #16) > (In reply to Hu Lin from comment #11) > > I think it doesn't mean that's not a bug with -ftrapv, it should preserve > > all overflow traps. Because it doesn't work, we use -fsanitize=undefined > > instead of it. > > > > refer: Gcc's trapv is known not always to work correctly. > > No, -ftrapv isn't a debugging tool. There is no overflow in the expression > that GCC actually evaluates (into which the expression has been optimized). > If you have overflow in an expression that is never used, GCC with -ftrapv > will also > eliminate it as unused and won't diagnose the trap. > -fsanitize=undefined behaves in that case actually the same with -O1 and > higher (intentionally, to decrease the cost of the sanitization). So, one > needs to use -O0 -fsanitize=undefined to get as many cases of UB in the > program diagnosed as possible. OK, that look like GCC's -ftrapv is not the same as clang's. Then my added condition should be (optimize || !TYPE_OVERFLOW_SANITIZED (type)). > When a pattern already has one if, can't you just add that to the preexisting > if rather than adding yet another one. I made a mistake on this line, it should be + (if (!TYPE_OVERFLOW_SANITIZED (type)) (if (!ANY_INTEGRAL_TYPE_P (type) || TYPE_OVERFLOW_WRAPS (type)) (negate (view_convert @1)) (view_convert (negate @1 I can't just modify the preexisting if, the optimization shouldn't be used with -fsanitize=undefined.
[Bug c/65672] type attribute "aligned" can decrease alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65672 --- Comment #3 from Andrew Pinski --- *** This bug has been marked as a duplicate of bug 89950 ***
[Bug c/89950] attribute aligned ignored with attribute vector_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89950 Andrew Pinski changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- *** Bug 65672 has been marked as a duplicate of this bug. ***
[Bug c/65672] type attribute "aligned" can decrease alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65672 Andrew Pinski changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|NEW --- Comment #4 from Andrew Pinski --- actually let's reopen this one and close the other one as a dup of this one.
[Bug c/89950] attribute aligned ignored with attribute vector_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89950 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 65672 ***
[Bug c/65672] type attribute "aligned" can decrease alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65672 --- Comment #5 from Andrew Pinski --- *** Bug 89950 has been marked as a duplicate of this bug. ***
[Bug c/65672] type attribute "aligned" can decrease alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65672 --- Comment #6 from Andrew Pinski --- Note I see Martin has argued both ways :). Anyways I the issue is in reconstruct_complex_type (either cp_reconstruct_complex_type in gcc/cp/decl2.cc or reconstruct_complex_type in gcc/tree.cc).
[Bug rust/113499] crab1 fails to link when configuring with --disable-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499 --- Comment #8 from Richard Biener --- (In reply to Arthur Cohen from comment #6) > (In reply to Richard Biener from comment #5) > > (In reply to Thomas Schwinge from comment #4) > > > If I understood Arthur correctly, GCC/Rust is going to effectively require > > > 'dlopen' (and therefore '--enable-plugin'?), so that means, if the > > > latter's > > > not available we have to auto-disable Rust language front end if enabled > > > '--enable-languages=all' vs. raise a 'configure'-time error if enabled via > > > explicit '--enable-languages=rust'? > > > > Not sure - --enable-plugin is not about dlopen, it's about exporting all > > GCCs internal symbols for use by a dlopened shared module. Is the > > macro processing requiring this or is it rather self-contained? > > > > Being able to dlopen() is something different. > > No, it does not require this and is rather self contained. Macro expansion > needs to be able to dlopen() compiled Rust libraries, which contain a > specific type of function our frontend calls as a macro. So we always need > to dlopen(). > > Is there anything similar in other frontends? If so, how does it work on > such platforms which do not support dlopen()? I'm not aware of other frontends absolutely requiring dlopen(), but the Modula-2 frontend uses a plugin for some extended diagnostics (but that requires a "real" plugin, with exporting symbols from GCC). I'm not aware of any abstraction for host shared module opening (to cover windows for example), I suppose in the end we need to have such a thing (like libiberty pex_* for execve/wait). Maybe there's functionality in gnulib for this. For now I suggest to look for dlopen(), there's # Some systems need dlopen save_LIBS="$LIBS" LIBS= AC_SEARCH_LIBS(dlopen, dl) DL_LIB="$LIBS" LIBS="$save_LIBS" AC_SUBST(DL_LIB) in gcc/configure.ac, so adding DL_LIB to the crab1 link should possibly suffice.
[Bug gcov-profile/114715] New: Gcov allocates branches to wrong row for nested switches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114715
Bug ID: 114715
Summary: Gcov allocates branches to wrong row for nested
switches
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: a_aili at hotmail dot com
Target Milestone: ---
While using the following GCC version
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
gcov allocates branches to the wrong row when using nested switches.
Given the following test program:
#include
int main()
{
int a = 1;
int b = 2;
int c = -3;
switch(a)
{
case 1:
c = 3;
switch(b) {
case 1:
c = 4;
break;
case 2:
c = 5;
break;
}
break;
case 2:
c = 6;
break;
default:
break;
}
printf("%i, %i, %i\n", a, b, c);
}
compiled with 'gcc test.c -o0 --coverage -o test'.
Gcov invoked with 'gcov --branch-count --branch-probabilities test.c' gives
-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:#include
-:2:
function main called 1 returned 100% blocks executed 70%
1:3:int main()
-:4:{
1:5:int a = 1;
1:6:int b = 2;
1:7:int c = -3;
1:8:switch(a)
branch 0 taken 1
branch 1 taken 0
branch 2 taken 0
-:9: {
1: 10: case 1:
1: 11:c = 3;
branch 0 taken 0
branch 1 taken 1
branch 2 taken 0
-: 12:switch(b) {
#: 13:case 1:
#: 14: c = 4;
#: 15: break;
1: 16:case 2:
1: 17: c = 5;
1: 18: break;
-: 19:}
1: 20:break;
#: 21: case 2:
#: 22:c = 6;
#: 23:break;
#: 24: default:
#: 25:break;
-: 26: }
-: 27:
1: 28:printf("%i, %i, %i\n", a, b, c);
call0 returned 1
-: 29:}
As you can see the branches for the nested switch is allocated to row 11 and
row 12 is marked as not executed. If gcov should have been consistent on how it
allocates coverage the branches on row 11 should have been allocated correctly
to the switch as on row 8. The second switch on row 12 should also be marked as
executed.
[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #30 from Richard Biener ---
I have tested the following since that might confuse the redundant store
removal sanity checks. It bootstraps fine on x86-64-unknown-linux-gnu but
causes
FAIL: gcc.dg/tree-ssa/ssa-dse-36.c scan-tree-dump-times dse1 "Deleted redundant
call" 3
FAIL: gcc.dg/tree-ssa/ssa-dse-36.c scan-tree-dump-times dse1 "Deleted redundant
store" 3
in particular foo1 and foo2 are no longer optimized. Specifically foo1:
- x = {};
+ MEM [(struct X *)&x] = {};
+ memset (&x.mem1, 0, 10);
the lack of the 'memset' removal looks fishy since memset uses alias set
zero while the earlier store uses the alias set of struct X (but contains
alias set zero because of the char[] members). For foo2:
x = {};
+ x.mem1[5] = 0;
the issue is less clear since 'x' is also involved in the store to
x.mem1[5] (but that store also uses alias-set zero). This shows the
situation is a bit odd wrt the behavior of a whole-aggregate store vs.
a component-wise store. But again in both cases a later conflict check
with say *(int *)p, while conflicting with the memset and x.mem1[5] stores,
would not conflict with the x = {} store.
So this fallout is to be expected and desired.
diff --git a/gcc/alias.cc b/gcc/alias.cc
index 808e2095d9b..bacae30db18 100644
--- a/gcc/alias.cc
+++ b/gcc/alias.cc
@@ -427,9 +427,7 @@ alias_set_subset_of (alias_set_type set1, alias_set_type
set2)
/* Check if set1 is a subset of set2. */
ase2 = get_alias_set_entry (set2);
- if (ase2 != 0
- && (ase2->has_zero_child
- || (ase2->children && ase2->children->get (set1
+ if (ase2 != 0 && ase2->children && ase2->children->get (set1))
return true;
/* As a special case we consider alias set of "void *" to be both subset
[Bug middle-end/114700] middle-end optimization generates causes -fsanitize=undefined not to happen in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700 --- Comment #18 from Jakub Jelinek --- (In reply to Hu Lin from comment #17) > (In reply to Jakub Jelinek from comment #16) > > (In reply to Hu Lin from comment #11) > > > I think it doesn't mean that's not a bug with -ftrapv, it should preserve > > > all overflow traps. Because it doesn't work, we use -fsanitize=undefined > > > instead of it. > > > > > > refer: Gcc's trapv is known not always to work correctly. > > > > No, -ftrapv isn't a debugging tool. There is no overflow in the expression > > that GCC actually evaluates (into which the expression has been optimized). > > If you have overflow in an expression that is never used, GCC with -ftrapv > > will also > > eliminate it as unused and won't diagnose the trap. > > -fsanitize=undefined behaves in that case actually the same with -O1 and > > higher (intentionally, to decrease the cost of the sanitization). So, one > > needs to use -O0 -fsanitize=undefined to get as many cases of UB in the > > program diagnosed as possible. > > OK, that look like GCC's -ftrapv is not the same as clang's. Then my added > condition should be (optimize || !TYPE_OVERFLOW_SANITIZED (type)). Why? Just !TYPE_OVERFLOW_SANITIZED (type). > > When a pattern already has one if, can't you just add that to the > > preexisting if rather than adding yet another one. > > I made a mistake on this line, it should be > + (if (!TYPE_OVERFLOW_SANITIZED (type)) > (if (!ANY_INTEGRAL_TYPE_P (type) > || TYPE_OVERFLOW_WRAPS (type)) > (negate (view_convert @1)) > (view_convert (negate @1 > > I can't just modify the preexisting if, the optimization shouldn't be used > with -fsanitize=undefined. TYPE_OVERFLOW_SANITIZED is #define TYPE_OVERFLOW_SANITIZED(TYPE) \ (INTEGRAL_TYPE_P (TYPE) \ && !TYPE_OVERFLOW_WRAPS (TYPE) \ && (flag_sanitize & SANITIZE_SI_OVERFLOW)) so, it isn't true for non-integral types, nor for TYPE_OVERFLOW_WRAPS types. So, if you want to avoid the (view_convert (negate @1)), just add (if !TYPE_OVERFLOW_SANITIZED (type)) above the (view_convert (negate @1)). But in each case, you want to be careful which exact type you want to check, type is the type of the outermost expression, otherwise TREE_TYPE (@0) etc.
