[Bug fortran/55735] ICE with deferred-length strings in COMMON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735 --- Comment #12 from Jürgen Reuter --- This is still present. Any progress?
[Bug c++/91697] New: Cannot use this in noexcept specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91697
Bug ID: 91697
Summary: Cannot use this in noexcept specifier
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugbjorn at fahller dot se
Target Milestone: ---
This C++11 code compiles with g++ 9.1, but fails with g++ versions 8, 7, 6, 5,
4.9, 4.8, and 4.7.
template
void f(const T&) noexcept;
struct S
{
auto fr() const -> decltype(f(*this));
void fe() const noexcept(noexcept(f(*this)));
};
The compilation error is on the use of 'this' in the noexcept specifier for
S::fe().
The message is:
t.cpp:7:42: error: invalid use of 'this' at top level
void fe() const noexcept(noexcept(f(*this)));
^~~~
https://godbolt.org/z/NvNMZC
It looks similar to bug 91141, except this one does compile with g++-9.
[Bug other/91698] New: -O2 optimization generates invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91698
Bug ID: 91698
Summary: -O2 optimization generates invalid code
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: lbukata at gmail dot com
Target Milestone: ---
Created attachment 46852
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46852&action=edit
A minimal example to reproduce the issue.
I encountered SIGSEGV in Extreme Tux Racer game.
I found the existing report at
https://sourceforge.net/p/extremetuxracer/discussion/help/thread/8cd652ef/?limit=25#9a38.
Initially, I thought that it is a bug in the source
code but after a deeper investigation I was able
to extract a part of the code that does not compile
fine if '-O2' optimization is used ('-O3' compiles fine).
It looks like that the optimizer removes 'if' branch
even though it should not.
Compile command (test.cpp in the attachment):
$ x86_64-pc-linux-gnu-g++-9.2.0 -E -v -g -march=native -O2 -pipe -std=c++11
test.cpp -o test
Using built-in specs.
COLLECT_GCC=x86_64-pc-linux-gnu-g++-9.2.0
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-9.2.0/work/gcc-9.2.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/9.2.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/g++-v9
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/python
--enable-languages=c,c++,go,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 9.2.0 p1' --disable-esp --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-systemtap
--enable-vtable-verify --enable-lto --with-isl --disable-isl-version-check
--enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 9.2.0 (Gentoo 9.2.0 p1)
COLLECT_GCC_OPTIONS='-E' '-v' '-g' '-march=native' '-O2' '-pipe' '-std=c++11'
'-o' 'test' '-shared-libgcc'
/usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/cc1plus -E -quiet -v -D_GNU_SOURCE
test.cpp -o test -march=sandybridge -mmmx -mno-3dnow -msse -msse2 -msse3
-mssse3 -mno-sse4a -mcx16 -msahf -mno-movbe -maes -mno-sha -mpclmul -mpopcnt
-mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-sgx -mno-bmi2
-mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1
-mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed
-mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er
-mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec
-mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma
-mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx
-mno-clzero -mno-pku -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2
-mno-avx512vnni -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri
-mno-movdir64b -mno-waitpkg -mno-cldemote -mno-ptwrite --param l1-cache-size=32
--param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=sandybridge
-std=c++11 -g -fworking-directory -O2
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/g++-v9
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/g++-v9/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/g++-v9/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include-fixed
/usr/include
End of search list.
COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-E' '-v' '-g' '-march=native' '-O2' '-pipe' '-std=c++11'
'-o' 'test' '-shared-libgcc'
Run the program:
$ perl -e 'print "-10\n"x10'
[Bug tree-optimization/91665] [8/9/10 Regression] ICE in build_vector_from_val, at tree.c:1904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91665 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Sat Sep 7 09:52:01 2019 New Revision: 275486 URL: https://gcc.gnu.org/viewcvs?rev=275486&root=gcc&view=rev Log: PR tree-optimization/91665 * tree-vect-loop.c (vectorizable_reduction): Punt if base has type incompatible with the type of PHI result. * gcc.dg/vect/pr91665.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr91665.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug other/91698] -O2 optimization generates invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91698 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- >val <= scores[pos] && pos < num Swap these and you will get correct behavior.
[Bug other/91698] -O2 optimization generates invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91698 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Your testcase is invalid: g++ -g -o pr91698 pr91698.C -std=c++11 -g -O2 -fsanitize=undefined [jakub@tucnak gcc]$ ./pr91698 < /tmp/10 pr91698.C:19:26: runtime error: index 8 out of bounds for type 'float [8]' pr91698.C:19:26: runtime error: load of address 0x7ffd384fc3d0 with insufficient space for an object of type 'float' 0x7ffd384fc3d0: note: pointer points here 00 00 20 c1 e0 7f 5d 6d f0 7f 00 00 00 00 00 00 00 00 00 00 f0 16 40 00 00 00 00 00 00 16 40 00 ^ The bug is on the: while (val <= scores[pos] && pos < num) pos++; line where you perform out of bound access val <= scores[8] and when you encounter UB, anything can happen, as the compiler optimizes based on the assumption that UB doesn't happen. Instead, you should write say: while (pos < num && val <= scores[pos]) pos++;
[Bug other/91698] -O2 optimization generates invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91698 --- Comment #3 from Libor Bukata --- I apology for a false positive, I will sent a patch to the upstream project to fix it. Thanks.
[Bug lto/84579] __gnu_lto_v1 should be removed when linking with -fno-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84579 Romain Geissler changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Romain Geissler --- Hi, I am closing this ticket as it's fixed in gcc 10. This will not backported officially to gcc 8 and 9, however in the Amadeus toolchain we are using these different patches untouched implemented that in gcc 8 and 9 for one month, successfully so far. Cheers, Romain
[Bug target/91289] powerpc-eabi: Usage of -fstack-limit-symbol leads to internal compiler error during RTL pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289 Segher Boessenkool changed: What|Removed |Added Target|powerpc |powerpc*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-07 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Segher Boessenkool --- Confirmed. Any target. Needs -O0 -m32 -fstack-limit-symbol=symbol_name .
[Bug target/91289] powerpc-eabi: Usage of -fstack-limit-symbol leads to internal compiler error during RTL pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289 Segher Boessenkool changed: What|Removed |Added Known to work||4.8.5 Known to fail||5.1.0 --- Comment #4 from Segher Boessenkool --- (I don't have working GCC 5 and GCC 6 compilers handy, but based on comment 1, I've marked those versions as failing as well).
[Bug tree-optimization/91699] New: [10 Regression] Bogus warnings with -O3 -flto after revision r274997
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91699 Bug ID: 91699 Summary: [10 Regression] Bogus warnings with -O3 -flto after revision r274997 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: iains at gcc dot gnu.org, msebor at gcc dot gnu.org Target Milestone: --- After revision r274997 I see the following failures FAIL: gfortran.dg/argument_checking_1.f90 -g -O3 -fwhole-program -flto (test for excess errors) FAIL: gfortran.dg/argument_checking_8.f90 -g -O3 -fwhole-program -flto (test for excess errors) FAIL: gfortran.dg/arrayio_derived_1.f90 -g -O3 -fwhole-program -flto (test for excess errors) FAIL: gfortran.dg/dtio_25.f90 -g -O3 -fwhole-program -flto (test for excess errors) FAIL: gfortran.dg/dtio_28.f03 -g -O3 -fwhole-program -flto (test for excess errors) FAIL: gfortran.dg/dtio_30.f03 -g -O3 -fwhole-program -flto (test for excess errors) FAIL: gfortran.dg/pr39865.f90 -g -O3 -fwhole-program -flto (test for excess errors) % /opt/gcc/gcc10p-274996p1/bin/gfortran /opt/gcc/_clean/gcc/testsuite/gfortran.dg/argument_checking_1.f90 -O3 -flto % /opt/gcc/gcc10p-274997p1/bin/gfortran /opt/gcc/_clean/gcc/testsuite/gfortran.dg/argument_checking_1.f90 -O3 -flto In function 'copy2', inlined from 'MAIN__' at /opt/gcc/_clean/gcc/testsuite/gfortran.dg/argument_checking_1.f90:13:0, inlined from 'main' at /opt/gcc/_clean/gcc/testsuite/gfortran.dg/argument_checking_1.f90:18:0: /opt/gcc/_clean/gcc/testsuite/gfortran.dg/argument_checking_1.f90:28: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 28 | out(1:2,1:5) = in(1:2,1:5) | Note that pr39865.f90 requires -fwhole-program in order to give the warning. This is not fixed by the patch at https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00425.html
[Bug tree-optimization/91699] [10 Regression] Bogus warnings with -O3 -flto after revision r274997
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91699 Dominique d'Humieres changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-07 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91647 Ever confirmed|0 |1
[Bug fortran/91686] ICE in gimplify:2554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91686 Dominique d'Humieres changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #2 from Dominique d'Humieres --- Duplicate of pr84109?
[Bug fortran/91544] When initializing allocatable character array get "Error: size of variable 'A.0' is too large"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91544 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-07 CC||pault at gcc dot gnu.org Blocks||68241 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Compiling the test with gcc4.8 or 4.9 gives an ICE pr91544.f90:6:0: internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1741 test_in=[ character(len=line_length) :: 'aaa','bb' ] I get the error starting at gcc5. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 [Bug 68241] [meta-bug] [F03] Deferred-length character
[Bug target/91289] powerpc-eabi: Usage of -fstack-limit-symbol leads to internal compiler error during RTL pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289 --- Comment #5 from Segher Boessenkool --- (BTW, using addic here is wrong: addic clobbers CA, which may not be free).
[Bug fortran/91589] [9/10 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2447
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91589 --- Comment #3 from Paul Thomas --- Author: pault Date: Sat Sep 7 14:41:25 2019 New Revision: 275487 URL: https://gcc.gnu.org/viewcvs?rev=275487&root=gcc&view=rev Log: 2019-09-07 Paul Thomas PR fortran/91589 * primary.c (gfc_match_varspec): Return MATCH_NO on an apparent component ref, when the primary type is intrinsic. 2019-09-07 Paul Thomas PR fortran/91589 * gfortran.dg/pr91589.f90 : New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91589.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/primary.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug fortran/91589] [9/10 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2447
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91589 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Paul Thomas --- Fixed on both branches. Thanks for the report Paul
[Bug target/91289] powerpc-eabi: Usage of -fstack-limit-symbol leads to internal compiler error during RTL pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289 Segher Boessenkool changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #6 from Segher Boessenkool --- Created attachment 46853 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46853&action=edit Proposed patch Could you try this patch?
[Bug c++/91697] Cannot use this in noexcept specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91697 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Marek Polacek --- Fixed by r266224. I don't think we want to backport it.
[Bug target/91275] __builtin_crypto_vpmsumd gives different results -O[123] vs -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91275 Segher Boessenkool changed: What|Removed |Added Target|ppc64le |powerpc*-*-* CC||segher at gcc dot gnu.org Host|ppc64le | --- Comment #2 from Segher Boessenkool --- Confirmed.
[Bug target/91275] __builtin_crypto_vpmsumd gives different results -O[123] vs -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91275 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-07 Ever confirmed|0 |1 --- Comment #3 from Segher Boessenkool --- Does not fail with -mcpu=power9.
[Bug target/91275] __builtin_crypto_vpmsumd gives different results -O[123] vs -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91275 Segher Boessenkool changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #4 from Segher Boessenkool --- It is caused by the "swaps" (p8swap) pass. Before this pass we have: 5: load r122 6: r123 = swap r122 7: r121 = swap r123 8: load r125 9: r126 = swap r125 10: r124 = swap r126 11: r117 = vpmsumd r121, r124 12: r127 = vec_select r117, 1 # this is the high dword, 0 in hardware 13: r128 = vec_select r117, 0 # this is the low dword, 1 in hardware 14: load r129 15: r5 = r127 16: r4 = r128 17: r3 = r129 18: call printf The swaps pass replaces 7 and 10 by plain moves.
[Bug fortran/91686] ICE in gimplify:2554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91686 --- Comment #3 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #2) > Duplicate of pr84109? No that was a wrong code bug. I haven't been able yet to identify, which patch fixed this. I'll have another look tomorrow. Also, I cannot see what is throwing the gimplifier. I presume that it is one of the usual use of a temporary before it is declared but I just don't see it yet. Regards Paul
[Bug inline-asm/65640] multiple alternative constraints and earlyclobbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65640
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #3 from Segher Boessenkool ---
(Please don't quote from previous messages when not replying to those lines).
This only fails with -O0.
IRA assigns the following:
int f(int out, int in) {
asm("foo %1,%0;" : "=&a" (out) : "b" (in));// a a
asm("foo %1,%0;" : "=&b" (out) : "b" (in));// a b
asm("foo %1,%0;" : "=&a" (out) : "a" (in));// a b
asm("foo %1,%0;" : "=&a,&b" (out) : "b,b" (in)); // a b
asm("foo %1,%0;" : "=&a,&b" (out) : "a,a" (in)); // a b
asm("foo %1,%0;" : "=&b,&a" (out) : "b,b" (in)); // a b
asm("foo %1,%0;" : "=&b,&a" (out) : "a,a" (in)); // a b
return out;
}
The LRA is left to clean up after it, and it comes up with
int f(int out, int in) {
asm("foo %1,%0;" : "=&a" (out) : "b" (in));// a b
asm("foo %1,%0;" : "=&b" (out) : "b" (in));// - -
asm("foo %1,%0;" : "=&a" (out) : "a" (in));// - -
asm("foo %1,%0;" : "=&a,&b" (out) : "b,b" (in)); // a b
asm("foo %1,%0;" : "=&a,&b" (out) : "a,a" (in)); // - -
asm("foo %1,%0;" : "=&b,&a" (out) : "b,b" (in)); // a b
asm("foo %1,%0;" : "=&b,&a" (out) : "a,a" (in)); // b a
return out;
}
(The "- -" are when LRA couldn't come up with something that works).
[Bug c++/91673] [10 Regression] GCC ICE when partially specialising class template on a function-signature type with deduced noexcept qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91673 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #3 from Marek Polacek --- https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00447.html
[Bug go/91700] New: Document go version for gcc 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91700 Bug ID: 91700 Summary: Document go version for gcc 9 Product: gcc Version: 9.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: dilyan.palauzov at aegee dot org CC: cmang at google dot com Target Milestone: --- Per http://gcc.gnu.org/gcc-8/changes.html gcc compiles for go 1.10.1 . http://gcc.gnu.org/gcc-9/changes.html states nothing about go, which means, that gcc 9 implements go 1.10.1 I have installed gcc 9.1.1 20190804 and its “go version” reports “go version go1.12.2 gccgo (GCC) 9.1.1 20190804 linux/amd64”. Please update http://gcc.gnu.org/gcc-9/changes.html to state, that it equivalent to the go 1.12 compiler, or fix by other means this inconsistency.
[Bug c++/91609] friend declaration not honoured
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91609
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2019-09-07
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
clang++ doesn't compile this, either:
$ clang++ -c 91609.C
91609.C:16:9: error: C++ requires a type specifier for all declarations
friend result;
~~ ^
91609.C:16:9: error: friends can only be classes or functions
91609.C:9:66: error: 'type' is a private member of 'traits_template'
class complicated : underlying_thing::type> {};
^
91609.C:21:36: note: in instantiation of template class 'complicated' requested here
traits_template::result_type foo;
^
91609.C:13:8: note: implicitly declared private here
using type = T;
^
3 errors generated.
[Bug fortran/91648] [9/10 Regression] ICE in generate_finalization_wrapper, at fortran/class.c:2009
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91648 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-07 CC||janus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- > Behavior changed between 20180909 and 20180916 : reduced range 20180916 and 20180916: r264350?
[Bug c++/84374] placeholder decltype(auto) accepted when it's not the placeholder alone in trailing-return-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84374 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug other/19180] Improve documentation on How to Add New GCC option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19180 --- Comment #7 from Andrew Pinski --- Things have improved so much since this bug report was written and when I confirmed it. Devang left Apple back in 2012.
[Bug libgomp/91694] configure.ac does not correctly check for gethostname
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91694 Rishi Khan changed: What|Removed |Added CC||ri...@extreme-scale.com --- Comment #1 from Rishi Khan --- To clarify further, configure.ac instructs to see if the program can compile and produce a *.o file. This works, with a warning but not error returned. However, a system that does not have gethostname will not link properly. That is why I think it should be AC_LINK_IFELSE instead of AC_COMPILE_IFELSE. There are a few other AC_COMPILE_IFELSE that should also be looked at. I think they may suffer the same problem.
