[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 --- Comment #4 from Marc Glisse --- (In reply to Javier Serrano Polo from comment #3) > Upstream wants to make multiarch harder; the patch will not be posted here. As long as the new behavior is optional (not the default), the patch stands a chance of being accepted. But I am not sure what exactly this PR is for, asking to support names that haven't been decided yet. (the discussion about names is probably more appropriate on the libc side, since that's usually where ld.so comes from)
[Bug target/84172] option "-O3" create slower code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84172 --- Comment #9 from Andreas Otto --- after morning "boot" it seems OK… BUT the bug come back → star without "-g" option #:~/test> make test for t in test.0 test.1 test.2 test.3; do ./$t; done ./test.0 → T1 = 663.640015 ms → HI = 0x1, LO = 0 ./test.0 → T2 = 490.407990 ms → HI = 0x1, LO = 0 ./test.1 → T1 = 137.326996 ms → HI = 0x1, LO = 0 ./test.1 → T2 = 133.870010 ms → HI = 0x1, LO = 0 ./test.2 → T1 = 138.035995 ms → HI = 0x1, LO = 0 ./test.2 → T2 = 135.183014 ms → HI = 0x1, LO = 0 ./test.3 → T1 = 137.481003 ms → HI = 0x1, LO = 0 ./test.3 → T2 = 134.893997 ms → HI = 0x1, LO = 0 #:~/test> make test for t in test.0 test.1 test.2 test.3; do ./$t; done ./test.0 → T1 = 656.669983 ms → HI = 0x1, LO = 0 ./test.0 → T2 = 490.566986 ms → HI = 0x1, LO = 0 ./test.1 → T1 = 134.537994 ms → HI = 0x1, LO = 0 ./test.1 → T2 = 132.356003 ms → HI = 0x1, LO = 0 ./test.2 → T1 = 144.015991 ms → HI = 0x1, LO = 0 ./test.2 → T2 = 134.715012 ms → HI = 0x1, LO = 0 ./test.3 → T1 = 137.255997 ms → HI = 0x1, LO = 0 ./test.3 → T2 = 134.914001 ms → HI = 0x1, LO = 0 add "-g" option again #:~/test> make test gcc-5 -march=native -mtune=native -g -static -O0 -o test.0 main.c gcc-5 -march=native -mtune=native -g -static -O1 -o test.1 main.c gcc-5 -march=native -mtune=native -g -static -O2 -o test.2 main.c gcc-5 -march=native -mtune=native -g -static -O3 -o test.3 main.c for t in test.0 test.1 test.2 test.3; do ./$t; done ./test.0 → T1 = 655.403992 ms → HI = 0x1, LO = 0 ./test.0 → T2 = 490.989014 ms → HI = 0x1, LO = 0 ./test.1 → T1 = 132.431000 ms → HI = 0x1, LO = 0 ./test.1 → T2 = 133.049988 ms → HI = 0x1, LO = 0 ./test.2 → T1 = 141.020004 ms → HI = 0x1, LO = 0 ./test.2 → T2 = 135.460999 ms → HI = 0x1, LO = 0 ./test.3 → T1 = 211.210999 ms → HI = 0x1, LO = 0 ./test.3 → T2 = 225.455002 ms → HI = 0x1, LO = 0 #:~/test> make test for t in test.0 test.1 test.2 test.3; do ./$t; done ./test.0 → T1 = 662.700989 ms → HI = 0x1, LO = 0 ./test.0 → T2 = 490.704010 ms → HI = 0x1, LO = 0 ./test.1 → T1 = 146.843994 ms → HI = 0x1, LO = 0 ./test.1 → T2 = 133.729996 ms → HI = 0x1, LO = 0 ./test.2 → T1 = 140.351990 ms → HI = 0x1, LO = 0 ./test.2 → T2 = 134.825012 ms → HI = 0x1, LO = 0 ./test.3 → T1 = 213.688995 ms → HI = 0x1, LO = 0 ./test.3 → T2 = 225.066010 ms → HI = 0x1, LO = 0 disable "-g" option #:~/test> make test gcc-5 -march=native -mtune=native -static -O0 -o test.0 main.c gcc-5 -march=native -mtune=native -static -O1 -o test.1 main.c gcc-5 -march=native -mtune=native -static -O2 -o test.2 main.c gcc-5 -march=native -mtune=native -static -O3 -o test.3 main.c for t in test.0 test.1 test.2 test.3; do ./$t; done ./test.0 → T1 = 652.817017 ms → HI = 0x1, LO = 0 ./test.0 → T2 = 490.574005 ms → HI = 0x1, LO = 0 ./test.1 → T1 = 139.962006 ms → HI = 0x1, LO = 0 ./test.1 → T2 = 134.207001 ms → HI = 0x1, LO = 0 ./test.2 → T1 = 134.936005 ms → HI = 0x1, LO = 0 ./test.2 → T2 = 135.485001 ms → HI = 0x1, LO = 0 ./test.3 → T1 = 217.895004 ms → HI = 0x1, LO = 0 ./test.3 → T2 = 224.744003 ms → HI = 0x1, LO = 0 #:~/test> make test for t in test.0 test.1 test.2 test.3; do ./$t; done ./test.0 → T1 = 660.490967 ms → HI = 0x1, LO = 0 ./test.0 → T2 = 490.671997 ms → HI = 0x1, LO = 0 ./test.1 → T1 = 141.137009 ms → HI = 0x1, LO = 0 ./test.1 → T2 = 133.236008 ms → HI = 0x1, LO = 0 ./test.2 → T1 = 136.444000 ms → HI = 0x1, LO = 0 ./test.2 → T2 = 135.473999 ms → HI = 0x1, LO = 0 ./test.3 → T1 = 256.563019 ms → HI = 0x1, LO = 0 ./test.3 → T2 = 225.742996 ms → HI = 0x1, LO = 0 do som additional testing #:~/test> rm test. test.0 test.1 test.2 test.3 #:~/test> rm test.* #:~/test> make test gcc-5 -march=native -mtune=native -static -O0 -o test.0 main.c gcc-5 -march=native -mtune=native -static -O1 -o test.1 main.c gcc-5 -march=native -mtune=native -static -O2 -o test.2 main.c gcc-5 -march=native -mtune=native -static -O3 -o test.3 main.c for t in test.0 test.1 test.2 test.3; do ./$t; done ./test.0 → T1 = 652.343994 ms → HI = 0x1, LO = 0 ./test.0 → T2 = 490.720978 ms → HI = 0x1, LO = 0 ./test.1 → T1 = 132.760010 ms → HI = 0x1, LO = 0 ./test.1 → T2 = 132.718994 ms → HI = 0x1, LO = 0 ./test.2 → T1 = 135.055008 ms → HI = 0x1, LO = 0 ./test.2 → T2 = 135.212997 ms → HI = 0x1, LO = 0 ./test.3 → T1 = 221.292007 ms → HI = 0x1, LO = 0 ./test.3 → T2 = 225.391006 ms →
[Bug libfortran/84156] [8 Regression] valgrind error with print *,1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84156 --- Comment #2 from Jerry DeLisle --- I think this is related to the front end initializing the dtp common structure and the runtime using it. This looking unititiaklzed and therefore a false error. I am not sure valgrind can detect this and I think this is why one is allowed to tell valgind to ignore these things. But I am certainly not an expert in this area and I simply presume this is not a real bug.
[Bug c++/84177] New: Attributes on C++17 nested namespaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84177
Bug ID: 84177
Summary: Attributes on C++17 nested namespaces
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Target Milestone: ---
One would expect this to work:
$ cat /tmp/foo.cc
namespace a::b __attribute__ ((visibility ("protected")) {}
$ g++-mp-7 -std=c++17 /tmp/foo.cc
/tmp/foo.cc:1:16: error: expected '{' before '__attribute__'
namespace a::b __attribute__ ((visibility ("protected")) {}
^
/tmp/foo.cc:1:58: error: expected ')' before '{' token
namespace a::b __attribute__ ((visibility ("protected")) {}
^
/tmp/foo.cc:1:59: error: expected unqualified-id at end of input
namespace a::b __attribute__ ((visibility ("protected")) {}
^
/tmp/foo.cc:1:59: error: expected '}' at end of input
This is:
$ g++-mp-7 --version
g++-mp-7 (MacPorts gcc7 7.2.0_0) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
FWIW, it's quite hard to navigate in the documentation to find
information about attributes for namespaces. I have not found
clear evidence that this feature had been considered and eliminated,
or whether it's just an overlook.
Cheers!
[Bug target/84176] New: Need a different thunk for -mindirect-branch=thunk-extern -fcf-protection -mcet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84176
Bug ID: 84176
Summary: Need a different thunk for
-mindirect-branch=thunk-extern -fcf-protection -mcet
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: igor.v.tsimbalist at intel dot com
Blocks: 81652
Target Milestone: ---
Target: x86_64-*-*, i?86-*-*
When -fcf-protection -mcet is used to compile kernel, nocf_check attribute
can be used to add notrack prefix:
[hjl@gnu-skx-1 nt-1]$ cat x.i
void (*func1) (void) __attribute__((nocf_check));
void (*func2) (void);
void
bar (void)
{
func1 ();
func2 ();
}
[hjl@gnu-skx-1 nt-1]$ /export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2 -fcf-protection -mcet
-S x.i
[hjl@gnu-skx-1 nt-1]$ cat x.s
.file "x.i"
.text
.p2align 4,,15
.globl bar
.type bar, @function
bar:
.LFB0:
.cfi_startproc
endbr64
subq$8, %rsp
.cfi_def_cfa_offset 16
notrack call*func1(%rip)
addq$8, %rsp
.cfi_def_cfa_offset 8
jmp *func2(%rip)
.cfi_endproc
.LFE0:
.size bar, .-bar
When -mindirect-branch=thunk-extern is added, we need a thunk with
a different name to tell a thunk for indirect branch with notrack
prefix from a thunk for indirect branch without notrack prefix
[hjl@gnu-skx-1 nt-1]$ /export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2 -fcf-protection -mcet
-mindirect-branch=thunk-extern -S -o y.s x.i
[hjl@gnu-skx-1 nt-1]$ cat y.s
.file "x.i"
.text
.p2align 4,,15
.globl bar
.type bar, @function
bar:
.LFB0:
.cfi_startproc
endbr64
subq$8, %rsp
.cfi_def_cfa_offset 16
movqfunc1(%rip), %rax
call__x86_indirect_thunk_rax
movqfunc2(%rip), %rax
addq$8, %rsp
.cfi_def_cfa_offset 8
jmp __x86_indirect_thunk_rax
.cfi_endproc
.LFE0:
.size bar, .-bar
Otherwise kernel can't properly update a thunk to an indirect branch with
notrack prefix for indirect branch with notrack prefix.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
[Bug 81652] [meta-bug] -fcf-protection=full -mcet bugs
[Bug target/81739] Replace calls to memcmp with more efficient code if possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81739 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-02 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Confirmed. Clang 5.0 emits semi-optimal code. For x86_64: cmp1(unsigned long long, unsigned long long): # @cmp1(unsigned long long, unsigned long long) mov qword ptr [rsp - 8], rdi mov qword ptr [rsp - 16], rsi bswap rdi bswap rsi xor ecx, ecx cmp rdi, rsi mov edx, -1 mov eax, 1 cmovb eax, edx cmove eax, ecx ret
[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #18 from Jason Merrill --- Assigning to Martin. I was convinced of his position by discussion on the Core reflector, which pointed out that in general explicit specializations are treated as entirely separate from their templates, such that for instance a specialization of a class template isn't required to define members with the same name. But the abi_tag attribute still needs to affect explicit specializations, as it applies to the name rather than any particular instance of a template.
[Bug c++/84160] [8 Regression] ICE on valid C++11 code: in build_capture_proxy, at cp/lambda.c:446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84160 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed.
[Bug c++/84160] [8 Regression] ICE on valid C++11 code: in build_capture_proxy, at cp/lambda.c:446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84160 --- Comment #2 from Jason Merrill --- Author: jason Date: Fri Feb 2 02:07:09 2018 New Revision: 257325 URL: https://gcc.gnu.org/viewcvs?rev=257325&root=gcc&view=rev Log: PR c++/84160 - ICE with nested variadic capture. * lambda.c (is_capture_proxy_with_ref): New. (insert_capture_proxy): Don't set DECL_CAPTURED_VARIABLE from a COMPONENT_REF. * expr.c (mark_use): Use is_capture_proxy_with_ref. * constexpr.c (potential_constant_expression_1): Likewise. * semantics.c (process_outer_var_ref): Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/expr.c trunk/gcc/cp/lambda.c trunk/gcc/cp/semantics.c
[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #25 from Jürgen Reuter --- The other errors actually appear in I/O procedures of external libraries that we link to our code. It would be hard(er) to come up with a test case here. Hope you can fix all of that, keeping fingers crossed.
[Bug c++/81716] Bogus -Wlto warning with forward-declared pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81716 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Known to work||8.0 Resolution|--- |DUPLICATE Known to fail||6.4.0, 7.3.0 --- Comment #3 from Martin Sebor --- I can confirm this with GCC 7 and 6 but not with GCC 8. r257183 was the last commit I see that dealt with the warning for bug 83954. It also had to do with arrays of pointers so based on that I'll resolve this as a duplicate of that bug. Please reopen if you have evidence it isn't the same thing. *** This bug has been marked as a duplicate of bug 83954 ***
[Bug lto/83954] [6/7 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954 Martin Sebor changed: What|Removed |Added CC||sgunderson at bigfoot dot com --- Comment #12 from Martin Sebor --- *** Bug 81716 has been marked as a duplicate of this bug. ***
[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #24 from Jürgen Reuter --- Created attachment 43322 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43322&action=edit Additional failing test case (after the prelim. fix) This is still lengthy, and I can reduce it further but maybe the error helps you when you run it in the debugger. I get Running test: resonance_insertion_2seg_prod(64951,0x7fff9ae91340) malloc: *** mach_vm_map(size=9223372036854779904) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x10900d64c #1 0x10900c9f3 #2 0x7fff620bcf59
[Bug c++/81714] incorrect location for uninitialised variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81714 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-02 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||6.4.0, 7.3.0, 8.0 --- Comment #1 from Martin Sebor --- Confirmed with 8, 7, and 6.
[Bug c++/81678] Variadic template parameters containing pointer to member function fail to be parsed unless name of the parameter is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81678 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #1 from Martin Sebor --- GCC 8.0 prints the following error (please remember to include compiler output): pr81678.C:2:19: error: variable or field ‘f’ declared void void f (void (T::*...)()) ^~~ pr81678.C:2:9: error: expected primary-expression before ‘void’ void f (void (T::*...)()) ^~~~ pr81678.C: In function ‘int main()’: pr81678.C:14:3: error: ‘f’ was not declared in this scope f (&C::f); ^ Clang compiles it fine but MSVC and EDG don't. EDG gives the following error: $ eccp -A --c++17 pr81678.C "pr81678.C", line 2: error: an unnamed parameter pack declaration cannot be parenthesized void f (void (T::*...)()) ^ Based on [dcl.fct] of N4700 I suspect this may be an ambiguity in the grammar that Clang handles more gracefully than other implementations but I'm not an expert on the C++ grammar so I'll leave it to someone else to either confirm or close.
[Bug c++/81674] gcc cannot detect missing initialisers for fields in constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81674 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-02 CC||msebor at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=19808 Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Bug 19808 is similar but not quite the same. It (and its duplicates) asks for a warning when an uninitialized member is used to initialized another. This one seems to be asking for a warning for members that are left uninitialized, even when they are not used. This would be a noisier warning that -Wuninitialized so it would probably need its own option, but I think it would useful nonetheless. It's likely that there already is a request like this one but I can't find it. Let me confirm this in the meantime.
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 --- Comment #3 from Javier Serrano Polo --- Upstream wants to make multiarch harder; the patch will not be posted here. Nevertheless, Adam, please answer to my previous question.
[Bug middle-end/81669] trunk/gcc/fibonacci_heap.h:58: possible missing initialisation ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81669
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-02-02
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Martin Sebor ---
Confirmed. The default constructor appears to be used in the definition of
fibonacci_heap::replace_key_data (fibonacci_node *node, K key, V *data):
...
/* If we wanted to, we do a real increase by redeleting and
inserting. */
if (node->compare_data (key) > 0)
{
delete_node (node, false);
node = new (node) fibonacci_node_t ();
insert (node, key, data);
return odata;
Having a test case showing what breaks because of it would provide motivation
to fix it.
[Bug tree-optimization/81600] tree-vect-loop.c:6075:22: runtime error: index -1 out of bounds for type 'tree_node *[3]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81600 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-02-02 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- I'm not having any luck reproducing it on trunk with gcc.c-torture/execute/pr68250.c testcase at -O3. Can it still reproduced still a problem and is the fix from comment #1 still needed or can this bug be resolved?
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- The ABI is fixed so we cannot change it.
[Bug tree-optimization/81603] Various compiler UB on very large constant offsets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81603 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-02-02 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Martin Sebor --- Are the committed fixes enough to resolve the bug?
[Bug c/84174] FAIL: gcc.dg/Wattributes-6.c (test for warnings, line 404)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84174 --- Comment #1 from John David Anglin --- Similar fail: FAIL: c-c++-common/Wattributes.c -Wc++-compat (test for warnings, line 404)
[Bug c/84175] New: FAIL: c-c++-common/Warray-bounds-4.c -Wc++-compat strcpy (test for warnings, line 67)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84175 Bug ID: 84175 Summary: FAIL: c-c++-common/Warray-bounds-4.c -Wc++-compat strcpy (test for warnings, line 67) Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 /test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/Warray-bounds-4.c: In function 'tes t_memcpy_bounds_memarray_range': /test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/Warray-bounds-4.c:47:3: warning: 'm emcpy' offset [6, 8] from the object at 'ma' is out of the bounds of referenced subobject 'a5' with type 'char[5]' at offset 0 [-Warray-bounds] /test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/Warray-bounds-4.c:48:3: warning: 'm emcpy' offset [6, 10] from the object at 'ma' is out of the bounds of referenced subobject 'a5' with type 'char[5]' at offset 0 [-Warray-bounds] PASS: c-c++-common/Warray-bounds-4.c -Wc++-compat (test for warnings, line 47 ) PASS: c-c++-common/Warray-bounds-4.c -Wc++-compat (test for warnings, line 48 ) XFAIL: c-c++-common/Warray-bounds-4.c -Wc++-compat strcpy (test for warnings, line 66) FAIL: c-c++-common/Warray-bounds-4.c -Wc++-compat strcpy (test for warnings, line 67) PASS: c-c++-common/Warray-bounds-4.c -Wc++-compat (test for excess errors)
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 Javier Serrano Polo changed: What|Removed |Added CC||adconrad at 0c3 dot net --- Comment #1 from Javier Serrano Polo --- Adam, if you had to come up with multiarch interpreter names for traditional architectures, which would be the proper place to discuss?
[Bug c/84174] New: FAIL: gcc.dg/Wattributes-6.c (test for warnings, line 404)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84174 Bug ID: 84174 Summary: FAIL: gcc.dg/Wattributes-6.c (test for warnings, line 404) Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gc c/gcc/testsuite/gcc.dg/Wattributes-6.c -fno-diagnostics-show-caret -fdiagnostics -color=never -Wall -Wattributes -ftrack-macro-expansion=0 -S -o Wattributes-6.s /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Wattributes-6.c:42:1: warning: 'packed' a ttribute ignored [-Wattributes] [...] FAIL: gcc.dg/Wattributes-6.c (test for warnings, line 404) PASS: gcc.dg/Wattributes-6.c (test for warnings, line 410) PASS: gcc.dg/Wattributes-6.c (test for warnings, line 421) PASS: gcc.dg/Wattributes-6.c (test for warnings, line 424) PASS: gcc.dg/Wattributes-6.c (test for warnings, line 428) PASS: gcc.dg/Wattributes-6.c (test for warnings, line 431) PASS: gcc.dg/Wattributes-6.c (test for warnings, line 435) PASS: gcc.dg/Wattributes-6.c (test for warnings, line 439) FAIL: gcc.dg/Wattributes-6.c (test for excess errors) Excess errors: /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Wattributes-6.c:404:1: error: alignment for 'finline_hot_noret_align' must be at least 8
[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095 --- Comment #13 from Martin Sebor --- Updated patch with fixes for the false positives discussed in comment #12: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00076.html
[Bug c/84173] New: Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 Bug ID: 84173 Summary: Support glibc multiarch interpreter names Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: javier--1JjCLmwH3DOs1h35RYKsyJrkQzDNHN at jasp dot net Target Milestone: --- Preferred multiarch names refer to the /lib directory and are unique, e.g. /lib/ld-linux-x86-64.so.2. Please consider accepting a future patch that selects glibc multiarch names instead of traditional ones. It looks like these multiarch names are yet to be decided.
[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #23 from paul.richard.thomas at gmail dot com --- Hi Everybody, I just got in from the lab.. Obviously, I will not be working on this problem tonight! I suspect that fact that I have had to pick out allocatable components for special treatment is the smoking gun. I will be giving the large chunk of specialised code devoted to allocatable components in trans-array.c a good looking over tomorrow. Somewhere, a perfectly good dtype is being overwirtten with zeros Paul On 1 February 2018 at 22:23, juergen.reuter at desy dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 > > --- Comment #22 from Jürgen Reuter --- > I'm actually running our code right now. It fixes _almost all_ of our unit and > functional tests. There is still one failing unit test and at least one > failing > functional test. Still waiting for the full results. Will try to add a > reproducer for the test. For the unit test that is straightforward, for the > functional test maybe not so much. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
[Bug fortran/84155] [8 Regression] program hangs on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155 --- Comment #9 from Jürgen Reuter --- This fixes almost all of our unit and functional test, but not all of them. There are still 19 functional tests failing, all of them seem to have to do with some sort of I/O . And one unit tests, which I cannot see what it directly does. For the latter I could do a reproducer, however, but it might take me a day or two.
[Bug tree-optimization/38785] [6/7/8 Regression] huge performance regression on EEMBC bitmnp01
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #48 from Aldy Hernandez ---
Is this still an issue?
int t(void);
void tt(int);
void
f (int i, long *a, long *b)
{
int sum = 0;
for (; --i >= 0; a++, b++)
{
b[i] = 0;
#define PART(I) if (t()) sum+=100+I;
PART (1);
PART (2);
PART (3);
PART (4);
PART (5);
PART (6);
tt (sum);
}
}
For --target=arc-elf, I've done:
./cc1 a.c -fdump-tree-all -quiet -I/tmp -O3 -mcpu=arc700
The inner loop looks like this:
bl @t;1
tst_s r0,r0
bl.d @t;1
add1.ne r13,r13,51 ;; r13 += 51 << 1 (which is 102)
tst_s r0,r0
add.ne r13,r13,103
bl @t;1
tst_s r0,r0
bl.d @t;1
add3.ne r13,r13,13 ;; r13 += 13 << 3 (which is 104)
tst_s r0,r0
add.ne r13,r13,105
...
...
I do not see any of the long sequences of integer constants on the stack, or
stack shuffling as was originally reported.
If I understand the first comment, i686 is presumably broken, but I see:
callt
testl %eax, %eax
je .L4
addl$101, %ebx
.L4:
callt
testl %eax, %eax
je .L5
addl$102, %ebx
.L5:
callt
testl %eax, %eax
je .L6
addl$103, %ebx
...
which doesn't look like long sequence of integers being pushed on the stack
either.
The PRE dump for arc700 doesn't show anything weird, or any combined ORed
values.
Has PRE changed and moved this bug around? Am I missing something?
[Bug c++/81589] Possible False-Positive with decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81589 Martin Sebor changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-01 CC||msebor at gcc dot gnu.org Known to work||8.0 Ever confirmed|0 |1 Known to fail||6.4.0, 7.3.0 --- Comment #2 from Martin Sebor --- Confirmed with GCC 6 and 7. GCC 8 compiles the translation unit without an error. Bisection points to r248153 as the revision that made it work.
[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #22 from Jürgen Reuter --- I'm actually running our code right now. It fixes _almost all_ of our unit and functional tests. There is still one failing unit test and at least one failing functional test. Still waiting for the full results. Will try to add a reproducer for the test. For the unit test that is straightforward, for the functional test maybe not so much.
[Bug rtl-optimization/84123] internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:908, alpha linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84123 --- Comment #6 from uros at gcc dot gnu.org --- Author: uros Date: Thu Feb 1 22:22:03 2018 New Revision: 257318 URL: https://gcc.gnu.org/viewcvs?rev=257318&root=gcc&view=rev Log: PR rtl-optimization/84123 * combine.c (change_zero_ext): Check if hard register satisfies can_change_dest_mode before calling gen_lowpart_SUBREG. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/combine.c
[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #21 from Dominique d'Humieres --- > A temporary fix: > ... Preliminary tests look good! Thanks.
[Bug target/84172] option "-O3" create slower code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84172 Marc Glisse changed: What|Removed |Added Known to work||7.2.0 Known to fail||5.5.0, 6.4.0 --- Comment #8 from Marc Glisse --- As far as I can tell, this is already fixed in gcc-7.
[Bug fortran/60576] [6/7/8 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576 --- Comment #26 from Dominique d'Humieres --- % gfc /opt/gcc/_clean/gcc/testsuite/gfortran.dg/assumed_rank_7.f90 -fsanitize=address % ./a.out = ==77100==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffeed4a1f28 at pc 0x000102a2f4b4 bp 0x7ffeed4a1b70 sp 0x7ffeed4a1320 READ of size 400 at 0x7ffeed4a1f28 thread T0 #0 0x102a2f4b3 in wrap_memmove (libasan.5.dylib:x86_64+0x184b3) #1 0x102760657 in bar.3811 (a.out:x86_64+0x13657) #2 0x10275efa3 in MAIN__ (a.out:x86_64+0x11fa3) #3 0x10276076e in main (a.out:x86_64+0x1376e) #4 0x7fff7011c114 in start (libdyld.dylib:x86_64+0x1114) Address 0x7ffeed4a1f28 is located in stack of thread T0 at offset 312 in frame #0 0x10275e0a8 in MAIN__ (a.out:x86_64+0x110a8) This frame has 5 object(s): [32, 48) 'FRAME.13' [96, 184) 'at' [224, 312) 'atmp.6' [352, 760) 'class.4' <== Memory access at offset 312 partially underflows this variable [800, 1208) 'class.5' HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow (libasan.5.dylib:x86_64+0x184b3) in wrap_memmove Shadow bytes around the buggy address: 0x1fffdda94390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffdda943a0: 00 00 00 00 00 00 00 00 00 f2 f3 f3 f3 f3 00 00 0x1fffdda943b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 0x1fffdda943c0: f1 f1 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 0x1fffdda943d0: 00 00 00 00 00 f2 f2 f2 f2 f2 00 00 00 00 00 00 =>0x1fffdda943e0: 00 00 00 00 00[f2]f2 f2 f2 f2 00 00 00 00 00 00 0x1fffdda943f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffdda94400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffdda94410: 00 00 00 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 0x1fffdda94420: f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffdda94430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==77100==ABORTING
[Bug c++/81475] missing -Wsequence-point on a self-referential array access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81475
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-02-01
CC||msebor at gcc dot gnu.org
Summary|Missing "undefined |missing -Wsequence-point on
|behavior" warning |a self-referential array
||access
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
You can download draft revisions of the C++ standard from the ISO/IEC WG21 C++
site: http://www.open-std.org/jtc1/sc22/wg21
But please keep in mind this is not the right place to ask for language
reference manuals.
That said, I can confirm that the test case has undefined behavior and should
trigger a -Wsequence-point warning. Here's a smaller C/C++ test case the
demonstrates the same limitation.
No GCC release diagnosed this code so this is not a regression.
int f (void)
{
int ar[2], *a = ar;
a[0] = 1;
return a[(*a)++ - 1]; // missing -Wsequence-point
}
[Bug target/84172] option "-O3" create slower code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84172 --- Comment #7 from Andreas Otto --- Created attachment 43321 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43321&action=edit cat /proc/cpuinfo
[Bug target/84172] option "-O3" create slower code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84172 --- Comment #6 from Andrew Pinski --- Can you also send the output of: cat /proc/cpuinfo ?
[Bug target/84172] option "-O3" create slower code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84172 --- Comment #5 from Andreas Otto --- Created attachment 43320 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43320&action=edit output of command you requested… gcc-5 -march=native -mtune=native -g -static -O3 -o test.3 main.c -v
[Bug target/84172] option "-O3" create slower code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84172 --- Comment #4 from Andrew Pinski --- (In reply to Andreas Otto from comment #3) > send me the command that I should run… I did: (In reply to Andrew Pinski from comment #2) > gcc-5 -march=native -mtune=native -g -static -O3 -o test.3 main.c -v
[Bug target/83370] [AARCH64]Tailcall register may be corrupted by epilogue code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83370 --- Comment #5 from Renlin Li --- Author: renlin Date: Thu Feb 1 21:33:05 2018 New Revision: 257315 URL: https://gcc.gnu.org/viewcvs?rev=257315&root=gcc&view=rev Log: [PR83370][AARCH64]Use tighter register constraint for sibcall patterns. gcc/ backport from mainline 2018-02-01 Renlin Li PR target/83370 * config/aarch64/aarch64.c (aarch64_class_max_nregs): Handle TAILCALL_ADDR_REGS. (aarch64_register_move_cost): Likewise. * config/aarch64/aarch64.h (reg_class): Rename CALLER_SAVE_REGS to TAILCALL_ADDR_REGS. (REG_CLASS_NAMES): Likewise. (REG_CLASS_CONTENTS): Rename CALLER_SAVE_REGS to TAILCALL_ADDR_REGS. Remove IP registers. * config/aarch64/aarch64.md (Ucs): Update register constraint. gcc/testsuite/ backport from mainline 2018-02-01 Richard Sandiford PR target/83370 * gcc.target/aarch64/pr83370.c: New. Added: branches/gcc-6-branch/gcc/testsuite/gcc.target/aarch64/pr83370.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/aarch64/aarch64.c branches/gcc-6-branch/gcc/config/aarch64/aarch64.h branches/gcc-6-branch/gcc/config/aarch64/constraints.md branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug target/84172] option "-O3" create slower code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84172 --- Comment #3 from Andreas Otto --- send me the command that I should run…
[Bug target/84172] option "-O3" create slower code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84172 Andrew Pinski changed: What|Removed |Added Target||x86_64-suse-linux Component|c |target --- Comment #2 from Andrew Pinski --- Can you provide the output of the following command: gcc-5 -march=native -mtune=native -g -static -O3 -o test.3 main.c -v We need to know what -march=native expands to.
[Bug c/84172] option "-O3" create slower code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84172 --- Comment #1 from Andreas Otto --- forget last "}"
[Bug c/84172] New: option "-O3" create slower code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84172
Bug ID: 84172
Summary: option "-O3" create slower code
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: aotto1...@t-online.de
Target Milestone: ---
here my test…
#:~/test> make test
gcc-5 -march=native -mtune=native -g -static -O0 -o test.0 main.c
gcc-5 -march=native -mtune=native -g -static -O1 -o test.1 main.c
gcc-5 -march=native -mtune=native -g -static -O2 -o test.2 main.c
gcc-5 -march=native -mtune=native -g -static -O3 -o test.3 main.c
for t in test.0 test.1 test.2 test.3; do ./$t; done
./test.0 → T1 = 673.300964 ms → HI = 0x1, LO = 0
./test.0 → T2 = 506.130981 ms → HI = 0x1, LO = 0
./test.1 → T1 = 136.671005 ms → HI = 0x1, LO = 0
./test.1 → T2 = 139.194000 ms → HI = 0x1, LO = 0
./test.2 → T1 = 139.225998 ms → HI = 0x1, LO = 0
./test.2 → T2 = 139.294998 ms → HI = 0x1, LO = 0
./test.3 → T1 = 217.908997 ms → HI = 0x1, LO = 0
./test.3 → T2 = 231.663010 ms → HI = 0x1, LO = 0
#:~/test> gcc-5 -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-5
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/5/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,fortran,ada,go --enable-checking=release
--with-gxx-include-dir=/usr/include/c++/5 --enable-ssp --disable-libssp
--disable-libvtv --enable-libmpx --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--with-default-libstdcxx-abi=gcc4-compatible
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-5 --without-system-libunwind
--enable-multilib --with-arch-32=x86-64 --with-tune=generic
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 5.3.1 20160301 [gcc-5-branch revision 233849] (SUSE Linux)
dev1usr@linux02:~/test> Selected "main.c:40 [main]"
#my code
==
#include
#include
#include
#include
#define SIZE1
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
# define HI 1
# define LO 0
#else
# define HI 0
# define LO 1
#endif
int main(int argc, char *argv[])
{
int i;
clock_t t1, t2;
// T1
if (1) {
uint64_ta = 0x;
uint64_tb = 0xfffe;
unsigned __int128 r;
t1 = clock();
for (i=0; i>64);
b -= (uint64_t) (r>>0);
} else {
a -= (uint64_t) (r>>64);
b += (uint64_t) (r>>0);
}
}
t2 = clock();
float diff = ((float)(t2 - t1) / (float)CLOCKS_PER_SEC ) * 1000;
printf("%-20s → T1 = %f ms → HI = %#x, LO = %#x\n", argv[0], diff, a,
b);
}
// T2
if (1) {
typedef union valU {
unsigned __int128 ui128;
uint64_tui64[2] ;
} valU_t;
uint64_ta = 0x;
uint64_tb = 0xfffe;
valU_t r;
t1 = clock();
for (i=0; i
[Bug c++/83268] [7 Regression] internal compiler error: in lambda_expr_this_capture, at cp/lambda.c:785
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83268 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-01 CC||dmalcolm at gcc dot gnu.org Summary|internal compiler error: in |[7 Regression] internal |lambda_expr_this_capture, |compiler error: in |at cp/lambda.c:785 |lambda_expr_this_capture, ||at cp/lambda.c:785 Ever confirmed|0 |1 --- Comment #4 from David Malcolm --- Confirmed that this ICEs gcc 7 (but trunk and gcc 6 don't ICE). ICE is here in lambda_expr_this_capture: 784 gcc_assert (TYPE_MAIN_VARIANT (TREE_TYPE (current_class_ref)) (gdb) call debug_tree (cfun->language->x_current_class_ref) unit size align 64 symtab 0 alias set -1 canonical type 0x70245888 fields used unsigned nonlocal decl_7 DI file /tmp/test.C line 9 col 11 size unit size align 64 offset_align 128 offset bit offset context chain > context full-name "const struct X::operator()()::" X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown pointer_to_this reference_to_this > readonly arg 0 unsigned type_6 DI size unit size align 64 symtab 0 alias set -1 canonical type 0x70245bd0> readonly arg 0 readonly used unsigned DI file /tmp/test.C line 8 col 25 size unit size align 64 context arg-type chain >>>
[Bug target/83370] [AARCH64]Tailcall register may be corrupted by epilogue code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83370 --- Comment #4 from Renlin Li --- Author: renlin Date: Thu Feb 1 21:09:06 2018 New Revision: 257314 URL: https://gcc.gnu.org/viewcvs?rev=257314&root=gcc&view=rev Log: [PR83370][AARCH64]Use tighter register constraint for sibcall patterns. gcc/ backport from mainline 2018-02-01 Renlin Li PR target/83370 * config/aarch64/aarch64.c (aarch64_class_max_nregs): Handle TAILCALL_ADDR_REGS. (aarch64_register_move_cost): Likewise. * config/aarch64/aarch64.h (reg_class): Rename CALLER_SAVE_REGS to TAILCALL_ADDR_REGS. (REG_CLASS_NAMES): Likewise. (REG_CLASS_CONTENTS): Rename CALLER_SAVE_REGS to TAILCALL_ADDR_REGS. Remove IP registers. * config/aarch64/aarch64.md (Ucs): Update register constraint. gcc/testsuite/ backport from mainline 2018-02-01 Richard Sandiford PR target/83370 * gcc.target/aarch64/pr83370.c: New. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/aarch64/pr83370.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/aarch64/aarch64.c branches/gcc-7-branch/gcc/config/aarch64/aarch64.h branches/gcc-7-branch/gcc/config/aarch64/constraints.md branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at recog.c:2311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113 --- Comment #18 from Douglas Mencken --- (In reply to Douglas Mencken from comment #17) > diff of libgcc/unwind-dw2.c between 6.4 and 7.1 > Reverting this file doesn’t help
[Bug c++/84125] [8 Regression] ICE in generic lambda when static_assert argument is implicitly converted to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84125 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed.
[Bug c++/84125] [8 Regression] ICE in generic lambda when static_assert argument is implicitly converted to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84125 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Thu Feb 1 20:32:33 2018 New Revision: 257311 URL: https://gcc.gnu.org/viewcvs?rev=257311&root=gcc&view=rev Log: PR c++/84125 * typeck.c (build_address): Relax the assert when processing_template_decl. * g++.dg/cpp1y/lambda-generic-84125.C:New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-84125.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/33699] [6/7/8 regression] missing optimization on const addr area store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33699 Aldy Hernandez changed: What|Removed |Added Last reconfirmed|2012-01-04 00:00:00 |2018-2-1 CC||aldyh at gcc dot gnu.org --- Comment #25 from Aldy Hernandez --- (In reply to Martin Sebor from comment #23) > No progress in GCC 7.0 which emits the following code for powerpc64le at -O2 > (-Os is slightly different but the same size): Same thing on mainline still.
[Bug fortran/46496] Missing strlen check / interop warnings with BIND(C) and non-C_* kinds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46496 --- Comment #4 from Thomas Koenig --- (In reply to Tobias Burnus from comment #0) > f) The following two examples are invalid - but seemingly gfortran does not > check the string length of DT character components: > > module mytypes >use ISO_C_BINDING >implicit none >private >public T >type, bind(C) :: T > character(len=2,kind=C_CHAR) item ! INVALID length: 2 >end type T > end module mytypes > > module mytypes >use ISO_C_BINDING >implicit none >private >public T >type, bind(C) :: T > character(len=*,kind=C_CHAR) item*(2) ! INVALID length of 2 >end type T > end module mytypes This has been fixed with PR84073.
[Bug fortran/60576] [6/7/8 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576 --- Comment #25 from Thomas Koenig --- Strange, I don't see it; what I get is ig25@linux-d6cw:/tmp> gfortran -g -fsanitize=address assumed_rank_7.f90 ig25@linux-d6cw:/tmp> ./a.out = ==21952==ERROR: LeakSanitizer: detected memory leaks Direct leak of 24 byte(s) in 1 object(s) allocated from: #0 0x7fa951f6cf30 in __interceptor_malloc ../../../../trunk/libsanitizer/asan/asan_malloc_linux.cc:86 #1 0x4013fc in MAIN__ /tmp/assumed_rank_7.f90:18 #2 0x40333b in main /tmp/assumed_rank_7.f90:25 #3 0x7fa950ec3f49 in __libc_start_main (/lib64/libc.so.6+0x20f49) SUMMARY: AddressSanitizer: 24 byte(s) leaked in 1 allocation(s). ... but the memory leak from an allocate in the main program is something else I also don't see anything with valgrind. Can you post your output?
[Bug target/29256] [6/7/8 regression] loop performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256 Aldy Hernandez changed: What|Removed |Added Last reconfirmed|2013-12-09 04:50:02 |2018-2-1 CC||aldyh at gcc dot gnu.org --- Comment #65 from Aldy Hernandez --- (In reply to Jeffrey A. Law from comment #45) > This problem still exists and can be seen by making the arrays external and > using -fno-tree-loop-distribute-patterns. > > .L2: > evlddx 31,10,9 > addi 7,9,8 > addi 0,9,16 > addi 11,9,24 > addi 3,9,32 > evstddx 31,8,9 > addi 4,9,40 > evlddx 31,10,7 > addi 5,9,48 > addi 6,9,56 > evlddx 12,10,6 > addi 9,9,64 > evstddx 31,8,7 > evlddx 7,10,0 > evstddx 7,8,0 > evlddx 0,10,11 > evstddx 0,8,11 > evlddx 11,10,3 > evstddx 11,8,3 > evlddx 3,10,4 > evstddx 3,8,4 > evlddx 4,10,5 > evstddx 4,8,5 > evstddx 12,8,6 > bdnz .L2 > evldd 31,8(1) > addi 1,1,16 > blr Still a problem. I get the same code Jeff got for comment 45.
[Bug c++/84171] [8 Regression] ICE with -Wsign-compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84171 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-02-01 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- I'll take a look.
[Bug fortran/83823] [8 Regression] Character length issues with PACK()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83823 --- Comment #2 from Thomas Koenig --- -fsanitize=address gives: ==21482==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00402624 at pc 0x7f6d755ede76 bp 0x7ffed65778c0 sp 0x7ffed6577070 READ of size 5 at 0x00402624 thread T0 #0 0x7f6d755ede75 in __interceptor_memmove ../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:720 #1 0x40134d in gfcbug145 /tmp/foo.f90:14 #2 0x402323 in main /tmp/foo.f90:17 #3 0x7f6d745f6f49 in __libc_start_main (/lib64/libc.so.6+0x20f49) #4 0x400c89 in _start (/tmp/a.out+0x400c89) 0x00402624 is located 60 bytes to the left of global variable '*.LC6' defined in 'foo.f90' (0x402660) of size 5 0x00402624 is located 0 bytes to the right of global variable '*.LC5' defined in 'foo.f90' (0x402620) of size 4 SUMMARY: AddressSanitizer: global-buffer-overflow ../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:720 in __interceptor_memmove Shadow bytes around the buggy address: 0x80078470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x80078480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x80078490: 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 0x800784a0: f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 00 00 00 00 0x800784b0: f9 f9 f9 f9 05 f9 f9 f9 f9 f9 f9 f9 05 f9 f9 f9 =>0x800784c0: f9 f9 f9 f9[04]f9 f9 f9 f9 f9 f9 f9 05 f9 f9 f9 0x800784d0: f9 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 00 00 00 00 0x800784e0: f9 f9 f9 f9 00 00 00 04 f9 f9 f9 f9 00 00 00 00 0x800784f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x80078500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x80078510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb This is the print *, pack (obstyp% name, mask) line.
[Bug fortran/60576] [6/7/8 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576 Dominique d'Humieres changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #24 from Dominique d'Humieres --- Still failing at r257125 when the test is compiled with -fsanitize=address.
[Bug c++/84171] New: [8 Regression] ICE with -Wsign-compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84171
Bug ID: 84171
Summary: [8 Regression] ICE with -Wsign-compare
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
The following invalid code snippet triggers an ICE on trunk if compiled
with -Wsign-compare (included in -Wall):
=
bool foo (char c)
{
const int i = 0 = 0;
return c = i;
}
=
bug.cc: In function 'bool foo(char)':
bug.cc:3:21: error: lvalue required as left operand of assignment
const int i = 0 = 0;
^
bug.cc:4:14: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in warn_for_sign_compare, at c-family/c-warn.c:1926
return c = i;
^
0x788cda tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9375
0x689286 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/gcc/tree.h:3255
0x689286 warn_for_sign_compare(unsigned int, tree_node*, tree_node*,
tree_node*, tree_node*, tree_node*, tree_code)
../../gcc/gcc/c-family/c-warn.c:1926
0x9dae42 cp_build_binary_op(unsigned int, tree_code, tree_node*, tree_node*,
int)
../../gcc/gcc/cp/typeck.c:5324
0x86e4c1 ocp_convert(tree_node*, tree_node*, int, int, int)
../../gcc/gcc/cp/cvt.c:812
0x86fa1e cp_convert(tree_node*, tree_node*, int)
../../gcc/gcc/cp/cvt.c:623
0x86fa1e cp_convert_and_check(tree_node*, tree_node*, int)
../../gcc/gcc/cp/cvt.c:642
0x81de78 convert_like_real
../../gcc/gcc/cp/call.c:7111
0x81eb5f perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/call.c:10574
0x9e22aa check_return_expr(tree_node*, bool*)
../../gcc/gcc/cp/typeck.c:9371
0x99cf2e finish_return_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:890
0x91a054 cp_parser_jump_statement
../../gcc/gcc/cp/parser.c:12368
0x91a054 cp_parser_statement
../../gcc/gcc/cp/parser.c:10773
0x91add0 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11218
0x91aea7 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11172
0x931630 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21710
0x931630 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21747
0x931ee0 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26648
0x932bf7 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26564
0x932bf7 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19436
Please submit a full bug report, [etc.]
Jason, the regression started with your patch
https://gcc.gnu.org/viewcvs?rev=249083&root=gcc&view=rev
Would you mind having a look?
[Bug fortran/79886] [6 Regression] ICE in pp_format, at pretty-print.c:681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79886 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #9 from Thomas Koenig --- Any plans to backport to gcc-6? If not, I think we can close this.
[Bug fortran/59781] [6 Regression] [F03] Incorrect initialisation of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59781 Thomas Koenig changed: What|Removed |Added Status|NEW |WAITING CC||tkoenig at gcc dot gnu.org --- Comment #17 from Thomas Koenig --- (In reply to janus from comment #15) > (In reply to Dominique d'Humieres from comment #14) > > AFAICT the above piece of dump appeared between revisions r241883 > > (2016-11-06, none) and r241924 (2016-11-07, present), likely r241885. > > Yes, very likely. Thanks for pinpointing this, Dominique. > > > > If I > > am correct, I am not sure that the commit qualifies for back port. > > Andre, do you think it would be reasonable to backport r241885? I think this is a bit too invasive. My vote would be to close this as FIXED.
[Bug c++/84160] [8 Regression] ICE on valid C++11 code: in build_capture_proxy, at cp/lambda.c:446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84160 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug fortran/83344] Use of uninitialized memory with ASSOCIATE and strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83344 --- Comment #11 from Janne Blomqvist --- Author: jb Date: Thu Feb 1 19:47:15 2018 New Revision: 257310 URL: https://gcc.gnu.org/viewcvs?rev=257310&root=gcc&view=rev Log: PR 83975 Associate target with non-constant character length When associating a variable of type character, if the length of the target isn't known at compile time, generate an error. See PR 83344 for more details. Regtested on x86_64-pc-linux-gnu. gcc/fortran/ChangeLog: 2018-02-01 Janne Blomqvist PR 83975 PR 83344 * resolve.c (resolve_assoc_var): Generate an error if target length unknown. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c
[Bug fortran/83975] [8 Regression] ICE in set_parm_default_def_partition, at tree-ssa-coalesce.c:1919
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83975 --- Comment #8 from Janne Blomqvist --- Author: jb Date: Thu Feb 1 19:47:15 2018 New Revision: 257310 URL: https://gcc.gnu.org/viewcvs?rev=257310&root=gcc&view=rev Log: PR 83975 Associate target with non-constant character length When associating a variable of type character, if the length of the target isn't known at compile time, generate an error. See PR 83344 for more details. Regtested on x86_64-pc-linux-gnu. gcc/fortran/ChangeLog: 2018-02-01 Janne Blomqvist PR 83975 PR 83344 * resolve.c (resolve_assoc_var): Generate an error if target length unknown. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c
[Bug middle-end/28831] [6/7/8 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28831 --- Comment #32 from Aldy Hernandez --- errr, slightly LESS worse code
[Bug fortran/60576] [6/7/8 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576 Thomas Koenig changed: What|Removed |Added Status|REOPENED|RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |FIXED --- Comment #23 from Thomas Koenig --- I just tested it with current trunk and gcc 7. It is fixed. Closing.
[Bug middle-end/28831] [6/7/8 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28831 Aldy Hernandez changed: What|Removed |Added Last reconfirmed|2010-01-17 13:10:45 |2018-2-1 CC||aldyh at gcc dot gnu.org --- Comment #31 from Aldy Hernandez --- Still a problem, though we now generate slightly worse code by using rep;movsl instead of a memcpy: movl%esp, %esi subl$12, %esp pushl %esi callf subl$3988, %esp movl$1000, %ecx movl%esp, %edi rep; movsl callg
[Bug fortran/68560] [6/7/8 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68560 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #26 from Thomas Koenig --- I have a patch.
[Bug target/27855] [6/7/8 regression] reassociation causes the RA to be confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #54 from Aldy Hernandez --- Results from comparing trunk and gcc-4_6-branch on (average of 7 runs): Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz 4.6.x -O2 -ffast-math -msse4.1 -DTYPE=double -fno-tree-reassoc atlasmm 60 1000 0.100 5415.4 -O2 -ffast-math -msse4.1 -DTYPE=double atlasmm 60 1000 0.082 4797.4 Performance penalty: 12.9% trunk: -O2 -ffast-math -msse4.1 -DTYPE=double -fno-tree-reassoc atlasmm 60 1000 0.105 5217.0 -O2 -ffast-math -msse4.1 -DTYPE=double atlasmm 60 1000 0.108 4773.0 Performance change: 9.3% It looks like the penalty for using fno-tree-reassoc now is even less than it was in 4.6.x. The original report was for a 30% drop. Has this been fixed, or am I missing something? (different flags for my 4.6 run? Is the 4.6 branch not a suitable representation of the 4.6.2 compiler against which this bug was originally filed against?)
[Bug target/84113] [7/8 Regression] gcc-7.3.0/libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at recog.c:2311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #17 from Douglas Mencken ---
diff of libgcc/unwind-dw2.c between 6.4 and 7.1
--- a/libgcc/unwind-dw2.c
+++ b/libgcc/unwind-dw2.c
@@ -1,5 +1,5 @@
/* DWARF2 exception handling and frame unwind runtime interface routines.
- Copyright (C) 1997-2016 Free Software Foundation, Inc.
+ Copyright (C) 1997-2017 Free Software Foundation, Inc.
This file is part of GCC.
@@ -136,6 +136,8 @@ struct _Unwind_Context
#define SIGNAL_FRAME_BIT ((~(_Unwind_Word) 0 >> 1) + 1)
/* Context which has version/args_size/by_value fields. */
#define EXTENDED_CONTEXT_BIT ((~(_Unwind_Word) 0 >> 2) + 1)
+ /* Bit reserved on AArch64, return address has been signed with A key. */
+#define RA_A_SIGNED_BIT ((~(_Unwind_Word) 0 >> 3) + 1)
_Unwind_Word flags;
/* 0 for now, can be increased when further fields are added to
struct _Unwind_Context. */
@@ -1185,6 +1187,11 @@ execute_cfa_program (const unsigned char *insn_ptr,
break;
case DW_CFA_GNU_window_save:
+#if defined (__aarch64__) && !defined (__ILP32__)
+ /* This CFA is multiplexed with Sparc. On AArch64 it's used to
toggle
+return address signing status. */
+ fs->regs.reg[DWARF_REGNUM_AARCH64_RA_STATE].loc.offset ^= 1;
+#else
/* ??? Hardcoded for SPARC register window configuration. */
if (__LIBGCC_DWARF_FRAME_REGISTERS__ >= 32)
for (reg = 16; reg < 32; ++reg)
@@ -1192,6 +1199,7 @@ execute_cfa_program (const unsigned char *insn_ptr,
fs->regs.reg[reg].how = REG_SAVED_OFFSET;
fs->regs.reg[reg].loc.offset = (reg - 16) * sizeof (void *);
}
+#endif
break;
case DW_CFA_GNU_args_size:
@@ -1513,10 +1521,15 @@ uw_update_context (struct _Unwind_Context *context,
_Unwind_FrameState *fs)
stack frame. */
context->ra = 0;
else
-/* Compute the return address now, since the return address column
- can change from frame to frame. */
-context->ra = __builtin_extract_return_addr
- (_Unwind_GetPtr (context, fs->retaddr_column));
+{
+ /* Compute the return address now, since the return address column
+can change from frame to frame. */
+ context->ra = __builtin_extract_return_addr
+ (_Unwind_GetPtr (context, fs->retaddr_column));
+#ifdef MD_POST_EXTRACT_FRAME_ADDR
+ context->ra = MD_POST_EXTRACT_FRAME_ADDR (context, fs, context->ra);
+#endif
+}
}
static void
@@ -1550,6 +1563,9 @@ uw_init_context_1 (struct _Unwind_Context *context,
void *outer_cfa, void *outer_ra)
{
void *ra = __builtin_extract_return_addr (__builtin_return_address (0));
+#ifdef MD_POST_EXTRACT_ROOT_ADDR
+ ra = MD_POST_EXTRACT_ROOT_ADDR (ra);
+#endif
_Unwind_FrameState fs;
_Unwind_SpTmp sp_slot;
_Unwind_Reason_Code code;
@@ -1586,6 +1602,9 @@ uw_init_context_1 (struct _Unwind_Context *context,
initialization context, then we can't see it in the given
call frame data. So have the initialization context tell us. */
context->ra = __builtin_extract_return_addr (outer_ra);
+#ifdef MD_POST_EXTRACT_ROOT_ADDR
+ context->ra = MD_POST_EXTRACT_ROOT_ADDR (context->ra);
+#endif
}
static void _Unwind_DebugHook (void *, void *)
@@ -1608,6 +1627,21 @@ _Unwind_DebugHook (void *cfa __attribute__
((__unused__)),
#endif
}
+/* Frob exception handler's address kept in TARGET before installing into
+ CURRENT context. */
+
+static inline void *
+uw_frob_return_addr (struct _Unwind_Context *current
+__attribute__ ((__unused__)),
+struct _Unwind_Context *target)
+{
+ void *ret_addr = __builtin_frob_return_addr (target->ra);
+#ifdef MD_POST_FROB_EH_HANDLER_ADDR
+ ret_addr = MD_POST_FROB_EH_HANDLER_ADDR (current, target, ret_addr);
+#endif
+ return ret_addr;
+}
+
/* Install TARGET into CURRENT so that we can return to it. This is a
macro because __builtin_eh_return must be invoked in the context of
our caller. */
@@ -1616,7 +1650,7 @@ _Unwind_DebugHook (void *cfa __attribute__
((__unused__)),
do \
{ \
long offset = uw_install_context_1 ((CURRENT), (TARGET));
\
- void *handler = __builtin_frob_return_addr ((TARGET)->ra); \
+ void *handler = uw_frob_return_addr ((CURRENT), (TARGET)); \
_Unwind_DebugHook ((TARGET)->cfa, handler); \
__builtin_eh_return (offset, handler); \
} \
[Bug web/84167] bugzilla should have a "next bug" button
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84167 Frédéric Buclin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Frédéric Buclin --- (In reply to Richard Biener from comment #0) > I'm currently using the web gcc-bug mailinglist archive to cycle through all > new bugs each morning. Instead of doing this, you should click the "Bugs reported in the last 24 hours" link on the Bugzilla home page. This will generate a list, and the Prev/Next link will automatically appear on each bug page.
[Bug c++/84126] [8 Regression] ICE in variadic generic lambda inside a template function calling a function with arguments by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84126 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/84036] [8 Regression] ICE on valid code in C++14, variadic lambda capture in a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84036 --- Comment #6 from Jason Merrill --- Author: jason Date: Thu Feb 1 18:44:41 2018 New Revision: 257307 URL: https://gcc.gnu.org/viewcvs?rev=257307&root=gcc&view=rev Log: PR c++/84126 - ICE with variadic generic lambda PR c++/84036 PR c++/82249 * pt.c (tsubst_pack_expansion): Handle function parameter_packs in PACK_EXPANSION_EXTRA_ARGS. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c
[Bug c++/82249] [8 Regression] wrong mismatched argument pack lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82249 --- Comment #9 from Jason Merrill --- Author: jason Date: Thu Feb 1 18:44:41 2018 New Revision: 257307 URL: https://gcc.gnu.org/viewcvs?rev=257307&root=gcc&view=rev Log: PR c++/84126 - ICE with variadic generic lambda PR c++/84036 PR c++/82249 * pt.c (tsubst_pack_expansion): Handle function parameter_packs in PACK_EXPANSION_EXTRA_ARGS. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c
[Bug c++/84126] [8 Regression] ICE in variadic generic lambda inside a template function calling a function with arguments by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84126 --- Comment #4 from Jason Merrill --- Author: jason Date: Thu Feb 1 18:44:41 2018 New Revision: 257307 URL: https://gcc.gnu.org/viewcvs?rev=257307&root=gcc&view=rev Log: PR c++/84126 - ICE with variadic generic lambda PR c++/84036 PR c++/82249 * pt.c (tsubst_pack_expansion): Handle function parameter_packs in PACK_EXPANSION_EXTRA_ARGS. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c
[Bug tree-optimization/21485] [6/7/8 Regression] missed load PRE, PRE makes i?86/7/8 suck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485 Aldy Hernandez changed: What|Removed |Added Last reconfirmed|2011-02-06 23:54:40 |2018-2-1 CC||aldyh at gcc dot gnu.org --- Comment #65 from Aldy Hernandez --- Still a problem. I get a score of 1750.7 on a: model name : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz
[Bug target/83743] -mcpu=native causes gcc to exit in error if cpu is not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83743 Peter Bergner changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/ml/gcc- |patches/2018-01/msg02059.ht |patches/2018-01/msg02469.ht |ml |ml Resolution|--- |FIXED --- Comment #7 from Peter Bergner --- Fixed on trunk. Will wait a few days and then will back port it to FSF 7.
[Bug target/56010] Powerpc, -mcpu=native and -mtune=native use the wrong name for target 7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56010 Peter Bergner changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/ml/gcc- |patches/2018-01/msg02059.ht |patches/2018-01/msg02469.ht |ml |ml Resolution|--- |FIXED --- Comment #12 from Peter Bergner --- Fixed on trunk. Will wait a few days and then will back port it to FSF 7.
[Bug target/56010] Powerpc, -mcpu=native and -mtune=native use the wrong name for target 7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56010 --- Comment #11 from Peter Bergner --- Author: bergner Date: Thu Feb 1 18:26:51 2018 New Revision: 257305 URL: https://gcc.gnu.org/viewcvs?rev=257305&root=gcc&view=rev Log: PR target/56010 PR target/83743 * config/rs6000/driver-rs6000.c: #include "diagnostic.h". #include "opts.h". (rs6000_supported_cpu_names): New static variable. (linux_cpu_translation_table): Likewise. (elf_platform) : Define new static variable and use it. Translate kernel AT_PLATFORM name to canonical name if needed. Error if platform name is unknown. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/driver-rs6000.c
[Bug target/83743] -mcpu=native causes gcc to exit in error if cpu is not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83743 --- Comment #6 from Peter Bergner --- Author: bergner Date: Thu Feb 1 18:26:51 2018 New Revision: 257305 URL: https://gcc.gnu.org/viewcvs?rev=257305&root=gcc&view=rev Log: PR target/56010 PR target/83743 * config/rs6000/driver-rs6000.c: #include "diagnostic.h". #include "opts.h". (rs6000_supported_cpu_names): New static variable. (linux_cpu_translation_table): Likewise. (elf_platform) : Define new static variable and use it. Translate kernel AT_PLATFORM name to canonical name if needed. Error if platform name is unknown. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/driver-rs6000.c
[Bug target/84169] [8 Regression] wrong code with u128 multiplication result at aarch64 -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84169
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #2 from ktkachov at gcc dot gnu.org ---
I think combine is at fault here. The faulty assembly is:
foo:
ldrbw0, [sp, 16]
neg x0, x0, lsl 4
csetm x3, ne
The csetm is supposed to set the top 64 bits of the TImode value (in x3) to
ones, based on the CC content, but the CC-setting instruction has disappeared.
The correct sequence (by hacking the assembly output and checking that it
passes) would be:
ldrbw0, [sp, 16]
negs x0, x0, lsl 4 // NEG sets the condition code as well.
csetm x3, ne
There's a few complex combinations going on, but before combine we have (some
RTL edited to tone down verbosity):
(insn 14 12 17 2 (set (reg:DI 87)
(lshiftrt:DI (reg:DI 103)
(const_int 60 [0x3c]))) "wrong.c":9 676
{*aarch64_lshr_sisd_or_int_di3}
(insn 19 17 20 2 (parallel [
(set (reg:CC 66 cc)
(compare:CC (reg:DI 85)
(reg:DI 105)))
(set (reg:DI 90)
(minus:DI (reg:DI 85)
(reg:DI 105)))
]) "wrong.c":9 270 {subdi3_compare1}
(insn 20 19 23 2 (set (reg:DI 91)
(minus:DI (minus:DI (reg:DI 85)
(reg:DI 87))
(ltu:DI (reg:CC 66 cc)
(const_int 0 [0] "wrong.c":9 327 {*subdi3_carryin}
where insn 19 sets the CC and insn 20 uses it. After combine we have:
(insn 14 12 17 2 (set (reg:DI 87)
(lshiftrt:DI (reg:DI 103)
(const_int 60 [0x3c]))) "wrong.c":9 676
{*aarch64_lshr_sisd_or_int_di3}
(note 19 17 20 2 NOTE_INSN_DELETED)
(insn 20 19 23 2 (set (reg:DI 91)
(neg:DI (ne:DI (reg:CC 66 cc)
(const_int 0 [0] "wrong.c":9 441 {cstoredi_neg}
with insn 20 still using the CC but the CC setting instruction being deleted.
There's a number of exciting things going on in combine so my analysis may not
be entirely accurate, but I see things like:
Trying 14 -> 20:
14: r87:DI=r103:DI 0>>0x3c
20: r91:DI=r85:DI-r87:DI-ltu(cc:CC,0)
REG_DEAD r87:DI
REG_DEAD r85:DI
REG_DEAD cc:CC
REG_EQUAL -r87:DI-ltu(cc:CC,0)
Successfully matched this instruction:
(set (reg:DI 91)
(neg:DI (ltu:DI (reg:CC 66 cc)
(const_int 0 [0]
and
Trying 19 -> 26:
19: cc:CC=cmp(r103:DI,0)
REG_DEAD r103:DI
26:
{cc:CC_C=zero_extend(r90:DI)+zero_extend(r111:DI)!=zero_extend(r90:DI+r111:DI);r95:DI=r90:DI+r111:DI;}
REG_DEAD r111:DI
REG_DEAD r90:DI
Successfully matched this instruction:
(parallel [
(set (reg:CC_C 66 cc)
(ne:CC_C (plus:TI (zero_extend:TI (reg:DI 90))
(zero_extend:TI (reg:DI 111 [ b ])))
(zero_extend:TI (plus:DI (reg:DI 90)
(reg:DI 111 [ b ])
(set (reg:DI 95)
(plus:DI (reg:DI 90)
(reg:DI 111 [ b ])))
])
deferring deletion of insn with uid = 19.
So insn 19 ends up being combined into a subsequent instruction and ends up
being deleted even though insn 20 depends on it's CC-setting effects
[Bug target/84169] [8 Regression] wrong code with u128 multiplication result at aarch64 -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84169 ktkachov at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-01 CC||ktkachov at gcc dot gnu.org Known to work||7.3.1 Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed
[Bug debug/83935] DWARF for a variant part is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935 --- Comment #6 from Pierre-Marie de Rodat --- Just got a notification that it got assigned issue #180123.1: http://dwarfstd.org/ShowIssue.php?issue=180123.1
[Bug ipa/80899] [6/7/8 Regression] Devirtualization causes incorrect code generation with placement new in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80899 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Jason Merrill --- (In reply to Jan Hubicka from comment #4) > Is this valid C++? bar.mem is non-POD and is already constructed and it > seems fishy to placement new it to something different. It's very fishy; the code should use aligned_storage rather a different non-trivial type. My old proposed resolution for wg21.link/cwg1116 would have clarified that this is undefined, and might still happen to resolve wg21.link/cwg1027 , but it hasn't been accepted yet. On the other hand, it is careful to use the pointer returned from placement new rather than a pointer derived from mem, and it seems like we ought to use the information from placement new to guide devirtualization. So...sketchy code in a volatile area of semantics, but it seems like we could get it right without breaking important optimizations.
[Bug middle-end/84089] [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84089 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Aldy Hernandez --- Fixed in trunk.
[Bug libstdc++/84170] New: std::find_if performance issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84170
Bug ID: 84170
Summary: std::find_if performance issues
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: barannikov88 at gmail dot com
Target Milestone: ---
Hi,
There are two internal implementations of std::find_if in bits/stl_algo.h. One
is for the input iterator case, the other is for the random access iterator
case. They are almost identical, except that the second is somewhat
"optimized".
> /// This is an overload used by find algos for the Input Iterator case.
> template
>inline _InputIterator
>__find_if(_InputIterator __first, _InputIterator __last,
> _Predicate __pred, input_iterator_tag)
>{
> while (__first != __last && !__pred(__first))
> ++__first;
> return __first;
>}
>
> /// This is an overload used by find algos for the RAI case.
> template
>_RandomAccessIterator
>__find_if(_RandomAccessIterator __first, _RandomAccessIterator __last,
> _Predicate __pred, random_access_iterator_tag)
>{
> typename iterator_traits<_RandomAccessIterator>::difference_type
> __trip_count = (__last - __first) >> 2;
>
> for (; __trip_count > 0; --__trip_count)
> {
> if (__pred(__first))
> return __first;
> ++__first;
>
> if (__pred(__first))
> return __first;
> ++__first;
>
> if (__pred(__first))
> return __first;
> ++__first;
>
> if (__pred(__first))
> return __first;
> ++__first;
> }
>
> switch (__last - __first)
> {
> case 3:
> if (__pred(__first))
> return __first;
> ++__first;
> case 2:
> if (__pred(__first))
> return __first;
> ++__first;
> case 1:
> if (__pred(__first))
> return __first;
> ++__first;
> case 0:
> default:
> return __last;
> }
>}
Manual unrolling increases the code size and reduces the chances of this
function to be inlined. Inlining of this function is critical because it can
contain indirect calls to the predicate function, and inlining can change this
calls to direct improving performance.
I would suggest to revert manual unrolling and let the compiler decide which
optimization steps should be taken.
[Bug middle-end/84089] [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84089 --- Comment #6 from Aldy Hernandez --- Author: aldyh Date: Thu Feb 1 17:12:28 2018 New Revision: 257304 URL: https://gcc.gnu.org/viewcvs?rev=257304&root=gcc&view=rev Log: PR target/84089 * config/pa/predicates.md (base14_operand): Handle E_VOIDmode. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/predicates.md
[Bug c/84166] Wrong warning message emitted for loss of qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84166 --- Comment #1 from joseph at codesourcery dot com --- It's not confused. It's saying that it's type-safe to convert "uint32_t **" to "volatile uint32_t *const *", but not to convert it to "volatile uint32_t *". http://c-faq.com/ansi/constmismatch.html
[Bug target/84169] New: [8 Regression] wrong code with u128 multiplication result at aarch64 -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84169 Bug ID: 84169 Summary: [8 Regression] wrong code with u128 multiplication result at aarch64 -O Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: aarch64-unknown-linux-gnu Created attachment 43319 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43319&action=edit reduced testcase Output: $ aarch64-unknown-linux-gnu-gcc testcase.c -static -O $ ./a.out qemu: uncaught target signal 6 (Aborted) - core dumped Aborted The most-significant 64bit are zeros, but should be ones. $ aarch64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-257303-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/8.0.1/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu --with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld --with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-257303-checking-yes-rtl-df-extra-aarch64 Thread model: posix gcc version 8.0.1 20180201 (experimental) (GCC)
[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158
--- Comment #6 from Martin Sebor ---
I tested the modified C++ 11 example below with Clang, EDG, GCC, ICC, and MSVC.
Of these, only MSVC implements the behavior I expect and doesn't warn. The
others do. (I verified that MSVC does support the attribute.)
Still, given that it's obviously meaningful to define a specialization that
does return, treating it as noreturn based on the definition of the primary is
incorrect.
Given the difference among implementations I think the standard ought to be
clarified which of the two is intended.
(See https://godbolt.org/g/sYPbD2 for Clang and MSVC output.)
template
[[noreturn]] T
g (T) { throw "not implemented"; }
template <> int
g (int) { return 0; }
int h (int i)
{
return g (i);
}
Your Weekly Breeze - February. 01 - February. 07
This email newsletter was sent to you in graphical HTML format. If you're seeing this version, your email program prefers plain text emails. You can read the original version online: http://ymlptrack7.com/zwbctq Having problems viewing Weekly Breeze Click here ( http://myoasisliving.com/weekly_breeze/weekly_breeze.php ). >> ( y ) --> Feeling bloated after too much turkey and plates of mince pies? Get into the shape of your life in 2018 with a new fitness regime – here are some helpful expert tips >> ( http://myoasisliving.com/en/article/article_detail/article_id_enc/b53a230d6e6d918b0a7f1526b2dedefa ) The end of last year saw the 21st Faldo Series Grand Final tee up in Al Ain’s AESGC, bringing Sir Nick himself to the greens. Oasis Living was lucky enough to have a chat with a living legend >> ( http://myoasisliving.com/en/article/article_detail/article_id_enc/fac8c74f2e95c9cb9c7741faf6748425 ) Al Ain Rugby Club activities in full swing >> ( http://myoasisliving.com/en/article/article_detail/article_id_enc/2d6476579c954312447ad6df5fb08e4c ) Abu Dhabi set to host over 4,000 tri-athletes on one of the most unique triathlon courses in the world >> ( http://myoasisliving.com/en/article/article_detail/article_id_enc/36d37ef8f848677bebb848d561055902 ) A once-in-a-lifetime opportunity bounces in for youth basketball players worldwide >> ( http://myoasisliving.com/en/article/article_detail/article_id_enc/4fea2c60a18b5d7a466458f897ede786 ) Eighth edition of Abu Dhabi’s famed community sporting event to take place in February 2018 >> ( http://myoasisliving.com/en/article/article_detail/article_id_enc/1df55ebf7501156898d6b16f4e415cc8 ) breeze@ myoasisliving.com for your chance to win aHanayen gift voucher in Bawadi Mall worth Dh100. To win, simply email your complete name and indicate Hanayenin the subject and you will qualify for a random draw. *If you win, you have 30 days to pick up your prize. If your prize is not collected within 30 days of notification, it will be cancelled. Participants who have won before are not eligible to win again within 90 days after winning --> www.nascintl.com. Al Nada Beauty Salon will be having a 50% discount on beauty and hair services for the first 10 days of Ramadan. Al Nada Beauty Salon timings will be 10:30 a.m. until 2 p.m. and 8 p.m. until 12 a.m. For appointments and inquiries call 03-7664017. --> Money matters Looking to create a financial plan for 2018 but don’t know where to start? Oasis Living chats with expert Catalin Voicu for some insights – as VAT rolls into the UAE >> ( http://myoasisliving.com/en/article/article_detail/article_id_enc/710718018521202fc85448c2b2c1976f ) What’s hot in health? Abu Dhabi’s Intercare Wellness Consultants, Dr Nas Al-Jafari and Dr Mourad Habib, predict some of the wellness trends you will be seeing everywhere this year >> ( http://myoasisliving.com/en/article/article_detail/article_id_enc/46e5535e8caf136bbebd41547cb67aa1 ) What to expect in 2018 Six new things coming to the UAE this year >> ( http://myoasisliving.com/en/news/news_detail/news_id_enc/9183cbcbf2b3187e12154b1401ef156b ) 2017 in search Google releases most trending searches in the UAE of last year >> ( http://myoasisliving.com/en/news/news_detail/news_id_enc/175b84862b37613ad8bcd2a6b8b19a56 ) Greener pastures GCC's first vertical farm launches in Dubai >> ( http://myoasisliving.com/en/news/news_detail/news_id_enc/15d9bb997af04708d42e8499fe699a9b ) Omar Abdulrahman says Al Ain target three points against Al Jazira 'to get back on a better footing' Al Ain are out to restore their battered pride when they meet Arabian Gulf League leaders Al Jazira in their rescheduled Round 1 match on Monday at the Hazza bin Zayed Stadium. >> ( http://www.myoasisliving.com/oasis_living_magazine/show_detail/encid/dna/opt/local_news_catch/offset/15 ) Al Ain in talks with 'two potential' replacements for Zlatko Dalic, with Jorge da Silva one of them Al Ain say they are yet to finalise a replacement for departed manager Zlatko Dalic but "are in talks" with two candidates with experience in the Arabian Gulf League. >> ( http://www.myoasisliving.com/oasis_living_magazine/show_detail/encid/dn8/opt/local_news_catch/offset/0 ) Zlatko Dalic to depart Al Ain after Al Jazira defeat: 'Thanks for three great years' Al Ain manager Zlatko Dalic is leaving the Garden City club after more than two years in charge following their 3-1 defeat at home to Al Jazira on Monday night. >> ( http://www.myoasisliving.com/oasis_living_magazine/show_detail/encid/dn9/opt/local_news_catch/offset/5 ) Get a recap ( ALDAR Young Chef Award : March 14, 2017 ) This year’s ALDAR Young Chef Award, held in collaboration with the local Ayla hotels, saw talented students present some of their finest dishes for a panel of judges includin
[Bug target/84128] i686: Stack spilling in -fstack-clash-protection prologue neglects %esp change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84128 --- Comment #3 from Jeffrey A. Law --- Author: law Date: Thu Feb 1 16:22:56 2018 New Revision: 257303 URL: https://gcc.gnu.org/viewcvs?rev=257303&root=gcc&view=rev Log: PR target/84128 * config/i386/i386.c (release_scratch_register_on_entry): Add new OFFSET and RELEASE_VIA_POP arguments. Use SP+OFFSET to restore the scratch if RELEASE_VIA_POP is false. (ix86_adjust_stack_and_probe_stack_clash): Un-constify SIZE. If we have to save a temporary register, decrement SIZE appropriately. Pass new arguments to release_scratch_register_on_entry. (ix86_adjust_stack_and_probe): Likewise. (ix86_emit_probe_stack_range): Pass new arguments to release_scratch_register_on_entry. PR target/84128 * gcc.target/i386/pr84128.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr84128.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/84128] i686: Stack spilling in -fstack-clash-protection prologue neglects %esp change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84128 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jeffrey A. Law --- Fixed on the trunk.
[Bug rtl-optimization/84157] [8 Regression] [nvptx] ICE: RTL check: expected code 'reg', have 'lshiftrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84157 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Uroš Bizjak --- Fixed.
[Bug rtl-optimization/84157] [8 Regression] [nvptx] ICE: RTL check: expected code 'reg', have 'lshiftrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84157 --- Comment #10 from uros at gcc dot gnu.org --- Author: uros Date: Thu Feb 1 16:04:18 2018 New Revision: 257302 URL: https://gcc.gnu.org/viewcvs?rev=257302&root=gcc&view=rev Log: PR rtl-optimization/84157 * combine.c (change_zero_ext): Use REG_P predicate in front of HARD_REGISTER_P predicate. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c
[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158
--- Comment #5 from Martin Sebor ---
(In reply to Jakub Jelinek from comment #3)
> As C++ now has standardized attributes, the question is what does the
> standard say about whether standard attributes on a template are inherited
> to specializations or not, and if the standard is fuzzy about it, what do
> other compilers do.
To my reading the standard doesn't specify attributes with enough detail to
answer the question, but inheriting attributes wouldn't make sense. For
another example, consider class templates and alignas:
template
struct alignas (32) A { T a; };
template <>
struct A { char c; };
static_assert (alignof (A) < 32, "alignof A < 32");
This passes with all compilers I tried, including Clang, GCC, ICC, and MSVC.
It would be most surprising if the rules for class templates were different
than for function templates.
[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503 --- Comment #17 from Jason Merrill --- On Wed, Jan 31, 2018 at 9:45 PM, msebor at gcc dot gnu.org wrote: > Jason, I'm only starting to look into it but if I understand your suggestion > correctly, I don't think the bug can be fixed by relying on attribute > exclusions. > > Based on the test cases alone (I haven't yet stepped through the code) the > underlying problem seems to be that explicit specializations "inherit" > attributes from their primary template rather than starting with a clean > slate. Often that will be correct; I don't think we want to require people to repeat all attributes on every explicit specialization. The problem here is that there's a conflicting attribute on the specialization, and we want that to win, so I'm suggesting that when we see that, we go through and remove conflicting attributes which came from the template.
[Bug c++/83796] [6/7 Regression] Abstract classes allowed to be instantiated when initialised as default parameter to function or constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83796 Paolo Carlini changed: What|Removed |Added Summary|[6/7/8 Regression] Abstract |[6/7 Regression] Abstract |classes allowed to be |classes allowed to be |instantiated when |instantiated when |initialised as default |initialised as default |parameter to function or|parameter to function or |constructor |constructor --- Comment #6 from Paolo Carlini --- Fixed in trunk so far.
[Bug c++/83796] [6/7/8 Regression] Abstract classes allowed to be instantiated when initialised as default parameter to function or constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83796
--- Comment #5 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Thu Feb 1 15:36:04 2018
New Revision: 257298
URL: https://gcc.gnu.org/viewcvs?rev=257298&root=gcc&view=rev
Log:
/cp
2018-02-01 Paolo Carlini
PR c++/83796
* call.c (convert_like_real): If w're initializing from {} explicitly
call abstract_virtuals_error_sfinae.
/testsuite
2018-02-01 Paolo Carlini
PR c++/83796
* g++.dg/cpp0x/abstract-default1.C: New.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/abstract-default1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog
[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158
--- Comment #4 from Martin Sebor ---
(In reply to Jakub Jelinek from comment #2)
> I actually think it is the right thing that the attributes from templates
> are inherited by specializations.
That cannot be correct. Because there is no way to remove an attribute from a
declaration such a design would make it impossible to declare a specialization
that differed from the primary.
Here's a modified example that should bring the problem into focus:
template T __attribute__ ((noreturn)) f (T) { __builtin_abort (); }
template <> int f (int) { return 0; } // bogus warning here
int g (int i)
{
f (i); // missing -Wreturn-type
}
t.C: In function ‘T f(T) [with T = int]’:
t.C:3:34: warning: function declared ‘noreturn’ has a ‘return’ statement
template <> int f (int) { return 0; }
^
t.C:3:34: warning: ‘noreturn’ function does return
