[Bug other/58312] libssp configure check for "usable vsnprintf" is broken on cross-compilers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312 --- Comment #6 from Brooks Moses --- (In reply to Eric Gallager from comment #5) > Is that patch still relevant? The relevant part of the libssp configure.ac hasn't changed much (if at all) since I posted the patch, so I think it's still worth applying just on basic of general correctness and avoiding unnecessary runtime checks in configure files for things that may be cross-compiled. However, our particular use-case for it is now gone; the relevant precompiled binary file was deleted from our source tree a few months ago. And apparently nobody else has run into the issue.
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020
Jerry DeLisle changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
--- Comment #8 from Jerry DeLisle ---
OK yes we are not doing anything with the return values of the calls to
'remove'.
The error machinery of generate_error takes care of actually assigning the
values to iostat or iomsg. I suggest the following patch.
diff --git a/libgfortran/io/close.c b/libgfortran/io/close.c
index cbcbf4e71a1..c5167bcbbc7 100644
--- a/libgfortran/io/close.c
+++ b/libgfortran/io/close.c
@@ -99,7 +99,11 @@ st_close (st_parameter_close *clp)
else
{
#if HAVE_UNLINK_OPEN_FILE
- remove (u->filename);
+
+ if (remove (u->filename))
+ generate_error (>common, LIBERROR_OS,
+ "File can not be deleted, possibly in use by"
+ " another process");
#else
path = strdup (u->filename);
#endif
@@ -112,7 +116,10 @@ st_close (st_parameter_close *clp)
#if !HAVE_UNLINK_OPEN_FILE
if (path != NULL)
{
- remove (path);
+ if (remove (u->filename))
+ generate_error (>common, LIBERROR_OS,
+ "File can not be deleted, possibly in use by"
+ " another process");
free (path);
}
#endif
I have not dreamt up a way to test this in a test case. I suppose I could
recreate the virtualbox environment Luke found this in. Reardless we should at
a minimum try to check for an OS error here. There are many possibilities so I
think the generic LIBERROR_OS we already have is sufficient. (The iostat code
will be 5000)
BTW I have seen where Windows 10 will essentially lock a file under weird
conditions where it thinks a file is being used by some process, including
simply haveing a folder open somewhere where the file resides. Even though this
environment is under Virtualbox under Ubunto, it is ultiately running NTFS and
the access rights in this environment can be obscure. As an example, I have
mounted NTFS systems using linux and been unable to change the priviliges of
the files.
Luke, do you ever build gcc?
[Bug c++/51253] [C++11][DR 1030] Evaluation order (sequenced-before relation) among initializer-clauses in braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
--- Comment #25 from Matthijs van Duin ---
I wasn't referring to the warnings though but incorrect code generation. Since
is exhibited by pretty trivial test cases (testsuite/g++.dg/cpp0x/initlist86.C
confirms that { i++, i++ } works but the analogous test for { ++i, ++i } fails)
yet was first reported long after this bug was marked "FIXED" I kind of assumed
it was a regression, but apparently it was just never really fixed to begin
with.
[Bug c++/70792] Incorrect sequence point warning with uniform initializer syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70792
--- Comment #8 from Matthijs van Duin ---
(In reply to Matthijs van Duin from comment #4)
> return std::pair{ ++i, ++i }.first;
My bad! This isn't an exhibit of the bug. I simply forgot that std::pair is not
really a struct, and this isn't aggregate initialization: the constructor takes
references, so correct code is generated in this case.
And in fact, if you do use an aggregate, the test works correctly.
However, if you replace std::pair by a class whose constructor takes (int,
int), similar to the one used in the existing testcase
(g++.dg/cpp0x/initlist86.C) then it fails again.
Looking at the disassembly (on ARM since I don't know x86 asm) shows that gcc
loads both arguments from the storage allocated for i, after both increments
have been done. Effectively it's copy-constructing the first argument too late.
The more general issue appears to be that if the arguments are trivially
copyable lvalues, then gcc keeps these as lvalues and copy-constructs the
actual arguments way too late. If I look at this disassembly of this code:
struct Foo {
char x[64]; // too big to pass in register
Foo( Foo const ) = default; // but still trivially copyable
Foo ();
};
struct Pair {
Pair( Foo x, Foo y );
};
void test( Foo ) {
Pair{ foo.mutate(), foo.mutate() };
}
Then test() effectively does:
Foo = foo.mutate();
Foo = foo.mutate();
Pair{ temp1, temp2 } // copy-construct arguments and call Pair constructor
(Also, interestingly, temp2 is copy-constructed before temp1 is!)
If Foo is not trivially copyable, even if merely due to the presence of a
destructor, then the problem disappears.
[Bug driver/89066] After creating valid paths, the \ in source directory are / which creates "No such file or directory"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89066 --- Comment #4 from Matthew Wuensche --- (In reply to Andrew Pinski from comment #2) > >Built by MinGW-W64 project > > Can you make sure you downloaded all of the correct binaries. Hi, um... I just uninstalled my online download... then downloaded i686-8.1.0-release-win32-sjlj-rt_v6-rev0.7z and after running 7-zip and installing it to the same directory so that the paths would still be valid, I receive the same response when running gcc in N:\nesys\asm6\src; however, I still receive an exe if I run gcc from its folder. Though, the line is adjusted to: gcc -v n:\nesys\asm6\src\myfile.c -o myfile It just doesn't work when it has to use the path to find gcc. I wish it would use the path successfully. That cc1.exe line is now, when not using the path: C:/Program Files (x86)/mingw-w64/i686-8.1.0-win32-sjlj-rt_v6-rev0/mingw32/bin/../libexec/gcc/i686-8.1.0-win32-w64-mingw32/8.1.0/cc1.exe -quiet -v -iprefix C:/Program Files (x86)/mingw-w64/i686-8.1.0-win32-sjlj-rt_v6-rev0/ming32/bin/../lib/gcc/i686-w64-mingw32/8.1.0/ -U_REENTRANT n:\nesys\asm6\src\myfile.c -quiet -dumpbase myfile.c -mtune=generic -march=i686 -auxbase myfile -version -o C:\Users\auser\AppData\Local\Temp\cc14fjys.s and then it says: GNU C17 (i686-win32-sjlj-rev0, Built by MinGW-W64 project) version 8.1.0 (i686-w64-mingw32) compiled by GNU C version 8.1.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP and then two sections of "GCC heuristics" follow.
[Bug fortran/87566] ICE with class(*) and select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566 --- Comment #11 from Antony Lewis --- I posted remaining ICE in 9.0.0 20190119 as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89069
[Bug fortran/89069] New: ICE in select type with function returning class array pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89069 Bug ID: 89069 Summary: ICE in select type with function returning class array pointer Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- Follow up to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566, seg fault ICE with gfortran 6.5-9.0 module test contains function getP() class(*), pointer :: getP(:) end function getP subroutine SegFaulter() class(*), pointer :: Pt => null() select type (P=>getP()) type is (real) end select end subroutine end module test
[Bug target/89063] [x86] lack of support for BEXTR from BMI extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89063 Peter Cordes changed: What|Removed |Added CC||peter at cordes dot ca --- Comment #1 from Peter Cordes --- Unfortunately Intel Haswell/Skylake implement BEXTR as 2 uops with 2c latency. Presumably those uops are a shift + bzhi, so 1p06 + 1p15 would explain Agner Fog's experimental result of 2p0156 for BEXTR, with 0.5c throughput. On AMD Excavator/Ryzen, it's 1 uop with 1c latency. On Steamroller and earlier, it's 2 uops but 1c latency. (I assume that's latency from the non-control input to the output. So maybe one of the uops pre-processes the control input, otherwise you'd expect 2c latency from either operand.) Ryzen dropped support for AMD TBM, so only Excavator (bdver4) has 1-uop bextr imm16 which would avoid the need for mov reg,imm32 with the control operand. But mov-imm + bextr can still be a win on Ryzen, lower latency than RORX+AND BMI2 RORX is single-uop on all CPUs that support it. If we already need a 2nd uop to mask anyway, we can use RORX+AND-immediate to duplicate the functionality and performance of BEXTR-immediate, with the smaller code-size if the AND-mask fits in an imm8. (5+5 vs. 6+3 or 6+4 if the AND needs a REX) Without an immediate-source BEXTR (like AMD TBM has/had), the only advantage mov-immediate+bextr has (on Intel) over mov-reg+shift+and is that can deal with wide bitfields using a count instead of an immediate AND mask. (Especially if it doesn't fit in 32 bits). If you can reuse the same control-register in a loop, BEXTR is good-ish for copy-and-extract. PEXT is 1 uop on Intel CPUs even though the simpler-looking BEXTR is 2. But PEXT is extremely slow on Ryzen (7 uops, 18c lat and tput). So for 32-bit constants at least, mov r32,imm32 + PEXT to copy-and-extract is better than BEXTR on Intel. movabs imm64 is too big and can cause front-end problems (slower to read from the uop cache, if that effect from Sandybridge is still present on Haswell/Skylake), and has no advantage vs. RORX + AND unless the bitfield you're extracting is wider than 32 bits. PEXT has 3 cycle latency, though, and can only run on port 1 on SnB-family. (All integer uops with latency > 1 are p1-only). It's potentially good for throughput, but worse than RORX+AND for latency. Unfortunately x86 bitfield instructions are pretty weak compared to ARM / AArch64 ubfx or PowerPC rlwinm and friends, where the bit-positions are simply specified as immediates. Only AMD's immediate version of BEXTR (1 uop on Excavator) matched them. Having a bunch of different control operands for BEXTR or PEXT in registers might be usable in a loop, but a lot more rarely useful than immediate controls. : 0: c4 e3 fb f0 c7 2a rorx $0x2a,%rdi,%rax# $(64-22) 6: c4 e3 fb f0 d7 35 rorx $0x35,%rdi,%rdx# $(64-11) c: 83 e7 3fand$0x3f,%edi f: 83 e0 3fand$0x3f,%eax 12: 83 e2 3fand$0x3f,%edx 15: 01 f8 add%edi,%eax # 32-bit operand-size because we can prove it can't overflow 17: 01 d0 add%edx,%eax # missed optimization in both gcc's versions. 19: c3 retq Not counting the ret, this is 7 uops for Skylake and Ryzen. **I'm pretty sure this is our best bet for -march=skylake, and for tune=generic -mbmi2** The BEXT intrinsics version is 9 uops for SKL, 7 for Ryzen, but is 2 bytes larger. (not counting the savings from avoiding a REX prefix on the ADD instructions; that missed optimization applies equally to both.) OTOH, the critical path latency for BEXTR on Ryzen is better by 1 cycle, so we could still consider it for -march=znver1. Or for tune=generic -mbmi without BMI2. The legacy mov+shr+and version is 10 uops because gcc wasted a `mov %rdi,%rax` instruction; it *should* be 9 uops for all normal CPUs. --- With only BMI1 but not BMI2 enabled, we should probably use the mov-imm + BEXTR version. It's not worse than the mov+shr+and version on SnB-family or bd/zn, and it's better on some AMD. And it's probably smaller code-size. And in future if Intel designs CPUs that can handle BEXTR as a single uop with 1c latency, mov+bextr will become good-ish everywhere. For code-size, BEXTR has a definite advantage for bitfields wider than 1 byte, because AND $imm32, %r32 is 6 bytes long instead of 3.
[Bug c++/89068] Nested inline anonymous namespaces are erroneously reported as conflicting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89068 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Marek Polacek --- Already fixed by r264016 which was backported to 8, too.
[Bug fortran/89067] Inaccurate error message: 'i' at (1) is not a member of the 'x' structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89067 --- Comment #1 from Antony Lewis --- The error message on this code subroutine test type x end type type, extends(x):: y integer ii end type type(y) yy yy%i=1 end subroutine is Error: 'i' at (1) is not a member of the 'x' structure But it should refer to the 'y' structure, not the base class 'x'. Obviously minor and low priority, but more less helpful if y is a deep derived class.
[Bug c++/89068] New: Nested inline anonymous namespaces are erroneously reported as conflicting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89068
Bug ID: 89068
Summary: Nested inline anonymous namespaces are erroneously
reported as conflicting
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
The following valid code is rejected by g++ -std=c++XY for any XY >= 11:
inline namespace {
inline namespace {}
}
inline namespace {}
The error message I get is:
:4:8: error: 'namespace { }' conflicts with a previous declaration
inline namespace {}
^
:1:8: note: previous declaration 'namespace { }'
inline namespace {
^
Compiler returned: 1
[Bug fortran/89067] New: Inaccurate error message: 'i' at (1) is not a member of the 'x' structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89067 Bug ID: 89067 Summary: Inaccurate error message: 'i' at (1) is not a member of the 'x' structure Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: ---
[Bug driver/89066] After creating valid paths, the \ in source directory are / which creates "No such file or directory"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89066 --- Comment #3 from Matthew Wuensche --- I ran the online installer... and received this file mingw-w64-install.exe. And I reran the file to make sure all of those files were added. I found cc1 and added that path before submitting my "bug" report. PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;"C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static";"C:\Program Files (x86)\Common Files\lenovo\easyplussdk\bin";C:\WINDOWS\System32\OpenSSH\;C:\Users\auser\AppData\Local\Microsoft\WindowsApps;"C:\Program Files (x86)\mingw-w64\i686-8.1.0-win32-sjlj-rt_v6-rev0\mingw32\bin";"C:\Program Files (x86)\mingw-w64\i686-8.1.0-win32-sjlj-rt_v6-rev0\mingw32\libexec\gcc\i686-w64-mingw32\8.1.0" see the last path? That's where cc1.exe is. :)
[Bug driver/89066] After creating valid paths, the \ in source directory are / which creates "No such file or directory"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89066 --- Comment #2 from Andrew Pinski --- >Built by MinGW-W64 project Can you make sure you downloaded all of the correct binaries.
[Bug driver/89066] After creating valid paths, the \ in source directory are / which creates "No such file or directory"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89066 Andrew Pinski changed: What|Removed |Added Target|*-mingw* *-cygwin* |i686-w64-mingw32 Component|c |driver Host||i686-w64-mingw32 Build||i686-w64-mingw32 --- Comment #1 from Andrew Pinski --- > cc1 -E -quiet -v -iprefix > N:/nesys/asm6/src/../lib/gcc/i686-w64-mingw32/8.1.0/ -U_REENTRANT good.c > -mtune=generic -march=i686 -fpch-preprocess -o good.i >gcc: error: CreateProcess: No such file or directory This is the problem the GCC driver can't find cc1. The replacement of \ to / is valid transformation for Windows.
[Bug c++/89056] Optimizer generates bad code for non-void function that fails to return a value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89056
--- Comment #6 from Darryl Okahata ---
(OK, at this point, I'm just whinging, so please feel free to ignore this.)
I just wish the C++ standard instead just allowed an undefined value to be
returned, instead of generating bad optimized code. With the current state, I
either have to add compiler-specific extensions or unreachable return
statements to insure that correct code is generated (unexpected and violates
POLA). The issue is that g++ (understandably) can't always detect if there is
always a proper return statement (execution can never hit the end of the
function). Grossly-oversimplified example (real code is much more
complicated):
enum E { A, B };
bool bah(const enum E a)
{
if (a == A)
return false;
if (a == B)
return true;
}
Compiling with (8.2.0):
g++ -S -O badbad.cc
gives:
badbad.cc: In function 'bool bah(E)':
badbad.cc:10:1: warning: control reaches end of non-void function
[-Wreturn-type]
}
^
Understandable, as I don't expect g++ to figure out complicated code
machinations. However, I don't know all the circumstances under which this
warning means that g++ is generating bad code. As a result, I have to add
unreachable return statements to insure that g++ does not generate bad
optimized code. Our code runs on multiple platforms, and so I'd rather avoid
the use of g++ extensions (e.g., __builtin_unreachable() or attributes) and
cluttering #ifdefs. Adding an unreachable return is undesirable but simple and
portable:
enum E { A, B };
bool bah(const enum E a)
{
if (a == A)
return false;
if (a == B)
return true;
return false; // UNREACHABLE
}
[Bug c/89066] New: After creating valid paths, the \ in source directory are / which creates "No such file or directory"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89066 Bug ID: 89066 Summary: After creating valid paths, the \ in source directory are / which creates "No such file or directory" Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: icypawn at aol dot com Target Milestone: --- In my direcory: N:\nesys\asm6\src after typing: gcc -v -save-temps good.c -o good > ok.txt 2>&1 ok.txt reads: Using built-in specs. COLLECT_GCC=gcc Target: i686-w64-mingw32 Configured with: ../../../src/gcc-8.1.0/configure --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32 --with-sysroot=/c/mingw810/i686-810-win32-sjlj-rt_v6-rev0/mingw32 --enable-shared --enable-static --enable-targets=all --enable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=win32 --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch-32=i686 --with-arch-64=nocona --with-tune-32=generic --with-tune-64=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw810/prerequisites/i686-w64-mingw32-static --with-mpfr=/c/mingw810/prerequisites/i686-w64-mingw32-static --with-mpc=/c/mingw810/prerequisites/i686-w64-mingw32-static --with-isl=/c/mingw810/prerequisites/i686-w64-mingw32-static --with-pkgversion='i686-win32-sjlj-rev0, Built by MinGW-W64 project' --with-bugurl=https://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -fno-ident -I/c/mingw810/i686-810-win32-sjlj-rt_v6-rev0/mingw32/opt/include -I/c/mingw810/prerequisites/i686-zlib-static/include -I/c/mingw810/prerequisites/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -fno-ident -I/c/mingw810/i686-810-win32-sjlj-rt_v6-rev0/mingw32/opt/include -I/c/mingw810/prerequisites/i686-zlib-static/include -I/c/mingw810/prerequisites/i686-w64-mingw32-static/include' CPPFLAGS=' -I/c/mingw810/i686-810-win32-sjlj-rt_v6-rev0/mingw32/opt/include -I/c/mingw810/prerequisites/i686-zlib-static/include -I/c/mingw810/prerequisites/i686-w64-mingw32-static/include' LDFLAGS='-pipe -fno-ident -L/c/mingw810/i686-810-win32-sjlj-rt_v6-rev0/mingw32/opt/lib -L/c/mingw810/prerequisites/i686-zlib-static/lib -L/c/mingw810/prerequisites/i686-w64-mingw32-static/lib -Wl,--large-address-aware' Thread model: win32 gcc version 8.1.0 (i686-win32-sjlj-rev0, Built by MinGW-W64 project) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'good.exe' '-mtune=generic' '-march=i686' cc1 -E -quiet -v -iprefix N:/nesys/asm6/src/../lib/gcc/i686-w64-mingw32/8.1.0/ -U_REENTRANT good.c -mtune=generic -march=i686 -fpch-preprocess -o good.i gcc: error: CreateProcess: No such file or directory *eof And so I think this happens because the second to last line beginning with "cc1" has the directory after -iprefix "N:/nesys/asm6/src/.." and in cmd the directories have to use \. I noticed this after looking though someone else's post in a forum citing output from a "gcc -v" line. Their text had "-iprefix c:\mingw.4.7.2\bin\../lib/gcc/i686-pc-mingw32/4.7.2/" and my slashes from my -v response, in the source directory, are backwards... so I think it's a bug. Sorry, if this isn't a bug. Matthew p.s. The -save-temps didn't return a *.i* file; I think that's because good.c is 0kb or empty. I received the exact same -v response when using my source file and didn't think this "bug" has anything to do with the gcc compiler compiling... so I substituted my empty good.c. Hope that's ok. :)
[Bug rtl-optimization/88846] [9 Regression] pr69776-2.c failure on 32 bit AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88846 --- Comment #6 from Vladimir Makarov --- Sorry, I wrote wrong PR number in the ChangeLog entry (I already fix the number). Here is the info about the patch I've committed Author: vmakarov Date: Fri Jan 25 22:13:43 2019 New Revision: 268280 URL: https://gcc.gnu.org/viewcvs?rev=268280=gcc=rev Log: 2019-01-25 Vladimir Makarov PR rtl-optimization/46 * ira.c (process_set_for_memref_referenced_p): New. (memref_referenced_p): Add new param. Use process_set_for_memref_referenced_p. Add new switch cases. (memref_used_between_p): Pass new arg to memref_referenced_p. Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c
[Bug libstdc++/89065] set::find always returns const iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89065 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Marc Glisse --- .
[Bug libstdc++/89065] set::find always returns const iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89065 --- Comment #2 from baltic <1000hz.radiowave at gmail dot com> --- Ok, i see 26.2.6.6 section of the standard: iterator of an associative container is of the bidirectional iterator category. For associative containers where the value type is the same as the key type, both iterator and const_iterator are constant iterators. Weird though. I think this could be closed as invalid. Thanks!
[Bug libstdc++/89065] set::find always returns const iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89065 --- Comment #1 from Marc Glisse --- iterator and const_iterator are the same type for std::set, the elements are always immutable...
[Bug fortran/88810] gcc/fortran/dependency.c:2200: possible cut'n'paste error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88810 --- Comment #8 from kargl at gcc dot gnu.org --- Created attachment 45533 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45533=edit patch The attached patch re-arranges the code to hopefully clarify the logic. 2019-01-26 Steven G. Kargl PR fortran/88810 * dependency.c (gfc_dep_resolver): Re-arrange code to make the logic a bit more transparent. Fix 2 nearby formatting issues. Note, as the code is correct in its current form, I will hold this patch until stage 1 opens for gcc 10.
[Bug libstdc++/89065] New: set::find always returns const iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89065
Bug ID: 89065
Summary: set::find always returns const iterator
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: 1000hz.radiowave at gmail dot com
Target Milestone: ---
by the standard there are 2 overloads of find:
iterator find( const Key& key );
const_iterator find( const Key& key ) const;
However, libstdc++ seem to return const iterator even on non const object.
Consider the example:
#include
#include
struct FatKey { int x; int ref_count; };
bool operator<(const FatKey& fk1, const FatKey& fk2) { return fk1.x < fk2.x; }
int main()
{
std::set example = { {1, 0 }, {2, 0 }, {3, 0 }, {4, 0 } };
auto search = example.find({1, 0});
if (search != example.end()) {
search->ref_count++;
std::cout << "Found " << search->x << '\n';
} else {
std::cout << "Not found\n";
}
}
It fails to compile with the error:
main.cpp: In function 'int main()':
main.cpp:11:26: error: increment of member 'FatKey::ref_count' in read-only
object
search->ref_count++;
While it shouldn't.
[Bug fortran/34871] Flavor VARIABLE vs. FUNCTION: Accepts invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34871 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #5 from Harald Anlauf --- If the example in comment #0 is changed as follows: MODULE TESTS dimension :: k(4) CONTAINS function k() result (kk) kk = 35 end function k END MODULE TESTS the code - although still invalid - still compiles, but the dump-tree is completely different. I also see big differences in the dump-tree between comment #0 and the above for 9-trunk, but not for 8-branch. ISTR a patch (Steve) that fixed a related issue with RESULT(), maybe that is the place to look for a fix?
[Bug libstdc++/89044] libstdc++-6.dll is installed in the wrong directory cross-compiling with a multilib configuration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89044 --- Comment #5 from Jonathan Wakely --- OK thanks, I'll try to take a look into it.
[Bug testsuite/89064] New: [9 regression] libgomp.graphite/force-parallel-5.c fails starting with r268257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89064 Bug ID: 89064 Summary: [9 regression] libgomp.graphite/force-parallel-5.c fails starting with r268257 Product: gcc Version: 9.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: --- Does this test case need updating? spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/libgomp/testsuite/libgomp.graphite/force-parallel-5.c -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/ -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp -I/home/seurer/gcc/gcc-test2/libgomp/testsuite/../../include -I/home/seurer/gcc/gcc-test2/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp -ansi -pedantic-errors -O2 -ftree-parallelize-loops=4 -floop-parallelize-all -fdump-tree-parloops-details -fdump-tree-optimized -fno-loop-strip-mine -fno-loop-block -fdump-tree-graphite-all -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs -lm -o ./force-parallel-5.exe Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ offload_gcn37385.c -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/ -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp -I/home/seurer/gcc/gcc-test2/libgomp/testsuite/../../include -I/home/seurer/gcc/gcc-test2/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp -foffload=amdgcn-unknown-amdhsa -S -o offload_gcn37385.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ offload_gcn37385.c -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/ -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp -I/home/seurer/gcc/gcc-test2/libgomp/testsuite/../../include -I/home/seurer/gcc/gcc-test2/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp -foffload=amdgcn-unknown-amdhsa -S -o offload_gcn37385.s xgcc: fatal error: GCC is not configured to support amdgcn-unknown-amdhsa as offload target compilation terminated. compiler exited with status 1 PASS: libgomp.graphite/force-parallel-5.c (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/build/gcc-test2/gcc:.:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs Execution timeout is: 300 spawn [open ...] PASS: libgomp.graphite/force-parallel-5.c execution test libgomp.graphite/force-parallel-5.c: pattern found 0 times FAIL: libgomp.graphite/force-parallel-5.c scan-tree-dump-times graphite "2 loops carried no dependency" 1 PASS: libgomp.graphite/force-parallel-5.c scan-tree-dump-times optimized "loopfn.0" 4 PASS: libgomp.graphite/force-parallel-5.c scan-tree-dump-times optimized "loopfn.1" 4 testcase /home/seurer/gcc/gcc-test2/libgomp/testsuite/libgomp.graphite/graphite.exp completed in 1 seconds === libgomp Summary === # of expected passes4 # of unexpected failures1 r268257 | rguenth | 2019-01-25 02:13:34 -0600 (Fri, 25 Jan 2019) | 10 lines 2019-01-25 Richard Biener PR tree-optimization/86865 * graphite-scop-detection.c (scop_detection::can_represent_loop): Reject non-do-while loops. * gcc.dg/graphite/pr86865.c: New testcase. * gcc.dg/graphite/pr69728.c: XFAIL. * gcc.dg/graphite/scop-21.c: Likewise.
[Bug fortran/87336] [8/9 regression] wrong output for pointer dummy assiocated to target actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87336 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Paul Thomas --- Fixed on 8- and 9-branches. Thanks for the report. Paul
[Bug fortran/87336] [8/9 regression] wrong output for pointer dummy assiocated to target actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87336 --- Comment #8 from Paul Thomas --- Author: pault Date: Fri Jan 25 20:08:58 2019 New Revision: 268279 URL: https://gcc.gnu.org/viewcvs?rev=268279=gcc=rev Log: 2019-01-25 Paul Thomas PR fortran/87336 * trans-array.c (gfc_get_array_span): Try to get the element length of incomplete types. Return NULL_TREE otherwise. (gfc_conv_expr_descriptor): Only set the 'span' field if the above does not return NULL_TREE. Set 'span' field if possible for all new descriptors. 2019-01-25 Paul Thomas PR fortran/87336 * gfortran.dg/pointer_array_10.f90 : New test. * gfortran.dg/assign_10.f90 : Increase 'parm' count to 20. * gfortran.dg/transpose_optimization_2.f90 : Increase 'parm' count to 72. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pointer_array_10.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/trans-array.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gfortran.dg/assign_10.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/transpose_optimization_2.f90
[Bug fortran/88961] valgrind error in resolve_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88961 David Binderman changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Binderman --- This bug seems fixed by the time we get to revision 268250.
[Bug target/89063] New: [x86] lack of support for BEXTR from BMI extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89063
Bug ID: 89063
Summary: [x86] lack of support for BEXTR from BMI extension
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wojciech_mula at poczta dot onet.pl
Target Milestone: ---
Instruction BEXTR extracts an arbitrary unsigned bit field from 32- or 64-bit
value. As I see in `config/i386.md`, there's support for the immediate
variant available in AMD's TBM (TARGET_TBM).
Intel's variant gets parameters from a register. Although this variant
won't be profitable in all cases -- as we need an extra move to setup
the bit-field parameters in a register -- I bet bit-field-intensive
code might benefit from BEXTR.
---bextr.c---
#include
#include
uint64_t test(uint64_t x) {
const uint64_t a0 = (x & 0x3f);
const uint64_t a1 = (x >> 11) & 0x3f;
const uint64_t a2 = (x >> 22) & 0x3f;
return a0 + a1 + a2;
}
uint64_t test_intrinsics(uint64_t x) {
const uint64_t a0 = (x & 0x3f);
const uint64_t a1 = _bextr_u64(x, 11, 6);
const uint64_t a2 = _bextr_u64(x, 22, 6);
return a0 + a1 + a2;
}
---eof---
$ gcc --version
gcc (GCC) 9.0.0 20190117 (experimental)
$ gcc -O3 -mbmi -march=skylake bextr.c -c && objdump -d bextr.o
:
0: 48 89 famov%rdi,%rdx
3: 48 c1 ea 0b shr$0xb,%rdx
7: 48 89 f8mov%rdi,%rax
a: 48 89 d1mov%rdx,%rcx
d: 48 c1 e8 16 shr$0x16,%rax
11: 83 e0 3fand$0x3f,%eax
14: 83 e1 3fand$0x3f,%ecx
17: 48 8d 14 01 lea(%rcx,%rax,1),%rdx
1b: 83 e7 3fand$0x3f,%edi
1e: 48 8d 04 3a lea(%rdx,%rdi,1),%rax
22: c3 retq
0030 :
30: b8 0b 06 00 00 mov$0x60b,%eax
35: c4 e2 f8 f7 d7 bextr %rax,%rdi,%rdx
3a: b8 16 06 00 00 mov$0x616,%eax
3f: c4 e2 f8 f7 c7 bextr %rax,%rdi,%rax
44: 83 e7 3fand$0x3f,%edi
47: 48 01 d0add%rdx,%rax
4a: 48 01 f8add%rdi,%rax
4d: c3 retq
[Bug c++/88969] [9 Regression] ICE in build_op_delete_call, at cp/call.c:6509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88969 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #7 from Paolo Carlini --- Foxed.
[Bug c++/88969] [9 Regression] ICE in build_op_delete_call, at cp/call.c:6509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88969 --- Comment #6 from paolo at gcc dot gnu.org --- Author: paolo Date: Fri Jan 25 19:50:55 2019 New Revision: 268278 URL: https://gcc.gnu.org/viewcvs?rev=268278=gcc=rev Log: /cp 2019-01-25 Paolo Carlini PR c++/88969 * call.c (build_op_delete_call): Implement 7.6.2.5/(10.1). * decl2.c (coerce_delete_type): Use build_pointer_type instead of TYPE_POINTER_TO. /testsuite 2019-01-25 Paolo Carlini PR c++/88969 * g++.dg/cpp2a/destroying-delete2.C: New. * g++.dg/cpp2a/destroying-delete3.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp2a/destroying-delete2.C trunk/gcc/testsuite/g++.dg/cpp2a/destroying-delete3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/80708] [f08] ALLOCATE with MOLD error if source-expr is a derived type with null-init pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80708 --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #3) > > Code compiles if I delete the suspicious code. > Unfortunately, there is a regression in the testsuite, and even more unfortunate, the regression comes in code that involves CLASS, which I have zero experience with.
[Bug c++/89062] class template argument deduction failure with parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89062 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #3 from ensadc at mailnesia dot com --- I think this should be treated as a different bug from bug 87709. In bug 87709, the error is emitted in cp_parser_type_id_1. In this bug, the error is produced by grokdeclarator.
[Bug middle-end/67946] Function multiversioning ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67946 --- Comment #4 from Stupachenko Evgeny --- fixed starting from gcc 6
[Bug lto/66835] C++ openMP test failed after switching to C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66835 --- Comment #5 from Stupachenko Evgeny --- Yes, It is fixed starting from 5.3.
[Bug fortran/85603] ICE with character array substring assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85603 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Paul Thomas --- Fixed on trunk. Thanks for the report. Paul
[Bug fortran/68241] [meta-bug] [F03] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 85603, which changed state. Bug 85603 Summary: ICE with character array substring assignment https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85603 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 --- Comment #7 from Steve Kargl --- On Fri, Jan 25, 2019 at 06:40:14PM +, jvdelisle at gcc dot gnu.org wrote: > > --- Comment #6 from Jerry DeLisle --- > (In reply to Steve Kargl from comment #5) > --- snip --- > > > > Of course, I could be missing something obvious. Jerry? > > Hi Steve, I have time today to have a look at this. Does seem a bit unusual on > the surface. > Thanks. I was expecting to see something like result = remove(...) /* returns 0, -1, and set errno. */ if (iostat is present) iostat = result; /* could also set to errno. */ if (iomsg is present) iomsg = strerror (errno); /* Look up errno error message. */
[Bug fortran/80708] [f08] ALLOCATE with MOLD error if source-expr is a derived type with null-init pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80708
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #3 from kargl at gcc dot gnu.org ---
The problematic code is in resolve.c at lines 8028-8040.
This code was added in r241885 by vehre. I don't see
how this code can possible work for an allocation of
an array of derived types as all information about the
array shape of mold has been striped.
if (code->expr3 && code->expr3->mold
&& code->expr3->ts.type == BT_DERIVED)
{
/* Default initialization via MOLD (non-polymorphic). */
gfc_expr *rhs = gfc_default_initializer (>expr3->ts);
if (rhs != NULL)
{
gfc_resolve_expr (rhs);
gfc_free_expr (code->expr3);
code->expr3 = rhs;
}
}
Prior to the if statement one has
(gdb) p *code->expr3
$3 = {expr_type = EXPR_VARIABLE, ts = {type = BT_DERIVED, kind = 0, u = {
derived = 0x20306f600, cl = 0x20306f600, pad = 50787840}, interface =
0x0,
is_c_interop = 0, is_iso_c = 0, f90_type = BT_UNKNOWN, deferred = false,
interop_kind = 0x0}, rank = 1, shape = 0x2031689f0, symtree = 0x2023a45d0,
ref = 0x203149300, where = {nextc = 0x20308a9cc, lb = 0x20308a960}, base_expr
= 0x0,
is_boz = 0, is_snan = 0, error = 0, user_operator = 0, mold = 1,
must_finalize = 0,
no_bounds_check = 0, external_blas = 0, do_not_resolve_again = 0,
representation = {
length = 0, string = 0x0}, value = {logical = 0, iokind = M_READ, integer =
{{
_mp_alloc = 0, _mp_size = 0, _mp_d = 0x0}}, real = {{_mpfr_prec = 0,
_mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0}}, complex = {{re = {{
_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0}}, im
= {{
_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0,
op = {
op = GFC_INTRINSIC_BEGIN, uop = 0x0, op1 = 0x0, op2 = 0x0}, function = {
actual = 0x0, name = 0x0, isym = 0x0, esym = 0x0}, compcall = {actual =
0x0,
name = 0x0, base_object = 0x0, tbp = 0x0, ignore_pass = 0, assign = 0},
character = {length = 0, string = 0x0}, constructor = 0x0}, param_list =
0x0}
after the if () completes, one has
$4 = {expr_type = EXPR_STRUCTURE, ts = {type = BT_DERIVED, kind = 0, u = {
derived = 0x20306f600, cl = 0x20306f600, pad = 50787840}, interface =
0x0,
is_c_interop = 0, is_iso_c = 0, f90_type = BT_UNKNOWN, deferred = false,
interop_kind = 0x0}, rank = 0, shape = 0x0, symtree = 0x0, ref = 0x0, where
= {
nextc = 0x20306a1d0, lb = 0x20306a190}, base_expr = 0x0, is_boz = 0,
is_snan = 0,
error = 0, user_operator = 0, mold = 0, must_finalize = 0, no_bounds_check =
0,
external_blas = 0, do_not_resolve_again = 0, representation = {length = 0,
string = 0x0}, value = {logical = 51159296, iokind = 51159296, integer = {{
_mp_alloc = 51159296, _mp_size = 2, _mp_d = 0x0}}, real = {{
_mpfr_prec = 8641093888, _mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d =
0x0}},
complex = {{re = {{_mpfr_prec = 8641093888, _mpfr_sign = 0, _mpfr_exp = 0,
_mpfr_d = 0x0}}, im = {{_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp =
0,
_mpfr_d = 0x0, op = {op = 51159296, uop = 0x0, op1 = 0x0, op2 =
0x0},
function = {actual = 0x2030ca100, name = 0x0, isym = 0x0, esym = 0x0},
compcall = {
actual = 0x2030ca100, name = 0x0, base_object = 0x0, tbp = 0x0,
ignore_pass = 0,
assign = 0}, character = {length = 8641093888, string = 0x0},
constructor = 0x2030ca100}, param_list = 0x0}
Code compiles if I delete the suspicious code.
[Bug fortran/87151] allocating array of character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87151 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Paul Thomas --- I cleared up a load of ASSOCIATE related bugs on trunk. Attempts to apply a composite patch don't apply cleanly and so I am marking this as fixed. Paul
[Bug fortran/68241] [meta-bug] [F03] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 87151, which changed state. Bug 87151 Summary: allocating array of character https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87151 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/87336] [8/9 regression] wrong output for pointer dummy assiocated to target actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87336 --- Comment #7 from Paul Thomas --- (In reply to Harald Anlauf from comment #6) > The patch in comment #3 seems to apply to gcc-8, but I haven't regtested it. > Paul, do you intend to backport it? It is regtesting on 8-branch as I write. Paul
[Bug fortran/87937] [8 Regression] LHS reallocation broken inside "select type" and "associate"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87937 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Paul Thomas --- The regression is fixed on 8- and 9-branches. Paul
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #6 from Jerry DeLisle --- (In reply to Steve Kargl from comment #5) --- snip --- > > Of course, I could be missing something obvious. Jerry? Hi Steve, I have time today to have a look at this. Does seem a bit unusual on the surface.
[Bug c++/89062] class template argument deduction failure with parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89062 --- Comment #2 from Barry Revzin --- This may or may not be the same bug as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87709, I do not know.
[Bug c++/89062] class template argument deduction failure with parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89062 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-25 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/89062] New: class template argument deduction failure with parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89062
Bug ID: 89062
Summary: class template argument deduction failure with
parentheses
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Reduced from StackOverflow https://stackoverflow.com/q/54369677/2069064:
template
struct Foo {
Foo(T) {}
};
template
struct Bar {
Bar(T) {};
};
Foo foo(Bar{1});
This fails with:
:11:9: error: 'auto' parameter not permitted in this context
Foo foo(Bar{1});
^~~
Compiler returned: 1
Every other alternative is fine:
Foo foo(Bar(1)); // ok
Foo foo{Bar{1}}; // ok
Foo foo{Bar(1)}; // ok
Foo foo(Bar(1)); // ok
Foo foo(Bar{1}); // ok
Foo> foo(Bar{1}); // ok
[Bug ipa/88933] ICE: verify_cgraph_node failed (Error: caller edge count does not match BB count)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88933 --- Comment #17 from Martin Jambor --- OK, I did that too and proposed a patch in https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01525.html
[Bug fortran/85780] ICE in resolve_fl_procedure, at fortran/resolve.c:12504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85780 kargl at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #11 from kargl at gcc dot gnu.org --- Fixed on trunk. Closing.
[Bug c/89061] GCC 9 introduces false positive in -Wjump-misses-init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89061 --- Comment #1 from joseph at codesourcery dot com --- Guessing this might be another issue from pushdecl being called for compound literals (r259641). (Technically of course it's true that the jump misses the initialization of the anonymous object for the compound literal, that's just a useless warning.)
[Bug fortran/85780] ICE in resolve_fl_procedure, at fortran/resolve.c:12504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85780 --- Comment #10 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Jan 25 17:55:25 2019 New Revision: 268277 URL: https://gcc.gnu.org/viewcvs?rev=268277=gcc=rev Log: 2019-01-25 Steven G. Kargl PR fortran/85780 * decl.c (gfc_match_subroutine): Check for conflict between BIND(C) and alternative return. 2019-01-25 Steven G. Kargl PR fortran/85780 * gfortran.dg/pr85780.f90: Update testcase for error message. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr85780.f90
[Bug c++/89024] [7/8/9 Regression] ICE testing convertibility of incomplete enumeration types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89024 Marek Polacek changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code --- Comment #6 from Marek Polacek --- Nope, changing it back.
[Bug middle-end/88560] [9 Regression] armv8_2-fp16-move-1.c and related regressions after r266385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560 --- Comment #11 from Tamar Christina --- Hi Vladimir, I've tested the patch and checked the testcases. The code is now better in most cases so no issue there. The testcases will need to be updated but I can do that after the patch is committed. I've kicked off an overnight native regression test and will inspect the result and any failing tests and update you first thing monday.
[Bug target/88469] [7/8 regression] AAPCS/AAPCS64 - Struct with 64-bit bitfield (128-bit on AArch64) may be passed in wrong registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469 --- Comment #11 from Richard Earnshaw --- Author: rearnsha Date: Fri Jan 25 17:09:33 2019 New Revision: 268273 URL: https://gcc.gnu.org/viewcvs?rev=268273=gcc=rev Log: This is pretty unlikely in real code, but similar to Arm, the AArch64 ABI has a bug with the handling of 128-bit bit-fields, where if the bit-field dominates the overall alignment the back-end code may end up passing the argument correctly. This is a regression that started in gcc-6 when the ABI support code was updated to support overaligned types. The fix is very similar in concept to the Arm fix. 128-bit bit-fields are fortunately extremely rare, so I'd be very surprised if anyone has been bitten by this. PR target/88469 gcc/ * config/aarch64/aarch64.c (aarch64_function_arg_alignment): Add new argument ABI_BREAK. Set to true if the calculated alignment has changed in gcc-9. Check bit-fields for their base type alignment. (aarch64_layout_arg): Warn if argument passing has changed in gcc-9. (aarch64_function_arg_boundary): Likewise. (aarch64_gimplify_va_arg_expr): Likewise. gcc/testsuite/ * gcc.target/aarch64/aapcs64/test_align-10.c: New test. * gcc.target/aarch64/aapcs64/test_align-11.c: New test. * gcc.target/aarch64/aapcs64/test_align-12.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/test_align-10.c trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/test_align-11.c trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/test_align-12.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c trunk/gcc/testsuite/ChangeLog
[Bug c++/89055] wrong location with predefined macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89055
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment #1 from David Malcolm ---
The location ("loc") for the diagnostic is coming from here in
compute_array_index_type_loc:
9644 location_t loc = cp_expr_loc_or_loc (size, name ? name_loc :
input_location);
For the 2nd example:
(gdb) p /x loc
$4 = 0x8001
(gdb) p /x line_table->location_adhoc_data_map.data[1]
$7 = {locus = 0x285e0, src_range = {m_start = 0x7fff, m_finish = 0x28640},
data = 0x0}
i.e. we have regular locations for the caret and finish, but a macro location
for the "start":
(gdb) call inform (line_table->location_adhoc_data_map.data[1].locus, "caret")
t.C:2:21: note: caret
2 | char b[__SIZE_MAX__ << 1];
| ^
(gdb) call inform
(line_table->location_adhoc_data_map.data[1].src_range.m_start, "start")
t.C:2:8: note: start
2 | char b[__SIZE_MAX__ << 1];
|^~~~
(gdb) call inform
(line_table->location_adhoc_data_map.data[1].src_range.m_finish, "finish")
t.C:2:24: note: finish
2 | char b[__SIZE_MAX__ << 1];
|^
When printing "loc", diagnostic-show-locus.c's layout::maybe_add_location_range
generates a sane layout_range:
(gdb) p ri
$15 = {m_start = {m_line = 2, m_column = 8}, m_finish = {m_line = 2, m_column =
24},
m_range_display_kind = SHOW_RANGE_WITH_CARET, m_caret = {m_line = 2, m_column
= 21}, m_original_idx = 0, m_label = 0x0}
but then sanitizes it to just the caret location here:
973 if (start.line > finish.line
974 || !compatible_locations_p (src_range.m_start, m_primary_loc)
975 || !compatible_locations_p (src_range.m_finish, m_primary_loc))
976 {
977 /* Is this the primary location? */
978 if (m_layout_ranges.length () == 0)
979 {
980 /* We want to print the caret for the primary location, but
981 we must sanitize away m_start and m_finish. */
982 ri.m_start = ri.m_caret;
983 ri.m_finish = ri.m_caret;
984 }
due to:
compatible_locations_p (src_range.m_start, m_primary_loc)
returning false.
As noted in compatible_locations_p, it may be "too strong a condition" (but I'm
loathe to weaken that sanitization in stage 4; it exists due to e.g. PR c/68473
and PR c++/70105).
If I hack out that sanitization, the 2nd is printed, sanely, as:
t.C:2:21: error: size of array ‘b’ is negative
2 | char b[__SIZE_MAX__ << 1];
|~^~~~
(It's also not clear to me that it's a good idea to be building a compound
location containing macro locations in the first place)
[Bug middle-end/89037] checking ice emitting 128-bit bit-field initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89037 --- Comment #4 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Fri Jan 25 16:57:32 2019 New Revision: 268272 URL: https://gcc.gnu.org/viewcvs?rev=268272=gcc=rev Log: Fix output_constructor_bitfield handling of wide bitfields (PR89037) The testcase was failing because we were trying to access TREE_INT_CST_ELT (x, 1) of a 128-bit integer that was small enough to need only a single element. 2019-01-25 Richard Sandiford gcc/ PR middle-end/89037 * varasm.c (output_constructor_bitfield): Use wi::extract_uhwi instead of accessing TREE_INT_CST_ELT directly. gcc/testsuite/ PR middle-end/89037 * gcc.dg/pr89037.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr89037.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/varasm.c
[Bug c++/89024] [7/8/9 Regression] ICE testing convertibility of incomplete enumeration types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89024 Marek Polacek changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code --- Comment #5 from Marek Polacek --- Jason says this is invalid, changing the keywords.
[Bug c++/89036] [8/9 Regression] ICE if destructor has a requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89036 --- Comment #3 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01513.html
[Bug c++/59813] tail-call elimination didn't fire for left-shift of char to cout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813 Jakub Jelinek changed: What|Removed |Added CC||vanyacpp at gmail dot com --- Comment #7 from Jakub Jelinek --- *** Bug 77938 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/77938] missing tailcall optimization in case when local variable escapes that goes out of scope before the possible tail call site
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77938 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #6 from Jakub Jelinek --- Let's track all of this in one PR. *** This bug has been marked as a duplicate of bug 59813 ***
[Bug c++/59813] tail-call elimination didn't fire for left-shift of char to cout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- *** Bug 89060 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/89060] Improve tail call optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89060 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Jakub Jelinek --- . *** This bug has been marked as a duplicate of bug 59813 ***
[Bug rtl-optimization/87639] GCC fails to consider end of automatic object lifetime when determining sibcall eligibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87639 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Jakub Jelinek --- . *** This bug has been marked as a duplicate of bug 89060 ***
[Bug tree-optimization/89060] Improve tail call optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89060 Jakub Jelinek changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #5 from Jakub Jelinek --- *** Bug 87639 has been marked as a duplicate of this bug. ***
[Bug fortran/80708] [f08] ALLOCATE with MOLD error if source-expr is a derived type with null-init pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80708 Vladimir Fuka changed: What|Removed |Added CC||vladimir.fuka at gmail dot com --- Comment #2 from Vladimir Fuka --- Here https://stackoverflow.com/questions/54356803/can-gfortran-allocate-with-mold-or-not/54368355#54368355 the error appears for an allocatable component. Does not have to be an array. I can also confirm the same for an initialized pointer component.
[Bug tree-optimization/89049] [8/9 Regression] Unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89049 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #8 from Segher Boessenkool --- (In reply to Richard Biener from comment #5) > So combine can see [ snip, 11 ] > with its uses [ snip, 13 and 25 ] > but somehow it only tries 11 -> 13: combine only tries to combine something with its first use. Trying second (or third, etc.) uses as well would easily take exponential time complexity. I do however want combine to try to combine an insn together with its first two uses. That is just as linear as even simple 1+1 combinations, and it is likely to succeed (in fact there is at least one other PR where I wanted this).
[Bug tree-optimization/89060] Improve tail call optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89060 --- Comment #4 from Andrew Pinski --- And even PR 59813.
[Bug tree-optimization/89060] Improve tail call optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89060 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > I suspect there is even older bug which reports this. PR 77938
[Bug tree-optimization/88760] GCC unrolling is suboptimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760 --- Comment #23 from Wilco --- (In reply to ktkachov from comment #22) > helps even more. On Cortex-A72 it gives a bit more than 6% (vs 3%) > improvement on parest, and about 5.3% on a more aggressive CPU. > I tried unrolling 8x in a similar manner and that was not faster than 4x on > either target. The 4x unrolled version has 19 instructions (and microops) vs 7*4 for the non-unrolled version, a significant reduction (without LDP it would be 21 vs 28). There is potential to use 2 more LDPs and use load+writeback which would make it 15 vs 28 instructions, so close to 2x reduction in instructions.
[Bug tree-optimization/89060] Improve tail call optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89060 --- Comment #2 from Andrew Pinski --- I suspect there is even older bug which reports this.
[Bug target/88734] [8 Regression] AArch64's ACLE intrinsics give an ICE instead of compile error when option mismatch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88734 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #11 from Ramana Radhakrishnan --- (In reply to Tamar Christina from comment #10) > Thanks Jakub! testing hasn't shown any breakages. I would prefer this to be backported to GCC-8 if it has baked reasonably on trunk.
[Bug c++/80916] [7/8/9 Regression] Spurious "declared 'static' but never defined" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80916 --- Comment #9 from Jason Merrill --- It has internal linkage because one of its template arguments is a local class, and it isn't instantiated because it isn't ever used. It's added to cgraph as a possible devirtualization target. I think the last of these is the place to attack this issue, since it's also the source of the regression.
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Jonathan Wakely changed: What|Removed |Added CC||ulidtko at gmail dot com --- Comment #35 from Jonathan Wakely --- *** Bug 89038 has been marked as a duplicate of this bug. ***
[Bug c++/89038] #pragma GCC diagnostic ignored "-Wunknown-pragmas" does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89038 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Jonathan Wakely --- It is a dup of PR 53431, I see no reason to keep this one open as well. The -Wunknown-pragmas warning is emitted by the preprocessor, and for C++ the preprocessor doesn't respect the diagnostic pragma. *** This bug has been marked as a duplicate of bug 53431 ***
[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #32 from Wilco --- Author: wilco Date: Fri Jan 25 13:29:06 2019 New Revision: 268265 URL: https://gcc.gnu.org/viewcvs?rev=268265=gcc=rev Log: [PATCH][AArch64] Fix generation of tst (PR87763) The TST instruction no longer matches in all cases due to changes in Combine. The fix is simple, we now need to allow a subreg as well when selecting the cc_mode. This fixes the tst_5.c and tst_6.c failures. AArch64 regress & bootstrap OK. PR rtl-optimization/87763 * config/aarch64/aarch64.c (aarch64_select_cc_mode): Allow SUBREG when matching CC_NZmode compare. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c
[Bug tree-optimization/89060] Improve tail call optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89060 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- This was previously reported as PR 87639, but this report has more analysis. Please close one or the other as a dup.
[Bug target/89012] SH2 (FDPIC) duplicate symbols in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89012 --- Comment #2 from Oleg Endo --- You can compile the code with the '-dp' option to see which insn patterns make up the asm code. The pattern names will be emitted as comments in the asm output.
[Bug debug/88878] .debug_pubnames/types empty with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88878 --- Comment #1 from Richard Biener --- Applies to -fdebug-types-section as well.
[Bug c/89061] New: GCC 9 introduces false positive in -Wjump-misses-init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89061
Bug ID: 89061
Summary: GCC 9 introduces false positive in -Wjump-misses-init
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: berrange at redhat dot com
Target Milestone: ---
The following demo program
$ cat demo.c
#include
struct demo {
const char *cmd;
};
int main(void)
{
struct demo demo = {0};
if ((demo.cmd = getenv("FOO")) == NULL) {
goto cleanup;
}
demo = (struct demo) { .cmd = "foo" };
cleanup:
return 0;
}
Results in new false positive warnings with GCC 9
$ gcc -Wjump-misses-init -o demo demo.c
demo.c: In function ‘main’:
demo.c:13:5: warning: jump skips variable initialization [-Wjump-misses-init]
13 | goto cleanup;
| ^~~~
demo.c:18:2: note: label ‘cleanup’ defined here
18 | cleanup:
| ^~~
demo.c:16:24: note: ‘({anonymous})’ declared here
16 | demo = (struct demo) { .cmd = "foo" };
|^
'demo' is fully initialized at every step of the program, even taking into
account the jumps.
It appears to be triggered by the full struct assignment. If I change
demo = (struct demo) { .cmd = "foo" };
to
demo.cmd = "foo";
then it no longer triggers the false positive warning.
This is seen on Fedora 30 rawhide with gcc-9.0.1-0.1.fc30.x86_64 which appears
to be using a git master snapshot taken sometime on 2019/01/23.
[Bug tree-optimization/89049] [8/9 Regression] Unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89049 --- Comment #7 from Richard Biener --- Author: rguenth Date: Fri Jan 25 12:46:24 2019 New Revision: 268264 URL: https://gcc.gnu.org/viewcvs?rev=268264=gcc=rev Log: 2019-01-25 Richard Biener PR tree-optimization/89049 * tree-vect-loop.c (vect_compute_single_scalar_iteration_cost): Look at the pattern stmt to determine if the stmt is vectorized. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug target/89028] 8-byte loop isn't vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89028
--- Comment #2 from H.J. Lu ---
I am working on a patch to generate:
[hjl@gnu-hsw-1 pr89028]$ cat x.i
void
foo (char* restrict r, char* restrict a){
for (int i = 0; i < 8; i++){
r[i] += a[i];
}
}
[hjl@gnu-hsw-1 pr89028]$ make x.s
/export/build/gnu/tools-build/gcc-mmx/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-mmx/build-x86_64-linux/gcc/ -O3 -S x.i
[hjl@gnu-hsw-1 pr89028]$ cat x.s
.file "x.i"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
movq(%rdi), %xmm0
movq(%rsi), %xmm1
paddb %xmm1, %xmm0
movq%xmm0, (%rdi)
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 9.0.1 20190124 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-hsw-1 pr89028]$
[Bug debug/87295] [early debug] ICE with -ffat-lto-objects -fdebug-types-section -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87295 --- Comment #4 from Richard Biener --- The odd thing I see is that we have two type DIEs with the same signature (but different members). DIE0: DW_TAG_compile_unit (0x768960a0) abbrev id: 0 offset: 0 mark: 0 DW_AT_producer: "GNU C++17 9.0.1 20190125 (experimental) [trunk revision 268137] -flto -ffat-lto-objects -fdebug-types-section -g -std=gnu++17" DW_AT_language: 4 DW_AT_name: "t.ii" DW_AT_comp_dir: "/abuild/rguenther/trunk2-g/gcc" DIE0: DW_TAG_structure_type (0x76896820) abbrev id: 0 offset: 0 mark: 0 signature: 2e365acce74a6a1f DW_AT_name: "integral_constant" DW_AT_signature: die -> signature: 2e365acce74a6a1f (0x768962d0) DW_AT_declaration: 1 DIE0: DW_TAG_member (0x76896320) abbrev id: 0 offset: 0 mark: 0 DW_AT_name: "value" DW_AT_decl_file: "t.ii" (0) DW_AT_decl_line: 4 DW_AT_decl_column: 24 DW_AT_type: die -> 0 (0x768963c0) DW_AT_external: 1 DW_AT_declaration: 1 DW_AT_const_expr: 1 DW_AT_inline: 1 DIE0: DW_TAG_subprogram (0x768964b0) abbrev id: 0 offset: 0 mark: 0 DW_AT_external: 1 DW_AT_name: "operator integral_constant::value_type" DW_AT_decl_file: "t.ii" (0) DW_AT_decl_line: 6 DW_AT_decl_column: 13 DW_AT_linkage_name: "_ZNK17integral_constantIbLb0EEcvbEv" DW_AT_type: die -> 0 (0x76896a00) DW_AT_declaration: 1 ... DIE0: DW_TAG_structure_type (0x76896a50) abbrev id: 0 offset: 0 mark: 0 DW_AT_name: "integral_constant" DW_AT_signature: die -> signature: 2e365acce74a6a1f (0x768962d0) DW_AT_declaration: 1 DIE0: DW_TAG_typedef (0x76896a00) abbrev id: 0 offset: 0 mark: 0 DW_AT_name: "value_type" DW_AT_decl_file: "t.ii" (0) DW_AT_decl_line: 5 DW_AT_decl_column: 15 DW_AT_type: die -> 0 (0x76896aa0) but the DW_AT_signature of the first one gets somehow mangled. So the "duplicate" is because originally it looks like DIE0: DW_TAG_structure_type (0x768962d0) abbrev id: 0 offset: 0 mark: 0 DW_AT_name: "integral_constant" DW_AT_byte_size: 1 DW_AT_decl_file: "t.ii" (0) DW_AT_decl_line: 2 DW_AT_decl_column: 8 DIE0: DW_TAG_member (0x76896320) abbrev id: 0 offset: 0 mark: 0 DW_AT_name: "value" DW_AT_decl_file: "t.ii" (0) DW_AT_decl_line: 4 DW_AT_decl_column: 24 DW_AT_type: die -> 0 (0x768963c0) DW_AT_external: 1 DW_AT_declaration: 1 DW_AT_const_expr: 1 DW_AT_inline: 1 DIE0: DW_TAG_typedef (0x76896460) abbrev id: 0 offset: 0 mark: 0 DW_AT_name: "value_type" DW_AT_decl_file: "t.ii" (0) DW_AT_decl_line: 5 DW_AT_decl_column: 15 DW_AT_type: die -> 0 (0x76896370) DIE0: DW_TAG_subprogram (0x768964b0) abbrev id: 0 offset: 0 mark: 0 DW_AT_external: 1 DW_AT_name: "operator integral_constant::value_type" DW_AT_decl_file: "t.ii" (0) DW_AT_decl_line: 6 DW_AT_decl_column: 13 DW_AT_type: die -> 0 (0x76896460) DW_AT_declaration: 1 DW_AT_object_pointer: die -> 0 (0x76896500) DIE0: DW_TAG_formal_parameter (0x76896500) abbrev id: 0 offset: 0 mark: 0 DW_AT_type: die -> 0 (0x76896550) DW_AT_artificial: 1 and we duplicate this out to DIE0: DW_TAG_structure_type (0x76896820) abbrev id: 0 offset: 0 mark: 1 signature: 2e365acce74a6a1f DW_AT_name: "integral_constant" DW_AT_signature: die -> signature: 2e365acce74a6a1f (0x768962d0) DW_AT_declaration: 1 DIE0: DW_TAG_member (0x76896320) abbrev id: 0 offset: 0 mark: 1 DW_AT_name: "value" DW_AT_decl_file: "t.ii" (0) DW_AT_decl_line: 4 DW_AT_decl_column: 24 DW_AT_type: die -> 0 (0x768963c0) DW_AT_external: 1 DW_AT_declaration: 1 DW_AT_const_expr: 1 DW_AT_inline: 1 DIE0: DW_TAG_subprogram (0x768964b0) abbrev id: 0 offset: 0 mark: 1 DW_AT_external: 1 DW_AT_name: "operator integral_constant::value_type" DW_AT_decl_file: "t.ii" (0) DW_AT_decl_line: 6 DW_AT_decl_column: 13 DW_
[Bug c/89045] [9 Regression] ICE in get_parm_info, at c/c-decl.c:7518
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89045 Martin Liška changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Known to work||8.2.0 Known to fail||9.0 --- Comment #2 from Martin Liška --- Sstarted with r259641.
[Bug fortran/88649] runtime error: load of value 137971008, which is not a valid value for type 'gfc_intrinsic_op'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88649 --- Comment #3 from Martin Liška --- I've got a patch candidate for it, am testing that.
[Bug fortran/88649] runtime error: load of value 137971008, which is not a valid value for type 'gfc_intrinsic_op'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88649 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Minimal test-case: $ cat r.f90 a= 3 .XOR. 5 end $ ./xgcc -B. r.f90 -c -fdec ../../gcc/fortran/resolve.c:4148:23: runtime error: load of value 138343072, which is not a valid value for type 'gfc_intrinsic_op' #0 0xb1797f in resolve_operator ../../gcc/fortran/resolve.c:4148 #1 0xb34835 in gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:6847 #2 0xb66561 in gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11291 #3 0xba15d8 in resolve_codes ../../gcc/fortran/resolve.c:16737 #4 0xba17df in gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16772 #5 0xad4ae4 in resolve_all_program_units ../../gcc/fortran/parse.c:6073 #6 0xad5dd6 in gfc_parse_file() ../../gcc/fortran/parse.c:6323 #7 0xc3b836 in gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204 #8 0x2309950 in compile_file ../../gcc/toplev.c:456 #9 0x2310e4b in do_compile ../../gcc/toplev.c:2176 #10 0x2311479 in toplev::main(int, char**) ../../gcc/toplev.c:2311 #11 0x46926ce in main ../../gcc/main.c:39 #12 0x7608cfea in __libc_start_main ../csu/libc-start.c:308 #13 0x875bd9 in _start (/home/marxin/Programming/gcc2/objdir/gcc/f951+0x875bd9) Let me try to fix it.
[Bug target/89058] GCC 7->8 regression: ARM(64) ld3 st4 less optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89058 --- Comment #2 from Allan Jensen --- Oops, sorry.
[Bug tree-optimization/89059] Once we emit switchconf tables, we don't optimize them anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89059 --- Comment #2 from Jakub Jelinek --- Ulrich (CCed) reported that. If the __builtin_unreachable hint is inside of foo, we do optimize it properly.
[Bug tree-optimization/88739] [7/8/9 Regression] Big-endian union bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739 --- Comment #51 from rsandifo at gcc dot gnu.org --- FWIW, the (In reply to Richard Biener from comment #44) > Created attachment 45523 [details] > workaround > > So I am testing the following workaround, at least "most suitable" for > branches. > It avoids generating affected BIT_FIELD_REFs (with bases with integral types > that have a precision not matching the size of the mode). > > Can arm folks please test this patch and aid me (provide) a dg-torture > testcase that currently fails? It passed testing on aarch64-linux-gnu (LE) and aarch64_be-elf.
[Bug tree-optimization/89060] New: Improve tail call optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89060
Bug ID: 89060
Summary: Improve tail call optimization
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
void qux (char *);
int baz (void);
int
foo (void)
{
char buf[64];
qux (buf);
return baz ();
}
int
bar (void)
{
{
char buf[64];
qux (buf);
}
return baz ();
}
While we must not tail call optimize the baz call in foo, because an address of
a local variable escapes and it could be live during the tail call, in bar we
don't tail call optimize it either, but we should.
The IL difference in *.tailc between foo and bar is:
char buf[64];
int _5;
[local count: 1073741824]:
qux ();
+ buf ={v} {CLOBBER};
_5 = baz ();
- buf ={v} {CLOBBER};
return _5;
Right now, we just do:
/* Make sure the tail invocation of this function does not indirectly
refer to local variables. (Passing variables directly by value
is OK.) */
FOR_EACH_LOCAL_DECL (cfun, idx, var)
{
if (TREE_CODE (var) != PARM_DECL
&& auto_var_in_fn_p (var, cfun->decl)
&& may_be_aliased (var)
&& (ref_maybe_used_by_stmt_p (call, var)
|| call_may_clobber_ref_p (call, var)))
return;
}
Perhaps we could record all these variables in a bitmap and if there are any,
perform a variable life analysis like cfgexpand.c does to determine variable
conflicts or what has been discussed for PR86214, and if we can prove that
those variables escaped, but are not live at the point of the tail call, we
could still tail call optimize this.
[Bug tree-optimization/89059] Once we emit switchconf tables, we don't optimize them anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89059 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-25 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed! Clang has the same problem. We at least fold away the guard check. How did you come to it Jakub?
[Bug c++/89038] #pragma GCC diagnostic ignored "-Wunknown-pragmas" does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89038 --- Comment #3 from Maxim Ivanov --- (In reply to Eric Gallager from comment #2) > I think this is a dup of something but I can't remember the bug number right > now; I'll search harder later... Eric, take a look at bug #53431, I think that's what you meant. It's a pretty similar report about in-source pragmas not working in C++. Further, that thread contains a WIP patch from Manuel López-Ibáñez, which he expressly abandoned while encouraging others to finish and merge it. P.S. I do harbor a hope to resolve this on my own, once I accumulate the necessary courage to allocate some time for a little GCC contribution. That's why I'm reporting a separate issue knowing it's a duplicate :)
[Bug tree-optimization/89059] New: Once we emit switchconf tables, we don't optimize them anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89059
Bug ID: 89059
Summary: Once we emit switchconf tables, we don't optimize them
anymore
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
For the following testcase:
static inline int
foo (int a)
{
switch (a)
{
case 0:
return 0;
case 1 ... 3:
return 1;
case 4 ... 10:
return -1;
default:
return 42;
}
}
int
bar (int a)
{
if (a < 0 || a > 3)
__builtin_unreachable ();
return foo (a);
}
we emit unnecessary code, I understand we want to run switchconf early, so that
inliner can already see simple code, but in this case we don't know value
ranges of the switch condition. So, I wonder if we couldn't mark the CSWTCH
tables with some attribute or whatever and in late GIMPLE reconsider if we
can't emit something simpler, whether it is a bit test or simple comparison.
If we commit to a bit test, I wonder if we are able to simplify it later too.
[Bug libstdc++/89044] libstdc++-6.dll is installed in the wrong directory cross-compiling with a multilib configuration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89044 --- Comment #4 from Andoni --- I am sorry for now explaining my self good enough. I am building a GCC toolchain for Windows: a cross-compiler one with Linux as host and a native one with Windows as host. Both toolchains are built in a Linux machine Host:Linux Target:Windows ../configure --prefix /home/andoni/mingw/linux/multilib --libdir /home/andoni/mingw/linux/multilib/lib --disable-maintainer-mode --disable-silent-rules --disable-gtk-doc --disable-introspection --with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm --disable-maintainer-mode--disable-shared --disable-libgomp --disable-libquadmath --disable-libquadmath-support --disable-libmudflap --disable-libmpx --disable-libssp --disable-nls --enable-threads=posix --enable-__cxa_atexit --enable-lto --enable-plugin --enable-multiarch --enable-languages=c,c++ --enable-long-long --with-sysroot=/home/andoni/mingw/linux/multilib/x86_64-w64-mingw32/sysroot --with-local-prefix=/home/andoni/mingw/linux/multilib/x86_64-w64-mingw32/sysroot --target=x86_64-w64-mingw32 --host=x86_64-pc-linux-gnu Host:Windows Target:Windows ../configure --prefix /home/andoni/mingw/windows/multilib --libdir /home/andoni/mingw/windows/multilib/lib --disable-maintainer-mode --disable-silent-rules --disable-gtk-doc --disable-introspection --with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm --disable-maintainer-mode--disable-shared --disable-libgomp --disable-libquadmath --disable-libquadmath-support --disable-libmudflap --disable-libmpx --disable-libssp --disable-nls --enable-threads=posix --enable-__cxa_atexit --enable-lto --enable-plugin --enable-multiarch --enable-languages=c,c++ --enable-long-long --with-sysroot=/home/andoni/mingw/windows/multilib/x86_64-w64-mingw32/sysroot --with-local-prefix=/home/andoni/mingw/windows/multilib/x86_64-w64-mingw32/sysroot --target=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 When cross-compiling the Windows toolchain, libstdc++-6.dll should be installed in lib/ and lib32/ instead of bin, in a similar fashion as the EH dll's, that are installed in lib/libgcc_s_seh-1.dll and lib32/libgcc_s_sjlj-1.dll. Being installed in bin, the x86_64 one is overridden during make install and there is a single dll for x86 installed in bin/
[Bug c++/89053] initializer-string too long for a large char array initialized with empty string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89053 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-25 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- It's failed this way since at least GCC 4.3.6
[Bug c++/89055] wrong location with predefined macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89055 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-25 Ever confirmed|0 |1
[Bug c++/89056] Optimizer generates bad code for non-void function that fails to return a value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89056 --- Comment #5 from Jonathan Wakely --- Yes, it allows it. It's undefined behaviour for your code to reach the end of the function (because there's no return statement) so the compiler assumes that the function will never reach that point. That means the loop must keep going (only exiting if one of the expressions in the loop throws an exception). If that's what you intended, then you can mark the function with the noreturn attribute to inform the compiler of your intention, or you can explicitly add __builtin_unreachable() at the end of the function. Either of those will suppress the warning. Of course that's not what you intended here, so you should heed the warning and fix the code.
[Bug libstdc++/89044] libstdc++-6.dll is installed in the wrong directory cross-compiling with a multilib configuration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89044 --- Comment #3 from Jonathan Wakely --- I don't understand how "gcc with multilib support for linux" can produce .dll files, so I don't understand what you're doing. Please provide the full configure command (which is shown in the output of 'gcc -v' which https://gcc.gnu.org/bugs asks you to provide). If you're cross-compiling, we need to know the build and host triplets as well as the target.
[Bug tree-optimization/86865] [9 Regression] Wrong code w/ -O2 -floop-parallelize-all -fstack-reuse=none -fwrapv -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-loop-ivcanon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86865 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|9.0 |8.3 --- Comment #10 from Richard Biener --- Fixed on trunk and GCC8 branch.
[Bug tree-optimization/86865] [9 Regression] Wrong code w/ -O2 -floop-parallelize-all -fstack-reuse=none -fwrapv -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-loop-ivcanon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86865 --- Comment #9 from Richard Biener --- Author: rguenth Date: Fri Jan 25 10:12:37 2019 New Revision: 268260 URL: https://gcc.gnu.org/viewcvs?rev=268260=gcc=rev Log: 2019-01-25 Richard Biener PR tree-optimization/86865 * graphite-scop-detection.c (scop_detection::can_represent_loop): Reject non-do-while loops. * gcc.dg/graphite/pr86865.c: New testcase. * gcc.dg/graphite/pr69728.c: XFAIL. * gcc.dg/graphite/scop-21.c: Likewise. libgomp/ * testsuite/libgomp.graphite/force-parallel-5.c: XFAIL. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/graphite/pr86865.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/graphite-scop-detection.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.dg/graphite/pr69728.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/graphite/scop-21.c branches/gcc-8-branch/libgomp/ChangeLog branches/gcc-8-branch/libgomp/testsuite/libgomp.graphite/force-parallel-5.c
