[Bug c++/118047] [12/13/14/15 Regression] Incorrect list initialization of vector of struct of array of struct of enum since r12-7803-gf0530882d99abc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118047 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102990 --- Comment #8 from Andrew Pinski --- (In reply to Sam James from comment #7) > (In reply to Sam James from comment #6) > > r12-7803-gf0530882d99abc > > .. but that patch got backported to 11? Maybe some other patch which didn't get backported is interacting here.
[Bug c++/102990] [9/10 Regression] ICE in tsubst_copy_and_build with NSDMI and double to int conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102990 Andrew Pinski changed: What|Removed |Added Target Milestone|9.5 |11.3
[Bug c++/118047] [12/13/14/15 Regression] Incorrect list initialization of vector of struct of array of struct of enum since r12-7803-gf0530882d99abc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118047 --- Comment #9 from Andrew Pinski --- (In reply to Andrew Pinski from comment #8) > (In reply to Sam James from comment #7) > > (In reply to Sam James from comment #6) > > > r12-7803-gf0530882d99abc > > > > .. but that patch got backported to 11? > > Maybe some other patch which didn't get backported is interacting here. Like r12-6028-ga37e8ce3b66325 (which might explain the difference between C++14 and C++11) .
[Bug tree-optimization/118046] [15 Regression] wrong code at -O{2, 3} on x86_64-linux-gnu since r15-6173-ge8febb641415fd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118046
Sam James changed:
What|Removed |Added
Summary|[15 Regression] wrong code |[15 Regression] wrong code
|at -O{2,3} on |at -O{2,3} on
|x86_64-linux-gnu|x86_64-linux-gnu since
||r15-6173-ge8febb641415fd
--- Comment #4 from Sam James ---
indeed r15-6173-ge8febb641415fd
[Bug target/118008] [14/15 regression] ICE when bootstrapping with Go on arm (gen_movdi, at config/arm/arm.md:6296)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118008 --- Comment #10 from Ian Lance Taylor --- I was not able to recreate the compiler crash using a cross-compiler to arm-eabi, using either GCC tip or GCC 14 branch. Are you building on an arm-linux system? Are there any such systems left in the GCC compile farm?
[Bug c++/118047] [12/13/14/15 Regression] Incorrect list initialization of vector of struct of array of struct of enum since r12-7803-gf0530882d99abc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118047
--- Comment #10 from Benjamin Miller ---
In case you're interested, here's the failing part of the Qt sources:
```
std::vector extContexts { { /* 0 - Always available */ } };
```
https://github.com/qt/qtquick3d/blob/6.8.0/src/runtimerender/rendererimpl/qssglayerrenderdata_p.h#L413
In this case, a recently added assertion came in with the compiler and caught
this but I think if I had only updated the compiler this would have resulted in
undefined behavior following this pattern:
std::vector somethings { { /* 0 - Always available */ } };
// ... later
somethings[0].readOrWrite(); // Undefined behavior
Could this be exploitable? It seems like it could be if an attacker could
manipulate the memory at the end of the vector but that would depend on the
implementation in libstdc++.
[Bug middle-end/118024] ICE when building openssh-9.9_p1 with -fstrub=all (internal compiler error: tree check: expected tree_list, have identifier_node in matching_alloc_calls_p, at gimple-ssa-warn-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118024
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9537ca5ad9bc23d7e9c446b4a7cbb98f63bddb6a
commit r15-6253-g9537ca5ad9bc23d7e9c446b4a7cbb98f63bddb6a
Author: Jakub Jelinek
Date: Sat Dec 14 11:27:20 2024 +0100
warn-access: Fix up matching_alloc_calls_p [PR118024]
The following testcase ICEs because of a bug in matching_alloc_calls_p.
The loop was apparently meant to be walking the two attribute chains
in lock-step, but doesn't really do that. If the first lookup_attribute
returns non-NULL, the second one is not done, so rmats in that case can
be some random unrelated attribute rather than "malloc" attribute; the
body assumes even rmats if non-NULL is "malloc" attribute and relies
on its argument to be a "malloc" argument and if it is some other
attribute with incompatible attribute, it just crashes.
Now, fixing that in the obvious way, instead of doing
(amats = lookup_attribute ("malloc", amats))
|| (rmats = lookup_attribute ("malloc", rmats))
in the condition do
((amats = lookup_attribute ("malloc", amats)),
(rmats = lookup_attribute ("malloc", rmats)),
(amats || rmats))
fixes the testcase but regresses Wmismatched-dealloc-{2,3}.c tests.
The problem is that walking the attribute lists in a lock-step is obviously
a very bad idea, there is no requirement that the same deallocators are
present in the same order on both decls, e.g. there could be an extra
malloc
attribute without argument in just one of the lists, or the order of say
free/realloc could be swapped, etc. We don't generally document nor
enforce
any particular ordering of attributes (even when for some attributes we
just
handle the first one rather than all).
So, this patch instead simply splits it into two loops, the first one walks
alloc_decl attributes, the second one walks dealloc_decl attributes.
If the malloc attribute argument is a built-in, that doesn't change
anything, and otherwise we have the chance to populate the whole
common_deallocs hash_set in the first loop and then can check it in the
second one (and don't need to use more expensive add method on it, can just
check contains there). Not to mention that it also fixes the case when
the function would incorrectly return true if there wasn't a common
deallocator between the two, but dealloc_decl had 2 malloc attributes with
the same deallocator.
2024-12-14 Jakub Jelinek
PR middle-end/118024
* gimple-ssa-warn-access.cc (matching_alloc_calls_p): Walk malloc
attributes of alloc_decl and dealloc_decl in separate loops rather
than in lock-step. Use common_deallocs.contains rather than
common_deallocs.add in the second loop.
* gcc.dg/pr118024.c: New test.
[Bug middle-end/118011] -fshort-enums reported as enabled by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118011 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:18f0b7d5f370c47633837e935f8a6e1b8616b56b commit r15-6252-g18f0b7d5f370c47633837e935f8a6e1b8616b56b Author: Jakub Jelinek Date: Sat Dec 14 11:25:08 2024 +0100 opts: Use OPTION_SET_P instead of magic value 2 for -fshort-enums default [PR118011] The magic values for default (usually -1 or sometimes 2) for some options are from times we haven't global_options_set, I think we should eventually get rid of all of those. The PR is about gcc -Q --help=optimizers reporting -fshort-enums as [enabled] when it is disabled. For this the following patch is just partial fix; with explicit gcc -Q --help=optimizers -fshort-enums or gcc -Q --help=optimizers -fno-short-enums it already worked correctly before, with this patch it will report even with just gcc -Q --help=optimizers correct value on most targets, except 32-bit arm with some options or defaults, so I think it is a step in the right direction. But, as I wrote in the PR, process_options isn't done before --help= and even shouldn't be in its current form where it warns on some option combinations or errors or emits sorry on others, so I think ideally process_options should have some bool argument whether it is done for --help= purposes or not, if yes, not emit warnings and just adjust the options, otherwise do what it currently does. 2024-12-14 Jakub Jelinek PR c/118011 gcc/ * opts.cc (init_options_struct): Don't set opts->x_flag_short_enums to 2. * toplev.cc (process_options): Test !OPTION_SET_P (flag_short_enums) rather than flag_short_enums == 2. gcc/ada/ * gcc-interface/misc.cc (gnat_post_options): Test !OPTION_SET_P (flag_short_enums) rather than flag_short_enums == 2.
[Bug other/118041] install.texi typos in --enable-host-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118041 --- Comment #1 from Jonathan Wakely --- Thanks, I'll apply this patch, but for next time please just send the patch to gcc-patc...@gcc.gnu.org - there's no need to open a bug if you already have a patch.
[Bug other/118041] install.texi typos in --enable-host-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118041 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- Fixed now, thanks. The online docs will regenerate overnight.
[Bug other/118041] install.texi typos in --enable-host-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118041 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |15.0
[Bug rtl-optimization/118042] New: ICE: maximum number of generated reload insns per insn achieved (90) with -O1 -fexpensive-optimizations -favoid-store-forwarding -mavx10.1 -mprefer-vector-width=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118042 Bug ID: 118042 Summary: ICE: maximum number of generated reload insns per insn achieved (90) with -O1 -fexpensive-optimizations -favoid-store-forwarding -mavx10.1 -mprefer-vector-width=128 --param=store-forwarding-max-distance=256 Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 59867 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59867&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O1 -fexpensive-optimizations -favoid-store-forwarding -mavx10.1 -mprefer-vector-width=128 --param=store-forwarding-max-distance=256 testcase.c testcase.c: In function 'foo': testcase.c:6:5: warning: division by zero [-Wdiv-by-zero] 6 | v %= 0; | ^~ during RTL pass: reload testcase.c:7:1: internal compiler error: maximum number of generated reload insns per insn achieved (90) 7 | } | ^ 0x2e0e771 internal_error(char const*, ...) /repo/gcc-trunk/gcc/diagnostic-global-context.cc:517 0x14653a0 lra_constraints(bool) /repo/gcc-trunk/gcc/lra-constraints.cc:5411 0x144c424 lra(_IO_FILE*, int) /repo/gcc-trunk/gcc/lra.cc:2449 0x13f5eef do_reload /repo/gcc-trunk/gcc/ira.cc:5977 0x13f5eef execute /repo/gcc-trunk/gcc/ira.cc:6165 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-20241214122823-r15-6251-ga6a15bc5b77c87-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-20241214122823-r15-6251-ga6a15bc5b77c87-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.0 20241214 (experimental) (GCC)
[Bug modula2/117120] case ch with a nul char constant causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117120 --- Comment #4 from GCC Commits --- The releases/gcc-14 branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:cfe21668f3a7a0f07fa1e79ef2561a107a09a67d commit r14-11089-gcfe21668f3a7a0f07fa1e79ef2561a107a09a67d Author: Gaius Mulley Date: Sat Dec 14 11:46:57 2024 + [PATCH] PR modula2/117120: case ch with a nul char constant causes ICE This patch fixes the ICE caused when a case clause contains a character constant ''. The fix was to walk the caselist and convert any 0 length string into a char constant of value 0. gcc/m2/ChangeLog: PR modula2/117120 * gm2-compiler/M2CaseList.mod (CaseBoundsResolved): Rewrite. (ConvertNulStr2NulChar): New procedure function. (NulStr2NulChar): Ditto. (GetCaseExpression): Ditto. (OverlappingCaseBound): Rewrite. * gm2-compiler/M2GCCDeclare.mod (CheckResolveSubrange): Allow '' to be used as the subrange low limit. * gm2-compiler/M2GenGCC.mod (FoldConvert): Rewrite. (PopKindTree): Ditto. (BuildHighFromString): Reformat. * gm2-compiler/SymbolTable.mod (PushConstString): Add test for length 0 and PushChar (nul). gcc/testsuite/ChangeLog: PR modula2/117120 * gm2/pim/pass/forloopnulchar.mod: New test. * gm2/pim/pass/nulcharcase.mod: New test. * gm2/pim/pass/nulcharvar.mod: New test. (cherry picked from commit e0ab8816ea53e2a343f7e945f4718172bff5ce95) Signed-off-by: Gaius Mulley
[Bug c/118043] New: -Wattributes: [[gnu::access(wo, n)]]: False positive with VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118043
Bug ID: 118043
Summary: -Wattributes: [[gnu::access(wo, n)]]: False positive
with VLA
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: alx at kernel dot org
Target Milestone: ---
alx@devuan:~/tmp/gcc$ cat f.c
[[gnu::access(write_only, 2)]]
int f(int n, int a[n])
{
a[0] = 42;
return 0;
}
alx@devuan:~/tmp/gcc$ cc -Wall -Wextra -S f.c
f.c: In function ‘f’:
f.c:2:5: warning: attribute ‘access (write_only, 2)’ positional argument 2
missing in previous designation [-Wattributes]
2 | int f(int n, int a[n])
| ^
f.c:2:11: note: designating the bound of variable length array argument 2
2 | int f(int n, int a[n])
| ^
[Bug tree-optimization/118025] gcc.dg/field-merge-9.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118025 John David Anglin changed: What|Removed |Added Ever confirmed|0 |1 CC||danglin at gcc dot gnu.org Status|UNCONFIRMED |NEW Target|sparc*-sun-solaris2.11, |sparc*-sun-solaris2.11, |powerpc64-unknown-linux-gnu |powerpc64-unknown-linux-gnu |, pru-unknown-elf, |, pru-unknown-elf, |s390x-ibm-linux-gnu |s390x-ibm-linux-gnu ||hppa-unknown-linux-gnu Last reconfirmed||2024-12-14
[Bug c/118044] New: -Wvla-parameter: False positive with [[gnu::access(wo, n)]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118044 Bug ID: 118044 Summary: -Wvla-parameter: False positive with [[gnu::access(wo, n)]] Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: alx at kernel dot org Target Milestone: --- alx@devuan:~/tmp/gcc$ cat f.c [[gnu::access(write_only, 2)]] int f(int n, int a[n]); int f(int n, int a[n]); alx@devuan:~/tmp/gcc$ cc -Wall -Wno-attributes -S f.c f.c:3:18: warning: argument 2 of type ‘int[n]’ declared as a variable length array [-Wvla-parameter] 3 | int f(int n, int a[n]); | ^~~~ f.c:2:18: note: previously declared as an ordinary array ‘int[]’ 2 | int f(int n, int a[n]); | ^~~~
[Bug other/118041] New: install.texi typos in --enable-host-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118041 Bug ID: 118041 Summary: install.texi typos in --enable-host-pie Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: heiko at hexco dot de Target Milestone: --- Created attachment 59866 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59866&action=edit Patch to fix two typos in --enable-host-pie There are some extra parentheses here '--enable-host-pie) may be used with --enable-host-shared), in which case -fPIC is used when compiling, and -pie when linking.' should be '--enable-host-pie may be used with --enable-host-shared, in which case -fPIC is used when compiling, and -pie when linking.' A patch is appended.
[Bug tree-optimization/118023] [15 Regression] ICE: verify_gimple failed: 'bit_field_ref' of non-mode-precision operand at -O1 and above when reinterpreting _BitInt() as _Complex since r15-6173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118023 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug middle-end/118024] ICE when building openssh-9.9_p1 with -fstrub=all (internal compiler error: tree check: expected tree_list, have identifier_node in matching_alloc_calls_p, at gimple-ssa-warn-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118024 --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/118023] [15 Regression] ICE: verify_gimple failed: 'bit_field_ref' of non-mode-precision operand at -O1 and above when reinterpreting _BitInt() as _Complex since r15-6173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118023
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7f4e85a954d24cc30bf85f4040fcd204bd5e23fd
commit r15-6254-g7f4e85a954d24cc30bf85f4040fcd204bd5e23fd
Author: Jakub Jelinek
Date: Sat Dec 14 11:28:25 2024 +0100
gimple-fold: Fix the recent ifcombine optimization for _BitInt [PR118023]
The BIT_FIELD_REF verifier has:
if (INTEGRAL_TYPE_P (TREE_TYPE (op))
&& !type_has_mode_precision_p (TREE_TYPE (op)))
{
error ("%qs of non-mode-precision operand", code_name);
return true;
}
check among other things, so one can't extract something out of say
_BitInt(63) or _BitInt(4096).
The new ifcombine optimization happily creates such BIT_FIELD_REFs
and ICEs during their verification.
The following patch fixes that by rejecting those in
decode_field_reference.
2024-12-14 Jakub Jelinek
PR tree-optimization/118023
* gimple-fold.cc (decode_field_reference): Return NULL_TREE if
inner has non-type_has_mode_precision_p integral type.
* gcc.dg/bitint-119.c: New test.
[Bug c++/116807] About c++ 20 module,chrono header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116807 Nathaniel Shead changed: What|Removed |Added CC||nshead at gcc dot gnu.org --- Comment #6 from Nathaniel Shead --- This works correctly on trunk, I haven't tried bisecting to find where it started working.
[Bug c++/103827] function which takes an argument via (hidden) reference should assume the argument does not escape or is only read from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103827 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-12-14 --- Comment #18 from Jan Hubicka --- Patch for the constructors is posted at https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671599.html We still ought to improve ipa-prop to propagate pointer differences next stage1
[Bug libstdc++/80331] unused const std::string not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331 --- Comment #15 from Jan Hubicka --- Original testcase is solved by https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671599.html We still won't optimize longer strings because _M_create is not inline.
[Bug libstdc++/87502] Poor code generation for std::string("c-style string")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502 --- Comment #16 from Jan Hubicka --- https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671599.html optimizes the string constructors. Having strlen pass catching more cases would be nice, too.
[Bug libstdc++/80331] unused const std::string not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331 Jan Hubicka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=94960 --- Comment #16 from Jan Hubicka --- Original testcase is solved by https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671599.html We still won't optimize longer strings because _M_create is not inline.
[Bug libstdc++/94960] extern template prevents inlining of standard library objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94960 --- Comment #17 from Sam James --- (In reply to Jan Hubicka from comment #15) > > Oh, sorry, that was linked earlier. But still, isn't the problem that > > "inline" > > is too strong? > Do we have some data on this? I at least don't have any. I could do comparisons with a large package list before/after although I don't have that scripted yet (nobody's asked before). But the user from dupe PR117550 seemed to say it had impacted their application badly...
[Bug tree-optimization/117924] unused std::vector are not optimized out fully at gimple level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117924 Jan Hubicka changed: What|Removed |Added Last reconfirmed||2024-12-14 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #4 from Jan Hubicka --- patch posted here https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671137.html
[Bug c/26154] [12/13/14/15 Regression] OpenMP extensions to the C language is not documented or doumented in the wrong spot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26154 sandra at gcc dot gnu.org changed: What|Removed |Added CC||tschwinge at gcc dot gnu.org --- Comment #37 from sandra at gcc dot gnu.org --- I've been looking at this issue again. It's one of our oldest open documentation issues. My proposed solution is: * In invoke.texi, move all the OpenMP and OpenACC option documentation (including -foffload, etc) out of "C Dialect Options" to a new section "OpenMP and OpenACC options". * In extend.texi, add a brief new section for OpenMP and OpenACC that just says GCC supports these things and points to the above new section and the libgomp manual. * Also in extend.texi, add a note to the pragma section that GCC supports OpenMP and OpenACC pragmas with the appropriate options, again with pointers; and similarly for OpenMP attribute-syntax directives. The libgomp manual has a table of the implementation status of various OpenMP features, but for OpenACC it points at the GCC wiki where I guess you have to comb through the release notes for multiple GCC versions to find out whether something is supported or not. :-S It would be good to fix that too, but maybe as a separate issue. Also the gfortran manual also probably needs updating (haven't looked at it yet). Comments?
[Bug libbacktrace/117812] zstd dependency 1.5.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117812
--- Comment #3 from jeffrey.cliff at gmail dot com ---
> replace ZSTD_CLEVEL_DEFAULT with 3
check
diff --git a/libbacktrace/zstdtest.c b/libbacktrace/zstdtest.c
index b9552ab1b88..0835ce5398d 100644
--- a/libbacktrace/zstdtest.c
+++ b/libbacktrace/zstdtest.c
@@ -380,7 +380,7 @@ test_large (struct backtrace_state *state ATTRIBUTE_UNUSED)
r = ZSTD_compress (compressed_buf, compressed_bufsize,
orig_buf, orig_bufsize,
-ZSTD_CLEVEL_DEFAULT);
+3);
if (ZSTD_isError (r))
{
fprintf (stderr, "zstd compress failed: %s\n", ZSTD_getErrorName (r));
result:
zstdtest.log:PASS: zstd large
[Bug fortran/117897] [13/14/15 Regression] Bug in gfortran compiled windows run time with the latest release (14.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117897 --- Comment #4 from Paul Thomas --- Created attachment 59868 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59868&action=edit Fix for this PR It needs tidying up and the testcase dejagnu-ifying but it does regtest OK. I didn't realise that class pointer assignment with pointer function targets went through the ordinary assignment route! It'll be ready for submission tomorrow. Paul
[Bug c++/118033] [Missing optimization] Keep __builtin_unreachable for asserts in the release build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118033 Xi Ruoyao changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||xry111 at gcc dot gnu.org Resolution|--- |INVALID --- Comment #5 from Xi Ruoyao --- Invalid per comment 2. You can define your own assert macro and use it if the standard one is not suitable, anyway. AFAIK many projects don't use the standard assert macro.
[Bug target/118039] New: [15 Regression] s390x/-m31: libsanitizer: interception_type_test.cpp: static assertion failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118039 Bug ID: 118039 Summary: [15 Regression] s390x/-m31: libsanitizer: interception_type_test.cpp: static assertion failed Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- seen with trunk 20241213 on s390x-linux-gnu, building the libsanitizer m31 multilibs: libtool: compile: /<>/build/./gcc/xgcc -shared-libgcc -B/<>/build/./gcc -nostdinc++ -L/<>/build/s390x-linux-gnu/32/libstdc++-v3/src -L/<>/build/s390x-linux-gnu/32/libstdc++-v3/src/.li bs -L/<>/build/s390x-linux-gnu/32/libstdc++-v3/libsupc++/.libs -B/usr/lib/gcc-snapshot/s390x-linux-gnu/bi n/ -B/usr/lib/gcc-snapshot/s390x-linux-gnu/lib/../lib32 -B/usr/lib/gcc-snapshot/s390x-linux-gnu/lib/ -isystem /usr/lib /gcc-snapshot/s390x-linux-gnu/include -isystem /usr/lib/gcc-snapshot/s390x-linux-gnu/sys-include -m31 -D_GNU_SOURCE -D _DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. -I../../../../../src/libsanitizer/int erception -I.. -I ../../../../../src/libsanitizer/include -I ../../../../../src/libsanitizer -Wall -W -Wno-unused-para meter -Wwrite-strings -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include -I../../libstdc++-v3/include/s390x-linux-gnu -I ../../../../../src/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++17 -g -O2 -D_GNU_SOURCE -m31 -MT interception_type _test.lo -MD -MP -MF .deps/interception_type_test.Tpo -c ../../../../../src/libsanitizer/interception/interception_typ e_test.cpp -fPIC -DPIC -o .libs/interception_type_test.o In file included from ../../../../../src/libsanitizer/interception/interception.h:18, from ../../../../../src/libsanitizer/interception/interception_type_test.cpp:14: ../../../../../src/libsanitizer/interception/interception_type_test.cpp:30:61: error: static assertion failed 30 | COMPILER_CHECK((__sanitizer::is_same<::SSIZE_T, ::ssize_t>::value)); |~^~ ../../../../../src/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:363:44: note: in definition of macro 'COMPI LER_CHECK' 363 | #define COMPILER_CHECK(pred) static_assert(pred, "") |^~~~ make[10]: *** [Makefile:469: interception_type_test.lo] Error 1 make[10]: Leaving directory '/<>/build/s390x-linux-gnu/32/libsanitizer/interception' make[9]: *** [Makefile:533: all-recursive] Error 1 make[9]: Leaving directory '/<>/build/s390x-linux-gnu/32/libsanitizer' make[8]: *** [Makefile:420: all] Error 2 make[8]: Leaving directory '/<>/build/s390x-linux-gnu/32/libsanitizer' make[7]: *** [Makefile:799: multi-do] Error 1
[Bug sanitizer/118040] New: GCC's Address Sanitizer misses 'global-buffer-overflow',while clang can detect it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118040
Bug ID: 118040
Summary: GCC's Address Sanitizer misses
'global-buffer-overflow',while clang can detect it
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: 652023330028 at smail dot nju.edu.cn
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
For the following code (https://godbolt.org/z/5qaWasqcn), GCC's ASan seems to
have missed 'global-buffer-overflow' (line 5 of function 'f'):
#include
static int a1 = 1;
static int *a2 = &a1;
static unsigned short b1 = 0;
static long b2 = 0;
static unsigned short b3 = 0;
static int c = 0;
static char d = 0;
int Arr[10];
static void f(int *p1, int *p2) {
int *t = &c;
*p1 = 4 ^ (*t = 0 < 10) + 0 && 0;
c=Arr[(*t - 32)-1]; //global-buffer-overflow
}
int main() {
f(a2, a2);
printf("%d",b1);
printf("%ld",b2);
printf("%d",b3);
printf("%c",d);
}
There is no report from GCC's AddressSanitizer.
Expected (clang):
==1==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55b76d461da0
at pc 0x55b76cad0f7b bp 0x7ffc9fa1c850 sp 0x7ffc9fa1c848
READ of size 4 at 0x55b76d461da0 thread T0
#0 0x55b76cad0f7a in f /app/example.c:15:4
#1 0x55b76cad0de6 in main /app/example.c:19:5
#2 0x7324f9829d8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId:
490fef8403240c91833978d494d39e537409b92e)
#3 0x7324f9829e3f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x29e3f) (BuildId:
490fef8403240c91833978d494d39e537409b92e)
#4 0x55b76c9ec354 in _start (/app/output.s+0x2c354)
0x55b76d461da0 is located 32 bytes before global variable 'b2' defined in
'/app/example.c:5' (0x55b76d461dc0) of size 8
0x55b76d461da2 is located 0 bytes after global variable 'b1' defined in
'/app/example.c:4' (0x55b76d461da0) of size 2
SUMMARY: AddressSanitizer: global-buffer-overflow /app/example.c:15:4 in f
[Bug target/118039] [15 Regression] s390x/-m31: libsanitizer: interception_type_test.cpp: static assertion failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118039 Sam James changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Sam James --- Dupe *** This bug has been marked as a duplicate of bug 117725 ***
[Bug sanitizer/117725] [15 Regression] s390 -m31 bootstrap failure in interception.h since r15-5164-gfa321004f3f628
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117725 --- Comment #4 from Sam James --- *** Bug 118039 has been marked as a duplicate of this bug. ***
[Bug sanitizer/118040] GCC's Address Sanitizer misses 'global-buffer-overflow',while clang can detect it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118040 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105405
[Bug sanitizer/118040] GCC's Address Sanitizer misses 'global-buffer-overflow',while clang can detect it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118040 --- Comment #2 from Andrew Pinski --- It is about where Arr is placed.
[Bug fortran/117897] [13/14/15 Regression] Bug in gfortran compiled windows run time with the latest release (14.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117897 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- After 7 bisections, I found that I was the culprit with my finalization patch: PR fortran/103854 PR fortran/96122 PR fortran/37336 commit r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee Author: Paul Thomas Date: Sat Mar 18 07:56:23 2023 + The bug has been dormant for 22 months then... or it hasn't been reported. Taking the diff between working and broken versions of the original tree dump shows: 1324c1324 < __result_get_pt_materiau_nom = cds_pt_materiau (&vector_element.52); --- > cds_pt_materiau (&vector_element.52)._vptr->_copy > (&cds_pt_materiau (&vector_element.52), &__result_get_pt_materiau_nom); The use of the vptr copy for the function result is the problem. This is clearly not a good idea for a pointer function result since it attempts to effect a deep copy. Taking the PR. Paul
[Bug sanitizer/118040] GCC's Address Sanitizer misses 'global-buffer-overflow',while clang can detect it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118040 Andrew Pinski changed: What|Removed |Added Resolution|WONTFIX |DUPLICATE --- Comment #3 from Andrew Pinski --- Similar as PR 117959. *** This bug has been marked as a duplicate of bug 117959 ***
[Bug sanitizer/117959] Address Sanitizer misses 'global-buffer-overflow' for a[-1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117959 --- Comment #5 from Andrew Pinski --- *** Bug 118040 has been marked as a duplicate of this bug. ***
[Bug sanitizer/118040] GCC's Address Sanitizer misses 'global-buffer-overflow',while clang can detect it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118040 --- Comment #4 from Andrew Pinski --- Just happens the order of variables layout is different between GCC and clang. Note I will note clang has 2 different layouts too, one for C and one for C++.
[Bug fortran/102689] Segfault with RESHAPE of CLASS as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102689 --- Comment #10 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #9) --- snip --- > > The mention of binutils jogged my memory. I had a test failure that showed > up randomly one time. It was related to class_transformational_2.f90. It > manifested as a segfault in ld. I will see if I can find it in the system > logs. No luck in search.
[Bug rtl-optimization/118042] ICE: maximum number of generated reload insns per insn achieved (90) with -O1 -fexpensive-optimizations -favoid-store-forwarding -mavx10.1 -mprefer-vector-width=128 --par
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118042
--- Comment #1 from Andrew Pinski ---
(insn 228 230 227 2 (set (reg:TI 345)
(subreg:TI (reg:HI 389) 0)) "/app/example.cpp":6:5 94 {*movti_internal}
(expr_list:REG_DEAD (reg:HI 389)
(nil)))
[Bug c/118043] -Wattributes: [[gnu::access(wo, n)]]: False positive with VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118043 --- Comment #3 from Alejandro Colomar --- (In reply to Andrew Pinski from comment #1) > /* The two specs designate different size arguments. It's okay > for the explicit spec to specify a size where none is provided > by the implicit (VLA) one, as in: Thanks for clarifying where the warning comes from. >__attribute__ ((access (read_write, 1, 2))) >void f (int*, int); > but not for two explicit access attributes to do that. */ Where's this quote from? I don't find that in the manual. > > Looks like this is by design, you still need to supply the size argument to > write_only. Note this is not documented though. Hmmm, considering that the compiler diagnoses when the sizes from the VLA and the attribute do not match, I don't mind too much repeating myself. I guess it's okay. Thanks!
[Bug target/118017] [15 Regression] ICE: maximum number of generated reload insns per insn achieved (90) with -Og -frounding-math -mno-80387 -mno-mmx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118017
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=118042,
||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=117946
--- Comment #2 from Andrew Pinski ---
(insn 33 32 36 2 (set (subreg:TI (reg:TD 99 [ _2 ]) 0)
(reg:TI 20 xmm0)) "/app/example.cpp":14:24 94 {*movti_internal}
(expr_list:REG_DEAD (reg:TI 20 xmm0)
(nil)))
[Bug middle-end/114087] RISC-V optimization on checking certain bits set ((x & mask) == val)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114087 --- Comment #4 from Jeffrey A. Law --- So just a couple notes. The more Oliver and I discuss this BZ, the more I suspect the right place to tackle these problems is either in the match.pd framework or at the gimple->rtl expansion phase. I think writing the match.pd pattern is actually quite simple, but assessing profitability would likely be hard since profitability is closely tied with the ability to reduce the cost of constant synthesis and that's going to be highly target dependent. Additionally, the cases where we typically try to reduce constants to improve code generation is done by bringing constants closer to zero, but in this case we need to do something quite different. If one was to try and tackle solely in the target files one might start with Oliver's pattern as a bridge pattern, then add a pattern to combine the bridge pattern with the equality test which in turn allows removal of an instruction.
[Bug middle-end/114087] RISC-V optimization on checking certain bits set ((x & mask) == val)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114087 --- Comment #5 from Andrew Pinski --- >From https://gcc.gnu.org/wiki/GimpleCanonical: (a | CST0) == CST1 or (a & CST2) == CST3 (where CST2 == ~CST0 and CST3 == CST1&~CST0 (PR 86975, related to PR 08) (LLVM chooses the &)
[Bug tree-optimization/118032] Bootstrap slowdown for risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032 --- Comment #1 from Jeffrey A. Law --- No, I'm not seeing this in my BPI bootstraps. My bootstrap + regression test is sitting at 26-27hrs. It's been in that range since I turned bootstrapping on back in mid Oct.
[Bug tree-optimization/118046] New: wrong code at -O{2,3} on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118046
Bug ID: 118046
Summary: wrong code at -O{2,3} on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
This appears to be a recent regression as it doesn't reproduce with 14.2 and
earlier.
Compiler Explorer: https://godbolt.org/z/3KP9f4n38
[610] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241214 (experimental) (GCC)
[611] %
[611] % gcctk -O1 small.c; ./a.out
[612] %
[612] % gcctk -O2 small.c
[613] % ./a.out
Aborted
[614] %
[614] % cat small.c
volatile int c;
int d, e = 1, *f, g, **h = &f, *i = &d, *a = &g, *b = &d;
char j;
int k(int l, int m) { return l < 0 || (m < 0) >= l ? l : l << m; }
int main() {
*b = 255;
*h = a;
j = *i;
*f = e && k(j, 1) & (c, 1);
if (g != 1)
__builtin_abort();
return 0;
}
[Bug libbacktrace/117812] zstd dependency 1.5.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117812 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Ian Lance Taylor --- Thanks, patch committed.
[Bug libbacktrace/117812] zstd dependency 1.5.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117812 --- Comment #4 from GCC Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:3e343ef7f0ac0eb9e526b4f6d3bf3f69be3f0684 commit r15-6258-g3e343ef7f0ac0eb9e526b4f6d3bf3f69be3f0684 Author: Ian Lance Taylor Date: Sat Dec 14 14:32:11 2024 -0800 libbacktrace: don't use ZSTD_CLEVEL_DEFAULT PR 117812 reports that testing GCC with zstd 1.3.4 fails because ZSTD_CLEVEL_DEFAULT is not defined, so avoid using it. PR libbacktrace/117812 * zstdtest.c (test_large): Use 3 rather than ZSTD_CLEVEL_DEFAULT
[Bug tree-optimization/118046] [15 Regression] wrong code at -O{2, 3} on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118046
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-12-14
Target Milestone|--- |15.0
Summary|wrong code at -O{2,3} on|[15 Regression] wrong code
|x86_64-linux-gnu|at -O{2,3} on
||x86_64-linux-gnu
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
>From ifcombine:
optimizing two comparisons to _22 == 2147483649
Merging blocks 3 and 4
[Bug tree-optimization/118046] [15 Regression] wrong code at -O{2, 3} on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118046 --- Comment #2 from Andrew Pinski --- From: ``` // char _6; // int _5; _5 = *i.3_4; _6 = (char) _5; ... _8 = (int) _6; if (_8 >= 0) // sign bit is not set goto ; [59.00%] else goto ; [41.00%] [local count: 220117072]: _19 = _6 & 1; if (_19 != 0) goto ; [85.98%] else goto ; [14.02%] [local count: 884494828]: [local count: 1073741824]: # iftmp.4_11 = PHI <1(4), 0(5)> ``` To ``` _8 = (int) _6; _19 = _6 & 1; _22 = _21 & 2147483649; if (_22 == 2147483649) goto ; [35.25%] else goto ; [64.75%] [local count: 884494828]: [local count: 1073741824]: # iftmp.4_11 = PHI <1(3), 0(4)> ``` Ifcombine ignored the original truncation for the sign bit comparison ...
[Bug tree-optimization/118046] [15 Regression] wrong code at -O{2, 3} on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118046
--- Comment #3 from Andrew Pinski ---
Reduced down to just:
```
__attribute__((noipa))
int f(int *a,int *d)
{
signed char b = *a;
int c = b;
*d = c; // This store is important even if otherwise unused
if (c < 0 && (b&1))
return 1;
return 0;
}
int main()
{
unsigned char t = 0x81;
int x = t, y;
int tt = f(&x, &y);
if (!tt)
__builtin_abort();
}
```
[Bug driver/118048] `-h`support does not work everywhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118048 Andrew Pinski changed: What|Removed |Added Known to fail||13.1.0 --- Comment #1 from Andrew Pinski --- The error message started in GCC 13.
[Bug driver/118048] `-h`support does not work everywhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118048 --- Comment #2 from Andrew Pinski --- So I think r13-4467-g6d3c634c8baebd changed the behavior to be correct in erroring out. Which means I think most LINK_SPECs were incorrect before and was not noticed either. Note aarch64 linux most likely copied from arm linux which is why it worked that. I have not looked into the history of why h was included in the other locations either.
[Bug c/118043] -Wattributes: [[gnu::access(wo, n)]]: False positive with VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118043 Andrew Pinski changed: What|Removed |Added Keywords|diagnostic |documentation --- Comment #1 from Andrew Pinski --- /* The two specs designate different size arguments. It's okay for the explicit spec to specify a size where none is provided by the implicit (VLA) one, as in: __attribute__ ((access (read_write, 1, 2))) void f (int*, int); but not for two explicit access attributes to do that. */ Looks like this is by design, you still need to supply the size argument to write_only. Note this is not documented though.
[Bug c/118043] -Wattributes: [[gnu::access(wo, n)]]: False positive with VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118043 --- Comment #2 from Andrew Pinski --- *** Bug 118044 has been marked as a duplicate of this bug. ***
[Bug c/118044] -Wvla-parameter: False positive with [[gnu::access(wo, n)]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118044 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Same issue as PR 118043. `gnu::access(write_only, 2)` will change the VLA for argument into an non-VLA. So you are getting a mismatch there because of it. *** This bug has been marked as a duplicate of bug 118043 ***
[Bug c/118044] -Wvla-parameter: False positive with [[gnu::access(wo, n)]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118044 --- Comment #2 from Alejandro Colomar --- Hmmm, interesting. Thanks!
[Bug c/118043] -Wattributes: [[gnu::access(wo, n)]]: False positive with VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118043 --- Comment #4 from Andrew Pinski --- (In reply to Alejandro Colomar from comment #3) > (In reply to Andrew Pinski from comment #1) > > /* The two specs designate different size arguments. It's okay > > for the explicit spec to specify a size where none is provided > > by the implicit (VLA) one, as in: > > Thanks for clarifying where the warning comes from. > > >__attribute__ ((access (read_write, 1, 2))) > >void f (int*, int); > > but not for two explicit access attributes to do that. */ > > Where's this quote from? I don't find that in the manual. It comes from the source around the spot where the warning is located. This is why I said there is a missing documentation.
[Bug target/118008] [14/15 regression] ICE when bootstrapping with Go on arm (gen_movdi, at config/arm/arm.md:6296)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118008 Andrew Pinski changed: What|Removed |Added Keywords||ice-checking --- Comment #9 from Andrew Pinski --- gcc_checking_assert (aligned_operand (operands[0], DImode)); gcc_checking_assert (aligned_operand (operands[1], DImode));
[Bug modula2/118045] New: [15 Regression] libm2iso.so.20.0.0 contains an unresolvable reference to symbol casin (and 171 other similar warnings)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118045 Bug ID: 118045 Summary: [15 Regression] libm2iso.so.20.0.0 contains an unresolvable reference to symbol casin (and 171 other similar warnings) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- trunk 20241214 produced an underlinked libm2iso.so on x86_64-linux-gnu, the Debian/Ubuntu packaging complaining about dpkg-shlibdeps: warning: debian/gcc-snapshot/usr/lib/gcc-snapshot/lib/libm2iso.so.20.0.0 contains an unresolvable reference to symbol casin: it's probably a plugin dpkg-shlibdeps: warning: 171 other similar warnings have been skipped (use -v to see them all) looks like a missing -lm.
[Bug fortran/104819] Reject NULL without MOLD as actual to an assumed-rank dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104819 --- Comment #18 from anlauf at gcc dot gnu.org --- Patch for the case of derived type dummies: https://gcc.gnu.org/pipermail/fortran/2024-December/061410.html
[Bug c++/118047] New: Incorrect direct-initialization of vector of struct of array of struct of enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118047
Bug ID: 118047
Summary: Incorrect direct-initialization of vector of struct of
array of struct of enum
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: MillerBenjaminT at johndeere dot com
Target Milestone: ---
Created attachment 59869
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59869&action=edit
Preprocessed source file
I've been hunting down an error in the Qt sources and I think I might have
found a compiler bug involving list appertainment.
In short, if a vector of structs, each containing one element that is a
default-initialized array of structs containing one enum that is assigned a
value is list-initialized with { { } }, the vector will contain 0 elements. My
best guess here is that g++ is creating an empty initializer list and copy
constructing another empty initializer list, rather than calling the default
constructor of the outermost struct.
#include
enum E {
One
};
struct A {
E e = One;
};
struct B {
A as[3] {};
};
int main() {
std::vector bs { { } };
if (bs.size() != 1) {
throw; // Throws on g++ >= 12.1.0
}
return 0;
}
Here is a godbolt snippet of this minimal example:
https://godbolt.org/z/zf96vY3Ev
The vector will have 0 elements on any g++ >= 12.1.0 and will have 1 element on
any suitable clang or icc compiler.
[Bug c++/118047] [12/13/14/15 Regression]Incorrect list initialization of vector of struct of array of struct of enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118047 Andrew Pinski changed: What|Removed |Added Summary|Incorrect list |[12/13/14/15 |initialization of vector of |Regression]Incorrect list |struct of array of struct |initialization of vector of |of enum |struct of array of struct ||of enum Target Milestone|13.4|12.5
[Bug c++/118047] Incorrect list initialization of vector of struct of array of struct of enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118047 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.4 Known to fail||12.1.0 Keywords||wrong-code Known to work||11.1.0
[Bug c++/118047] [12/13/14/15 Regression]Incorrect list initialization of vector of struct of array of struct of enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118047 Andrew Pinski changed: What|Removed |Added Attachment #59870|0 |1 is obsolete|| --- Comment #2 from Andrew Pinski --- Created attachment 59871 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59871&action=edit Reduced
[Bug c++/118047] [12/13/14/15 Regression]Incorrect list initialization of vector of struct of array of struct of enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118047
Andrew Pinski changed:
What|Removed |Added
Known to work||11.4.0
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2024-12-15
--- Comment #3 from Andrew Pinski ---
Confirmed.
s/E e = One;/int e = 0;/ shows it works without being an enum.
Even doing:
s/E e = One;/E e{};/ allows this to work.
[Bug c++/118047] [12/13/14/15 Regression]Incorrect list initialization of vector of struct of array of struct of enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118047 --- Comment #1 from Andrew Pinski --- Created attachment 59870 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59870&action=edit unincluded version
[Bug driver/118048] New: `-h`support does not work everywhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118048
Bug ID: 118048
Summary: `-h`support does not work everywhere
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
partly forwarded From
https://www.reddit.com/r/gcc/comments/1he7lp5/im_not_asking_to_support_its_because_this_is_just/
-h from the driver is passed on to the linker (and is the same as --soname).
It works for arm-linux-gnueabi and aarch64-linux-gnu but not for
x86_64-linux-gnu.
aarch64/aarch64-linux.h:#define LINUX_TARGET_LINK_SPEC "%{h*} \
arc/linux.h:#define LINK_SPEC "%{h*} \
arm/linux-elf.h:#define LINUX_TARGET_LINK_SPEC "%{h*} \
or1k/linux.h:#define LINK_SPEC "%{h*} \
Also for solaris:
sol2.h: "%{h*} %{v:-V} \
And when it is not in the LINK_SPEC we get the following odd error message:
[apinski@xeond2 upstream-cross-aarch64]$ ~/upstream-gcc/bin/gcc -ht.so t.cc
gcc: error: unrecognized command-line option ‘-h’
This used to work with an older version of GCC wehre no error message happened
even if it was not passed on to the linker.
[Bug c++/118047] [12/13/14/15 Regression] Incorrect list initialization of vector of struct of array of struct of enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118047 Sam James changed: What|Removed |Added Summary|[12/13/14/15|[12/13/14/15 Regression] |Regression]Incorrect list |Incorrect list |initialization of vector of |initialization of vector of |struct of array of struct |struct of array of struct |of enum |of enum --- Comment #4 from Sam James --- I'll bisect it in a minute.
[Bug c++/118047] [12/13/14/15 Regression] Incorrect list initialization of vector of struct of array of struct of enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118047
--- Comment #5 from Andrew Pinski ---
here is a compile time testcase:
```
#include
enum E {
One
};
struct A {
E e = One;
};
struct B {
A as[1] {};
};
struct v
{
constexpr v(const std::initializer_list &a) : size(a.size()){}
int size;
};
constexpr v a{{}};
static_assert(a.size == 1);
```
Note it works for -std=c++11 but fails for -std=c++14. Note the original
testcase acts similar too.
[Bug c++/118047] [12/13/14/15 Regression] Incorrect list initialization of vector of struct of array of struct of enum since r12-7803-gf0530882d99abc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118047 Sam James changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression] |Incorrect list |Incorrect list |initialization of vector of |initialization of vector of |struct of array of struct |struct of array of struct |of enum |of enum since ||r12-7803-gf0530882d99abc Keywords|needs-bisection | --- Comment #6 from Sam James --- r12-7803-gf0530882d99abc
[Bug c++/118047] [12/13/14/15 Regression] Incorrect list initialization of vector of struct of array of struct of enum since r12-7803-gf0530882d99abc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118047 --- Comment #7 from Sam James --- (In reply to Sam James from comment #6) > r12-7803-gf0530882d99abc .. but that patch got backported to 11?
[Bug c++/117658] Different ADL behavior between gcc and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117658
Nathaniel Shead changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=101140
CC||jason at gcc dot gnu.org,
||nshead at gcc dot gnu.org
--- Comment #2 from Nathaniel Shead ---
Specifically, a minimal example would be:
// a.cpp
export module A;
export template void test(T t) { foo(t); }
namespace ns {
export struct S {};
/* not exported */ void foo(S) {}
}
// b.cpp
import A;
int main() {
ns::S s;
test(s); // OK?
}
Clang compiles this, but GCC complains:
In module A, imported at b.cpp:1:
a.cpp: In instantiation of 'void test@A(T) [with T = ns::S@A]':
b.cpp:4:7: required from here
4 | test(ns::S{});
| ^
a.cpp:2:50: error: 'foo' was not declared in this scope
2 | export template void test(T t) { foo(t); }
| ~~~^~~
If `ns::foo` is exported then GCC also compiles this example.
Relevant seems to be https://eel.is/c++draft/basic.lookup.argdep#4. The first
set of bullet points don't apply, but since `t` is a dependent name lookup
should also be performed from each point in the instantiation context.
This is not an instantiation of a template in an enclosing specialisation, so
it looks to me that the instantiation context here is just the point of
instantiation of `test` (https://eel.is/c++draft/module.context#5), i.e.
main.cpp, but Clang seems to think that it should also include the point at the
end of `a.cpp`. This latter interpretation seems to be supported by the example
here https://eel.is/c++draft/basic.lookup.argdep#5 so I'm probably missing
something!
CCing Jason in case he has any thoughts.
