[Bug tree-optimization/98845] [9/10/11/12 Regression] ICE: SSA corruption (Unable to coalesce ssa_names 2 and 23 which are marked as MUST COALESCE.) since r6-528-g465770e43996a132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98845
--- Comment #12 from Richard Biener ---
(In reply to Arseny Solokha from comment #11)
> It should be labeled [12 Regression] again, then, as the issue is still
> there on trunk.
w/ -O2 -fno-tree-dce -fno-tree-dse (possibly with -fno-tree-dse also for the
testcase in the description)
int n;
__attribute__ ((returns_twice)) void
foo (void);
void
bar (void);
void
quux (int x)
{
if (x)
++x;
else
{
if (n)
{
x = 1;
foo ();
}
else
bar ();
if (n)
{
++x;
++n;
}
}
}
[Bug middle-end/90115] OpenACC: predetermined private levels for variables declared in blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90115 --- Comment #17 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:004fc4f2fc686d3366c9e1a2d8b9183796073866 commit r12-7684-g004fc4f2fc686d3366c9e1a2d8b9183796073866 Author: Thomas Schwinge Date: Wed Mar 16 12:15:01 2022 +0100 Enhance further testcases to verify handling of OpenACC privatization level [PR90115] As originally introduced in commit 11b8286a83289f5b54e813f14ff56d730c3f3185 "[OpenACC privatization] Largely extend diagnostics and corresponding testsuite coverage [PR90115]". PR middle-end/90115 gcc/testsuite/ * c-c++-common/goacc-gomp/nesting-1.c: Enhance. * gfortran.dg/goacc/common-block-3.f90: Likewise. libgomp/ * testsuite/libgomp.oacc-c-c++-common/acc_prof-kernels-1.c: Enhance. * testsuite/libgomp.oacc-fortran/if-1.f90: Likewise.
[Bug middle-end/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0 since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984
--- Comment #18 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7276a18aba41eed65c0cf535ae029e0ceeca6c77
commit r12-7686-g7276a18aba41eed65c0cf535ae029e0ceeca6c77
Author: Jakub Jelinek
Date: Thu Mar 17 09:23:45 2022 +0100
gimplify: Emit clobbers for TARGET_EXPR_SLOT vars later [PR103984]
As mentioned in the PR, we emit a bogus uninitialized warning but
easily could emit wrong-code for it or similar testcases too.
The bug is that we emit clobber for a TARGET_EXPR_SLOT too early:
D.2499.e = B::qux (&h); [return slot optimization]
D.2516 = 1;
try
{
B::B (&D.2498, &h);
try
{
_2 = baz (&D.2498);
D.2499.f = _2;
D.2516 = 0;
try
{
try
{
bar (&D.2499);
}
finally
{
C::~C (&D.2499);
}
}
finally
{
D.2499 = {CLOBBER(eol)};
}
}
finally
{
D.2498 = {CLOBBER(eol)};
}
}
catch
{
if (D.2516 != 0) goto ; else goto ;
:
A::~A (&D.2499.e);
goto ;
:
:
}
The CLOBBER for D.2499 is essentially only emitted on the non-exceptional
path, if B::B or baz throws, then there is no CLOBBER for it but there
is a conditional destructor A::~A (&D.2499.e). Now, ehcleanup1
sink_clobbers optimization assumes that clobbers in the EH cases are
emitted after last use and so sinks the D.2499 = {CLOBBER(eol)}; later,
so we then have
# _3 = PHI <1(3), 0(9)>
:
D.2499 ={v} {CLOBBER(eol)};
D.2498 ={v} {CLOBBER(eol)};
if (_3 != 0)
goto ; [INV]
else
goto ; [INV]
:
_35 = D.2499.a;
if (&D.2499.b != _35)
where that _35 = D.2499.a comes from inline expansion of the A::~A dtor,
and that is a load from a clobbered memory.
Now, what the gimplifier sees in this case is a CLEANUP_POINT_EXPR with
somewhere inside of it a TARGET_EXPR for D.2499 (with the C::~C (&D.2499)
cleanup) which in its TARGET_EXPR_INITIAL has another TARGET_EXPR for
D.2516 bool flag which has CLEANUP_EH_ONLY which performs that conditional
A::~A (&D.2499.e) call.
The following patch ensures that CLOBBERs (and asan poisoning) are emitted
after even those gimple_push_cleanup pushed cleanups from within the
TARGET_EXPR_INITIAL gimplification (i.e. the last point where the slot
could
be in theory used). In my first version of the patch I've done it by just
moving the
/* Add a clobber for the temporary going out of scope, like
gimplify_bind_expr. */
if (gimplify_ctxp->in_cleanup_point_expr
&& needs_to_live_in_memory (temp))
{
...
}
block earlier in gimplify_target_expr, but that regressed a couple of tests
where temp is marked TREE_ADDRESSABLE only during (well, very early during
that) the gimplification of TARGET_EXPR_INITIAL, so we didn't emit e.g. on
pr80032.C or stack2.C tests any clobbers for the slots and thus stack slot
reuse wasn't performed.
So that we don't regress those tests, this patch gimplifies
TARGET_EXPR_INITIAL as before, but doesn't emit it directly into pre_p,
emits it into a temporary sequence. Then emits the CLOBBER cleanup
into pre_p, then asan poisoning if needed, then appends the
TARGET_EXPR_INITIAL temporary sequence and finally adds TARGET_EXPR_CLEANUP
gimple_push_cleanup. The earlier a GIMPLE_WCE appears in the sequence, the
outer try/finally or try/catch it is.
So, with this patch the part of the testcase in gimple dump cited above
looks instead like:
try
{
D.2499.e = B::qux (&h); [return slot optimization]
D.2516 = 1;
try
{
try
{
B::B (&D.2498, &h);
_2 = baz (&D.2498);
D.2499.f = _2;
D.2516 = 0;
try
{
bar (&D.2499);
}
finally
{
[Bug middle-end/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0 since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #19 from Jakub Jelinek --- Fixed.
[Bug testsuite/104960] [12 regression] several test cases fail after r12-7670-gf6fb661ea8ac7e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104960 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:3a7ba8fd0cda387809e4902328af2473662b6a4a commit r12-7687-g3a7ba8fd0cda387809e4902328af2473662b6a4a Author: Richard Biener Date: Thu Mar 17 08:10:59 2022 +0100 tree-optimization/104960 - unsplit edges after late sinking Something went wrong when testing the earlier patch to move the late sinking to before the late phiopt for PR102008. The following makes sure to unsplit edges after the late sinking since the split edges confuse the following phiopt leading to missed optimizations. I've went for a new pass parameter for this to avoid changing the CFG after the early sinking pass at this point. 2022-03-17 Richard Biener PR tree-optimization/104960 * passes.def: Add pass parameter to pass_sink_code, mark last one to unsplit edges. * tree-ssa-sink.cc (pass_sink_code::set_pass_param): New. (pass_sink_code::execute): Always execute TODO_cleanup_cfg when we need to unsplit edges. * gcc.dg/gimplefe-37.c: Adjust to allow either the true or false edge to have a forwarder.
[Bug testsuite/102841] [12 regression] libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102841 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Thomas Schwinge --- > Can't (easily) test due to corresponding Solaris/Darwin system > non-availability, but I think I understand the issue, and it should now be > fixed. Please re-open if not. The failures are gone in last night's i386-pc-solaris2.11 and sparc-sun-solaris2.11 bootstraps. Thanks.
[Bug c/104948] When '&&' present in a comparison, a warning should be generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104948 --- Comment #13 from dagelf --- Yes, I seem to have had a hole in my head. Sorry. For reference, to summarise then: & returns only the bits that are the same (bitwise AND) (or the bits that are left after AND) (which will evaluate to true unless its 0 eg. (2 & 1) is false but (3 & 1) is true. && casts operands to bool, so anything nonzero becomes 1. (eg. (2 && 1) is true) && and & nonequivalence: https://godbolt.org/z/Yf5cxcKch So & and && are only interchangeable when operating on bool parameters, on anything else they each do something completely different. The fact that there's a warning is great. Perhaps its fine. But this is something so fundamental, it feels like no room for confusion should be left. In fact, the more I think about it, the more I am convinced that it should not be a warning, but an error, so -Werror is my new default. Although I would love to find counter examples, I would be willing to wager that && mixed with non bools, will almost always be done in error.
[Bug tree-optimization/104964] New: Wrong *** buffer overflow detected ***: terminated - acl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
Bug ID: 104964
Summary: Wrong *** buffer overflow detected ***: terminated -
acl
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
The test-case is reduced from acl:
$ cat x.c
#include
#include
#include
struct __string_ext {
char s_str[0];
};
struct string_obj_tag {
struct __string_ext i;
};
typedef struct string_obj_tag string_obj;
static void
writeto(char *text_p, ssize_t size)
{
fprintf (stderr, "Write to: %p, size=%d\n", text_p, size);
strncpy(text_p, "sparta", size);
}
int main()
{
ssize_t size = 30;
string_obj *string_obj_p = (string_obj *)malloc (sizeof(string_obj) + size);
fprintf (stderr, "allocated: %d B starting at %p\n", size,
string_obj_p->i.s_str);
writeto(string_obj_p->i.s_str, size);
fprintf (stderr, "result STR(%p)=%s\n", string_obj_p->i.s_str,
string_obj_p->i.s_str);
return 0;
}
$ gcc x.c -D_FORTIFY_SOURCE=2 -O2 && ./a.out
In file included from /usr/include/string.h:535,
from x.c:3:
In function ‘strncpy’,
inlined from ‘writeto’ at x.c:19:3,
inlined from ‘main’ at x.c:28:3:
/usr/include/bits/string_fortified.h:95:10: warning: ‘__builtin___strncpy_chk’
writing 30 bytes into a region of size 0 overflows the destination
[-Wstringop-overflow=]
95 | return __builtin___strncpy_chk (__dest, __src, __len,
| ^~
96 | __glibc_objsize (__dest));
| ~
allocated: 30 B starting at 0x4052a0
Write to: 0x4052a0, size=30
*** buffer overflow detected ***: terminated
Aborted (core dumped)
While clang is fine:
$ clang x.c -D_FORTIFY_SOURCE=2 -O2 && ./a.out
allocated: 30 B starting at 0x4052a0
Write to: 0x4052a0, size=30
result STR(0x4052a0)=sparta
and ASAN,UBSAN as well:
$ gcc-11 x.c -fsanitize=address,undefined && ./a.out
allocated: 30 B starting at 0x60300040
Write to: 0x60300040, size=30
result STR(0x60300040)=sparta
I see the error happens also with older GCC compilers.
[Bug tree-optimization/104964] Wrong *** buffer overflow detected ***: terminated - acl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-03-17 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Priority|P3 |P1 CC||siddhesh at gcc dot gnu.org
[Bug tree-optimization/104964] Wrong *** buffer overflow detected ***: terminated - acl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964 --- Comment #1 from Martin Liška --- Likely related to PR101836?
[Bug tree-optimization/104964] Wrong *** buffer overflow detected ***: terminated - acl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964 --- Comment #2 from Martin Liška --- Note the test-case is reduced from acl package (with -D_FORTIFY_SOURCE=3) that used to work with -D_FORTIFY_SOURCE=2. So maybe my reduction was too aggressive or should the current master support trailing arrays?
[Bug middle-end/101134] Bogus -Wstringop-overflow warning about non-existent overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134 --- Comment #14 from Jonathan Wakely --- (In reply to Giuseppe D'Angelo from comment #13) > Does this make sense? Yes, perfect sense, and many of us agree 100%.
[Bug testsuite/104960] [12 regression] several test cases fail after r12-7670-gf6fb661ea8ac7e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104960 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Richard Biener --- Fixed.
[Bug target/104952] [nvptx][OpenMP] wrong code with OR / AND reduction ('reduction(||:' and '&&') with SIMT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952
Tom de Vries changed:
What|Removed |Added
Keywords||openmp
--- Comment #1 from Tom de Vries ---
I can reproduce the problem.
I've made the simd explicit (I hope that's still valid openmp code):
...
$ cat libgomp/testsuite/libgomp.c/test.c
#define N 32
static char arr[N];
int
main (void)
{
unsigned int result = 0;
for (unsigned int i = 0; i < N; ++i)
arr[i] = 0;
arr[5] = 1;
#pragma omp target map(tofrom:result) map(to:arr)
#pragma omp simd reduction(||: result)
for (unsigned int i = 0; i < N; ++i)
result = result || arr[i];
if (result != 1)
return 1;
return 0;
}
...
Easy workaround:
...
diff --git a/gcc/omp-low.cc b/gcc/omp-low.cc
index d932d74cb03..bf6845d654e 100644
--- a/gcc/omp-low.cc
+++ b/gcc/omp-low.cc
@@ -4641,6 +4641,15 @@ lower_rec_simd_input_clauses (tree new_var, omp_context
*ctx,
sctx->max_vf = 1;
break;
}
+
+ if (OMP_CLAUSE_REDUCTION_CODE (c) == TRUTH_ANDIF_EXPR
+ || OMP_CLAUSE_REDUCTION_CODE (c) == TRUTH_ORIF_EXPR)
+ {
+ sctx->max_vf = 1;
+ break;
+ }
}
}
if (maybe_gt (sctx->max_vf, 1U))
...
[Bug c/104948] When '&&' has non bool parameters, a better warning should be generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104948
--- Comment #14 from Jonathan Wakely ---
(In reply to dagelf from comment #13)
> Although I would love to find counter examples, I would be willing to wager
> that && mixed with non bools, will almost always be done in error.
No, this is valid and not done in error:
void f(const char* str, size_t len)
{
if (str && len)
{ /* ... */ }
}
The condition is equivalent to (str != 0 && len != 0) but more succinct. If you
prefer the more verbose form, that's fine, but it doesn't mean everyone else's
code is erroneous.
[Bug middle-end/99578] [11/12 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 --- Comment #33 from Jonathan Wakely --- (In reply to Martin Sebor from comment #31) > As I mentioned in comment #25 and elsewhere, I envisioned that code would > annotate these hardwired addresses somehow, ideally using an attribute like > addr or the Keil compiler's at (see below), or until one is added, using a > workaround like your absolute_pointer(). I realize it means work, but I > believe with the attribute the gain in type safety would make it worthwhile. > Is that something the kernel developers could be trained to start using? > (In full disclosure, I don't expect to have the cycles to work on the > attribute anytime soon.) Whether or not it's reasonable to expect working code to be transitioned to a new feature, in the absence of such a feature (and no likelihood of it appearing any time soon) we should not be giving warnings for this code. The idea that it's zero-cost or zero-risk to go around sprinkling casts in working code that passes all its tests is foolish. Every cast added to silence a false positive warning has a risk of introducing a new problem and hiding a real bug in future.
[Bug middle-end/99578] [11/12 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 --- Comment #34 from Jonathan Wakely --- (In reply to Goswin von Brederlow from comment #29) > There is no garantee in the C standard that '(type *)CONSTANT' will actually > point to the hardware address 'CONSTANT'. It's just how gcc happens to do it > in most cases. So no, your code is not fine. It is fragile. It relies on > implementation details of gcc. But lets not argue about that. Actually, lets. It relies on guaranteed behaviour of GCC: https://gcc.gnu.org/onlinedocs/gcc/Arrays-and-pointers-implementation.html That's not going to change, and neither is the fact that the Linux kernel depends on implementation-defined properties of GCC (where "implementation-defined" is used in the formal sense, not "just an implementation detail that might change tomorrow").
[Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943 --- Comment #48 from Richard Biener --- (In reply to Andrew Macleod from comment #47) > Created attachment 52637 [details] > new patch > > I am working on a alternative cache for GCC 13, but along the way, I have > changes to the ranger_cache::range_from_dom() routine. The original version > gave up when it hit a block which had outgoing edges. The new version is > smarter and basically goes back until it finds a cache entry, and then > intersects all outgoing edge between the two places. It also removes the > recursion , and does not SET any cache values during the lookup (making it a > true query). > > The net effect of this is significant improvements in cache performance > because its used far less, but there is more time spend doing calculations. > This bootstraps and passes all regression tests. we do miss out on a few > minor opportunities (30 out of 4400 in all of EVRP over the GCC source) > which occur as a result of updated values not being propagated properly as > the cache is no longer "full" like it was before. > > IN GCC 13 I will address this, but I thought you might be interested in > trying this patch against this PR. > > In building 380 GCC source files, I see the following avg speedups > evrp : -22.57% > VRP2 : -5.4% > thread_jumps_full : -14.16% > total : -0.44% > > So it is not insignificant. > > It is likely to be most effective in large CFGs. > This is *total* compile time percent speed up for the 5 most significant > cases: > > expr.ii -2.62% > lra-constraints.ii -3.75% > caller-save.ii -3.98% > reload.ii -4.04% > optabs.ii -5.05% > > EVRP isolated speedups (yes, these are *percetage* speedup) > expr.ii -62.38 > simplify-rtx.ii -65.97 > lra-constraints.ii -67.87 > reload.ii trunk -68.67 > caller-save.ii trunk -71.93 > optabs.ii trunk -78.69 > > I think those times are probably worth the odd miss. > > Anyway, next time you are checking performance for this PR maybe also try > this patch and see how it performs. It helps quite a bit, the worst case is now tree VRP : 5.14 ( 7%) 0.02 ( 3%) 5.15 ( 7%) 2 9M ( 3%) backwards jump threading : 4.05 ( 6%) 0.00 ( 0%) 4.06 ( 6%) 222 0k ( 0%) overall the patch reduces compile time from 766s to 749 (parallel compile, serial LTO, release checking). So IMHO definitely worth it if you are happy with it.
[Bug tree-optimization/104964] Wrong *** buffer overflow detected ***: terminated - acl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964 Martin Liška changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=92815 --- Comment #3 from Martin Liška --- It's likely the same what was mentioned here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92815#c3
[Bug tree-optimization/104964] Wrong *** buffer overflow detected ***: terminated - acl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
Martin Liška changed:
What|Removed |Added
Priority|P1 |P3
--- Comment #4 from Martin Liška ---
All right, so this one is likely an invalid code:
cat x.c
#include
#include
#include
struct bad_struct {
struct
{
char s_str[1];
} i;
};
struct good_struct
{
char s_str[1];
};
ssize_t size = 30;
struct bad_struct *bad;
struct good_struct *good;
int main()
{
good = (struct good_struct *)malloc (sizeof(struct good_struct) + size);
char *str = good->s_str;
strcpy (str, "sparta");
bad = (struct bad_struct *)malloc (sizeof(struct bad_struct) + size);
char *str2 = bad->i.s_str;
strcpy (str2, "sparta");
return 0;
}
It shows the difference in between wrapped struct and not wrapped one.
[Bug driver/13071] no easy way to exclude backward C++ headers from include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13071 Jonathan Wakely changed: What|Removed |Added Status|NEW |WAITING --- Comment #9 from Jonathan Wakely --- (In reply to Harald van Dijk from comment #8) > (In reply to Andrew Pinski from comment #7) > > Isn't doing the extern "C" around standard C++ headers declared by the C++ > > standard as undefined behavior? > > It is (as is doing extern "C++" around standard C++ headers, for that > matter), Where does it say that? > but only became a standard C++ header in C++11. This > bug is from 2003 and the comment before yours was from 2009, so I think > was not a standard C++ header yet. Agreed. But there is no complex.h in the backward directory now. The contents of that directory are: auto_ptr.h backward_warning.h binders.h hash_fun.h hash_map hash_set hashtable.h strstream The header is required for standard conformance, so excluding that directory would make it impossible to use that standard header. The other headers seem unlikely to conflict with any headers in /usr/include (which was the original subject of this PR). Can we close this now?
[Bug tree-optimization/104964] Wrong *** buffer overflow detected ***: terminated - acl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
Siddhesh Poyarekar changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot
gnu.org
--- Comment #5 from Siddhesh Poyarekar ---
I'm not 100% sure if it's invalid code, but I was just about to write that it
depends on what the pass ends up seeing. If earlier passes end up optimizing
the code such that the objsz pass sees the malloc first (e.g. the reproducer in
pr104961), it ends up with the malloc'd size, otherwise it ends up with the
declared size.
So if it was:
struct bad_struct {
struct g
{
char s_str[1];
} i;
};
and
struct g *i = &bad->i;
strcpy (i->s_str, "sparta");
then i tends to get optimized as a MEM_REF of the malloc'd block, letting us
see the extra space.
This needs to be fixed, but then it's possibly a different bug from the one
you're seeing in acl since this affects __bos too, not just __bdos.
(I'm off in a couple of hours btw, returning on Tuesday so I may not get to it
until then)
[Bug driver/13071] no easy way to exclude backward C++ headers from include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13071 --- Comment #10 from Harald van Dijk --- (In reply to Jonathan Wakely from comment #9) > (In reply to Harald van Dijk from comment #8) > > (In reply to Andrew Pinski from comment #7) > > > Isn't doing the extern "C" around standard C++ headers declared by the C++ > > > standard as undefined behavior? > > > > It is (as is doing extern "C++" around standard C++ headers, for that > > matter), > > Where does it say that? It's the exact same rule as for extern "C", [using.headers]p3. (And yes, it does make a difference to not having extern "C++" around it and can cause breakage, this is not purely hypothetical, but it's much less likely to cause problems than extern "C".) > > but only became a standard C++ header in C++11. This > > bug is from 2003 and the comment before yours was from 2009, so I think > > was not a standard C++ header yet. > > Agreed. But there is no complex.h in the backward directory now. >[...] > Can we close this now? Testing with GCC 11 as provided by Ubuntu, including will cause GCC's c++/11/complex.h to be included, both in C++03 and in C++11 modes, but in C++03 it just delegates to glibc's . To me, that looks like it's fixed.
[Bug target/104952] [nvptx][OpenMP] wrong code with OR / AND reduction ('reduction(||:' and '&&') with SIMT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952 --- Comment #2 from Tom de Vries --- I think the problem can be seen already at omp-lower, in the body of the butterfly loop. Let's first look at what we have if we use reduction op '|': ... D.2173 = .GOMP_SIMT_VF (); D.2164 = 1; D.2161 = 0; goto ; : D.2165 = D.2163; D.2165 = D.2163; D.2166 = .GOMP_SIMT_XCHG_BFLY (D.2165, D.2164); D.2167 = D.2165 | D.2166; D.2163 = D.2167; D.2164 = D.2164 << 1; : if (D.2164 < D.2173) goto ; else goto ; : ... Fairly straightforward, we have a loop, runs a couple of times, first a shuffle (GOMP_SIMT_XCHG_BFLY), then an update (D.2167 = D.2165 | D.2166). Now compare that with reduction op '||': ... D.2183 = .GOMP_SIMT_VF (); D.2164 = 1; D.2161 = 0; goto ; : D.2169 = D.2163; D.2170 = (_Bool) D.2169; if (D.2170 != 0) goto ; else goto ; : D.2169 = D.2163; D.2172 = .GOMP_SIMT_XCHG_BFLY (D.2169, D.2164); D.2173 = (_Bool) D.2172; if (D.2173 != 0) goto ; else goto ; : iftmp.5 = 1; goto ; : iftmp.5 = 0; : D.2163 = iftmp.5; D.2164 = D.2164 << 1; : if (D.2164 < D.2183) goto ; else goto ; : ... The shuffle is now conditional. I think the shuffle is inserted too late, in the middle of the update rather than before.
[Bug middle-end/104965] New: Yet another -Warray-bounds false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104965
Bug ID: 104965
Summary: Yet another -Warray-bounds false positive
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 56456
Target Milestone: ---
Maybe another dup, I can't keep track.
#include
template
T* f(const std::basic_string& str)
{
auto n = str.size();
auto p = new T[n];
str.copy(p, n);
return p;
}
int main()
{
std::basic_string s;
auto p = f(s);
char c = 0;
if (s.size())
c = *p;
delete[] p;
return c;
}
With -O2
copy.cc: In function 'int main()':
copy.cc:18:9: warning: array subscript 0 is outside array bounds of 'short
unsigned int [0]' [-Warray-bounds]
18 | c = *p;
| ^~
In function 'T* f(const std::__cxx11::basic_string<_CharT>&) [with T = short
unsigned int]',
inlined from 'int main()' at copy.cc:15:13:
copy.cc:7:12: note: object of size 0 allocated by 'operator new []'
7 | auto p = new T[n];
|^~~~
This is ridiculous. The array subscript is guarded by the same length as the
array. GCC manages to use the string length to determine the allocation size,
but can't use it to confirm the conditional read doesn't happen.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug target/99555] [OpenMP/nvptx] Execution-time hang for simple nested OpenMP 'target'/'parallel'/'task' constructs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555
--- Comment #13 from Thomas Schwinge ---
Thanks -- I'm confirming:
PASS: libgomp.c/../libgomp.c-c++-common/task-detach-6.c (test for excess
errors)
[-XFAIL:-]{+PASS:+} libgomp.c/../libgomp.c-c++-common/task-detach-6.c
execution test
PASS: libgomp.c/pr99555-1.c (test for excess errors)
[-XFAIL:-]{+PASS:+} libgomp.c/pr99555-1.c execution test
PASS: libgomp.c++/../libgomp.c-c++-common/task-detach-6.c (test for excess
errors)
[-XFAIL:-]{+PASS:+} libgomp.c++/../libgomp.c-c++-common/task-detach-6.c
execution test
PASS: libgomp.fortran/task-detach-6.f90 -O0 (test for excess errors)
[-XFAIL:-]{+PASS:+} libgomp.fortran/task-detach-6.f90 -O0 execution test
PASS: libgomp.fortran/task-detach-6.f90 -O1 (test for excess errors)
[-XFAIL:-]{+PASS:+} libgomp.fortran/task-detach-6.f90 -O1 execution test
PASS: libgomp.fortran/task-detach-6.f90 -O2 (test for excess errors)
[-XFAIL:-]{+PASS:+} libgomp.fortran/task-detach-6.f90 -O2 execution test
PASS: libgomp.fortran/task-detach-6.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess
errors)
[-XFAIL:-]{+PASS:+} libgomp.fortran/task-detach-6.f90 -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
execution test
PASS: libgomp.fortran/task-detach-6.f90 -O3 -g (test for excess errors)
[-XFAIL:-]{+PASS:+} libgomp.fortran/task-detach-6.f90 -O3 -g execution
test
PASS: libgomp.fortran/task-detach-6.f90 -Os (test for excess errors)
[-XFAIL:-]{+PASS:+} libgomp.fortran/task-detach-6.f90 -Os execution test
..., but on one system (only!), I'm also seeing regressions as follows:
PASS: libgomp.c/../libgomp.c-c++-common/task-detach-10.c (test for excess
errors)
{+WARNING: program timed out.+}
[-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/task-detach-10.c
execution test
PASS: libgomp.c/../libgomp.c-c++-common/task-detach-8.c (test for excess
errors)
{+WARNING: program timed out.+}
[-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/task-detach-8.c
execution test
PASS: libgomp.c++/../libgomp.c-c++-common/task-detach-10.c (test for excess
errors)
{+WARNING: program timed out.+}
[-PASS:-]{+FAIL:+} libgomp.c++/../libgomp.c-c++-common/task-detach-10.c
execution test
PASS: libgomp.c++/../libgomp.c-c++-common/task-detach-8.c (test for excess
errors)
{+WARNING: program timed out.+}
[-PASS:-]{+FAIL:+} libgomp.c++/../libgomp.c-c++-common/task-detach-8.c
execution test
PASS: libgomp.fortran/task-detach-10.f90 -O0 (test for excess errors)
{+WARNING: program timed out.+}
[-PASS:-]{+FAIL:+} libgomp.fortran/task-detach-10.f90 -O0 execution test
PASS: libgomp.fortran/task-detach-10.f90 -O1 (test for excess errors)
{+WARNING: program timed out.+}
[-PASS:-]{+FAIL:+} libgomp.fortran/task-detach-10.f90 -O1 execution test
PASS: libgomp.fortran/task-detach-10.f90 -O2 (test for excess errors)
{+WARNING: program timed out.+}
[-PASS:-]{+FAIL:+} libgomp.fortran/task-detach-10.f90 -O2 execution test
PASS: libgomp.fortran/task-detach-10.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess
errors)
{+WARNING: program timed out.+}
[-PASS:-]{+FAIL:+} libgomp.fortran/task-detach-10.f90 -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
execution test
PASS: libgomp.fortran/task-detach-10.f90 -O3 -g (test for excess errors)
{+WARNING: program timed out.+}
[-PASS:-]{+FAIL:+} libgomp.fortran/task-detach-10.f90 -O3 -g execution
test
PASS: libgomp.fortran/task-detach-10.f90 -Os (test for excess errors)
{+WARNING: program timed out.+}
[-PASS:-]{+FAIL:+} libgomp.fortran/task-detach-10.f90 -Os execution test
PASS: libgomp.fortran/task-detach-8.f90 -O0 (test for excess errors)
{+WARNING: program timed out.+}
[-PASS:-]{+FAIL:+} libgomp.fortran/task-detach-8.f90 -O0 execution test
PASS: libgomp.fortran/task-detach-8.f90 -O1 (test for excess errors)
{+WARNING: program timed out.+}
[-PASS:-]{+FAIL:+} libgomp.fortran/task-detach-8.f90 -O1 execution test
PASS: libgomp.fortran/task-detach-8.f90 -O2 (test for excess errors)
{+WARNING: program timed out.+}
[-PASS:-]{+FAIL:+} libgomp.fortran/task-detach-8.f90 -O2 execution test
PASS: libgomp.fortran/task-detach-8.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess
errors)
{+WARNING: program timed out.+}
[-PASS:-]{+FAIL:+} libgomp.fortran/task-detach-8.f90 -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
execution test
PASS: libgomp.fortran/task-detach-8.f90 -O3 -g (test for excess errors)
{+WARNING: program timed out.+}
[-PASS:-]{+FAIL:+} libgomp.
[Bug middle-end/104966] New: [11/12 Regression] Yet another bogus -Warray-bounds warning in libstdc++ headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966 Bug ID: 104966 Summary: [11/12 Regression] Yet another bogus -Warray-bounds warning in libstdc++ headers Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Blocks: 56456 Target Milestone: --- This has been failing for a while, but since there seems little chance of it getting fixed I didn't bother reporting it. This can be seen on any target with: make check RUNTESTFLAGS="conformance.exp=22_locale/money_get/cons/3.cc --target_board=unix/-std=gnu++20" Executing on host: /home/jwakely/build/./gcc/xg++ -shared-libgcc -B/home/jwakely/build/./gcc -nostdinc++ -L/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/src -L/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/jwakely/gcc/12/powerpc64le-unknown-linux-gnu/bin/ -B/home/jwakely/gcc/12/powerpc64le-unknown-linux-gnu/lib/ -isystem /home/jwakely/gcc/12/powerpc64le-unknown-linux-gnu/include -isystem /home/jwakely/gcc/12/powerpc64le-unknown-linux-gnu/sys-include -B/home/jwakely/build/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/jwakely/src/gcc/libstdc++-v3/libsupc++ -I/home/jwakely/src/gcc/libstdc++-v3/include/backward -I/home/jwakely/src/gcc/libstdc++-v3/testsuite/util /home/jwakely/src/gcc/libstdc++-v3/testsuite/22_locale/money_get/cons/3.cc -std=gnu++20 -fdiagnostics-plain-output -S -o 3.s(timeout = 90) spawn -ignore SIGHUP /home/jwakely/build/./gcc/xg++ -shared-libgcc -B/home/jwakely/build/./gcc -nostdinc++ -L/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/src -L/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/jwakely/gcc/12/powerpc64le-unknown-linux-gnu/bin/ -B/home/jwakely/gcc/12/powerpc64le-unknown-linux-gnu/lib/ -isystem /home/jwakely/gcc/12/powerpc64le-unknown-linux-gnu/include -isystem /home/jwakely/gcc/12/powerpc64le-unknown-linux-gnu/sys-include -B/home/jwakely/build/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/jwakely/src/gcc/libstdc++-v3/libsupc++ -I/home/jwakely/src/gcc/libstdc++-v3/include/backward -I/home/jwakely/src/gcc/libstdc++-v3/testsuite/util /home/jwakely/src/gcc/libstdc++-v3/testsuite/22_locale/money_get/cons/3.cc -std=gnu++20 -fdiagnostics-plain-output -S -o 3.s In file included from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/string:50, from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/locale_classes.h:40, from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/locale:39, from /home/jwakely/src/gcc/libstdc++-v3/testsuite/22_locale/money_get/cons/3.cc:24: In static member function 'static constexpr _Tp* std::__copy_move<_IsMove, true, std::random_access_iterator_tag>::__copy_m(const _Tp*, const _Tp*, _Tp*) [with _Tp = __gnu_cxx::character; bool _IsMove = false]', inlined from 'constexpr _OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove = false; _II = const __gnu_cxx::character*; _OI = __gnu_cxx::character*]' at /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:495, inlined from 'constexpr _OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove = false; _II = const __gnu_cxx::character*; _OI = __gnu_cxx::character*]' at /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:522, inlined from 'constexpr _OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove = false; _II = const __gnu_cxx::character*; _OI = __gnu_cxx::character*]' at /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:529, inlined from 'constexpr _OI std::copy(_II, _II, _OI) [with _II = const __gnu_cxx::character*; _OI = __gnu_cxx::character*]' at /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:620, inlined from 'static std::char_traits<__gnu_c
[Bug target/104912] [12 Regression] 416.gamess regression after r12-7612-g69619acd8d9b58
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104912
--- Comment #6 from Richard Biener ---
Created attachment 52640
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52640&action=edit
patch
Like this - this counts the number of vector stmts and the number of strided
loads/stores and then when finishing up:
+void
+ix86_vector_costs::finish_cost (const vector_costs *scalar_costs)
+{
+ m_finished = true;
+ if (m_costing_for_scalar)
+return;
+
+ /* When we have more than one strided load or store and the
+ number of strided stores is high compared to all vector
+ stmts in the body we require at least an estimated
+ improvement due to the vectorization of a factor of two. */
+ if (m_n_body_strided_load_store > 1
+ && m_n_body_stmts / m_n_body_strided_load_store < 4)
+{
+ unsigned vf = 1;
+ if (is_a (m_vinfo))
+ vf = vect_vf_for_cost (as_a (m_vinfo));
+ if (scalar_costs->prologue_cost () * vf < 2 * body_cost ())
+ m_costs[vect_body] *= 2;
+}
+}
the scaling of m_costs[vect_body] will make the vectorization unprofitable.
Instead of a hard limit like this we could also scale the strided load
cost based on the overall number of them, like if adding
m_n_body_strided_load_store squared to the cost.
Note that the "true" cost would only be visible when doing a scheduling
model with dependences in mind. Note that for this particular case this
is all hand-waving since the true cost is the versioning/branching overhead,
not the vectorized loop body and the low number of iterations makes this
particularly visible. So for 416.gamess it will be all a hack...
[Bug middle-end/104966] [11/12 Regression] Yet another bogus -Warray-bounds warning in libstdc++ headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966
--- Comment #1 from Jonathan Wakely ---
Created attachment 52641
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52641&action=edit
Partially reduced preprocessed source for second issue
-std=gnu++20 -Wall gives:
3.ii: In member function 'void std::__moneypunct_cache<_CharT,
_Intl>::_M_cache(const std::locale&) [with _CharT =
__gnu_cxx::character; bool _Intl = false]':
3.ii:37583:9: warning: array subscript 0 is outside array bounds of
'__gnu_cxx::character [0]' [-Warray-bounds]
37583 | { __c1 = __c2; }
| ^~~~
3.ii:36040:22: note: referencing an object of size 0 allocated by 'void*
operator new [](std::size_t)'
36040 |__positive_sign = new _CharT[_M_positive_sign_size];
| ^
3.ii:37583:9: warning: array subscript 0 is outside array bounds of
'__gnu_cxx::character [0]' [-Warray-bounds]
37583 | { __c1 = __c2; }
| ^~~~
3.ii:36045:22: note: referencing an object of size 0 allocated by 'void*
operator new [](std::size_t)'
36045 |__negative_sign = new _CharT[_M_negative_sign_size];
| ^
[Bug target/104967] New: ICE: Segmentation fault (in find_instance)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104967
Bug ID: 104967
Summary: ICE: Segmentation fault (in find_instance)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-e300c3-linux-gnu
gcc 12.0.1 20220313 snapshot (g:7e28750395889d16a9cba49cd5935ced7dc00ce8) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/powerpc/float128-hw4.c, for 32-bit BE target:
long double
set_float128_exponent_float128 (long double a, int e)
{
return __builtin_vec_scalar_insert_exp (a, e);
}
% powerpc-e300c3-linux-gnu-gcc-12.0.1 -c iudcdop7.c
iudcdop7.c: In function 'set_float128_exponent_float128':
iudcdop7.c:4:3: internal compiler error: Segmentation fault
4 | return __builtin_vec_scalar_insert_exp (a, e);
| ^~
0xe3e12f crash_signal
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/toplev.cc:322
0x8f5e88 tree_check2(tree_node*, char const*, int, char const*, tree_code,
tree_code)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/tree.h:3467
0x8f5e88 find_instance(bool*, ovlddata**, rs6000_gen_builtins,
rs6000_gen_builtins, tree_node**, tree_node**)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/config/rs6000/rs6000-c.cc:1690
0x8f692c altivec_resolve_overloaded_builtin(unsigned int, tree_node*, void*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/config/rs6000/rs6000-c.cc:1951
0x81e3d4 c_build_function_call_vec(unsigned int, vec const&, tree_node*, vec*, vec*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/c/c-typeck.cc:3268
0x83fdd7 c_parser_postfix_expression_after_primary
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/c/c-parser.cc:10561
0x836f98 c_parser_postfix_expression
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/c/c-parser.cc:10234
0x83b47a c_parser_unary_expression
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/c/c-parser.cc:8261
0x83cc51 c_parser_cast_expression
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/c/c-parser.cc:8103
0x83cee1 c_parser_binary_expression
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/c/c-parser.cc:7906
0x83e3ae c_parser_conditional_expression
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/c/c-parser.cc:7606
0x83ec00 c_parser_expr_no_commas
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/c/c-parser.cc:7521
0x83ee91 c_parser_expression
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/c/c-parser.cc:10697
0x83f668 c_parser_expression_conv
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/c/c-parser.cc:10736
0x8351cb c_parser_statement_after_labels
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/c/c-parser.cc:6173
0x836ada c_parser_compound_statement_nostart
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/c/c-parser.cc:5800
0x8573e5 c_parser_compound_statement
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/c/c-parser.cc:5609
0x858f78 c_parser_declaration_or_fndef
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/c/c-parser.cc:2544
0x861363 c_parser_external_declaration
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/c/c-parser.cc:1779
0x861dbb c_parser_translation_unit
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220313/work/gcc-12-20220313/gcc/c/c-parser.cc:1652
I'm not sure if it is related to PR104482.
[Bug middle-end/104966] [11/12 Regression] Yet another bogus -Warray-bounds warning in libstdc++ headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966 --- Comment #2 from Jonathan Wakely --- Oops, I forgot to add that these all need -O2 to trigger the warnings.
[Bug middle-end/104966] [11/12 Regression] Yet another bogus -Warray-bounds warning in libstdc++ headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966 --- Comment #3 from Jonathan Wakely --- Created attachment 52642 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52642&action=edit Preprocessed source for the first issue This is the original unreduced preprocessed output for the test libstdc++-v3/testsuite/22_locale/money_get/cons/3.cc -std=gnu++20 -Wall -O2 gives four bogus warnings for this one.
[Bug target/104952] [nvptx][OpenMP] wrong code with OR / AND reduction ('reduction(||:' and '&&') with SIMT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952
--- Comment #3 from Tom de Vries ---
Hmm, that seems to be actually due to:
...
if (sctx.is_simt)
{
if (!simt_lane)
simt_lane = create_tmp_var (unsigned_type_node);
x = build_call_expr_internal_loc
(UNKNOWN_LOCATION, IFN_GOMP_SIMT_XCHG_BFLY,
TREE_TYPE (ivar), 2, ivar, simt_lane);
x = build2 (code, TREE_TYPE (ivar), ivar, x);
gimplify_assign (ivar, x, &llist[2]);
}
...
which gimplifies assigning:
...
(gdb) call debug_generic_expr (x)
D.2163 || .GOMP_SIMT_XCHG_BFLY (D.2163, D.2164)
...
to:
...
(gdb) call debug_generic_expr (ivar)
D.2163
...
[Bug middle-end/104966] [11/12 Regression] Yet another bogus -Warray-bounds warning in libstdc++ headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966
--- Comment #4 from Richard Biener ---
Well, the IL definitely has
tem = operator new[] (0);
/* some magic computing with 'positive_sign_size' */
if (min (positive-sign-size, something) != 0)
if (__n == 1)
;
else
{
tem = __n * 4;
if (tem != 0)
__builtin_memmove (dest, ..., tem);
so I guess that "magic" should always evaluate to 0 but we are not able
to figure that out despite the allocation being statically size zero.
You might be able to pin-point the libstdc++ piece with that magic?
[Bug middle-end/104854] -Wstringop-overread should not warn for strnlen, strndup and strncmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104854 --- Comment #9 from David Malcolm --- (In reply to Siddhesh Poyarekar from comment #8) > (In reply to Martin Sebor from comment #7) > > Moving warnings into the analyzer and scaling it up to be able to run by > > default, during development, sounds like a good long-term plan. Until that > > That's not quite what I'm suggesting here. I'm not a 100% convinced that > those are the right heuristics at all; the size argument for strnlen, > strndup and strncmp does not intend to describe the size of the passed > strings. It is only recommended security practice that the *n* variant > functions be used instead of their unconstrained relatives to mitigate > overflows. In fact in more common cases the size argument (especially in > case of strnlen and strncmp) may describe a completely different buffer or > some other application-specific property. > > This is different from the -Wformat-overflow, where there is a clear > relationship between buffer, the format string and the string representation > of input numbers and we're only tweaking is the optimism level of the > warnings. So it is not just a question of levels of verosity/paranoia. > > In that context, using size to describe the underlying buffer of the source > only makes sense only for a subset of uses, making this heuristic quite > noisy. So what I'm actually saying is: the heuristic is too noisy but if we > insist on keeping it, it makes sense as an analyzer warning where the user > *chooses* to look for pessimistic scenarios and is more tolerant of noisy > heuristics. Right now -fanalyzer enables all of the various -Wanalyzer-* warnings by default [1], and in theory all of them only emit a diagnostic for the case when the analyzer "thinks" there's a definite problem. There may be bugs in the analyzer, of course. I'm a bit wary of the above sentence, as it suggests that the analyzer should be the place to put noisy diagnostics. Looking at the GCC UX guidelines: https://gcc.gnu.org/onlinedocs/gccint/Guidelines-for-Diagnostics.html note "The user’s attention is important": if a diagnostic is too noisy, the user will either turn it off, or stop paying attention. The distinction I've been making for -fanalyzer is that -fanalyzer enables a more expensive (path-based) analysis of the user's code, and will slow down the user's compile-time, with various warnings tied to that, i.e. I've been messaging it primarily as a compile-time tradeoff for extra warnings that otherwise would be too slow to implement, rather than a signal:noise ratio tradeoff. -fanalyzer can generate false positives, but I've been trying to drive that down via bugfixes (it's also relatively new code) [1] apart from -Wanalyzer-too-complex, but that's more of an implementation detail. > > > happens, rather than gratuitously removing warnings that we've added over > > the years, just because they fall short of the ideal 100% efficacy (as has > > been known and documented), making them easier to control seems like a > > better approach. > > It's not just a matter of efficacy here IMO. The heuristic for strnlen, > strncmp and strndup overreads is too loose for it to be taken seriously.
[Bug middle-end/104966] [11/12 Regression] Yet another bogus -Warray-bounds warning in libstdc++ headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966 --- Comment #5 from Richard Biener --- Ah, so we have this_42(D)->_M_positive_sign_size = 0; _62 = operator new [] (0); (possible EH) [local count: 268220751]: _6 = this_42(D)->_M_positive_sign_size; _192 = MEM[(long unsigned int *)&D.281666(address-taken) + 8B]; _188 = MIN_EXPR <_6, _192>; if (_188 != 0) goto ; [50.00%] and 'new' is now (after some "recent" fix) possibly clobbering this->_M_positive_sign_size. I suggest to save that to an automatic local, only loading it once as workaround.
[Bug middle-end/104966] [11/12 Regression] Yet another bogus -Warray-bounds warning in libstdc++ headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966 --- Comment #6 from Richard Biener --- (In reply to Richard Biener from comment #5) > and 'new' is now (after some "recent" fix) PR101480 > possibly clobbering this->_M_positive_sign_size.
[Bug middle-end/104966] [11/12 Regression] Yet another bogus -Warray-bounds warning in libstdc++ headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966 --- Comment #7 from Jonathan Wakely --- N.B. with no warning options the test fails with -Wstringop-overflow warnings (enabled by default) and with -Wall the same exact same line of correct code gives -Warray-bounds warnings. So I need to disable *both* to stop a bogus warning on that one line.
[Bug middle-end/99578] [11/12 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
--- Comment #35 from Jakub Jelinek ---
Created attachment 52643
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52643&action=edit
gcc12-pr99578-wip.patch
What we could do is differentiate between the invalid constant addresses
from pointer arithmetics on NULL or propagation of NULL into &ptr->field
and valid (type *)constant used heavily in real-world code and accepted by all
major compilers by representing the former internally as
&MEM_REF[(void *)0B + offset] while the user (type *)constant as INTEGER_CSTs.
That in full seems like a stage1 task because we'd need to ensure we don't
regress much by doing that. Some things would be unavoidable (like avoiding
SCCVN of those pointer INTEGER_CSTs vs. the &MEM_REF[(void *)0B + offset]
form),
e.g. equality comparison of &MEM_REF[(void *)0B + CST] vs. (void *)CST should
be
optimized etc., and we would need to force that form even on say (int *)0 + 24
etc. in the FEs.
But we badly need to fix this for GCC 12 and backport to GCC 11.
So this WIP patch treats addresses in the first page (a param defaulting to
4KB)
temporarily as emitting the warnings as before in GCC 11/12, and only creates
the &MEM_REF[(void *)0B + offset] form for larger offsets which will make them
very rare.
Some further tweaks will be needed on the gimple-array-bounds* etc. side so
that
we treat those &MEM_REF[(void *)0B + offset] as equivalent to the GCC 11 up to
current trunk handling of (void *)offset, so that say on:
struct S { int a, b[4]; };
struct T { int a, b[8192], c[4]; };
void
foo (struct S *p)
{
if (p) return;
__builtin_memset (p->b, 0, sizeof p->b);
}
void
bar (struct T *p)
{
if (p) return;
__builtin_memset (p->c, 0, sizeof p->c);
}
one gets the same warnings rather than different.
On IRC Richi suggested just the params.opt and pointer-query.cc
(compute_objsize_r) hunks which would only warn above in foo and not in bar.
[Bug middle-end/104965] [11/12 Regression] Yet another -Warray-bounds false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104965 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.3 --- Comment #1 from Richard Biener --- Likely a similar issue as PR104966, avoid relying on memory CSE across a call to 'new'.
[Bug target/104952] [nvptx][OpenMP] wrong code with OR / AND reduction ('reduction(||:' and '&&') with SIMT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952
--- Comment #4 from Tom de Vries ---
This fixes it:
...
diff --git a/gcc/omp-low.cc b/gcc/omp-low.cc
index d932d74cb03..f2ac8f98e32 100644
--- a/gcc/omp-low.cc
+++ b/gcc/omp-low.cc
@@ -6734,7 +6734,21 @@ lower_rec_input_clauses (tree clauses, gimple_seq
*ilist, gimpl
e_seq *dlist,
x = build_call_expr_internal_loc
(UNKNOWN_LOCATION, IFN_GOMP_SIMT_XCHG_BFLY,
TREE_TYPE (ivar), 2, ivar, simt_lane);
- x = build2 (code, TREE_TYPE (ivar), ivar, x);
+ /* Make sure x is evaluated unconditionally. */
+ enum tree_code update_code;
+ switch (OMP_CLAUSE_REDUCTION_CODE (c))
+ {
+ case TRUTH_ANDIF_EXPR:
+ update_code = TRUTH_AND_EXPR;
+ break;
+ case TRUTH_ORIF_EXPR:
+ update_code = TRUTH_OR_EXPR;
+ break;
+ default:
+ update_code = code;
+ break;
+ }
+ x = build2 (update_code, TREE_TYPE (ivar), ivar, x);
gimplify_assign (ivar, x, &llist[2]);
}
tree ivar2 = ivar;
...
[Bug middle-end/104966] [11/12 Regression] Yet another bogus -Warray-bounds warning in libstdc++ headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.3
[Bug target/104952] [nvptx][OpenMP] wrong code with OR / AND reduction ('reduction(||:' and '&&') with SIMT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952
--- Comment #5 from Jakub Jelinek ---
Note, I guess this is related to PR94366 and r12-438-g1580fc764423bf89e9b which
was fixing it for non-SIMT and quite possibly left out the SIMT stuff out.
Using the TRUTH_{AND,OR}_EXPR instead of TRUTH_{AND,OR}IF_EXPR ought to be
fine,
it is only merging the private vars into the original var, so neither has
really side-effects, all we want is that we are actually merging orig = (orig
!= 0) & (private != 0) rather than orig & private etc.
[Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943 --- Comment #49 from Andrew Macleod --- Let me clean it up a little and I'll post it.
[Bug target/104952] [nvptx][OpenMP] wrong code with OR / AND reduction ('reduction(||:' and '&&') with SIMT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952
--- Comment #6 from Jakub Jelinek ---
And yes, #c1 is valid. But would be nice to have similar test with && and
initial result = 2; and arr[] say { 1, 2, 3, 4, 5, 6, 7, ..., 32 } and test
result is 1 at the end to make sure we don't actually do just
orig = orig & (private != 0)
style merging or even just
orig = orig & private;
[Bug target/104952] [nvptx][OpenMP] wrong code with OR / AND reduction ('reduction(||:' and '&&') with SIMT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952 --- Comment #7 from Tom de Vries --- Alternative fix that doesn't require fiddling with the 'code' var: ... diff --git a/gcc/omp-low.cc b/gcc/omp-low.cc index d932d74cb03..d0ddd4a6142 100644 --- a/gcc/omp-low.cc +++ b/gcc/omp-low.cc @@ -6734,7 +6734,10 @@ lower_rec_input_clauses (tree clauses, gimple_seq *ilist, gimpl e_seq *dlist, x = build_call_expr_internal_loc (UNKNOWN_LOCATION, IFN_GOMP_SIMT_XCHG_BFLY, TREE_TYPE (ivar), 2, ivar, simt_lane); - x = build2 (code, TREE_TYPE (ivar), ivar, x); + /* Make sure x is evaluated unconditionally. */ + tree bfly_var = create_tmp_var (TREE_TYPE (ivar)); + gimplify_assign (bfly_var, x, &llist[2]); + x = build2 (code, TREE_TYPE (ivar), ivar, bfly_var); gimplify_assign (ivar, x, &llist[2]); } tree ivar2 = ivar; ...
[Bug target/104952] [nvptx][OpenMP] wrong code with OR / AND reduction ('reduction(||:' and '&&') with SIMT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952
--- Comment #8 from Tom de Vries ---
(In reply to Jakub Jelinek from comment #6)
> And yes, #c1 is valid.
Thanks for confirming.
> But would be nice to have similar test with && and
> initial result = 2; and arr[] say { 1, 2, 3, 4, 5, 6, 7, ..., 32 } and test
> result is 1 at the end to make sure we don't actually do just
> orig = orig & (private != 0)
> style merging or even just
> orig = orig & private;
Ack, will add that.
[Bug tree-optimization/104931] [9/10/11 Regression] wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931 --- Comment #7 from Richard Biener --- Created attachment 52644 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52644&action=edit GIMPLE testcase This is a GIMPLE testcase created from the cddce2 IL of the respective ltrans unit from trunk with the match.pd hunk reverted. It does not exhibit the bug. The reason is likely different pre-caching in SCEV and/or niter estimates.
[Bug tree-optimization/104931] [9/10/11 Regression] wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931 --- Comment #8 from Richard Biener --- Created attachment 52645 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52645&action=edit ivcanon dump as seen from LTO (with bug)
[Bug middle-end/104965] [11/12 Regression] Yet another -Warray-bounds false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104965 --- Comment #2 from Jonathan Wakely --- In this case s.size() reads a local variable that can't be altered by new.
[Bug target/104968] New: [nvptx][OpenMP] SIGSEGV / ICE in final_scan_insn_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104968
Bug ID: 104968
Summary: [nvptx][OpenMP] SIGSEGV / ICE in final_scan_insn_1
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: vries at gcc dot gnu.org
Target Milestone: ---
Target: nvptx-none
* Testcase is
https://github.com/clang-ykt/omptests/blob/master/t-taskloopsimd/test.c
* Reduced testcase: see below.
In either case:
* When compiled with -fopenmp -O1, it fails as follows. With -O0, it works.
This seems to be a REGRESSION:
* it PASSES on OG11 (devel/omp/gcc-11) branch
(which should have no local patches in this area)
* it fails on mainline/GCC 12
With our approx. bi-nightly tester, I see PASS, an intermittend fail on
2022-01-11,
then PASS until 2022-02-20 and FAIL since 2022-02-22.
In that time range, I see the following commit (but it might also be
caused/exposed by another commit):
commit g:5ed77fb3ed1ee0289a0ec9499ef52b99b39421f1
CommitDate: Tue Feb 22 15:48:03 2022 +0100
[libgomp, nvptx] Fix hang in gomp_team_barrier_wait_end
commit g:c2b23aaaf4457278403c01cd145cd3936683384e
CommitDate: Tue Feb 22 14:51:59 2022 +0100
[nvptx] Add -mptx-comment
commit g:02aedc6f269b5e3c1f354edcf5b84d27b0a15946
CommitDate: Mon Feb 21 16:49:37 2022 +0100
[nvptx] Initialize ptx regs
commit 69cb3f2abb911acebfc7ffede2ee7151a3e14a59
CommitDate: Sat Feb 19 20:05:56 2022 +0100
[nvptx] Use _ as destination operand of atom.exch
Program received signal SIGSEGV, Segmentation fault.
final_scan_insn_1 (insn=0x7743ecc0, file=,
seen=0x7fffddbc, nopeepholes=, optimize_p=)
at gcc-mainline/gcc/final.cc:2648
2648if (*loc.file && loc.line)
(gdb) bt
#0 final_scan_insn_1 (insn=0x7743ecc0, file=,
seen=0x7fffddbc, nopeepholes=, optimize_p=)
at gcc-mainline/gcc/final.cc:2648
#1 0x0087eeac in final_scan_insn (insn=,
file=, optimize_p=, nopeepholes=,
seen=)
at gcc-mainline/gcc/final.cc:2940
#2 0x0087efc6 in final_1 (first=0x7742b460, file=0x21c59e0,
seen=1, optimize_p=1) at gcc-mainline/gcc/final.cc:1997
#3 0x0087ffe5 in rest_of_handle_final () at
gcc-mainline/gcc/final.cc:4285
#4 (anonymous namespace)::pass_final::execute (this=) at
gcc-mainline/gcc/final.cc:4363
#5 0x00b97a2b in execute_one_pass (pass=pass@entry=0x21eeca0) at
gcc-mainline/gcc/passes.cc:2637
#6 0x00b98398 in execute_pass_list_1 (pass=0x21eeca0) at
gcc/passes.cc:2737
#7 0x00b983aa in execute_pass_list_1 (pass=0x21ee7c0) at
gcc/passes.cc:2738
#8 0x00b983aa in execute_pass_list_1 (pass=0x21eccc0) at
gcc/passes.cc:2738
#9 0x00b983f5 in execute_pass_list (fn=,
pass=) at gcc-mainline/gcc/passes.cc:2748
#10 0x0076423d in cgraph_node::expand (this=0x773f7550) at
gcc-mainline/gcc/cgraphunit.cc:1834
#11 0x0076599d in expand_all_functions () at
gcc-mainline/gcc/cgraphunit.cc:1998
Doing in the debugger 'up', 'up' (as isns are optimized out) and then the
following:
(gdb) p debug_rtx(insn)
(insn 113 115 112 14 (asm_input ("// Start: Added by -minit-regs=3:")) -1
(nil))
Reduced testcase
int main()
{
double a[10], a_h[10];
int myId = -1;
#pragma omp target map(tofrom:a)
#pragma omp taskloop simd shared(a) lastprivate(myId)
for(int i = 0 ; i < 10; i++) if (a[i] != a_h[i]) { }
}
[Bug tree-optimization/104931] [9/10/11 Regression] wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931 --- Comment #9 from Richard Biener --- Created attachment 52646 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52646&action=edit ivcanon dump from the GIMPLE testcase (without bug) The difference is that with LTO we have expanded expressions to Analyzing # of iterations of loop 1 exit condition [(struct TValue *) (_2 + 4294967272) + 12, + , 24](no_overflow) < _2 + 4294967272 while with the GIMPLE testcase we immediately get to Statement (exit)if (from_26 < to_27) is executed at most 0 (bounded by 0) + 1 times in loop 1. ... Loop 1 iterates 0 times. Note the GIMPLE FE doesn't yet support parsing CLOBBER stmts (but I'm quite sure this doesn't matter here) and for the loops() support you need to commit a pending patch.
[Bug driver/13071] no easy way to exclude backward C++ headers from include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13071 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED Target Milestone|--- |4.3.0 --- Comment #11 from Jonathan Wakely --- [using.headers] says you can't include a header inside a declaration or definition. A linkage specification is a declaration in terms of the C++ grammar, but I'm not sure that's what [using.headers] means. It doesn't actually declare anything. I'll open an LWG issue to get clarification. Anyway, let's close this.
[Bug c/104937] wrong code with _Complex division and -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104937 --- Comment #6 from Jakub Jelinek --- What we could for _Complex int just use the standard (a + b*i) / (c + d*i) = (a*c + b*d) / (c*c + d*d) + ((b*c - a*d) / (c*c + d*d))*i which would be 6 multiplications and 2 divisions instead of the current 3 multiplications and 3 divisions. But in order to avoid overflows we'd need to do that all in bigger precision. c*c + d*d for _Complex int is in [0, LONG_LONG_MAX+1ULL] range, a*c+b*d in [-LONG_LONG_MAX+2*INT_MAX+2, LONG_LONG_MAX+1ULL] range etc., so perhaps with some special cases we fit into 2*prec type. For _Complex unsigned we'd also need to watch for b*c being smaller than a*d and handle that by doing - ((a*d - b*c) / (c*c + d*d)) instead.
[Bug tree-optimization/104969] New: Likely a false positive of -D_FORTIFY_SOURCE=3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104969
Bug ID: 104969
Summary: Likely a false positive of -D_FORTIFY_SOURCE=3
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: siddhesh at gcc dot gnu.org
Target Milestone: ---
It's isolated from sratom package:
$ cat sratom.c
#include
#include
#include
int size = 3;
unsigned char data = 0xff;
int main()
{
unsigned len = size * 2 + 1;
char * str = __builtin_calloc(len, 1);
for (uint32_t i = 0; i < size; ++i) {
fprintf (stderr, "i=%i\n", i);
snprintf((char*)str + (2 * i), len, "%02X", data);
}
fprintf (stderr, "R=%s\n", str);
}
$ gcc sratom.c -O2 -D_FORTIFY_SOURCE=3 && ./a.out
i=0
i=1
*** buffer overflow detected ***: terminated
Aborted (core dumped)
$ clang sratom.c -O2 -D_FORTIFY_SOURCE=3 && ./a.out
i=0
i=1
*** buffer overflow detected ***: terminated
Aborted (core dumped)
$ gcc-11 sratom.c -g -O2 -fsanitize=address,undefined && ./a.out
i=0
i=1
i=2
R=FF
The original code is defective a bit as it wrongly assumes that
(char*)str + (2 * i) is at maximum 'len' big. It's actually len - (2 * i) big.
But it should be still valid code, am I right?
[Bug tree-optimization/104969] Likely a false positive of -D_FORTIFY_SOURCE=3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104969 Martin Liška changed: What|Removed |Added Target Milestone|--- |12.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-03-17
[Bug target/104952] [nvptx][OpenMP] wrong code with OR / AND reduction ('reduction(||:' and '&&') with SIMT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952 --- Comment #9 from Tom de Vries --- Created attachment 52647 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52647&action=edit Tentative patch with test-cases, rationale and changelog I'll put this through testing, and submit if no problems found.
[Bug target/104952] [nvptx][OpenMP] wrong code with OR / AND reduction ('reduction(||:' and '&&') with SIMT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952 --- Comment #10 from Jakub Jelinek --- Comment on attachment 52647 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52647 Tentative patch with test-cases, rationale and changelog Please change arr[5] = 1; to arr[5] = 42; or so also to test it is doing != 0 comparisons.
[Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943 --- Comment #50 from hubicka at kam dot mff.cuni.cz --- > It helps quite a bit, the worst case is now > > tree VRP : 5.14 ( 7%) 0.02 ( 3%) 5.15 ( > 7%) >2 > 9M ( 3%) > backwards jump threading : 4.05 ( 6%) 0.00 ( 0%) 4.06 ( > 6%) > 222 > 0k ( 0%) > > overall the patch reduces compile time from 766s to 749 (parallel compile, > serial LTO, release checking). So IMHO definitely worth it if you are happy > with it. This looks really promising. Does it also solve the situation with --param param_inline_functions_called_once_insns=100 I will benchmark how copmile time now behaves with respect increasing this bound. Honza
[Bug target/104968] [nvptx][OpenMP] SIGSEGV / ICE in final_scan_insn_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104968 --- Comment #1 from Tom de Vries --- Can't reproduce. It this not fixed by: ... commit 7862f6ccd85a001e4d70abb00bb95d8c7846ba80 Author: Tom de Vries Date: Wed Feb 23 09:33:33 2022 +0100 [nvptx] Fix dummy location in gen_comment ... ?
[Bug lto/102426] [12 regression] Fix for PR 49664 breaks Solaris bootstrap with gld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102426 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- So, shouldn't we instead of the -export-symbols-regex use a version script? We have it in multiple lib* directories, so presumably it should work reliably. Say the version script in libssp/ is quite simple, small configure.ac hunk, small Makefile.am hunk, small version script.
[Bug tree-optimization/104969] Likely a false positive of -D_FORTIFY_SOURCE=3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104969 --- Comment #1 from Andreas Schwab --- Passing a max len bigger than the available space is already an error. The whole point of snprintf is to never overflow no matter how large the output.
[Bug tree-optimization/104931] [9/10/11 Regression] wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931 --- Comment #10 from Richard Biener --- The bug also shows in a -flto-partition=max build where the offending function ends up in ltrans unit 23 (and only this function) which might enable side-by-side debugging if desired.
[Bug target/104968] [nvptx][OpenMP] SIGSEGV / ICE in final_scan_insn_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104968 --- Comment #2 from Tom de Vries --- (In reply to Tom de Vries from comment #1) > Can't reproduce. > > It this not fixed by: > ... > commit 7862f6ccd85a001e4d70abb00bb95d8c7846ba80 > Author: Tom de Vries > Date: Wed Feb 23 09:33:33 2022 +0100 > > [nvptx] Fix dummy location in gen_comment > ... > ? Hmm, wait, of course I have a patch in my stack that's pending for upstream. Let me undo that one and retry.
[Bug target/104968] [nvptx][OpenMP] SIGSEGV / ICE in final_scan_insn_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104968 --- Comment #3 from Tom de Vries --- (In reply to Tom de Vries from comment #2) > (In reply to Tom de Vries from comment #1) > > Can't reproduce. > > > > It this not fixed by: > > ... > > commit 7862f6ccd85a001e4d70abb00bb95d8c7846ba80 > > Author: Tom de Vries > > Date: Wed Feb 23 09:33:33 2022 +0100 > > > > [nvptx] Fix dummy location in gen_comment > > ... > > ? > > Hmm, wait, of course I have a patch in my stack that's pending for upstream. > Let me undo that one and retry. Ack, reproduced.
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772 --- Comment #8 from Jakub Jelinek --- Does libgomp.fortran/pointer2.f90 still FAIL?
[Bug target/104968] [nvptx][OpenMP] SIGSEGV / ICE in final_scan_insn_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104968 --- Comment #4 from Tom de Vries --- This ( https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591912.html ) proposed patch fixes this ICE, pinged again.
[Bug target/94680] Missed optimization with __builtin_shuffle and zero vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94680 Roger Sayle changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED CC||roger at nextmovesoftware dot com Status|NEW |RESOLVED --- Comment #7 from Roger Sayle --- This has been fixed since Hongtao's patch last year. But the single remaining case has now been fully optimized with: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=732e4a75fe792182f171bba348a665e8b8d21176 https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591788.html
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772 --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #8 from Jakub Jelinek --- > Does libgomp.fortran/pointer2.f90 still FAIL? It does.
[Bug c/98198] [11/12 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in decl_or_type_attrs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98198 Roger Sayle changed: What|Removed |Added Target Milestone|11.3|12.0 CC||roger at nextmovesoftware dot com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Roger Sayle --- This has now been fixed on mainline.
[Bug tree-optimization/104970] New: ICE in execute_todo, at passes.cc:2133 since r12-6480-gea19c8f33a3a8d2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
Bug ID: 104970
Summary: ICE in execute_todo, at passes.cc:2133 since
r12-6480-gea19c8f33a3a8d2b
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: siddhesh at gcc dot gnu.org
Target Milestone: ---
The following is reduced from libmsym package:
$ cat linalg.i
__inline void
memset2(void *__dest, int __ch, long __len) {
long __trans_tmp_1 = __builtin_dynamic_object_size(__dest, 0);
__builtin___memset_chk(__dest, __ch, __len, __trans_tmp_1);
}
void
mleye(int l, double E[][l]) { memset2(E, 0, sizeof(double)); }
$ gcc linalg.i -c -D_FORTIFY_SOURCE=2 -O
during GIMPLE pass: objsz
linalg.i: In function ‘mleye’:
linalg.i:8:1: internal compiler error: in execute_todo, at passes.cc:2133
8 | mleye(int l, double E[][l]) { memset2(E, 0, sizeof(double)); }
| ^
0x75edfa execute_todo
/home/marxin/Programming/gcc/gcc/passes.cc:2133
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/104970] ICE in execute_todo, at passes.cc:2133 since r12-6480-gea19c8f33a3a8d2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970 Martin Liška changed: What|Removed |Added Priority|P3 |P1 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-03-17 Target Milestone|--- |12.0
[Bug middle-end/104965] [11/12 Regression] Yet another -Warray-bounds false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104965
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #3 from Martin Sebor ---
It looks like an escape analysis limitation. With this simpler test case using
different types to rule out aliasing assumptions:
#include
int main()
{
std::basic_string s;
auto p = new int[s.size ()]{ };
char c = 0;
if (s.size())
c = *p;
delete[] p;
return c;
}
pr104965.C:9:9: warning: array subscript 0 is outside array bounds of ‘void
[0]’ [-Warray-bounds]
9 | c = *p;
| ^~
pr104965.C:6:34: note: object of size 0 allocated by ‘operator new []’
6 | auto p = new short[s.size ()]{ };
| ^
One of the stores to the local s escapes its address which is then assumed to
have been clobbered by operator new:
[local count: 1073741824]:
s ={v} {CLOBBER};
MEM[(struct _Alloc_hider *)&s] ={v} {CLOBBER};
MEM[(struct _Alloc_hider *)&s]._M_p = &s.D.33279._M_local_buf;
s._M_string_length = 0;
MEM[(char_type &)&s + 16] = 0;
_5 = operator new [] (0);
[local count: 1073741824]:
_10 = s._M_string_length;
if (_10 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
_1 = MEM[(int *)_5];
c_6 = (char) _1;
[Bug rtl-optimization/104961] [9/10/11/12 Regression] compilation never (?) finishes at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104961 --- Comment #2 from Vladimir Makarov --- I've reproduced the bug. The mentioned patch is not the cause but a trigger. The origin of the problem is actually a removal of hard reg propagation before RA which happened about year ago. I hope the fix will be ready on Friday or Monday.
[Bug fortran/103039] [12 Regression] Segfault with openmp block within a select type block since r12-1016-g0e3b3b77e13cac76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039 --- Comment #6 from Jakub Jelinek --- unshare_expr doesn't do anything wrong. The problem is that because of the select we have firstprivate(__tmp_class_a) clause where __tmp_class_a has type which has struct __class_seltype_A_p * type. Before the r12-1016 change, we clearly firstprivatized that var because gfc_omp_clause_copy_ctor just did: return build2_v (MODIFY_EXPR, dest, src); for that case, so emitted: D.4011 = .omp_data_i->__tmp_class_a; __tmp_class_a = D.4011; which essentially means that the __tmp_class_a var (the pointer) was privatized, but what it points to was shared. Now, since r12-1016 it copies various elements the pointer points to from what the source pointer points to to what the destination pointer points to. But we don't really initialize what dest points to first. I bet we want to privatize what the pointer points to, so we need to emit something like: __class_seltype_A_p temp; __tmp_class_a = &temp; __tmp_class_a->vptr = .omp_data_i->__tmp_class_a->vptr; etc. (not gimplified form). I think the way to achieve this would be make sure to return true from the gfc_omp_privatize_by_reference hook. Tobias, can you please have a look?
[Bug tree-optimization/104969] Likely a false positive of -D_FORTIFY_SOURCE=3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104969 --- Comment #2 from Siddhesh Poyarekar --- (In reply to Martin Liška from comment #0) > The original code is defective a bit as it wrongly assumes that > (char*)str + (2 * i) is at maximum 'len' big. It's actually len - (2 * i) > big. But it should be still valid code, am I right? It doesn't overflow in this case, but specifying a length larger than the actual buffer size is a standard violation. """ The snprintf() function shall be equivalent to sprintf(), with the addition of the n argument which states the size of the buffer referred to by s. If n is zero, nothing shall be written and s may be a null pointer. Otherwise, output bytes beyond the n-1st shall be discarded instead of being written to the array, and a null byte is written at the end of the bytes actually written into the array. """ https://pubs.opengroup.org/onlinepubs/9699919799/functions/snprintf.html
[Bug tree-optimization/104970] ICE in execute_todo, at passes.cc:2133 since r12-6480-gea19c8f33a3a8d2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970 Siddhesh Poyarekar changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #1 from Siddhesh Poyarekar --- Looks like a codegen issue with parm_object_size; it's referring to a non-existent SSA name. I'll take a look at it first thing on Tuesday.
[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1d47c0512a265d4bb3ab9e56259fd1e4f4d42c75 commit r12-7689-g1d47c0512a265d4bb3ab9e56259fd1e4f4d42c75 Author: Jakub Jelinek Date: Thu Mar 17 18:49:00 2022 +0100 libatomic: Improve 16-byte atomics on Intel AVX [PR104688] As mentioned in the PR, the latest Intel SDM has added: "Processors that enumerate support for Intel® AVX (by setting the feature flag CPUID.01H:ECX.AVX[bit 28]) guarantee that the 16-byte memory operations performed by the following instructions will always be carried out atomically: ⢠MOVAPD, MOVAPS, and MOVDQA. ⢠VMOVAPD, VMOVAPS, and VMOVDQA when encoded with VEX.128. ⢠VMOVAPD, VMOVAPS, VMOVDQA32, and VMOVDQA64 when encoded with EVEX.128 and k0 (masking disabled). (Note that these instructions require the linear addresses of their memory operands to be 16-byte aligned.)" The following patch deals with it just on the libatomic library side so far, currently (since ~ 2017) we emit all the __atomic_* 16-byte builtins as library calls since and this is something that we can hopefully backport. The patch simply introduces yet another ifunc variant that takes priority over the pure CMPXCHG16B one, one that checks AVX and CMPXCHG16B bits and on non-Intel clears the AVX bit during detection for now (if AMD comes with the same guarantee, we could revert the config/x86/init.c hunk), which implements 16-byte atomic load as vmovdqa and 16-byte atomic store as vmovdqa followed by mfence. 2022-03-17 Jakub Jelinek PR target/104688 * Makefile.am (IFUNC_OPTIONS): Change on x86_64 to -mcx16 -mcx16. (libatomic_la_LIBADD): Add $(addsuffix _16_2_.lo,$(SIZEOBJS)) for x86_64. * Makefile.in: Regenerated. * config/x86/host-config.h (IFUNC_COND_1): For x86_64 define to both AVX and CMPXCHG16B bits. (IFUNC_COND_2): Define. (IFUNC_NCOND): For x86_64 define to 2 * (N == 16). (MAYBE_HAVE_ATOMIC_CAS_16, MAYBE_HAVE_ATOMIC_EXCHANGE_16, MAYBE_HAVE_ATOMIC_LDST_16): Define to IFUNC_COND_2 rather than IFUNC_COND_1. (HAVE_ATOMIC_CAS_16): Redefine to 1 whenever IFUNC_ALT != 0. (HAVE_ATOMIC_LDST_16): Redefine to 1 whenever IFUNC_ALT == 1. (atomic_compare_exchange_n): Define whenever IFUNC_ALT != 0 on x86_64 for N == 16. (__atomic_load_n, __atomic_store_n): Redefine whenever IFUNC_ALT == 1 on x86_64 for N == 16. (atomic_load_n, atomic_store_n): New functions. * config/x86/init.c (__libat_feat1_init): On x86_64 clear bit_AVX if CPU vendor is not Intel.
[Bug middle-end/104966] [11/12 Regression] Yet another bogus -Warray-bounds warning in libstdc++ headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966 --- Comment #8 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:38ce4489635f2d65de965af3ec5d5c4adf7762d9 commit r12-7690-g38ce4489635f2d65de965af3ec5d5c4adf7762d9 Author: Jonathan Wakely Date: Thu Mar 17 13:33:07 2022 + libstdc++: Rewrite __moneypunct_cache::_M_cache [PR104966] GCC thinks the following can lead to a buffer overflow when __ns.size() equals zero: const basic_string<_CharT>& __ns = __mp.negative_sign(); _M_negative_sign_size = __ns.size(); __negative_sign = new _CharT[_M_negative_sign_size]; __ns.copy(__negative_sign, _M_negative_sign_size); This happens because operator new might be replaced with something that writes to this->_M_negative_sign_size and so the basic_string::copy call could use a non-zero size to write to a zero-length buffer. The solution suggested by Richi is to cache the size in a local variable so that the compiler knows it won't be changed between the allocation and the copy. This commit goes further and rewrites the whole function to use RAII and delay all modifications of *this until after all allocations have succeeded. The RAII helper type caches the size and copies the string and owns the memory until told to release it. libstdc++-v3/ChangeLog: PR middle-end/104966 * include/bits/locale_facets_nonio.tcc (__moneypunct_cache::_M_cache): Replace try-catch with RAII and make all string copies before any stores to *this.
[Bug libstdc++/92546] Large increase in preprocessed file sizes in C++2a mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546 --- Comment #26 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:00df7ee4474faca91d3460fe78a88e280c6c1126 commit r12-7691-g00df7ee4474faca91d3460fe78a88e280c6c1126 Author: Jonathan Wakely Date: Thu Mar 17 14:36:07 2022 + libstdc++: Avoid including in [PR92546] This only affects Windows, but reduces the preprocessed size of significantly. libstdc++-v3/ChangeLog: PR libstdc++/92546 * include/bits/fs_path.h (path::make_preferred): Use handwritten loop instead of std::replace.
[Bug middle-end/104971] New: Optimisation for __builtin_ia32_readeflags corrupts the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104971
Bug ID: 104971
Summary: Optimisation for __builtin_ia32_readeflags corrupts
the stack
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: andrew.cooper3 at citrix dot com
Target Milestone: ---
Full example: https://godbolt.org/z/xGq3c4Mnc
Given:
int broken(void)
{
int fl = __builtin_ia32_readeflags_u64();
}
gcc -O2 generates:
broken:
pushfq
ret
Which is going explode very quickly.
Code generation appears to be safe without optimisation, but even -O alone is
enough to create problems.
At a guess, the optimiser has concluded that the result is unused, drops the
`pop %reg`, but fails to also drop the `pushf` too.
Looking through history on Godbolt, it appears that GCC 4.9 (which introduced
this builtin) has correct optimised code generation, and it regressed between
4.9 and 5.1.
[Bug middle-end/104971] [9/10/11/12 Regression] Optimisation for __builtin_ia32_readeflags corrupts the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104971 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |9.5 Summary|Optimisation for|[9/10/11/12 Regression] |__builtin_ia32_readeflags |Optimisation for |corrupts the stack |__builtin_ia32_readeflags ||corrupts the stack CC||jakub at gcc dot gnu.org Priority|P3 |P2 --- Comment #1 from Jakub Jelinek --- The builtin has been implemented in r0-127024-g9bbd48d120d203e8eade09e0bb830370b6d69801 and the pop is optimized away with pushf kept since r5-4951-g4ab74a01477d4089a3474d52479ed372c9b5ae29 so this is a regression from GCC 4.9.
[Bug lto/102426] [12 regression] Fix for PR 49664 breaks Solaris bootstrap with gld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102426 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #7 from Jakub Jelinek --- > So, shouldn't we instead of the -export-symbols-regex use a version script? We certainly could, but IIUC this would lose the functionality on non-ELF targets that do support -export-symbols-regex in a different way. No idea if this is deemed acceptable... > We have it in multiple lib* directories, so presumably it should work > reliably. > Say the version script in libssp/ is quite simple, small configure.ac hunk, > small Makefile.am hunk, small version script. We could even simplify the libssp example: given that we only want to export one single symbol, we don't need the make_sunver.pl magic, only the difference between -Wl,--version-script and -Wl,-M. Just in case you wonder, we still need that script for libssp on Solaris: mempcpy and thus __mempcpy_chk don't exist on Solaris, thus that symbol needs to be filtered from ssp.map. I long meant to unify all those instances of version script handling, but that turned out to be a terrible can of worms and is certainly not GCC 12 material.
[Bug tree-optimization/104969] Likely a false positive of -D_FORTIFY_SOURCE=3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104969 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- That's not the intended reading of the POSIX text. But (outside of extensions for behavior C leaves undefined) POSIX defers to C, so the authoritative text is there. C doesn't impose any requirement on the size argument. That said, specifying a snprintf size that's bigger than the space in the provided buffer is certainly asking for trouble, even more so than doing the same with strncmp. GCC should be enhanced to warn about that when possible (pr83430 tracks the request), although I suspect that wouldn't help in this case. For the constant subset of instances Clang issues warning: 'snprintf' size argument is too large; destination buffer has size 4, but size argument is 7 [-Wfortify-source].
[Bug lto/102426] [12 regression] Fix for PR 49664 breaks Solaris bootstrap with gld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102426
--- Comment #9 from Jakub Jelinek ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > --- Comment #7 from Jakub Jelinek ---
> > So, shouldn't we instead of the -export-symbols-regex use a version script?
>
> We certainly could, but IIUC this would lose the functionality on
> non-ELF targets that do support -export-symbols-regex in a different
> way. No idea if this is deemed acceptable...
The world doesn't end if other symbols are exported, it worked that way for
years.
Perhaps we could test in configure whether -export-symbols-regex works and only
use a fallback if it doesn't? Or decide it based on target triplet,
do those GNU and SUN version script checks and if neither of them works, fall
back to -export-symbols-regex ?
gld supports version scripts like:
{ global: onload; local: *; };
which makes onload a non-versioned GLOBAL symbol while everything else LOCAL,
does Sun ld support that too or similar?
[Bug tree-optimization/40635] [12 Regression] bogus name and location in 'may be used uninitialized' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635 Martin Sebor changed: What|Removed |Added Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #21 from Martin Sebor --- Deferring to Andrew per comment #19.
[Bug preprocessor/41540] -dM -E doesn't #define __FILE__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41540 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #6 from Martin Sebor --- No longer working on this.
[Bug c/67872] missing -Warray-bounds warning, bogus -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67872 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #5 from Martin Sebor --- I'm no longer working on this.
[Bug c++/70076] no exception for excess initializer elements in a multidimensional VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70076 Martin Sebor changed: What|Removed |Added Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #8 from Martin Sebor --- I'm no longer working on this.
[Bug c++/70588] SIGBUS on a VLA larger than SIZE_MAX / 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70588 Martin Sebor changed: What|Removed |Added Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #14 from Martin Sebor --- I'm no longer working on this.
[Bug tree-optimization/80420] missing -Wformat-overfow on snprintf with excessive bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80420 Martin Sebor changed: What|Removed |Added Blocks||85741 Status|ASSIGNED|NEW --- Comment #1 from Martin Sebor --- I'm no longer working on this. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741 [Bug 85741] [meta-bug] bogus/missing -Wformat-overflow
[Bug c++/83430] missing warning for specifying larger snprintf bound than destination size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83430 Martin Sebor changed: What|Removed |Added CC|msebor at gcc dot gnu.org | Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW Blocks||85741 --- Comment #3 from Martin Sebor --- I'm no longer working on this. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741 [Bug 85741] [meta-bug] bogus/missing -Wformat-overflow
[Bug c++/84318] [9/10/11/12 Regression] attribute deprecated on function templates different than class templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84318 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #9 from Martin Sebor --- I'm no longer working on this.
[Bug tree-optimization/84050] [9/10/11/12 Regression] missing -Warray-bounds accessing a struct array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84050 Martin Sebor changed: What|Removed |Added Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #12 from Martin Sebor --- I'm no longer working on this.
[Bug middle-end/104076] bogus -Wdangling-pointer on a conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104076 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #6 from Martin Sebor --- I'm no longer working on this.
[Bug middle-end/104069] -Werror=use-after-free false positive on elfutils-0.186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069 Martin Sebor changed: What|Removed |Added Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW CC|msebor at gcc dot gnu.org | --- Comment #22 from Martin Sebor --- I'm no longer working on this.
[Bug middle-end/101665] -fno-delete-null-pointer checks ineffective for attribute nonnull parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101665 Martin Sebor changed: What|Removed |Added Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #4 from Martin Sebor --- I'm no longer working on this.
[Bug middle-end/104971] [9/10/11/12 Regression] Optimisation for __builtin_ia32_readeflags corrupts the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104971
Jakub Jelinek changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Might be useful to drop the builtin on the floor during expansion if it doesn't
have lhs as an optimization (I think it is intentionally not const or pure
because it depends on any code that sets the flags; though it seems rather
poorly defined because we don't have any dependencies on the surrounding code,
but after all, user can't know what arithmetic instruction that modifies flags
we decide to use last before the builtin).
That said, LRA shouldn't optimize away instructions like:
(insn 6 5 0 2 (set (reg:DI 82)
(mem:DI (post_inc:DI (reg/f:DI 7 sp)) [0 S8 A8])) "pr104971.c":3:14 62
{*popdi1}
(expr_list:REG_UNUSED (reg:DI 82)
(nil)))
just because they are unused, because they have side-effects.
[Bug tree-optimization/99475] [10/11 Regression] bogus -Warray-bounds accessing an array element of empty structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99475 Martin Sebor changed: What|Removed |Added Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot gnu.org Summary|[10/11/12 Regression] bogus |[10/11 Regression] bogus |-Warray-bounds accessing an |-Warray-bounds accessing an |array element of empty |array element of empty |structs |structs Known to work||12.0 Status|ASSIGNED|NEW --- Comment #4 from Martin Sebor --- This has been fixed in GCC 12. I'm not planning to backport it.
[Bug c/99295] [9 Regression] documentation on __attribute__((malloc)) is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99295 Martin Sebor changed: What|Removed |Added Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|RESOLVED CC|msebor at gcc dot gnu.org | Resolution|--- |FIXED --- Comment #11 from Martin Sebor --- Fixed.
