[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 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/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 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 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 --- Comment #3 from Andrew Pinski --- *** This bug has been marked as a duplicate of bug 89950 ***
[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 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 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/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 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 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 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 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 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 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 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 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 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 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 Andrew Pinski changed: What|Removed |Added Severity|blocker |normal
[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/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 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 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 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 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 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 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 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 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=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 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(, ))
__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 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 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++/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 tree-optimization/112493] [11/12/13/14 Regression] ICE in verify_sra_access_forest with scalar_storage_order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112493 Andrew Pinski changed: What|Removed |Added Keywords|needs-bisection | --- Comment #3 from Andrew Pinski --- gcc_assert (reverse == access->reverse); Oh the verification was added with r10-6320-g5b9e89c922dc2e . So there is no reason to do a bisect either. Lucky this is with checking enabled so most folks are not running into this.
