[Bug debug/101669] error reading variable from debug information when compiling with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101669 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Version|11.0|11.1.1 Keywords||wrong-debug CC||jakub at gcc dot gnu.org Last reconfirmed||2021-07-29 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- gdb doesn't complain for me but readelf does: readelf: Warning: Location lists in .debug_loc section start at 0x10 readelf: Warning: Location list starting at offset 0x10 is not terminated. readelf: Warning: Hole and overlap detection requires adjacent view lists and loclists. readelf: Warning: Location list starting at offset 0x2b is not terminated. readelf: Warning: There is an overlap [0xe4 - 0x0] in .debug_loc section. it doesn't happen with -gdwarf-4. It also happens with GCC 9 and -gdwarf-5. With GCC 7 and -gdwarf-5 there are many more complaints from readelf.
[Bug tree-optimization/101668] BB vectorizer doesn't handle lowpart of existing vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101668 --- Comment #2 from Hongtao.liu --- > it looks like there's no V8SI->V8DI conversion optab or we choose V4DI > for some other reason as prefered vector mode. We have, just need to add -mprefer-vector-width=512, the we'll get bar_s32_s64: vpmovsxdq zmm0, ymm0 vmovdqa64 ZMMWORD PTR [rdi], zmm0 ret
[Bug c++/84583] -fdirectives-only does not handle CRLF properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84583 Boris Kolpackov changed: What|Removed |Added Component|preprocessor|c++ Version|7.2.0 |10.2.0 --- Comment #1 from Boris Kolpackov --- Still being bitten by this with GCC 10.2. Any translation unit that uses a line continuation in a string literal triggers this bug. A typical example: char copyright[] = "@(#) Copyright (c) 1990 The Regents of the University of California.\n\ All rights reserved.\n";
[Bug target/100952] [12 regression] several test case failures after r12-1202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952 --- Comment #10 from CVS Commits --- The master branch has been updated by HaoChen Gui : https://gcc.gnu.org/g:f0529d96f56758e56151f409c55bab3034163210 commit r12-2592-gf0529d96f56758e56151f409c55bab3034163210 Author: Haochen Gui Date: Thu Jul 29 14:56:12 2021 +0800 Fix failed test cases caused by disabling mode promotion for pseudos [PR100952] gcc/testsuite PR target/100952 * gcc.target/powerpc/pr56605.c: Change matching conditions. * gcc.target/powerpc/pr81348.c: Likewise.
[Bug fortran/101660] [12 Regression] FAIL: gfortran.dg/bind_c_array_params_3.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101660
Tobias Burnus changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
--- Comment #2 from Tobias Burnus ---
The problem is the patch set for PR 101305, which moved from a static
libgfortran/ISO_Fortran_binding.h
to a generated
$build/$arch/libgfortran/ISO_Fortran_binding.h
And in the include file:
-#include "../../../libgfortran/ISO_Fortran_binding.h"
+#include "ISO_Fortran_binding.h"
I am not quite sure whether that should be "..." or now "<...>".
Notes:
* When doing incremental builds, ISO_Fortran_binding.h was not build; I had to
delete $build/{*,*/*}/libgfortran/ (or $build to do a proper bootstrap)
to get it generated.
* Here, it does work in that case with in-build-tree testing, except that with
testing -m64 and -m32 at the same time, the wrong header is used,
cf. https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576194.html
It would be useful to know:
* whether you did an incremental build or not (cf. above)
* whether your are testing in build tree or with the installed compiler.
→ If the latter, does changing "ISO_Fortran_binding.h" to
help?
* Do you use RUNTESTFLAGS - in particular --target_board= to run multiple
archs at the
the same time (→ email above)
[Bug tree-optimization/100499] [9/10/11/12 Regression] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #34 from Eric Botcazou --- > The user I'm most worried about is stor-layout.c:place_field which > uses multiple_of_p to optimize DECL_OFFSET_ALIGN, where losing that > might have severe impact on Ada. Indeed, this might measurably impact dynamic offsets, which are very common in Ada (but they are never negative in record/union/qualified union types).
[Bug fortran/101660] [12 Regression] FAIL: gfortran.dg/bind_c_array_params_3.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101660 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I think it should be . Anyway, at least on Fedora it fails because we install the ISO_Fortran_binding.h header not to /usr/include but to /usr/lib/gcc///include/ISO_Fortran_binding.h and so when using xgcc -B ... the just built compiler can't use the system compiler's version, which IMHO is the only reason why it could succeed for Sandra or anyone else. We need an -I ... option that will point the compiler to the libgfortran build directory (and do so correctly for the current multilib).
[Bug tree-optimization/101641] Bogus redundant store removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101641 --- Comment #2 from Richard Biener --- And the DOM copy has been split out to refs_same_for_tbaa_p, now also used by RTL CSE and DSE (which do the same transform), see the fix for PR93946.
[Bug debug/101669] error reading variable from debug information when compiling with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101669 --- Comment #2 from Jiu Fu Guo --- Similar to what Richard said, tested with gdb, use -gdwarf-4 with trunk, the msg also disappears.
[Bug tree-optimization/101641] Bogus redundant store removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101641
--- Comment #3 from Richard Biener ---
With union punning we've basically opened up a way to change the dynamic type
of storage in a way that expects us from generating no code from a "virtual"
read-write cycle involving the previous and the next dynamic type of the
storage.
Now the checks we're currently performing try to assess whether such a
change takes place but given we don't really know the current dynamic type
we're guessing based on the "read" which constrains that dynamic type.
And we're willing to elide changes to a type that is strictly more
restrictive as to what followon accesses it allows.
What goes wrong here is our guessing of the current dynamic type based on
the observed read, that's because the read picks up *py but the reads
alias-set is not equal to or a subset of the *py stores alias-set (but
it conflicts since the subset relation is the other way around).
What we know from the union read is that the dynamic type is either the
union type (so the read can pun) or the dynamic type is the union member
type (then the read cannot pun). 6.5/7 allows accesses using
"an aggregate or union type that includes [a type compatible with the effective
type of the object]". Though the 'aggregate' case appears quite odd to me,
does it really allow 'int i; struct { float f; int i; } *p = &i; float x =
p->f;'? GCC doesn't allow this already based on the fact that sizeof (*p)
is larger than 'i', thus would even disallow it in case the 'f' member was
'int' as well.
[Bug tree-optimization/101641] Bogus redundant store removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101641 --- Comment #4 from Richard Biener --- Just some more brain-dumps from thinking about a fix. - we can annotate the alias_set_entry with a flag whether it was created for a union type and use that to improve the logic - we can introduce some dynamic-type change IL elements that would allow us to elide all those redundant stores but preserve their effect. They'd be modeled as stores but would generate no code. The stored value would be implicit so we can readily remove the load (or constant). An internal function call like we have for masked stores would be a possibility but those would be quite disruptive to passes compared to the load/store sequence, so preserving the original store but with a special RHS seems most logical (but we cannot use RHS == LHS as that's only valid GIMPLE for non-register-types). We'd also have to be careful to not treat those "stores" as kills which leans towards the IFN again. A fix along the first idea looks least intrusive for backporting. A fix along the second idea looks best for recovering lost redundant store removal.
[Bug libstdc++/101659] _GLIBCXX_DEBUG mode for std::optional ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101659 --- Comment #1 from Marc Glisse --- I already see some "__glibcxx_assert(this->_M_is_engaged());" in the code, which IIUC should be enabled by _GLIBCXX_ASSERTIONS (and a fortiori by _GLIBCXX_DEBUG). Did you actually try it?
[Bug objc/101616] Objective-C frontend should not emit vtable/fixup messages (at least, not by default)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101616 --- Comment #4 from Iain Sandoe --- (In reply to Matt Jacobson from comment #3) > As it happens, I'm targeting the NeXT v2 runtime, but I'm *not* actually > targeting Darwin. So `flag_next_runtime` is just 1 for me--not an OS > version value like 100600 (`USE_FIXUP_BEFORE` / SnowLeopard). (And I can't > fake it via arguments, AFAICT.) As I am sure you are aware - there is quite an amount of Mach-O-specific stuff baked into the NeXT implementation. However, for any system that supports named sections it would seem reasonable to be able to support it. Perhaps raise an 'emhancement' bug "Support NeXT runtime on system x" where x is the system you want to support. There are surely a number of changes that would be needed - and some that I've most likely already thought about already (e.g. when thinking about what would be needed to support ELF-based systems). > I wonder if it would be reasonable to add a separate flag to disable (or > enable) fixup messages, such that the default value of the flag is > controlled by `-mmacosx-version-min` when targeting Darwin. Darwin does three things - (a) for an invocation without 'mmacosx-version-min' it figures out the OS version from the kernel. (b) when the invocation includes mmacosx-version-min that overrides (c) MACOSX_DEPLOYMENT_TARGET is also consulted to determine the target version if there is no mmacosx-version-min. The fine detail is that the *actual* code-gen produced by clang varies (in a way that is incompatible with various versions of the linker) - so that we have to take account of this and make sure we emit a suitable version for the OS revision being targeted. There are enough bits spare in the int representing flag_next_runtime that we could arrange to have it indicate a non-Darwin implementation in some MSBs (and then have the LSBs represent something different). I suspect that this is just one of several changes that will be needed to code-gen (thus the suggestion to have a tracking PR) and we should not be adding more flags, but rather arranging to control the value of the next_runtime flag and use that to determine the code-gen we want.
[Bug debug/101669] error reading variable from debug information when compiling with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101669 --- Comment #3 from Jakub Jelinek --- This is weird. There is no .debug_loc section with DWARF 5 at all, only .debug_loclists. I don't see any complains from readelf: readelf --debug-dump=loc pr101669 >/dev/null (binutils 2.36.1). And no errors from gdb (10.2). So isn't this because of too old gdb or binutils?
[Bug middle-end/101671] New: pr83510 fails because threader confuses -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101671 Bug ID: 101671 Summary: pr83510 fails because threader confuses -Warray-bounds Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: aldyh at gcc dot gnu.org Target Milestone: --- After my rewrite of the backwards threader with the ranger (commit 2e96b5f14e4025691b57d2301d71aa6092ed44bc), gcc.c-torture/compile/pr83510.c is failing. Here's a quote from my analysis in the test itself: /* This test is XFAILed because thread1 threads a switch statement such that the various cases have been split into different independent blocks. One of these blocks exposes an arr[i_27] which is later propagated by VRP to be arr[10]. This is an invalid access, but the array bounds code doesn't know it is an unreachable path. However, it is not until dom2 that we "know" that the value of the switch index is such that the path to arr[10] is unreachable. For that matter, it is not until dom3 that we remove the unreachable path. See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83510 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83312 It's not until here that ranger "knows" that the path is unreachable: thread1 vrp1<-- array bounds checking dce2 stdarg cdce cselim copyprop ifcombine mergephi3 <-- too late */
[Bug d/101672] New: d: Allow use of classes without the runtime if they only contain static members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101672
Bug ID: 101672
Summary: d: Allow use of classes without the runtime if they
only contain static members
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
This should compile, but may not link and run properly without a thread-local
storage implementation.
---
interface I
{
static int i;
}
class A : I
{
static int a;
}
class B : A
{
static int b;
}
void main()
{
B.i = 32;
B.a = 42;
B.b = 52;
}
[Bug middle-end/101673] New: shorter unprofitable jump thread path inhibits threading of larger path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101673 Bug ID: 101673 Summary: shorter unprofitable jump thread path inhibits threading of larger path Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: aldyh at gcc dot gnu.org Target Milestone: --- This is tree-ssa/ranger-threader-5.c which is now failing after the rewrite of the backwards threader with a ranger based threader (commit 2e96b5f14e4025691b57d2301d71aa6092ed44bc). I am not sure this is worth fixing, but am adding a PR so we don't loose track of the regression. Here are my notes from the test: /* This tests that we can thread BB4->BB999 coming in through the following path: latch many insns | | V V 6 -> 7 -> 3 -> 4 -> 999 The ranger based threader cannot thread this because BB4 has too many instructions so it gives up looking back. However, if we were able to looking further, we would notice that a profitable path passing through the loop latch (BB7) exists. That is, 3->4->N in isolation is not profitable, but 6->7->3->4->N is. It is not clear whether handling this case in the backwards threader is profitable, as it would increase the search space considerably. The test is being added to note a regression from the old backward threader code. This test has been distilled from libphobos/src/std/net/isemail.d. The ranger threader stops at the 3->4 subpath with: "did not thread around loop and would copy too many statements". */
[Bug middle-end/101674] New: gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101674 Bug ID: 101674 Summary: gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: aldyh at gcc dot gnu.org Target Milestone: --- The ranger-based jump threader (commit 2e96b5f14e4025691b57d2301d71aa6092ed44bc) shuffles things around in such a way as to confuse the -Wuninitialized pass.
[Bug middle-end/101675] New: analyzer/pr94851-2.c marked XFAIL because it fails with new jump threader
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101675
Bug ID: 101675
Summary: analyzer/pr94851-2.c marked XFAIL because it fails
with new jump threader
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: aldyh at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
Target Milestone: ---
By *.033t.forwprop1, we have the following:
:
# p_9 = PHI
# last_11 = PHI
if (p_9 != 0B)
goto ; [INV]
else
goto ; [INV]
:
_3 = p_9->m_name;
_4 = (char) c_20;
if (_3 != _4)
goto ; [INV]
else
goto ; [INV]
:
if (p_9 != 0B)
goto ; [INV]
else
goto ; [INV]
:
printf ("over writing mark %c\n", c_20);
goto ; [INV]
:
p_24 = malloc (16);
if (p_24 == 0B)
goto ; [INV]
else
goto ; [INV]
After the jump threader rewrite (commit
2e96b5f14e4025691b57d2301d71aa6092ed44bc), we thread the 4->6->8 path in the
early threader pass:
Registering FSM jump thread: (4, 6) incoming edge; (6, 8) nocopy; (6, 8)
This causes the false edge on the first conditional to jump directly to BB8.
Presumably this is confusing the analyzer, which is no longer warning here:
if (curbp->b_amark == (AMARK *)NULL)
curbp->b_amark = p;
else
last->m_next = p; /* { dg-warning "dereference of NULL 'last'" "deref" {
xfail *-*-* } } */
[Bug target/101609] no right shift pattern for vector(2) long long on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101609 --- Comment #3 from Tejas Belagod --- > .. but still doesn't generate 'vector code' for the example shown here. Actually, it does. I was looking in the wrong place.
[Bug tree-optimization/101667] GNAT bug detected in op1_range in range-op.cc during GIMPLE pass evrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101667 --- Comment #2 from Aldy Hernandez --- I was able to reproduce on my Fedora 11.1.1 system compiler, but it seems to work on trunk: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/notnfs/aldyh/bld/threader/ada/install/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/aldyh/src/gcc/configure --enable-languages=c,c++,ada --disable-bootstrap --disable-multilib --prefix =/home/aldyh/bld/threader/ada/install --disable-libgomp Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20210729 (experimental) (GCC) $ make gnatmake -gnatVa -gnata -O1 -ftree-vrp src/egl-objects-displays.adb gcc -c -Isrc/ -gnatVa -gnata -O1 -ftree-vrp -I- src/egl-objects-displays.adb gcc -c -Isrc/ -gnatVa -gnata -O1 -ftree-vrp -I- src/egl.adb gcc -c -Isrc/ -gnatVa -gnata -O1 -ftree-vrp -I- src/egl-api.ads gcc -c -Isrc/ -gnatVa -gnata -O1 -ftree-vrp -I- src/egl-errors.adb gcc -c -Isrc/ -gnatVa -gnata -O1 -ftree-vrp -I- src/egl-objects.adb gcc -c -Isrc/ -gnatVa -gnata -O1 -ftree-vrp -I- src/egl-objects-devices.adb gcc -c -Isrc/ -gnatVa -gnata -O1 -ftree-vrp -I- src/egl-loading.adb
[Bug tree-optimization/101667] GNAT bug detected in op1_range in range-op.cc during GIMPLE pass evrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101667 --- Comment #3 from Aldy Hernandez --- Works on 11.2.1 as well: tor:~/tmp/tree-vrp-test$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/notnfs/aldyh/bld/threader/ada/install/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/aldyh/src/gcc/configure --enable-languages=c,c++,ada --disable-bootstrap --disable-multilib --prefix =/home/aldyh/bld/threader/ada/install --disable-libgomp Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.2.1 20210728 (GCC) tor:~/tmp/tree-vrp-test$ ls Makefile src tor:~/tmp/tree-vrp-test$ make gnatmake -gnatVa -gnata -O1 -ftree-vrp src/egl-objects-displays.adb gcc -c -Isrc/ -gnatVa -gnata -O1 -ftree-vrp -I- src/egl-objects-displays.adb gcc -c -Isrc/ -gnatVa -gnata -O1 -ftree-vrp -I- src/egl.adb gcc -c -Isrc/ -gnatVa -gnata -O1 -ftree-vrp -I- src/egl-api.ads gcc -c -Isrc/ -gnatVa -gnata -O1 -ftree-vrp -I- src/egl-errors.adb gcc -c -Isrc/ -gnatVa -gnata -O1 -ftree-vrp -I- src/egl-objects.adb gcc -c -Isrc/ -gnatVa -gnata -O1 -ftree-vrp -I- src/egl-objects-devices.adb gcc -c -Isrc/ -gnatVa -gnata -O1 -ftree-vrp -I- src/egl-loading.adb
[Bug middle-end/81596] backwards threader misses simple copy within the same BB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81596 Aldy Hernandez changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #3 from Aldy Hernandez --- By design the backwards jump threader works on paths greater than one block, so this is not even a candidate to eliminate with the threader. : x_2 = 25; xcopy_3 = x_2; if (xcopy_3 == 25) goto ; [INV] else goto ; [INV] Closing.
[Bug libstdc++/101659] _GLIBCXX_DEBUG mode for std::optional ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101659 Simon Marchi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Simon Marchi --- (In reply to Marc Glisse from comment #1) > I already see some "__glibcxx_assert(this->_M_is_engaged());" in the code, > which IIUC should be enabled by _GLIBCXX_ASSERTIONS (and a fortiori by > _GLIBCXX_DEBUG). Did you actually try it? Arf, yes I did try it. But I now see that I compiled my test.cpp _without_ _GLIBCXX_DEBUG (with the intention of compiling with it). Now that I did it correctly, I see the assertion triggers. Thanks, and sorry for wasting everyone's time.
[Bug libstdc++/101659] _GLIBCXX_DEBUG mode for std::optional ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101659 --- Comment #3 from Jonathan Wakely --- Indeed. Marc added them in r8-711.
[Bug libstdc++/101659] _GLIBCXX_DEBUG mode for std::optional ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101659 --- Comment #4 from Jonathan Wakely --- It might be nice to add them to std::experimental::optional too though.
[Bug testsuite/101647] [12 regression] excess error in g++.dg/cpp0x/initlist48.C after r12-2534
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101647 --- Comment #1 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7d014f7b224cb41e9570284d125f4c605cb0ab0a commit r12-2594-g7d014f7b224cb41e9570284d125f4c605cb0ab0a Author: Jakub Jelinek Date: Thu Jul 29 14:17:55 2021 +0200 testsuite: Fix up two tests for recent libstdc++ header changes [PR101647] After recent libstdc++ header changes no longer includes (parts of?) and doesn't have to and no longer includes (parts of?) . This patch fixes: testsuite/g++.dg/pr71389.C:10:39: error: aggregate 'std::array, 16> v13' has incomplete type and cannot be defined as well as testsuite/g++.dg/cpp0x/initlist48.C:11:6: error: 'initializer_list' in namespace 'std' does not name a template type; did you mean 'uninitialized_fill'? 2021-07-29 Jakub Jelinek PR testsuite/101647 * g++.dg/pr71389.C: Include instead of . * g++.dg/cpp0x/initlist48.C: Include also .
[Bug fortran/98411] [10/11] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #12 from Tobias Burnus --- Regarding the message: Warning: Array ‘a’ at (1) is larger than limit set by ‘-fmax-stack-var-size=’, moved from stack to static storage. This makes the procedure unsafe when called recursively, or concurrently from multiple threads. Consider using ‘-frecursive’, or increase the ‘-fmax-stack-var-size=’ limit, or change the code to use an ALLOCATABLE array. [-Wsurprising] The -frecursive flag is fine - but highly misleading, until reading the gfortran manual. I think the last sentence should be something like: "Consider increasing the ‘-fmax-stack-var-size=’ limit (or use -frecursive, which implies unlimited -fmax-stack-var-size) - or change the code to use an ALLOCATABLE array. If the variable is never accessed concurrently, this warning can be ignored; in this case, the variable could also be declared with the SAVE attribute." Or differently worded - but -frecursive needs some explanation in the message.
[Bug testsuite/101647] [12 regression] excess error in g++.dg/cpp0x/initlist48.C after r12-2534
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101647 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/101676] New: ^ not changed to | if the non-zero don't overlap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101676
Bug ID: 101676
Summary: ^ not changed to | if the non-zero don't overlap
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
int f(int a, int b)
{
if (a & ~8) __builtin_unreachable();
if (b & 8) __builtin_unreachable();
return a ^ b;
}
- CUT -
The xor here can converted into ior as a and b non-zero bits don't overlap.
Note clang does this optimization.
But clang does not do the following (which we should be able to do too).
Take:
int f(int a, int b)
{
if (a & 8) __builtin_unreachable();
if (b & ~1) __builtin_unreachable();
return (a) ^ (b<<3);
}
This should be able to turn into a bit insert of b into a.
Right now both GCC (and really clang) turn this on aarch64:
eor w0, w0, w1, lsl 3 ;;;clang uses orr
Both can handle the following though:
int f(int a, int b)
{
// if (a & 8) __builtin_unreachable();
// if (b & ~1) __builtin_unreachable();
return (a&~8) ^ ((b&1)<<3);
}
Unless you uncomment out the condtionals :).
[Bug target/101543] extra zeroing of empty struct argument/return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101543 Tejas Belagod changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2021-07-29 CC||belagod at gcc dot gnu.org
[Bug target/101543] extra zeroing of empty struct argument/return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101543 Tejas Belagod changed: What|Removed |Added Status|ASSIGNED|UNCONFIRMED Ever confirmed|1 |0
[Bug target/101609] no right shift pattern for vector(2) long long on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101609 Tejas Belagod changed: What|Removed |Added Status|NEW |ASSIGNED
[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 Last reconfirmed||2021-07-29 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100404 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Keywords||documentation --- Comment #2 from Martin Sebor --- This is essentially a duplicate of pr100404 which was resolved as invalid, but I think it's possible to do better: at a minimum, updating the documentation might help. Issuing a warning when both attributes are set on the same function indicating that one is ignored (as is normally done) would be even better but wouldn't help if -fno-delete-null-pointer-checks is set by a #pragma or on the command line. Let me see what I can do.
[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340 Matt Thompson changed: What|Removed |Added CC||matthew.thompson at nasa dot gov --- Comment #10 from Matt Thompson --- Query from someone who I believe just encountered this trying to build 11.2 on macOS 11.5.1 with XCode 12.5: What is the best method to work around this for now? 1. Update to XCode 12.5.1 (which apparently exists, but I don't know if it has the fixes?) 2. Pass in `--without-build-config` to configure (which is how Homebrew does it) 3. Iain's last suggestion about `-mllvm -x86-pad-for-align=false` (I'm not sure where to put that) The easiest for me to try was #2 and it seems to work, but I don't know if that has side-effects for the built compiler. (Of course, our software currently has some issues with GCC 11.1 that I think are still open here on Bugzilla (like #100651), but I thought I'd see if 11.2 fixes them!)
[Bug d/101656] d: Don't escape quoted format strings in escape_d_format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101656 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:cd4bda42979cb40860a9cd2c0ed188b9a0948cd4 commit r12-2595-gcd4bda42979cb40860a9cd2c0ed188b9a0948cd4 Author: Iain Buclaw Date: Mon Jul 26 15:52:23 2021 +0200 d: Don't escape quoted format strings in escape_d_format (PR101656) If the format string is enclosed by two '`' characters, then don't escape the first and laster characters. PR d/101656 gcc/d/ChangeLog: * d-diagnostic.cc (escape_d_format): Don't escape quoted format strings.
[Bug d/101657] d: di header file created even if errors occur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101657 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:75f2e3f6cbbb79421b12e399498e9c14241359e7 commit r12-2596-g75f2e3f6cbbb79421b12e399498e9c14241359e7 Author: Iain Buclaw Date: Mon Jul 26 17:24:38 2021 +0200 d: Remove generated D header files on error (PR101657) If an error occurs later during compilation, remember that we generated the headers, so that they can be removed before exit. PR d/101657 gcc/d/ChangeLog: * d-lang.cc (d_parse_file): Remove generated D header files on error. gcc/testsuite/ChangeLog: * gdc.dg/pr101657.d: New test.
[Bug d/96435] d: Returning boolean in a union violates @safe code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96435 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:5c9b7408dc578cb2ae142a5c1b724c183497bdb2 commit r12-2597-g5c9b7408dc578cb2ae142a5c1b724c183497bdb2 Author: Iain Buclaw Date: Mon Jul 26 19:28:02 2021 +0200 d: Ensure casting from bool results in either 0 or 1 (PR96435) If casting from bool, the result is either 0 or 1, any other value violates @safe code, so enforce that it is never invalid. PR d/96435 gcc/d/ChangeLog: * d-convert.cc (convert_for_rvalue): New function. * d-tree.h (convert_for_rvalue): Declare. * expr.cc (ExprVisitor::visit (CastExp *)): Use convert_for_rvalue. (build_return_dtor): Likewise. gcc/testsuite/ChangeLog: * gdc.dg/torture/pr96435.d: New test.
[Bug d/101664] d: Return the correct value for C++ constructor calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101664 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:7616ed6307c90b5bbf1bf53550d33cc674ab4b6f commit r12-2598-g7616ed6307c90b5bbf1bf53550d33cc674ab4b6f Author: Iain Buclaw Date: Mon Jul 26 19:34:33 2021 +0200 d: Return the correct value for C++ constructor calls (PR101664) C++ constructors return void, even though the front-end semantic treats them as implicitly returning `this'. To handle this correctly, the object reference is cached and used as the result of the expression. PR d/101664 gcc/d/ChangeLog: * expr.cc (ExprVisitor::visit (CallExp *)): Use object expression as result for C++ constructor calls. gcc/testsuite/ChangeLog: * gdc.dg/extern-c++/extern-c++.exp: New. * gdc.dg/extern-c++/pr101664.d: New test. * gdc.dg/extern-c++/pr101664_1.cc: New test.
[Bug d/101672] d: Allow use of classes without the runtime if they only contain static members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101672 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:3c13cf479ba81c4d29b202e9b8c6a7f0031a8b20 commit r12-2599-g3c13cf479ba81c4d29b202e9b8c6a7f0031a8b20 Author: Iain Buclaw Date: Mon Jul 26 20:01:29 2021 +0200 d: Generate Object class if it doesn't exist during TypeInfo emission (PR101672) Having a stub will prevent errors from occuring when compiling D code with an empty object.d. Though if it were to actually be used implicitly then an error should occur. PR d/101672 gcc/d/ChangeLog: * typeinfo.cc (make_frontend_typeinfo): Generate Object class if it doesn't exist. (check_typeinfo_type): Don't warn if there's no location. gcc/testsuite/ChangeLog: * gdc.dg/pr100967.d: Update test. * gdc.dg/pr101672.d: New test.
[Bug d/96435] d: Returning boolean in a union violates @safe code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96435 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:22589586940439fb5878180a7c586ea753d179f6 commit r11-8816-g22589586940439fb5878180a7c586ea753d179f6 Author: Iain Buclaw Date: Mon Jul 26 19:28:02 2021 +0200 d: Ensure casting from bool results in either 0 or 1 (PR96435) If casting from bool, the result is either 0 or 1, any other value violates @safe code, so enforce that it is never invalid. PR d/96435 gcc/d/ChangeLog: * d-convert.cc (convert_for_rvalue): New function. * d-tree.h (convert_for_rvalue): Declare. * expr.cc (ExprVisitor::visit (CastExp *)): Use convert_for_rvalue. (build_return_dtor): Likewise. gcc/testsuite/ChangeLog: * gdc.dg/torture/pr96435.d: New test. (cherry picked from commit 5c9b7408dc578cb2ae142a5c1b724c183497bdb2)
[Bug d/101664] d: Return the correct value for C++ constructor calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101664 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:0a3f1c2402c87533d38e1016fcf842a5493e8806 commit r11-8817-g0a3f1c2402c87533d38e1016fcf842a5493e8806 Author: Iain Buclaw Date: Mon Jul 26 19:34:33 2021 +0200 d: Return the correct value for C++ constructor calls (PR101664) C++ constructors return void, even though the front-end semantic treats them as implicitly returning `this'. To handle this correctly, the object reference is cached and used as the result of the expression. PR d/101664 gcc/d/ChangeLog: * expr.cc (ExprVisitor::visit (CallExp *)): Use object expression as result for C++ constructor calls. gcc/testsuite/ChangeLog: * gdc.dg/extern-c++/extern-c++.exp: New. * gdc.dg/extern-c++/pr101664.d: New test. * gdc.dg/extern-c++/pr101664_1.cc: New test. (cherry picked from commit 7616ed6307c90b5bbf1bf53550d33cc674ab4b6f)
[Bug d/96435] d: Returning boolean in a union violates @safe code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96435 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:10490b7a453159f9b602b7f273f0aa6b4caebca7 commit r10-10012-g10490b7a453159f9b602b7f273f0aa6b4caebca7 Author: Iain Buclaw Date: Mon Jul 26 19:28:02 2021 +0200 d: Ensure casting from bool results in either 0 or 1 (PR96435) If casting from bool, the result is either 0 or 1, any other value violates @safe code, so enforce that it is never invalid. PR d/96435 gcc/d/ChangeLog: * d-convert.cc (convert_for_rvalue): New function. * d-tree.h (convert_for_rvalue): Declare. * expr.cc (ExprVisitor::visit (CastExp *)): Use convert_for_rvalue. (build_return_dtor): Likewise. gcc/testsuite/ChangeLog: * gdc.dg/pr96435.d: New test. (cherry picked from commit 5c9b7408dc578cb2ae142a5c1b724c183497bdb2)
[Bug d/96435] d: Returning boolean in a union violates @safe code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96435 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:c848c0ec7fab0c0a220683ad234c8842939941cf commit r9-9653-gc848c0ec7fab0c0a220683ad234c8842939941cf Author: Iain Buclaw Date: Mon Jul 26 19:28:02 2021 +0200 d: Ensure casting from bool results in either 0 or 1 (PR96435) If casting from bool, the result is either 0 or 1, any other value violates @safe code, so enforce that it is never invalid. PR d/96435 gcc/d/ChangeLog: * d-convert.cc (convert_for_rvalue): New function. * d-tree.h (convert_for_rvalue): Declare. * expr.cc (ExprVisitor::visit (CastExp *)): Use convert_for_rvalue. (build_return_dtor): Likewise. gcc/testsuite/ChangeLog: * gdc.dg/pr96435.d: New test. (cherry picked from commit 5c9b7408dc578cb2ae142a5c1b724c183497bdb2)
[Bug testsuite/101531] [11 regression] gcc.target/powerpc/pr101129.c has excess errors after r11-8780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101531 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by William Schmidt : https://gcc.gnu.org/g:868cb29b1ddebc4128e9e4b84d92f4473aa3389c commit r11-8818-g868cb29b1ddebc4128e9e4b84d92f4473aa3389c Author: Bill Schmidt Date: Thu Jul 29 10:24:27 2021 -0500 rs6000: Add int128 target check to pr101129.c (PR101531) Backport from mainline. 2021-07-21 Bill Schmidt gcc/testsuite/ PR target/101531 * gcc.target/powerpc/pr101129.c: Adjust.
[Bug d/101672] d: Allow use of classes without the runtime if they only contain static members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101672 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Buclaw --- Fix committed.
[Bug d/101657] d: di header file created even if errors occur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101657 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Iain Buclaw --- Fix committed.
[Bug d/101656] d: Don't escape quoted format strings in escape_d_format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101656 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Buclaw --- Fix committed.
[Bug d/101664] d: Return the correct value for C++ constructor calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101664 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Iain Buclaw --- Fix committed.
[Bug d/96435] d: Returning boolean in a union violates @safe code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96435 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Iain Buclaw --- Fix committed.
[Bug testsuite/101531] [11 regression] gcc.target/powerpc/pr101129.c has excess errors after r11-8780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101531 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by William Schmidt : https://gcc.gnu.org/g:e925336ec309e581317f9b198207db915402b83f commit r10-10013-ge925336ec309e581317f9b198207db915402b83f Author: Bill Schmidt Date: Thu Jul 29 10:28:08 2021 -0500 rs6000: Add int128 target check to pr101129.c (PR101531) Backport from mainline. 2021-07-21 Bill Schmidt gcc/testsuite/ PR target/101531 * gcc.target/powerpc/pr101129.c: Adjust.
[Bug testsuite/101531] [11 regression] gcc.target/powerpc/pr101129.c has excess errors after r11-8780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101531 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by William Schmidt : https://gcc.gnu.org/g:49a2cbb3f5906ac20d7a4619d5d3112584d46cf7 commit r9-9654-g49a2cbb3f5906ac20d7a4619d5d3112584d46cf7 Author: Bill Schmidt Date: Thu Jul 29 10:31:22 2021 -0500 rs6000: Add int128 target check to pr101129.c (PR101531) Backport from mainline. 2021-07-21 Bill Schmidt gcc/testsuite/ PR target/101531 * gcc.target/powerpc/pr101129.c: Adjust.
[Bug testsuite/101531] [11 regression] gcc.target/powerpc/pr101129.c has excess errors after r11-8780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101531 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Bill Schmidt --- Now fixed everywhere.
[Bug fortran/100651] Weird memory corruption with multiple triggers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100651 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #3 from Iain Sandoe --- could you please: * identify the linux and macOS platforms affected (add to target in the BZ here) * identify if this is a regression (i.e. does 8.5 work as expected?) we adjust the title to read [N,M,O Regression blah blah] if that is so.
[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101674 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Target|ppc64*-*-* |powerpc64*-*-* Last reconfirmed||2021-07-29 CC||msebor at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- I can confirm the test fails (despite the xfail): FAIL: gcc.dg/uninit-pred-9_b.c bogus warning (test for bogus messages, line 25) The xfail target should probably be powerpc64*-*-*. Since the failure is on line 25 would it make sense to xfail just that assertion?
[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340 --- Comment #11 from Iain Sandoe --- (In reply to Matt Thompson from comment #10) > Query from someone who I believe just encountered this trying to build 11.2 > on macOS 11.5.1 with XCode 12.5: What is the best method to work around this > for now? > > 1. Update to XCode 12.5.1 (which apparently exists, but I don't know if it > has the fixes?) not yet checked - but if someone has time I'd like to know ;) > 2. Pass in `--without-build-config` to configure (which is how Homebrew does > it) the disadvantage of that is that it skips the compare objects stage (because that is what fails) .. but it works, indeed. > 3. Iain's last suggestion about `-mllvm -x86-pad-for-align=false` (I'm not > sure where to put that) We will need configure to detect version(s) of the assembler that fail and to apply this to the 'as' lines where needed - I didn't get to this because it's far from a 5mins job and: a) was hoping for a fix [does anyone know if 12.5.1 fixes?] b) it was easier for me to revert to using command-line-tools 12.4 for X86 (the bug doesn't fire for my experimental work on arm64, so I can use 12.5 there). ... having said that, if we don't see a fix soon and there end up being un-fixable configurations (e.g. versions which don't support a fixed Xcode, then we'll need to do the configury magic). > The easiest for me to try was #2 and it seems to work, but I don't know if > that has side-effects for the built compiler. as noted above - no side effects on the compiler, but a reduction in the testing of the build. > (Of course, our software currently has some issues with GCC 11.1 that I > think are still open here on Bugzilla (like #100651), but I thought I'd see > if 11.2 fixes them!) please CC me on Darwin/macOS bugs -- too many mailing lists ;-) I miss bugs sometimes.
[Bug d/101664] d: Return the correct value for C++ constructor calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101664 --- Comment #4 from Andrew Pinski --- (In reply to Iain Buclaw from comment #0) > C++ constructors return void, even though the front-end semantic treats them > as implicitly returning `this'. But on some targets they actually do return this. You can check by targetm.cxx.cdtor_returns_this ().
[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101674 --- Comment #2 from Aldy Hernandez --- (In reply to Martin Sebor from comment #1) > I can confirm the test fails (despite the xfail): > > FAIL: gcc.dg/uninit-pred-9_b.c bogus warning (test for bogus messages, line > 25) > > The xfail target should probably be powerpc64*-*-*. Since the failure is on > line 25 would it make sense to xfail just that assertion? Ahhh. Yes, that seems appropriate. Feel free to commit it as obvious. Thanks for taking care of this.
[Bug d/101664] d: Return the correct value for C++ constructor calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101664 --- Comment #5 from Iain Buclaw --- (In reply to Andrew Pinski from comment #4) > (In reply to Iain Buclaw from comment #0) > > C++ constructors return void, even though the front-end semantic treats them > > as implicitly returning `this'. > > But on some targets they actually do return this. > You can check by targetm.cxx.cdtor_returns_this (). Ah, I didn't see that was available for all front-ends. I had assumed it was just C++.
[Bug c++/101677] New: [11 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101677
Bug ID: 101677
Summary: [11 Regression] Concept with use of incomplete type
succeeds on GCC 10.3.0, fails on GCC 11 onward
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joeloser93 at gmail dot com
Target Milestone: ---
A concept that uses an incomplete type in testing the well-formedness of
calling a function template is well-formed in GCC 10.3.0, but fails in GCC 11
onward (including trunk at the time of this writing).
For example, consider the following:
template
concept C_bug_with_forward_decl = requires(T& t){
t.template f();
};
struct good {
template auto f() -> void {}
};
static_assert(C_bug_with_forward_decl); // works in GCC 10.3.0, fails on
GCC 11 onward
This bug can be worked around by using a complete type instead when defining
the concept. For example:
struct U{};
template
concept C_workaround = requires(T& t){
t.template f();
};
static_assert(C_workaround); // works on GCC 10.3.0 and GCC 11 onward
See it live at https://godbolt.org/z/h7GzqGhYn
[Bug middle-end/101671] pr83510 fails with -Os because threader confuses -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101671
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Last reconfirmed||2021-07-29
Keywords||diagnostic
Summary|pr83510 fails because |pr83510 fails with -Os
|threader confuses |because threader confuses
|-Warray-bounds |-Warray-bounds
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Martin Sebor ---
Confirmed. I've extracted the test case that fails from the bigger test.
Rather than xfailing the whole test I think it would be better to split out
just the failing case and/or xfail just that assertion. Unless you expect the
others to start failing too due to some changes you still have planned?
$ cat a.c && gcc -Os -S -Wall a.c
extern int f (void);
extern void sink (unsigned int);
unsigned int a[10];
static unsigned int g (int i, int j)
{
if (i == 9)
return j;
else if (i == 10)
return a[i];// no warning here
return 0;
}
void test_g (int j)
{
for (int i = 0; i < 10; i++)
{
if (f ())
sink (g (i, j));
}
}
static unsigned int h (int i, int j)
{
switch (i)
{
case 9:
return j;
case 10:
return a[i]; // { dg-bogus "-Warray-bounds" }
}
return 0;
}
void test_h (int j)
{
for (int i = 0; i < 10; i++)
{
if (f ())
sink (h (i, j));
}
}
In function ‘h’,
inlined from ‘test_h’ at a.c:41:2:
a.c:31:15: warning: array subscript 10 is above array bounds of ‘unsigned
int[10]’ [-Warray-bounds]
31 | return a[i]; // { dg-bogus "-Warray-bounds" }
| ~^~~
a.c: In function ‘test_h’:
a.c:4:14: note: while referencing ‘a’
4 | unsigned int a[10];
| ^
[Bug fortran/100651] Weird memory corruption with multiple triggers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100651 Iain Sandoe changed: What|Removed |Added Target||x86_64-linux-gnu, ||x86_64-apple-darwin Last reconfirmed||2021-07-29 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #4 from Iain Sandoe --- (In reply to Iain Sandoe from comment #3) > could you please: > > * identify the linux and macOS platforms affected (add to target in the BZ > here) > > * identify if this is a regression (i.e. does 8.5 work as expected?) > we adjust the title to read [N,M,O Regression blah blah] if that is so. NM.. I checked it - it fails for at least gcc5.5+ on Darwin and 8.3+ on Linux (so not a regression - but the fortran folks probably should look at it). (disclaimer: I didn't read the code - just tested that it failed on several systems)
[Bug c++/101670] Internal compiler error with concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101670
Joe Loser changed:
What|Removed |Added
CC||joeloser93 at gmail dot com
--- Comment #1 from Joe Loser ---
Here's a simple workaround using concepts directly:
```
template concept Complete = requires(T t) { sizeof(t); };
template concept Incomplete = !Complete;
template struct S {};
struct A;
S s1;
struct A {};
S s2;
```
See it live at https://gcc.godbolt.org/z/MjKoM8dP6
[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101674 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:2f6bdd51cfe15403085b69c133065ebda4af9bb9 commit r12-2600-g2f6bdd51cfe15403085b69c133065ebda4af9bb9 Author: Martin Sebor Date: Thu Jul 29 10:11:18 2021 -0600 Xfail just the failing assertion and correct target. Related to: PR middle-end/101674 - gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite gcc/testsuite: PR middle-end/101674 * gcc.dg/uninit-pred-9_b.c: Xfail just the failing assertion and correct target.
[Bug middle-end/101671] pr83510 fails with -Os because threader confuses -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101671
--- Comment #2 from Aldy Hernandez ---
Yeah, that would be great. Thanks!
On Thu, Jul 29, 2021 at 6:05 PM msebor at gcc dot gnu.org
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101671
>
> Martin Sebor changed:
>
>What|Removed |Added
>
> CC||msebor at gcc dot gnu.org
>Last reconfirmed||2021-07-29
>Keywords||diagnostic
> Summary|pr83510 fails because |pr83510 fails with -Os
>|threader confuses |because threader confuses
>|-Warray-bounds |-Warray-bounds
> Ever confirmed|0 |1
> Status|UNCONFIRMED |NEW
>
> --- Comment #1 from Martin Sebor ---
> Confirmed. I've extracted the test case that fails from the bigger test.
> Rather than xfailing the whole test I think it would be better to split out
> just the failing case and/or xfail just that assertion. Unless you expect the
> others to start failing too due to some changes you still have planned?
>
> $ cat a.c && gcc -Os -S -Wall a.c
> extern int f (void);
> extern void sink (unsigned int);
>
> unsigned int a[10];
>
> static unsigned int g (int i, int j)
> {
> if (i == 9)
> return j;
> else if (i == 10)
> return a[i];// no warning here
> return 0;
> }
>
> void test_g (int j)
> {
> for (int i = 0; i < 10; i++)
> {
> if (f ())
> sink (g (i, j));
> }
> }
>
> static unsigned int h (int i, int j)
> {
> switch (i)
> {
> case 9:
> return j;
> case 10:
> return a[i]; // { dg-bogus "-Warray-bounds" }
> }
> return 0;
> }
>
> void test_h (int j)
> {
> for (int i = 0; i < 10; i++)
> {
> if (f ())
> sink (h (i, j));
> }
> }
> In function ‘h’,
> inlined from ‘test_h’ at a.c:41:2:
> a.c:31:15: warning: array subscript 10 is above array bounds of ‘unsigned
> int[10]’ [-Warray-bounds]
>31 | return a[i]; // { dg-bogus "-Warray-bounds" }
> | ~^~~
> a.c: In function ‘test_h’:
> a.c:4:14: note: while referencing ‘a’
> 4 | unsigned int a[10];
> | ^
>
> --
> You are receiving this mail because:
> You reported the bug.
>
[Bug debug/101669] error reading variable from debug information when compiling with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101669 --- Comment #4 from Andrew Pinski --- What version of gdb are you using?
[Bug fortran/101627] List-directed read with trailing characters after quotes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101627
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-07-29
Priority|P3 |P4
Ever confirmed|0 |1
--- Comment #2 from kargl at gcc dot gnu.org ---
Here a correct patch, which has been regression tested.
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 8cc7ddbe8e2..b551f2b9843 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -1258,7 +1258,7 @@ read_character (st_parameter_dt *dtp, int length
__attribute__ ((unused)))
done:
c = next_char (dtp);
done_eof:
- if (is_separator (c) || c == EOF)
+ if (quote == '"' || quote == '\'' || is_separator (c) || c == EOF)
{
unget_char (dtp, c);
eat_separator (dtp);
[Bug testsuite/101678] New: [12 regression] many fortran errors afterr r12-2553
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101678 Bug ID: 101678 Summary: [12 regression] many fortran errors afterr r12-2553 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:a3b350f1799a1c0f9e2ece5b817a537fe42f0d2d, r12-2553 FAIL: gfortran.dg/ISO_Fortran_binding_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_1.f90 -O1 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_1.f90 -O2 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_1.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_1.f90 -Os (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_10.f90 -O0 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_10.f90 -O1 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_10.f90 -O2 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_10.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_10.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_10.f90 -Os (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_11.f90 -O0 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_11.f90 -O1 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_11.f90 -O2 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_11.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_11.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_11.f90 -Os (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_12.f90 -O0 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_12.f90 -O1 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_12.f90 -O2 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_12.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_12.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_12.f90 -Os (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_15.f90 -O0 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_15.f90 -O1 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_15.f90 -O2 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_15.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_15.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_15.f90 -Os (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_16.f90 -O0 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_16.f90 -O1 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_16.f90 -O2 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_16.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_16.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_16.f90 -Os (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_17.f90 -O0 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_17.f90 -O1 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_17.f90 -O2 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_17.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_17.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_17.f90 -Os (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_18.f90 -O0 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_18.f90 -O1 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_18.f90 -O2 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_18.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_18.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_18.f90 -Os (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_3.f90 -O0 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_3.f90 -O1 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran
[Bug tree-optimization/71538] Missing removal of null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71538
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Ever confirmed|0 |1
Last reconfirmed||2021-07-29
Status|UNCONFIRMED |NEW
--- Comment #5 from Andrew Pinski ---
(In reply to sasho648 from comment #4)
> More *shocking* example will be:
>
> struct tx { int a[6], b[6]; } *f();
>
> void (main)()
> {
> int *p = f()->b;
>
> if(p == NULL)
> printf("What?");
> }
>
This one works with GCC 10+.
The first one is still not implemented.
The cast is removed early:
<;
So it might be hard to implement.
Confirmed
[Bug c/97892] [10/11/12 Regression] ICE in tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:2946
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97892 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 101171. *** This bug has been marked as a duplicate of bug 101171 ***
[Bug c/101171] [10 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:3006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101171 Andrew Pinski changed: What|Removed |Added CC||doko at debian dot org --- Comment #9 from Andrew Pinski --- *** Bug 97892 has been marked as a duplicate of this bug. ***
[Bug c/93574] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:2925
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93574 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 101171. *** This bug has been marked as a duplicate of bug 101171 ***
[Bug c/101171] [10 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:3006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101171 Andrew Pinski changed: What|Removed |Added CC||changochen1 at gmail dot com --- Comment #10 from Andrew Pinski --- *** Bug 93574 has been marked as a duplicate of this bug. ***
[Bug c/92428] Crash on conflicting types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92428 Andrew Pinski changed: What|Removed |Added Known to work||11.0 Status|UNCONFIRMED |RESOLVED Keywords||ice-on-invalid-code Resolution|--- |DUPLICATE Known to fail||4.1.2 --- Comment #3 from Andrew Pinski --- Fixed by the patch which fixed PR 97882. *** This bug has been marked as a duplicate of bug 97882 ***
[Bug c/97882] [8/9/10/11 Regression] Segmentation Fault on improper redeclaration of function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97882 Andrew Pinski changed: What|Removed |Added CC||dpotapov at gmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 92428 has been marked as a duplicate of this bug. ***
[Bug objc/67694] ICE on returning undefined enum in must_pass_in_stack_var_size_or_pad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67694 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2017-08-09 00:00:00 |2021-7-29 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97882 Component|target |objc Keywords||error-recovery --- Comment #3 from Andrew Pinski --- Related to PR 97882 but this one still happens.
[Bug target/89932] ICE in must_pass_in_stack_var_size_or_pad, at calls.c:5824
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89932 --- Comment #4 from Andrew Pinski --- Actually this one has been fixed while PR 67694 has not. THis is a dup of bug 97882. *** This bug has been marked as a duplicate of bug 97882 ***
[Bug c/97882] [8/9/10/11 Regression] Segmentation Fault on improper redeclaration of function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97882 Andrew Pinski changed: What|Removed |Added CC||gs...@t-online.de --- Comment #9 from Andrew Pinski --- *** Bug 89932 has been marked as a duplicate of this bug. ***
[Bug c/37187] please provide a way to treat -pedantic as warning when using -Werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37187 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.0 Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Andrew Pinski --- So this was fixed in GCC 5 because it is an exact dup of bug 60139. *** This bug has been marked as a duplicate of bug 60139 ***
[Bug c/60139] Imprecise column number for -pedantic on non-computable initializer element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60139 Andrew Pinski changed: What|Removed |Added CC||edwin+bugs at etorok dot eu --- Comment #4 from Andrew Pinski --- *** Bug 37187 has been marked as a duplicate of this bug. ***
[Bug fortran/100651] Weird memory corruption with multiple triggers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100651 --- Comment #5 from Matt Thompson --- Iain, The Linux system would be SUSE Linux Enterprise Server 12 SP3. The macOS system is macOS 11.5.1. On the Linux machine, I can confirm the error with (I only have some versions of GCC available): * 8.3.0 * 9.2.0 * 10.1.0 * 11.1.0 On the macOS where I just built 11.2.0, I see the same crash. Now, with 7.4.0 and 6.5.0 (can only test on Linux), I don't get the run-time crash. Instead, I believe it works...sort of? To wit: $ ./a.out opt_string.F90 122 T opt_string.F90 123 10922 err_msg: foo bar, err_msg: foo bar, err_msg: foo bar, err_msg: foo bar, err_msg: foo bar, err_msg: foo bar, err_msg: foo bar, err_msg: foo bar, err_msg: foo bar, err_msg: foo bar, err_msg: foo bar, err_msg: foo bar, err_msg: foo bar, err_msg: foo bar, err_msg: foo bar, err_msg: foo bar, err_msg: foo bar,... That last bit goes on for a while. This isn't the intended behavior. Intel 2021.3 does: $ ./a.out opt_string.F90 122 T opt_string.F90 123 7 err_msg: foo bar and NAG 7.0_7048 does: $ ./a.out opt_string.F90 122 T opt_string.F90 123 7 err_msg: foo bar We are unsure why GNU is doing this...recursive-like behavior? It's not like the routine is called in a loop!
[Bug c/24293] Undefined behaviour not diagnosed with -fsyntax-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24293 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c/63878] Variables of incomplete type can be defined with -fno-fat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63878 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- So this has been fixed since GCC 6 by PR 24293 so closing as a dup. *** This bug has been marked as a duplicate of bug 24293 ***
[Bug c/24293] Undefined behaviour not diagnosed with -fsyntax-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24293 Andrew Pinski changed: What|Removed |Added CC||hristo at venev dot name --- Comment #8 from Andrew Pinski --- *** Bug 63878 has been marked as a duplicate of this bug. ***
[Bug middle-end/101679] New: duplicate warning offset outside bounds of constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101679
Bug ID: 101679
Summary: duplicate warning offset outside bounds of constant
string
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Only one instance of -Warray-bounds should be reported the access below but GCC
issues two. The warning is issued from c_strlen() with the first instance
during lowering and the second during (or just before) expansion. The first
instance calls suppress_warning(arg, OPT_Warray_bounds) which is checked again
before issuing the second instance by calling warning_suppressed_p (arg,
OPT_Warray_bounds). The problem is that the first time arg is an ADDR_EXPR but
VAR_DECL the second. Stripping the ADDR_EXPR and disabling the warning for its
operand is not a solution because it would disable warnings for invalid uses of
the same operand in other statements, both in the same function or (for global
variables) in others.
$ cat a.c && gcc -S -Wall a.c
const char s0[0] = { };
char* f (char *d)
{
return __builtin_strcpy (d, s0);
}
a.c: In function ‘f’:
a.c:5:31: warning: offset ‘0’ outside bounds of constant string
[-Warray-bounds]
5 | return __builtin_strcpy (d, s0);
| ^~
a.c:1:12: note: ‘s0’ declared here
1 | const char s0[0] = { };
|^~
a.c:5:10: warning: offset ‘0’ outside bounds of constant string
[-Warray-bounds]
5 | return __builtin_strcpy (d, s0);
| ^~~~
a.c:1:12: note: ‘s0’ declared here
1 | const char s0[0] = { };
|^~
[Bug tree-optimization/101641] Bogus redundant store removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101641
--- Comment #5 from Martin Uecker ---
(In reply to Richard Biener from comment #3)
>
> What we know from the union read is that the dynamic type is either the
> union type (so the read can pun) or the dynamic type is the union member
> type (then the read cannot pun). 6.5/7 allows accesses using
> "an aggregate or union type that includes [a type compatible with the
> effective
> type of the object]". Though the 'aggregate' case appears quite odd to me,
> does it really allow 'int i; struct { float f; int i; } *p = &i; float x =
> p->f;'?
I do not think this is meant to work as the
read is using an lvalue of type float and
that is not covered by the rules.
I believe that the aggregate case is meant for
the case where sub objects are modified as part of
struct/union assignment (i.e. when the lvalue used
for the access is of struct/union type).
But the rules could be interpreted to allow:
int i; struct { float f; int i; } *p = &i;
int j = p->i;
which I think should not be allowed.
[Bug fortran/100651] [9/10/11/12 Regression] Weird memory corruption with multiple triggers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100651 Iain Sandoe changed: What|Removed |Added Summary|Weird memory corruption |[9/10/11/12 Regression] |with multiple triggers |Weird memory corruption ||with multiple triggers --- Comment #6 from Iain Sandoe --- (In reply to Matt Thompson from comment #5) Thanks for the additional checks. > $ ./a.out > opt_string.F90 122 T > opt_string.F90 123 7 > err_msg: foo bar > > and NAG 7.0_7048 does: > > $ ./a.out > opt_string.F90 122 T > opt_string.F90 123 7 > err_msg: foo bar Then, this is indeed a regression: gcc-5.5: /source/test/fortran/pr100651.F90 122 T /source/test/fortran/pr100651.F90 123 32727 err_msg: foo bar gcc-6-5; /source/test/fortran/pr100651.F90 122 T /source/test/fortran/pr100651.F90 123 32767 err_msg: foo barH\? gcc-7.5 /source/test/fortran/pr100651.F90 122 T /source/test/fortran/pr100651.F90 123 32767 err_msg: foo barH\? gcc8.5: /source/test/fortran/pr100651.F90 122 T /source/test/fortran/pr100651.F90 123 1569183428 t(23248,0x106ee05c0) malloc: can't allocate region *** mach_vm_map(size=140734762573824) failed (error code=3) t(23248,0x106ee05c0) malloc: *** set a breakpoint in malloc_error_break to debug Operating system error: Cannot allocate memory Memory allocation failure in xrealloc Error termination. Backtrace: #0 0x106659f9d .. etc.
[Bug testsuite/101517] Some testcases were lost when tree-ssa was merged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101517 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2021-07-29 --- Comment #2 from Andrew Pinski --- I will take care of this.
[Bug testsuite/16230] Spurious test failures with --disable-static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16230 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- libgcj was removed in GCC 7 so closing as fixed.
[Bug testsuite/37628] gcc.c-torture/execute/pr35456.c is not generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37628 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-07-29 Severity|normal |enhancement Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Maybe we should add an signed_zero target and run the tests that used signed zeros only on those targets. Though I don't think anyone will be doing this any time soon as most targets are IEEE targets. Confirmed.
[Bug testsuite/45068] g++.dg/debug/dwarf2/nested-2.C failed on Linux/ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45068 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- Fixed long time ago.
[Bug testsuite/43495] gcc.c-torture/execute/20000603-1.c fails with -fpic/-fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43495 Andrew Pinski changed: What|Removed |Added Known to work|| Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Andrew Pinski --- Just going to make this as a dup of bug 14319. *** This bug has been marked as a duplicate of bug 14319 ***
[Bug rtl-optimization/14319] incorrect optimization of union of structs with common initial sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319 Andrew Pinski changed: What|Removed |Added CC||ghazi at gcc dot gnu.org --- Comment #19 from Andrew Pinski --- *** Bug 43495 has been marked as a duplicate of this bug. ***
[Bug fortran/98411] [10/11/12 Regression] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[10/11] Pointless: Array|[10/11/12 Regression] |larger than |Pointless: Array larger |‘-fmax-stack-var-size=’,|than |moved from stack to static |‘-fmax-stack-var-size=’, |storage for main program|moved from stack to static |variables |storage for main program ||variables --- Comment #13 from anlauf at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #12) Hi Tobias, > The -frecursive flag is fine - but highly misleading, until reading the > gfortran manual. > I think the last sentence should be something like: > > "Consider increasing the ‘-fmax-stack-var-size=’ limit (or use -frecursive, > which implies unlimited -fmax-stack-var-size) - or change the code to use an > ALLOCATABLE array. If the variable is never accessed concurrently, this > warning can be ignored; in this case, the variable could also be declared > with the SAVE attribute." that should be easier to understand. Do you want to take over this PR? I still have the patch from comment#9 in my tree, fixing comment#0. However, IIRC my debugging sessions had cases where we miss setting an implicit save. Unfortunately, those particular testcases are lost. As a reminder: Fortran 2018:8.5.16(4) has: "A variable, common block, or procedure pointer declared in the scoping unit of a main program, module, or submodule implicitly has the SAVE attribute, which may be confirmed by explicit specification. If a common block has the SAVE attribute in any other kind of scoping unit, it shall have the SAVE attribute in every scoping unit that is not of a main program, module, or submodule." As a minimal solution we could combine the patch in comment#9 with the textual change from comment#12 and defer the handling of implicit save.
[Bug libfortran/98076] Increase speed of integer I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98076 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|11.3|--- --- Comment #3 from anlauf at gcc dot gnu.org --- Not a regression, so removing target milestone.
[Bug testsuite/97826] internal compiler error: in cp_build_addr_expr_1, at cp/typeck.c:6453
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97826 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 65573. *** This bug has been marked as a duplicate of bug 65573 ***
[Bug c++/65573] 13908.C:20:33: internal compiler error: in cp_build_addr_expr_1, at cp/typeck.c:5527
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65573 Andrew Pinski changed: What|Removed |Added CC||vladimir.kokovic at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 97826 has been marked as a duplicate of this bug. ***
[Bug testsuite/97824] internal compiler error: in gimplify_expr, at gimplify.c:14531
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97824 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 65572. *** This bug has been marked as a duplicate of bug 65572 ***
[Bug target/65572] ptrmem5.C:7:26: internal compiler error: in gimplify_expr, at gimplify.c:8629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65572 Andrew Pinski changed: What|Removed |Added CC||vladimir.kokovic at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 97824 has been marked as a duplicate of this bug. ***
[Bug target/65568] ptrmem8.C:9:9: internal compiler error: in build_ptrmemfunc, at cp/typeck.c:7940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65568 Andrew Pinski changed: What|Removed |Added Status|WAITING |NEW
