[Bug fortran/84189] Internal procedure allowed as type bound procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84189 Neil Carlson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Neil Carlson --- Sorry, this is completely bogus -- lack of sleep is my only excuse.
[Bug fortran/84189] New: Internal procedure allowed as type bound procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84189 Bug ID: 84189 Summary: Internal procedure allowed as type bound procedure Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- C465 (F08) prohibits an internal procedure from being a type bound procedure, but gfortran mistakenly allows it when the TPB has the NOPASS attribute. The following invalid example should fail to compile, but gfortran compiles it without error. module foobar type :: foo contains procedure, nopass :: bar end type contains subroutine bar end subroutine end module Note that the func_result_6.f90 testsuite problem, and perhaps others, use this type of invalid code.
[Bug c++/83871] wrong code for attribute const and pure on distinct template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83871 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-02-03 Assignee|unassigned at gcc dot gnu.org |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 --- A solution for this bug is necessary to fix pr83503 and pr84158. I'm working on a patch.
[Bug tree-optimization/84188] assume non-null malloc pointers are distinct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84188
--- Comment #1 from Martin Sebor ---
Another test case for the guarantee that "...and moreover no pointers to valid
objects occur in any storage addressed by P."
void* __attribute__ ((malloc, returns_nonnull))
f (unsigned);
void g3 (unsigned n)
{
void *p = f (n);
void **q = f (n);
if (p == *q)// must be false
__builtin_abort (); // can be eliminated but isn't
}
[Bug tree-optimization/84188] New: assume non-null malloc pointers are distinct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84188
Bug ID: 84188
Summary: assume non-null malloc pointers are distinct
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The manual documents the effect of the malloc attribute like so:
This tells the compiler that a function is malloc-like, i.e., that the
pointer P returned by the function cannot alias any other pointer valid when
the function returns, and moreover no pointers to valid objects occur in any
storage addressed by P.
The following test case shows that GCC doesn't take advantage of this property
nearly to the extent it could. (To enable GCC to make full use of this
property implementations of malloc functions would of course have to avoid such
comparisons internally, but presumably they do that already since that's the
documentation makes it clear that such comparisons must be false.)
$ cat t.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout t.c
void* __attribute__ ((malloc, returns_nonnull))
f (unsigned);
void g0 (unsigned n)
{
extern char a[];
void *p = f (n);// p is non-null
if (p == a) // must be false
__builtin_abort (); // can be eliminated but isn't
}
void g1 (unsigned n)
{
char a[1];
void *p = f (n);
if (p == a) // folded into false
__builtin_abort (); // eliminated (good)
}
void g2 (unsigned n, void *p)
{
// here, p must be valid when f() returns regardless what
// it points to otherwise the equality would be undefined
// therefore p cannot equal q
void *q = f (n);
if (p == q) // must be false
__builtin_abort (); // can be eliminated but isn't
}
void g3 (unsigned n)
{
void *p = f (n);
void *q = f (n);
// the relationship between p and q is the same as in g2
if (p == q) // must be false
__builtin_abort (); // can be eliminated but isn't
}
;; Function g0 (g0, funcdef_no=0, decl_uid=1952, cgraph_uid=0, symbol_order=0)
g0 (unsigned int n)
{
void * p;
[local count: 1073741825]:
p_4 = f (n_2(D));
if (p_4 == &a)
goto ; [0.00%]
else
goto ; [99.96%]
[count: 0]:
__builtin_abort ();
[local count: 1073312327]:
return;
}
;; Function g1 (g1, funcdef_no=1, decl_uid=1958, cgraph_uid=1, symbol_order=1)
g1 (unsigned int n)
{
[local count: 1073741825]:
f (n_2(D)); [tail call]
return;
}
;; Function g2 (g2, funcdef_no=2, decl_uid=1964, cgraph_uid=2, symbol_order=2)
g2 (unsigned int n, void * p)
{
void * q;
[local count: 1073741825]:
q_4 = f (n_2(D));
if (q_4 == p_5(D))
goto ; [0.00%]
else
goto ; [99.96%]
[count: 0]:
__builtin_abort ();
[local count: 1073312327]:
return;
}
;; Function g3 (g3, funcdef_no=3, decl_uid=1968, cgraph_uid=3, symbol_order=3)
g3 (unsigned int n)
{
void * q;
void * p;
[local count: 1073741825]:
p_4 = f (n_2(D));
q_6 = f (n_2(D));
if (p_4 == q_6)
goto ; [0.00%]
else
goto ; [99.96%]
[count: 0]:
__builtin_abort ();
[local count: 1073312327]:
return;
}
[Bug middle-end/84184] gcc generates wrong relocations with negative offsets in struct arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184
--- Comment #10 from Sergei Trofimovich ---
Oh, I have forgot to ask another question:
In attached reloc-bug.c there is seemingly two functionally identical samples:
extern char glo_u64_middle_hidden[] __attribute__((visibility("hidden")));
static u64 __attribute__((noinline)) val_u64_hidden(void) {
const u64 * m = (const u64 *)glo_u64_middle_hidden;
return m[-1];
}
and
extern char glo_s_middle_hidden[] __attribute__((visibility("hidden")));
struct s { u64 a; };
static u64 __attribute__((noinline)) val_s_hidden(void) {
const struct s * m = (const struct s *)glo_s_middle_hidden;
return m[-1].a;
}
Why those are handled differently? First looks like it works, second does not.
It was my main signal to file a bug against gcc as asymmetry looked fishy.
$ ./reloc-bug
val/global = 100
val/hidden = 100
Segmentation fault
[Bug tree-optimization/81038] [8 regression] test case g++.dg/vect/slp-pr56812.cc fails starting with r248678
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81038 --- Comment #9 from Bill Schmidt --- Prospective patch posted at https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00137.html.
[Bug c/84187] -O0 fails inline assembly compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84187 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-02-02 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Can you provide the preprocessed source? This might be a bug in the linux kernel headers really.
[Bug middle-end/84184] gcc generates wrong relocations with negative offsets in struct arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184 --- Comment #9 from Sergei Trofimovich --- Aha, makes sense! Proposed kernel tweak upstream as: https://lkml.org/lkml/2018/2/2/914
[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 --- Comment #49 from Campbell --- I can confirm that the latest gcc 8 snapshot still fails by default, but it works with 8 cores using Chris's fix above of replacing ln -s with cp. This in my mind pretty conclusively points to it not being a makefile logic error, but rather a filesystem error. However, regardless of whose fault it is, Chris's patch represents an actual viable solution to the problem, and is simple to understand, and does not unduly penalize other platforms. This situation has persisted for far too long and it makes GCC look bad and lose actual users, regardless of whether Apple or GCC caused the problem.
[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
Benjamin Buch changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #7 from Benjamin Buch ---
I have to reopen this with an extended test case. Its still an ICE as soon as I
access the captured pack:
template < typename T > void sink(T ...){}
template < typename T >
auto f(T){
[](auto ... i){
[i ...]{ sink(i ...); };
};
}
int main(){
f(0);
}
$ g++ -std=c++14 main2.cpp
main2.cpp: In instantiation of 'auto f(T) [with T = int]':
main2.cpp:11:5: required from here
main2.cpp:6:16: internal compiler error: in retrieve_specialization, at
cp/pt.c:1191
[i ...]{ sink(i ...); };
^~~
0x603f91 retrieve_specialization
../../gcc/gcc/cp/pt.c:1188
0x942e53 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11524
0x927dcd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17684
0x934e29 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17100
0x934e29 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16838
0x933950 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16059
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x932751 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16045
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x925b7b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16030
0x925b7b tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:17056
0x927478 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18346
0x934e29 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17100
0x934e29 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16838
0x933950 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16059
0x932751 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16045
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x925b7b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16030
0x925b7b tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:17056
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ g++ --version
g++ (GCC) 8.0.1 20180202 (experimental)
Copyright (C) 2018 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.
[Bug c/84187] New: -O0 fails inline assembly compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84187
Bug ID: 84187
Summary: -O0 fails inline assembly compile
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rong2.liu at intel dot com
Target Milestone: ---
Hi,
When I use -O0 flag to compile a kernel module, compile fails with following
error message. The same code compiles fine if not using -O0 flag.
make -C /lib/modules/4.12.0+/build M=/home/bob/GccCompileError
make[1]: Entering directory '/home/bob/kernel/v4.12/linux'
CC [M] /home/bob/GccCompileError/GccCompileError.o
In file included from ./include/linux/compiler.h:62:0,
from ./include/linux/init.h:4,
from /home/bob/GccCompileError/GccCompileError.c:1:
./arch/x86/include/asm/cpufeature.h: In function ‘GccCompileError_init’:
./include/linux/compiler-gcc.h:264:38: warning: asm operand 0 probably doesn’t
match constraints
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
./arch/x86/include/asm/cpufeature.h:146:3: note: in expansion of macro
‘asm_volatile_goto’
asm_volatile_goto("1: jmp 6f\n"
^
./include/linux/compiler-gcc.h:264:38: warning: asm operand 2 probably doesn’t
match constraints
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
./arch/x86/include/asm/cpufeature.h:146:3: note: in expansion of macro
‘asm_volatile_goto’
asm_volatile_goto("1: jmp 6f\n"
^
./include/linux/compiler-gcc.h:264:38: error: impossible constraint in ‘asm’
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
./arch/x86/include/asm/cpufeature.h:146:3: note: in expansion of macro
‘asm_volatile_goto’
asm_volatile_goto("1: jmp 6f\n"
^
scripts/Makefile.build:308: recipe for target
'/home/bob/GccCompileError/GccCompileError.o' failed
make[2]: *** [/home/bob/GccCompileError/GccCompileError.o] Error 1
Makefile:1512: recipe for target '_module_/home/bob/GccCompileError' failed
make[1]: *** [_module_/home/bob/GccCompileError] Error 2
make[1]: Leaving directory '/home/bob/kernel/v4.12/linux'
Makefile:16: recipe for target 'all' failed
make: *** [all] Error 2
Here is the very simple source code to demonstrate the error:
1 #include
2 #include
3 #include
4 #include
5
6 MODULE_LICENSE("Proprietary");
7
8 static int __init GccCompileError_init(void)
9 {
10 bool invPcid = false;
11
12 invPcid = static_cpu_has(X86_FEATURE_INVPCID);
13 printk(KERN_ERR "<1> INVPCID = %s\n", invPcid == true ? "true" :
"false");
14
15 //printk("GccCompileError: Hello, world!\n");
16 return 0;
17 }
18
19 static void __exit GccCompileError_exit(void)
20 {
21 printk("GccCompileError: Goodbye, world!\n");
22 }
23
24 module_init(GccCompileError_init);
25 module_exit(GccCompileError_exit);
And the following is Makefile:
1 KERNEL_MODULE_NAME := GccCompileError
2
3 KERNELDIR:=/lib/modules/$(shell uname -r)/build
4 PWD=$(shell pwd)
5
6 INCLUDES = -I.
7
8 ccflags-y += $(INCLUDES) -ggdb -O0
9 #ccflags-y += $(INCLUDES) -ggdb
10
11 obj-m += GccCompileError.o
12
13 switch-y := GccCompileError.o
14
15 all:
16 $(MAKE) -C $(KERNELDIR) M=$(PWD)
17
18 clean:
19 $(MAKE) -C $(KERNELDIR) M=$(PWD) clean
20
21 install:
22 $(MAKE) -C $(KERNELDIR) M=$(PWD) modules_install
[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 Jens-S. Vöckler changed: What|Removed |Added CC||jens4303 at me dot com --- Comment #48 from Jens-S. Vöckler --- The consensus of this thread is that APFS has a bug that HFS+ does not. I also remember that last autumn I was able to build gcc-7.2.0 from source on Sierra. Two weeks later, after upgrading to High Sierra, the same build failed. I just compiled gcc-7.3.0 on 10.13.3 using fink's build mechanism and a large empty non-encrypted HFS+ formatted image file that I created with Disk Utility, and then attached (mounted) at the root of the directory tree where gcc will be unpacked and the "objdir" resides. In fink's case that means mounting the HFS+ image as /sw/fink/src/fink.build after stashing the original "fink.build" to the side. The build utilized all 8 HT cores of the i7, and successfully compiled and installed gcc-7.3.0 (gcc, g++, gfortran) on my machine. I have not tried to compile gcc from source, without fink, using the HFS+ image file work-around, though I don't see why it should not work.
[Bug c/83390] valgrind error in lra_eliminate_regs_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83390 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #7 from David Malcolm --- Can you reproduce it with a specific source file and specific compilation flags? Thanks.
[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84181
--- Comment #6 from Benjamin Buch ---
Yet another version:
template < typename T >
auto var = [](auto ... i){ [i ...]{}; }();
int main(){
var< int >;
}
$ g++ -std=c++14 main4.cpp
main4.cpp: In instantiation of ' [with auto:1 = {}]':
main4.cpp:2:40: required from 'auto var'
main4.cpp:5:5: required from here
main4.cpp:2:31: internal compiler error: Segmentation fault
auto var = [](auto ... i){ [i ...]{}; }();
^~~
0xe79ecf crash_signal
../../gcc/gcc/toplev.c:325
0x916d50 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3245
0x916d50 enclosing_instantiation_of
../../gcc/gcc/cp/pt.c:12694
0x942a7e tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11450
0x941bc8 tsubst_decl
../../gcc/gcc/cp/pt.c:12858
0x92571d tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:16970
0x927478 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18346
0x934e29 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17100
0x934e29 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16838
0x933950 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16059
0x932751 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16045
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x9311d8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16030
0x9311d8 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23384
0x87aeeb maybe_instantiate_decl
../../gcc/gcc/cp/decl2.c:5178
0x87ccf8 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:5273
0x7e7c90 build_over_call
../../gcc/gcc/cp/call.c:8201
0x7f5f1c build_op_call_1
../../gcc/gcc/cp/call.c:4567
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ g++ --version
g++ (GCC) 8.0.1 20180202 (experimental)
Copyright (C) 2018 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.
[Bug c++/84186] nested template qualified-id not parsed correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84186 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-02 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- It accepts it with 'template' added: int a[sizeof(typename N::template S2::X*)]; I'm not sure if that's needed there or not.
[Bug c/84184] gcc generates wrong relocations with negative offsets in struct arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Summary|gcc generates wrong |gcc generates wrong |relocations with negative |relocations with negative |offsets in struct arrays|offsets in struct arrays |(but not integral arrays) | --- Comment #7 from Eric Botcazou --- Investigating about the warning.
[Bug middle-end/84184] gcc generates wrong relocations with negative offsets in struct arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184 Eric Botcazou changed: What|Removed |Added Component|c |middle-end --- Comment #8 from Eric Botcazou --- Recategorizing.
[Bug c++/84186] New: nested template qualified-id not parsed correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84186
Bug ID: 84186
Summary: nested template qualified-id not parsed correctly
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: smw at gcc dot gnu.org
Target Milestone: ---
OK, bear with me on this one, but it appears like a nested qualified-id that is
a simple-template-id confuses the parser, or something.
Here's some code.
template struct N {
struct S1 { // not a template class
typedef short X;
template struct S11 {
int a[sizeof(typename N::S1::X*)]; // OK
};
};
template struct S2 { // woah, a class template
typedef short X;
template struct S21 {
int a[sizeof(typename N::S2::X*)]; // not OK
};
};
};
That snippet gets accepted by ICC, MSVC, clang, and pretty much every other
compiler I tested on, bug GCC (all versions, up to and including 8.0.1
20180202) reject it [-std=c++14 -O0 -Wall -pedantic
-fdiagnostics-generate-patch] with the following diagnostic output.
:14:45: error: 'typename N::S2' names 'template
template struct N::S2', which is not a type
int a[sizeof(typename N::S2::X*)]; // not OK
^
:14:41: error: 'typename N::S2' names 'template
template struct N::S2', which is not a type
int a[sizeof(typename N::S2::X*)]; // not OK
^
:14:46: error: expected '(' before '::' token
int a[sizeof(typename N::S2::X*)]; // not OK
^~
(
:14:46: error: expected ')' before '::' token
int a[sizeof(typename N::S2::X*)]; // not OK
~^~
)
:14:52: error: expected ']' before ';' token
int a[sizeof(typename N::S2::X*)]; // not OK
^
]
---
+++
@@ -11,7 +11,7 @@
typedef short X;
template struct S21 {
-int a[sizeof(typename N::S2::X*)]; // not OK
+int a[sizeof(typename N::S2()::X*)]]; // not OK
};
};
};
Compiler returned: 1
[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #33 from Jürgen Reuter --- Mea culpa. I had to recompile the external libraries again. Then those tests depending on the external libraries did also work (headbang).
[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84181
--- Comment #5 from Benjamin Buch ---
I'm not completely sure anymore whether this is related, another version of the
new bug is:
template < typename ... T >
void sink(T ...){}
template < typename T >
auto var = [](auto ... i){ sink(i + 0 ...); }();
int main(){
var< int >;
}
$ g++ -std=c++14 main3.cpp
main3.cpp: In instantiation of ' [with auto:1 = {}]':
main3.cpp:5:46: required from 'auto var'
main3.cpp:8:5: required from here
main3.cpp:5:32: internal compiler error: Segmentation fault
auto var = [](auto ... i){ sink(i + 0 ...); }();
^~~
0xe79ecf crash_signal
../../gcc/gcc/toplev.c:325
0x916d50 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3245
0x916d50 enclosing_instantiation_of
../../gcc/gcc/cp/pt.c:12694
0x942a7e tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11450
0x927dcd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17684
0x934e29 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17100
0x934e29 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16838
0x933950 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16059
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x9311d8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16030
0x9311d8 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23384
0x87aeeb maybe_instantiate_decl
../../gcc/gcc/cp/decl2.c:5178
0x87ccf8 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:5273
0x7e7c90 build_over_call
../../gcc/gcc/cp/call.c:8201
0x7f5f1c build_op_call_1
../../gcc/gcc/cp/call.c:4567
0x7f5f1c build_op_call(tree_node*, vec**, int)
../../gcc/gcc/cp/call.c:4596
0x970075 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2506
0x92849e tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17874
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/84184] gcc generates wrong relocations with negative offsets in struct arrays (but not integral arrays)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184 --- Comment #6 from Eric Botcazou --- > Could gcc generate warning without much of additional effort (or even better > an error) when it knows it is about to generate broken code? Generating broken code from invalid C is perfectly OK, but we could indeed warn. > For this code I guess the pattern is + . The key is really the misalignment, which forces the bitfield path. Other paths in the compiler handle the negative literal just fine.
[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 Benjamin Buch changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Benjamin Buch --- I've checked it again and this bug seems not to be related, I do a separate report.
[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
Benjamin Buch changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #6 from Benjamin Buch ---
Thanks for fixing!
Found a variable template version that is still broken:
template
void sink(Ts...){}
template
int bar(T&){} // ICE with reference, work with just T
template
auto var = [](auto ... k){
sink(bar(k) ...);
}(0);
int main() {
var;
}
$ g++ -std=c++14 main2.cpp
main2.cpp: In function 'int bar(T&)':
main2.cpp:5:13: warning: no return statement in function returning non-void
[-Wreturn-type]
int bar(T&){} // ICE with reference, work with just T
^
main2.cpp: In instantiation of ' [with auto:1 = {int}]':
main2.cpp:10:6: required from 'auto var'
main2.cpp:14:5: required from here
main2.cpp:9:13: internal compiler error: Segmentation fault
sink(bar(k) ...);
^~~~
0xe79ecf crash_signal
../../gcc/gcc/toplev.c:325
0x916d50 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3245
0x916d50 enclosing_instantiation_of
../../gcc/gcc/cp/pt.c:12694
0x942a7e tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11450
0x927dcd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17684
0x934e29 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17100
0x934e29 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16838
0x933950 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16059
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x9311d8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16030
0x9311d8 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23384
0x87aeeb maybe_instantiate_decl
../../gcc/gcc/cp/decl2.c:5178
0x87ccf8 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:5273
0x7e7c90 build_over_call
../../gcc/gcc/cp/call.c:8201
0x7f5f1c build_op_call_1
../../gcc/gcc/cp/call.c:4567
0x7f5f1c build_op_call(tree_node*, vec**, int)
../../gcc/gcc/cp/call.c:4596
0x970075 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2506
0x92849e tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17874
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ g++ --version
g++ (GCC) 8.0.1 20180202 (experimental)
Copyright (C) 2018 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.
[Bug tree-optimization/81038] [8 regression] test case g++.dg/vect/slp-pr56812.cc fails starting with r248678
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81038
--- Comment #8 from Bill Schmidt ---
The commentary for r248678 reads in part: "Compute costs for doing no peeling
at all, compare to the best peeling costs so far and avoid peeling if cheaper."
Indeed, if you look at the vect dump for r248677, you see that the vectorizer
decides to force alignment using peeling, even though the target processor has
efficient unaligned memory access. Peeling proved to be barely unprofitable:
/home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/g++.dg/vect/slp-pr56812.cc:1\
6:18: note: Cost model analysis:
Vector inside of loop cost: 1
Vector prologue cost: 7
Vector epilogue cost: 6
Scalar iteration cost: 1
Scalar outside cost: 0
Vector outside cost: 13
prologue iterations: 2
epilogue iterations: 2
Calculated minimum iters for profitability: 17
/home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/g++.dg/vect/slp-pr56812.cc:1\
6:18: note: Runtime profitability threshold = 16
/home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/g++.dg/vect/slp-pr56812.cc:1\
6:18: note: Static estimate profitability threshold = 16
/home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/g++.dg/vect/slp-pr56812.cc:1\
6:18: note: not vectorized: vectorization not profitable.
In the vect dump for r248678, the vectorizer isn't overly focused on peeling,
and determines that it can use the efficient unaligned storage accesses. This
leads to the more reasonable cost calculation:
/home/wschmidt/gcc/gcc-mainline-test/gcc/testsuite/g++.dg/vect/slp-pr56812.cc:1\
6:18: note: Cost model analysis:
Vector inside of loop cost: 1
Vector prologue cost: 1
Vector epilogue cost: 0
Scalar iteration cost: 1
Scalar outside cost: 0
Vector outside cost: 1
prologue iterations: 0
epilogue iterations: 0
Calculated minimum iters for profitability: 2
/home/wschmidt/gcc/gcc-mainline-test/gcc/testsuite/g++.dg/vect/slp-pr56812.cc:1\
6:18: note: Runtime profitability threshold = 3
/home/wschmidt/gcc/gcc-mainline-test/gcc/testsuite/g++.dg/vect/slp-pr56812.cc:1\
6:18: note: Static estimate profitability threshold = 3
/home/wschmidt/gcc/gcc-mainline-test/gcc/testsuite/g++.dg/vect/slp-pr56812.cc:1\
6:18: note: loop vectorized
For this processor, we vectorized the code in "vect" rather than in "slp". For
other processors, the choice could be different because of cost model
differences. But I think in general we should always vectorize. In both cases
the "optimized" dump produces:
void mydata::Set(float) (struct mydata * const this, float x)
{
vector(4) float vect_cst__10;
[11.11%]:
vect_cst__10 = {x_5(D), x_5(D), x_5(D), x_5(D)};
MEM[(float *)this_4(D)] = vect_cst__10;
MEM[(float *)this_4(D) + 16B] = vect_cst__10;
return;
}
So I think perhaps it would be better to change the test to examine the
"optimized" dump for one definition and two uses of a vect_cst__*. The point
of the original complaint in PR56812 was that this test case was not vectorized
(by SLP at the time), but so long as it is vectorized, that should be good
enough for everyone.
[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84181
Benjamin Buch changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #4 from Benjamin Buch ---
Thanks for your fast patching!
I found another variant of this bug if you use a variable template instead of a
function:
template < int ... I >
struct A{};
template < typename T >
auto var = [](auto ... i){
return A< decltype(i)::x ... >{};
};
int main(){
var< int >();
}
$ g++ -std=c++14 main3.cpp
main3.cpp: In instantiation of ' [with auto:1 = {}]':
main3.cpp:10:16: required from here
main3.cpp:6:40: internal compiler error: Segmentation fault
return A< decltype(i)::x ... >{};
^
0xe79ecf crash_signal
../../gcc/gcc/toplev.c:325
0x916d50 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3245
0x916d50 enclosing_instantiation_of
../../gcc/gcc/cp/pt.c:12694
0x942a7e tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11450
0x94452a tsubst_template_args
../../gcc/gcc/cp/pt.c:11836
0x944438 tsubst_template_args
../../gcc/gcc/cp/pt.c:11854
0x940d15 tsubst_aggr_type
../../gcc/gcc/cp/pt.c:12067
0x93b25e tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13706
0x926df4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18153
0x934e29 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17100
0x934e29 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16838
0x932e80 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16055
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x9311d8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16030
0x9311d8 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23384
0x87aeeb maybe_instantiate_decl
../../gcc/gcc/cp/decl2.c:5178
0x87ccf8 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:5273
0x7e7c90 build_over_call
../../gcc/gcc/cp/call.c:8201
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/82914] 'struct __attribute__ ((aligned (N))) s' ignores 'aligned' attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82914 --- Comment #6 from Martin Sebor --- Created attachment 43330 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43330&action=edit Patch tested on x86_64-linux. GCC 9 patch regression-tested on x86_64-linux.
[Bug tree-optimization/81038] [8 regression] test case g++.dg/vect/slp-pr56812.cc fails starting with r248678
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81038 Bill Schmidt changed: What|Removed |Added Assignee|acsawdey at gcc dot gnu.org|wschmidt at gcc dot gnu.org --- Comment #7 from Bill Schmidt --- I'm looking at this one.
[Bug c/82914] 'struct __attribute__ ((aligned (N))) s' ignores 'aligned' attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82914
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|RESOLVED|ASSIGNED
Last reconfirmed||2018-02-02
CC||msebor at gcc dot gnu.org
Resolution|INVALID |---
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #5 from Martin Sebor ---
(In reply to Paul Eggert from comment #4)
> Here, GCC says the alignment of 'b' is 1, not 8. What happened to the
> attribute?
GCC silently drops it, without validating it. For instance, this is accepted
as well:
struct s { char mem; };
struct __attribute__ ((foobar))
s b;
I view it as a bug. At a minimum, GCC should point out that it's ignoring the
attribute like other compilers do, such as Clang:
warning: unknown attribute 'foobar' ignored [-Wunknown-attributes]
I happened to notice this bug while testing a fix for pr84108. It seems that a
simple fix is fairly straightforward so hopefully Richard won't be offended if
I reopen this bug, assign it to myself, and submit my patch in stage 1 of GCC
9.
[Bug c/84184] gcc generates wrong relocations with negative offsets in struct arrays (but not integral arrays)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184 --- Comment #5 from Sergei Trofimovich --- Good suggestion! I will do it. Could gcc generate warning without much of additional effort (or even better an error) when it knows it is about to generate broken code? For this code I guess the pattern is + .
[Bug c/84184] gcc generates wrong relocations with negative offsets in struct arrays (but not integral arrays)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184
--- Comment #4 from Eric Botcazou ---
I'd suggest fixing the code instead:
extern struct s glo_s_middle_hidden[] __attribute__((visibility("hidden")));
which makes it valid C and generates correct code.
[Bug c/84184] gcc generates wrong relocations with negative offsets in struct arrays (but not integral arrays)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-02 Ever confirmed|0 |1 --- Comment #3 from Eric Botcazou --- Calling this standard C is really questionable. This goes awry on 64-bit RISC architectures with strict-alignment requirement because get_inner_reference returns a negative bit position and passes it down to the bitfield extraction machinery, which expects only non-negative bit positions.
[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #32 from Thomas Koenig --- (In reply to Jürgen Reuter from comment #31) > Unfortunately, the problem with our external libraries still persist. Don't > know how to provide you with a test case for this without providing our > complete code and their external complete code. :( How does the error manifest itself? Internal library error, segfault, ... ? If it is an internal error, you could compile everything with -g (including the external libraries), start under a debugger, then set a breakpoint at _gfortrani_internal_error, and then run. A backtrace could be quite illuminating. Similar for a segfault - run under a debugger and look at a backtrace.
[Bug tree-optimization/84178] [7/8 Regression] ICE in release_bb_predicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84178 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-02-02 CC||dmalcolm at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Confirmed with trunk and gcc 7. There seem to be two issues here; the differences seen between trunk and gcc 7 appear to be due to trunk currently defaulting to --enable-checking=yes,extra and 7 defaulting to --enable-checking=release and thus gcc_assert is a no-op by default for gcc 7. Checked builds of trunk and gcc 7 both fail this assertion inside "ifcvt": 283 if (flag_checking) 284 for (gimple_stmt_iterator i = gsi_start (stmts); 285 !gsi_end_p (i); gsi_next (&i)) 286 gcc_assert (! gimple_use_ops (gsi_stmt (i))); #1 0x010b98ff in release_bb_predicate (bb=) at ../../src/gcc/tree-if-conv.c:286 #2 0x010b994c in free_bb_predicate (bb=) at ../../src/gcc/tree-if-conv.c:300 #3 0x010c091f in tree_if_conversion (loop=0x71a09ee0) at ../../src/gcc/tree-if-conv.c:2897 #4 0x010c0aa2 in (anonymous namespace)::pass_if_conversion::execute (this=0x2abab80, fun=0x71a00160) at ../../src/gcc/tree-if-conv.c:2962 #5 0x00ec11b2 in execute_one_pass (pass=) at ../../src/gcc/passes.c:2497 [...] on this GIMPLE_ASSIGN: _175 = (signed char) _117; Release builds of trunk and of gcc 7 fail later, reading through a NULL basic_block in VRP: (gdb) bt #0 mark_block_for_update(basic_block_def*) () at ../../src/gcc/tree-into-ssa.c:447 #1 0x00af1c10 in mark_use_interesting (insert_phi_p=false, bb=, stmt=, var=) at ../../src/gcc/tree-into-ssa.c:2540 #2 prepare_use_sites_for (insert_phi_p=false, name=) at ../../src/gcc/tree-into-ssa.c:2705 #3 prepare_names_to_update (insert_phi_p=false) at ../../src/gcc/tree-into-ssa.c:2773 #4 update_ssa(unsigned int) () at ../../src/gcc/tree-into-ssa.c:3339 #5 0x00c39fd0 in insert_range_assertions () at ../../src/gcc/tree-vrp.c:6849 #6 execute_vrp (warn_array_bounds_p=false) at ../../src/gcc/tree-vrp.c:11724 #7 (anonymous namespace)::pass_vrp::execute(function*) () at ../../src/gcc/tree-vrp.c:11833 #8 0x009df329 in execute_one_pass (pass=pass@entry=) at ../../src/gcc/passes.c:2465 [...] again on a GIMPLE_ASSIGN: _177 = (signed char) _26; due to it having a NULL bb: (gdb) p stmt->bb $5 =
[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #31 from Jürgen Reuter --- Unfortunately, the problem with our external libraries still persist. Don't know how to provide you with a test case for this without providing our complete code and their external complete code. :(
[Bug c/84184] gcc generates wrong relocations with negative offsets in struct arrays (but not integral arrays)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184 --- Comment #2 from Sergei Trofimovich --- > - large amount of code Jason pointed out the blowup happens due to byte-level reads (caused by 'char*' -> 'u64*' required alignment increase) thus it's expected. Only correctness issue is left.
[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 --- Comment #27 from Thomas Koenig --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00071.html
[Bug bootstrap/56750] [6/7/8 Regression] static -lstdc++ logic bleeds into all subdirs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56750 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #13 from Aldy Hernandez --- (In reply to Eric Botcazou from comment #4) > > Well, if you can link dynamically, you should, if say libstdc++ contains > > some security bug and gdb isn't built in the combined tree with gcc, then > > I'd say it is highly undesirable to link it statically. > > Your point of view is clearly too Linux-centric here. :-) I can assure you > that the last thing people want on Solaris on HP-UX is to have to install > shared libraries to run GDB. Hi folks. It's been 4 years with no progress here. Is this becoming a WONTFIX or should we add a toplevel configure flag to give the user an option to opt out of -static-libstdc++ -static-libgcc? The the original patch has a work around, just specify --with-stage1-libs=" " and you won't get the offending behavior :): # In stage 1, default to linking libstdc++ and libgcc statically with GCC # if supported. But if the user explicitly specified the libraries to use, # trust that they are doing what they want. if test "$stage1_libs" = "" -a "$have_static_libs" = yes; then stage1_ldflags="-static-libstdc++ -static-libgcc" fi]) Should we make an explicit configury flag for this behavior instead of the above work around? Should we instead close this as a WONTFIX with a pointer to the following in our docs: --with-stage1-ldflags=flags This option may be used to set linker flags to be used when linking stage 1 of GCC. These are also used when linking GCC if configured with --disable-bootstrap. If --with-stage1-libs is not set to a value, then the default is ‘-static-libstdc++ -static-libgcc’, if supported. Any input would be great.
[Bug target/84169] [8 Regression] wrong code with u128 multiplication result at aarch64 -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84169 --- Comment #4 from Segher Boessenkool --- This starts to fail with r249850 (don't know yet what the problem is).
[Bug c/84183] internal compiler error: in initialize, at alloc-pool.h:257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84183 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #1 from David Malcolm --- Thanks for filing this bug report. Looks like it's failing in "s-selftest", running the selftests within cc1. These ought to be a no-op for a release build, so presumably it's just happening to fail the first time that the newly built cc1 is run. Line 257 of alloc-pool.h is: gcc_checking_assert (m_name); within base_pool_allocator ::initialize (), so presumably m_name is NULL ...somehow.
[Bug c/84108] [8 Regression] incorrect -Wattributes warning for packed/aligned conflict on struct members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84108 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #4 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00125.html
[Bug fortran/84155] [8 Regression] program hangs on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155 --- Comment #12 from Thomas Koenig --- (In reply to Jürgen Reuter from comment #11) > There was another test case that I submitted for #84141. It still failed > after the first preliminary fix. This one also works with the patch from comment #8 (and without the trans-io.c patch). Looking very good, I think.
[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #30 from Jürgen Reuter --- Yep, that looks good. Paul's fix is now the change in trans-array.c only, or still the change in trans-io.c ? I guess only the trans-array.c patch. I'll try it out later tonight.
[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #29 from Thomas Koenig --- (In reply to Jürgen Reuter from comment #24) > Created attachment 43322 [details] > 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 With Paul's fix for PR84155, the output of the test now is | | Running self-test: resonance_insertion | Running test: resonance_insertion_2 ... success. *** Test Summary *** Success: resonance_insertion_2: resonance color mismatch Total = 1 Success = 1 Failure = 0 *** End of test Summary *** | WHIZARD run finished. |=| which looks like success.
[Bug fortran/84155] [8 Regression] program hangs on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155 --- Comment #11 from Jürgen Reuter --- There was another test case that I submitted for #84141. It still failed after the first preliminary fix.
[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #28 from Jürgen Reuter --- Created attachment 43329 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43329&action=edit Shortened test case (after prelim. fix) This is a shortened test case that still failed after the first preliminary fix by Paul Thomas with the special care for the allocatables. Just compile and run, it seg faults.
[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #27 from Paul Thomas --- Please see PR84155 for a fix that looks somewhat cleaner but note the caveat associated with it. Paul
[Bug fortran/84155] [8 Regression] program hangs on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155 --- Comment #10 from Paul Thomas --- Created attachment 43328 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43328&action=edit Patch for the bug This patch fixes the PR and PR84141. The dejagnuified version of the reproducer will appear with submission to the list - it reads back the scratch file and checks that the value recorded is correct. There is an important caveat to this fix, which has me very worried: On top of removal of uncalled code making the bug disappear, I cannot see any difference in the tree dump between the working testcase and the failing version. I am going to have to call in the cavalry tomorrow. Paul
[Bug middle-end/84185] New: missing warning when ignoring attribute aligned on a member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84185
Bug ID: 84185
Summary: missing warning when ignoring attribute aligned on a
member
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
As mentioned in bug 84108 comment 2, GCC warns about variable declarations that
specify both attribute aligned and packed, yet it requires both attributes to
reduce the alignment of a struct member and doesn't indicate that a sole
aligned attribute has no such effect (i.e., doesn't reduce the member's
alignment).
The limitation/requirement of the aligned attribute is documented in the
manual:
When used on a struct, or struct member, the aligned attribute can only
increase the alignment; in order to decrease it, the packed attribute must be
specified as well.
but because it is subtle and inconsistent with how the attribute is treated for
non-members, it's easy to miss. See also bug 82914 for another example of
confusion this has lead to.
Assuming it's too risky to make the attribute behave consistently for both
members and non-members, GCC could help reduce the confusion (and bugs) by
issuing a warning when the attribute is specified alone on a member and known
to have no effect.
$ cat t.c && gcc -S -Wall -Wextra t.c
#define ASSERT(e) _Static_assert (e, #e)
struct {
int a __attribute__ ((aligned (2))); // attribute ignored, missing warning
} a;
ASSERT (_Alignof (a.a) == 2);// assertion failure
struct {
int b __attribute__ ((packed));
} b;
ASSERT (_Alignof (b.b) == 1);// passes
struct {
int c __attribute__ ((aligned (2), packed));
} c;
ASSERT (_Alignof (c.c) == 2);// passes
t.c:1:19: error: static assertion failed: "_Alignof (a.a) == 2"
#define ASSERT(e) _Static_assert (e, #e)
^~
t.c:7:1: note: in expansion of macro ‘ASSERT’
ASSERT (_Alignof (a.a) == 2);// assertion failure
^~
[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 --- Comment #13 from Eric Botcazou --- Author: ebotcazou Date: Fri Feb 2 18:09:32 2018 New Revision: 257343 URL: https://gcc.gnu.org/viewcvs?rev=257343&root=gcc&view=rev Log: PR lto/83954 * lto-symtab.c (warn_type_compatibility_p): Do not recurse into the component type of array types with non-aliased component. Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto-symtab.c
[Bug c/84184] gcc generates wrong relocations with negative offsets in struct arrays (but not integral arrays)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184
Sergei Trofimovich changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment #1 from Sergei Trofimovich ---
Dumping 'val_s_hidden':
extern char glo_s_middle_hidden[] __attribute__((visibility("hidden")));
static u64 __attribute__((noinline)) val_s_hidden(void) {
const struct s * m = (const struct s *)glo_s_middle_hidden;
return m[-1].a;
}
$ cat reloc-bug.c.227t.optimized
;; Function val_s_hidden (val_s_hidden, funcdef_no=23, decl_uid=2082,
cgraph_uid=23, symbol_order=24) (executed once)
__attribute__((noinline))
val_s_hidden ()
{
u64 _2;
[100.00%]:
_2 = MEM[(const struct s *)&glo_s_middle_hidden + -8B].a;
return _2;
}
Still looks ok, right? I guess RTL is doing funny things here (+Eric).
$ cat reloc-bug.c.229r.expand
;;
;; Full RTL generated for this function:
;;
(note 1 0 3 NOTE_INSN_DELETED)
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 3 5 2 NOTE_INSN_FUNCTION_BEG)
(insn 5 2 6 2 (set (reg/f:DI 342)
(symbol_ref:DI ("glo_s_middle_hidden") [flags 0x42] )) "reloc-bug.c":17 -1
(nil))
(insn 6 5 7 2 (set (reg:DI 343)
(reg/f:DI 342)) "reloc-bug.c":17 -1
(nil))
(insn 7 6 8 2 (set (reg:DI 345)
(const_int 2305843009213693944 [0x1ff8]))
"reloc-bug.c":17 -1
(nil))
...
Surprisingly large amount of code is generated here:
$ cat reloc-bug.S
val_s_hidden:
.prologue
.body
.mlx
nop 0
movl r14 = @gprel(glo_s_middle_hidden#)
.mlx
nop 0
movl r16 = 2305843009213693945 ; 0x1ff9
;;
.mlx
add r14 = r1, r14
movl r15 = 2305843009213693944 ; 0x1ff8
.mlx
nop 0
movl r17 = 2305843009213693946 ; 0x1ffa
;;
.mmi
add r15 = r14, r15
add r17 = r14, r17
add r16 = r14, r16
;;
.mmi
ld1 r8 = [r15]
ld1 r16 = [r16]
nop 0
;;
.mlx
ld1 r15 = [r17]
movl r17 = 2305843009213693947 ; 0x1ffb
.mib
nop 0
shl r16 = r16, 8
nop 0
;;
.mmi
add r17 = r14, r17
or r16 = r8, r16
shl r15 = r15, 16
;;
.mlx
ld1 r8 = [r17]
movl r17 = 2305843009213693948 ; 0x1ffc
.mmi
or r15 = r16, r15
;;
add r17 = r14, r17
shl r8 = r8, 24
;;
.mlx
ld1 r16 = [r17]
movl r17 = 2305843009213693949 ; 0x1ffd
.mmi
or r8 = r15, r8
;;
add r17 = r14, r17
shl r16 = r16, 32
;;
.mlx
ld1 r15 = [r17]
movl r17 = 2305843009213693950 ; 0x1ffe
.mmi
or r16 = r8, r16
;;
add r17 = r14, r17
shl r15 = r15, 40
;;
.mlx
ld1 r8 = [r17]
movl r17 = 2305843009213693951 ; 0x1fff
.mmi
or r15 = r16, r15
;;
add r14 = r14, r17
shl r8 = r8, 48
;;
.mii
ld1 r16 = [r14]
or r15 = r15, r8
;;
shl r8 = r16, 56
;;
.mib
nop 0
or r8 = r15, r8
br.ret.sptk.many b0
.endp val_s_hidden#
I hoped to see here single load (something like that):
mov = @gprel64(glo_s_middle_hidden#)
add = gp,
ld8 r8 = []
I see 2 issues here:
- code is invalid
- large amount of code
[Bug c/84184] New: gcc generates wrong relocations with negative offsets in struct arrays (but not integral arrays)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184
Bug ID: 84184
Summary: gcc generates wrong relocations with negative offsets
in struct arrays (but not integral arrays)
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Created attachment 43327
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43327&action=edit
reloc-bug.c
It's a trimmed-down version of linux kernel miscompilation on ia64:
https://bugs.gentoo.org/518130
Minimal reproducer:
// cat reloc-bug.c
#include
typedef unsigned long long u64;
struct s { u64 a; };
struct s glo_s[] = {
{ 100, },
// glo_s_middle_hidden:
// ; Injected as LDFLAGS="-Wl,--defsym=glo_s_middle=glo_s+8
-Wl,--defsym=glo_s_middle_hidden=glo_s+8"
{ 700, },
{ 800, },
};
extern char glo_s_middle_hidden[] __attribute__((visibility("hidden")));
static u64 __attribute__((noinline)) val_s_hidden(void) {
const struct s * m = (const struct s *)glo_s_middle_hidden;
return m[-1].a;
}
int main() {
printf ("val/hidden = %lld\n", val_s_hidden());
}
+ ia64-unknown-linux-gnu-gcc-7.2.0 -c -O2 reloc-bug.c -o reloc-bug.o
+ ia64-unknown-linux-gnu-gcc-7.2.0 -O2 reloc-bug.o -o reloc-bug
-Wl,--defsym=glo_s_middle=glo_s+8 -Wl,--defsym=glo_s_middle_hidden=glo_s+8
+ ./reloc-bug
./mk.sh: line 12: 12418 Segmentation fault ./reloc-bug
Note a few things:
Note 1:
it's not trivial to write the code in standard C. I had to synthesise symbol
with --defsym. I tried a few targets where this sample crashes instead of
returning 100:
# fails
CC=sparc64-unknown-linux-gnu-gcc
CC=ia64-unknown-linux-gnu-gcc
CC=alpha-unknown-linux-gnu-gcc
# works
CC=sparc-unknown-linux-gnu-gcc
CC=x86_64-pc-linux-gnu-gcc
CC=aarch64-unknown-linux-gnu-gcc
CC=armv5tel-softfloat-linux-gnueabi-gcc
CC=hppa-unknown-linux-gnu-gcc
CC=hppa2.0-unknown-linux-gnu-gcc
CC=m68k-unknown-linux-gnu-gcc
CC=mips-unknown-linux-gnu-gcc
CC=nios2-unknown-linux-gnu-gcc
CC=powerpc-unknown-linux-gnu-gcc
CC=powerpc64-unknown-linux-gnu-gcc
CC=powerpc64le-unknown-linux-gnu-gcc
CC=s390x-unknown-linux-gnu-gcc
CC=sh4-unknown-linux-gnu-gcc
Note 2:
If we change
struct s { u64 a; };
struct s glo_s[] = {
to
u64 glo_s[] = {
gcc will generate correct code.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #16 from Andrew Jenner --- I have committed a patch to the .opt files: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00114.html I have also submitted a patch to the documentation: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00115.html
[Bug tree-optimization/82604] [8 Regression] SPEC CPU2006 410.bwaves ~50% performance regression with trunk@253679 when ftree-parallelize-loops is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82604 --- Comment #24 from Alexander Nesterovskiy --- Yes, it looks like more time is being spent in synchronizing. r256990 really changes the way autopar works: For r253679...r256989 the most of work was in main thread0 mostly (thread0 ~91%, threads1-3 ~3% each one). For r256990 there is the same distribution as for r253678 (thread0 ~34%, threads1-3 ~22% each one) but a lot of time is being spent spinning. I've attached a chart comparing r253678 and r256990 in the same time scale (~0.5 sec). libgomp.so.1.0.0 code executed in thread1 for both cases is wait functions, and for r256990 they are called more often. Setting OMP_WAIT_POLICY doesn't change a lot: for ACTIVE - performance is nearly the same as default for PASSIVE - there is a serious performance drop for r256990 (looks reasonable because of a lots of threads sleeps/wake-ups) Changing parloops-schedule also have no positive effect: r253678 performance is mostly the same for static, guided and dynamic r256990 performance is best with static, which is default
[Bug tree-optimization/82604] [8 Regression] SPEC CPU2006 410.bwaves ~50% performance regression with trunk@253679 when ftree-parallelize-loops is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82604 --- Comment #23 from Alexander Nesterovskiy --- Created attachment 43326 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43326&action=edit r253678 vs r256990
[Bug rtl-optimization/84071] [7/8 regression] wrong elimination of zero-extension after sign-extended load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071 --- Comment #22 from Eric Botcazou --- > So MIPS fundamentally needs this feature to work correctly; whether AArch64 > needs it or may just benefit from it depends on a lot of detailed knowledge > of the ISA and architecture. Given Richard Sandiford is currently working on > ARM ports but also fully understands the MIPS arch then he may be a good > person to consult. If "this feature" is WORD_REGISTER_OPERATIONS, then I don't think that any target, including MIPS, really needs it. Defining the macro is only an optimization and a way to convey multiple properties of the target with only one setting. And, for MIPS, the implementation of the sign-extension invariant is done by other means.
[Bug c++/84182] [8 Regression] ICE in variadic lambda inside a template when calling a captured lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84182 Jason Merrill changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Keywords||ice-on-valid-code Last reconfirmed||2018-02-02 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |8.0
[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84181 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed.
[Bug c/84108] [8 Regression] incorrect -Wattributes warning for packed/aligned conflict on struct members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84108 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84181 --- Comment #2 from Jason Merrill --- Author: jason Date: Fri Feb 2 16:42:46 2018 New Revision: 257339 URL: https://gcc.gnu.org/viewcvs?rev=257339&root=gcc&view=rev Log: PR c++/84181 - ICE with lambda parm in template argument. * tree.c (strip_typedefs_expr): Use cp_tree_operand_length. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-targ1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c
[Bug c++/77712] int() is incorrectly treated as a null pointer constant in C++11 and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77712 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2016-09-23 00:00:00 |2018-2-2 --- Comment #1 from Jonathan Wakely --- This should be accepted in C++03 mode but rejected in C++11 and later (as I think we treat DR 903 as a DR against C++11)
[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84181 Jason Merrill changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P1 Target Milestone|--- |8.0
[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84181 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-02-02 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/84169] [8 Regression] wrong code with u128 multiplication result at aarch64 -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84169 --- Comment #3 from Segher Boessenkool --- Confirmed. Does not happen with a compiler a few months old.
[Bug testsuite/52641] Test cases fail for 16-bit int targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641 --- Comment #16 from Georg-Johann Lay --- Author: gjl Date: Fri Feb 2 15:07:37 2018 New Revision: 257333 URL: https://gcc.gnu.org/viewcvs?rev=257333&root=gcc&view=rev Log: PR testsuite/52641 * gcc.c-torture/execute/pr83362.c: Make work for int16. * gcc.dg/Wsign-conversion.c: Dito. * gcc.dg/attr-alloc_size-4.c: Dito. * gcc.dg/pr81020.c: Dito. * gcc.dg/pr81192.c: Dito. * gcc.dg/pr83463.c (dg-options): Add -Wno-pointer-to-int-cast. * gcc.dg/attr-alloc_size-11.c: Also special-case avr. * gcc.dg/pr83844.c: Restrict to int32plus. * gcc.dg/attr-alloc_size-3.c: Restrict to size32plus. * gcc.dg/tree-ssa/ldist-25.c: Dito. * gcc.dg/tree-ssa/ldist-27.c: Dito. * gcc.dg/tree-ssa/ldist-28.c: Dito. * gcc.dg/tree-ssa/ldist-29.c: Dito. * gcc.dg/tree-ssa/ldist-30.c: Dito. * gcc.dg/tree-ssa/ldist-31.c: Dito. * gcc.dg/tree-ssa/ldist-32.c: Dito. * gcc.dg/tree-ssa/ldist-33.c: Dito. * gcc.dg/tree-ssa/ldist-34.c: Dito. * gcc.dg/tree-ssa/ldist-35.c: Dito. * gcc.dg/tree-ssa/ldist-36.c: Dito. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/pr83362.c trunk/gcc/testsuite/gcc.dg/Wsign-conversion.c trunk/gcc/testsuite/gcc.dg/attr-alloc_size-11.c trunk/gcc/testsuite/gcc.dg/attr-alloc_size-3.c trunk/gcc/testsuite/gcc.dg/attr-alloc_size-4.c trunk/gcc/testsuite/gcc.dg/pr81020.c trunk/gcc/testsuite/gcc.dg/pr81192.c trunk/gcc/testsuite/gcc.dg/pr83463.c trunk/gcc/testsuite/gcc.dg/pr83844.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-25.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-27.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-28.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-29.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-30.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-31.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-32.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-33.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-34.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-35.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-36.c
[Bug c++/82734] -Wignored-qualifiers is maybe too strict when using decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82734 --- Comment #3 from Sylvestre Ledru --- For people who are getting these error, we fixed it with: static_cast::type>(INT32_MAX)
[Bug c/84100] [7 Regression] Function __attribute__((optimize(align-loops=32))) gives spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84100 --- Comment #6 from Chris Hall --- Created attachment 43325 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43325&action=edit Summary of results using Compiler Explorer: for v5.4.0, 6.3.0 and 7.2.0. Setting -O2 or -O3 on the command line appears to imply -falign-functions=16 and -falign-loops=n, where n is at least 10 but less than 14. Setting -falign-functions=32 on the command line does the requested alignment, plus the implied -falign-loops=n for -O2 and -O3 -- except for -Os, which does no alignment Setting both -falign-functions=32 and -falign-loops=32 on the command line does both requested alignments -- except for -Os which does neither and -O0 which does only the function alignment. So far, so good. One might hope that using _Pragma() would have the same effect as the command line -falign-functions=32 and -falign-loops=32. Sadly, this is not the case. As reported, v7 rejects the pragmas. But I find that v5.4.0 and v6.3.0, (a) don't always do the same thing and (b) don't always align loops as requested. In particular: for -O2 and -O3, setting both align-functions=32 and align-loops=32 by _Pragma() will: align functions as requested, BUT loops are aligned to 8 (which is less than useful) !! The last set of results looks at compiling with command line -O0 through to -O3 (including -Og and -Os), with _Pragma() for -O3, align-functions=32 and align-loops=32. The _Pragma() for -O3 seems to override the command line as far as this small test is concerned, except for -fomit-frame-pointer. Sadly, align-loops=32 is still broken.
[Bug bootstrap/84153] Bootstrap failure when using dependency libraries in non-system location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84153 --- Comment #4 from Brett Neumeier --- Created attachment 43324 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43324&action=edit Patch to add rpath for GMP, MPC, MPFR, ISL when needed OK. I'm just going to leave this patch here -- tested and verified to resolve my issues I'm having -- for anyone else who runs across this problem and happens to check the gcc bugzilla to see if it's a known problem. I was interested to see that the GMP, MPC, MPFR, and ISL configure scripts all have logic to add RPATHs as well, although the logic there is a good deal more complicated than this. So at least I'm in good company thinking it's The Right Thing to do. Cheers!
[Bug target/59865] gnu multiversion calculates wrong target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59865 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Eric Gallager --- (In reply to Eric Gallager from comment #4) > (In reply to Eric Gallager from comment #3) > > > > I can't reproduce this bug due to my target lacking ifunc support. Someone > > with a more capable target will need to test to be able to move this bug out > > of WAITING. > > Now that I have access to the gcc compile farm, I have been able to test on > x86_64-pc-linux-gnu, and I get an assemble failure instead of an executable: > > egallager@gcc12:~$ /opt/cfarm/gcc-latest/bin/gcc 59865.C -S -Wall -Wextra > egallager@gcc12:~$ /opt/cfarm/gcc-latest/bin/gcc 59865.C -o 59865.exe > /tmp/cc2p5hY8.s: Assembler messages: > /tmp/cc2p5hY8.s:158: Error: unrecognized symbol type "gnu_indirect_function" > egallager@gcc12:~$ grep movl 59865.s | grep foov > movl$_Z3foov.popcnt, %eax > movl$_Z3foov.arch_corei7, %eax > movl$_Z3foov, %eax > egallager@gcc12:~$ Closing since it's been in WAITING for so long with no response
[Bug target/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |FIXED --- Comment #34 from Eric Gallager --- So, since backports were requested for 5 and 6, and the 5 branch is closed now, and the backport for 6 is already done, I'm going to close this as FIXED now.
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 --- Comment #7 from Adam Conrad --- (In reply to Javier Serrano Polo from comment #6) > > > the discussion about names is probably more appropriate on the libc side > > Adam, do you agree? I agree with this statement, sure. But I don't agree that there's any point in having the discussion. Essentially, you're asking for one of two possible things here, as I see it: 1) We come up with a new set of interpreter paths, and have a --break-abi-with-alternate-paths build option, or 2) We don't come up with any list, and have a --break-abi-with-arbitrary-interpreter=/path option. I don't see how providing options that encourage users to shoot themselves so readily in their feet is a useful thing to do. Sure, 99% of users never build either gcc or glibc, and thus this is entirely hidden to them, but I still don't see why the 0.0001% that deeply care about moving the interpreter on their system can't just patch glibc and gcc in the two places necessary to make that happen, rather than publishing a config interface that makes it look like a supportable option in the toolchains that define those ABIs.
[Bug tree-optimization/39612] [6/7/8 Regression] LIM inserts loads from uninitialized local memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #29 from Aldy Hernandez ---
(In reply to Richard Biener from comment #11)
> Re-confirmed on trunk with the testcase in comment #4 and -Os:
>
> > ./cc1 -quiet t.c -Os -Wall -fdump-tree-all
> t.c: In function 'f2':
> t.c:4:11: warning: 'inter[0]' is used uninitialized in this function
> [-Wuninitialized]
> t.c:4:11: warning: 'inter[1]' is used uninitialized in this function
> [-Wuninitialized]
>
> There is also a store data-race introduced by LIM when the loop header
> is not copied. I suppose the real fix is to disable SM if the loop
> header is not copied.
The warning is gone for the testcase in comment #4:
abulafia:/build/t/gcc$ ./cc1 b.c -Os -Wall -quiet -fdump-tree-all
abulafia:/build/t/gcc$ ./cc1 b.c -O2 -Wall -quiet -fdump-tree-all
But the load from maybe-uninitialized memory is still there. This is lim2:
f2 (int * dst, int R)
{
_Bool inter_I_lsm.3;
int inter_I_lsm.2;
_Bool inter_I_lsm.1;
int inter_I_lsm.0;
int inter[2];
int i;
[local count: 118111601]:
inter_I_lsm.0_16 = inter[0]; // unconditional load outside loop
inter_I_lsm.1_17 = 0;
inter_I_lsm.2_18 = inter[1]; // unconditional load outside loop
inter_I_lsm.3_19 = 0;
goto ; [100.00%]
Reconfirmed, I guess?
[Bug target/84124] FAIL: gcc.target/i386/pr80969-4.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84124
--- Comment #1 from H.J. Lu ---
[hjl@gnu-skx-1 gcc]$ make check-gcc
RUNTESTFLAGS="--target_board='unix{-march=native}' i386.exp=pr80969-4*.c"
rm -rf testsuite/gcc-parallel
make[1]: Entering directory '/export/build/gnu/gcc-test/build-x86_64-linux/gcc'
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd /export/gnu/import/git/sources/gcc/gcc; ${PWDCMD-pwd}` ; export
srcdir ; \
if [ -n "" ] \
&& [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] \
&& [ -f testsuite/gcc-parallel/finished ]; then \
rm -rf testsuite/gcc; \
else \
cd testsuite/gcc; \
rm -f tmp-site.exp; \
sed '/set tmpdir/ s|testsuite$|testsuite/gcc|' \
< ../../site.exp > tmp-site.exp; \
/bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \
EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo
${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ; \
export TCL_LIBRARY ; \
fi ; \
`if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo
${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool gcc
--target_board='unix{-march=native}' i386.exp=pr80969-4*.c; \
if [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] ; then \
touch ${rootme}/testsuite/gcc-parallel/finished; \
fi ; \
fi )
WARNING: Couldn't find the global config file.
Test run by hjl on Fri Feb 2 05:44:49 2018
Native configuration is x86_64-pc-linux-gnu
=== gcc tests ===
Schedule of variations:
unix/-march=native
Running target unix/-march=native
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /export/gnu/import/git/sources/gcc/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/i386.exp ...
FAIL: gcc.target/i386/pr80969-4.c execution test
FAIL: gcc.target/i386/pr80969-4a.c execution test
FAIL: gcc.target/i386/pr80969-4b.c execution test
=== gcc Summary ===
# of expected passes 3
# of unexpected failures3
/export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc version 8.0.1 20180202
(experimental) (GCC)
make[1]: Leaving directory '/export/build/gnu/gcc-test/build-x86_64-linux/gcc'
[hjl@gnu-skx-1 gcc]$
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 --- Comment #6 from Javier Serrano Polo --- > As long as the new behavior is optional (not the default), the patch stands a > chance of being accepted. Thank you. I will change the status of the report if you do not mind. > the discussion about names is probably more appropriate on the libc side Adam, do you agree?
[Bug c++/82711] -Wignored-qualifiers could be moved into -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82711 --- Comment #3 from Sylvestre Ledru --- Jonathan, if I write a patch to implement the change, will you accept it?
[Bug middle-end/46989] Mixing "-fprofile-arcs -ftest-coverage" and OpenMP triggers a bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46989 Sylvestre Ledru changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Sylvestre Ledru --- Open for 7 years, no action but no duplicate, I think I can close it.
[Bug c/84183] New: internal compiler error: in initialize, at alloc-pool.h:257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84183 Bug ID: 84183 Summary: internal compiler error: in initialize, at alloc-pool.h:257 Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tplank at gmx dot at Target Milestone: --- Created attachment 43323 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43323&action=edit config log $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-cygwin/7.2.0/lto-wrapper.exe Target: x86_64-unknown-cygwin Configured with: ../gcc-7.2.0/configure --enable-threads --enable-languages=c,c++,fortran,lto,objc,obj-c++ --disable-sjlj-exceptions --with-mpc=/usr/local --with-isl=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local Thread model: posix gcc version 7.2.0 (GCC) I'm trying to build GCC 7.3.0 on the same platform as above (7.2.0 worked). I'm getting the following error: cc1: internal compiler error: in initialize, at alloc-pool.h:257 Please submit a full bug report, with preprocessed source if appropriate. This is my first attempt to file such a report. == Here's the make log: [ -f stage_final ] || echo stage3 > stage_final make[1]: Entering directory '/cygdrive/f/buildgcc730' make[2]: Entering directory '/cygdrive/f/buildgcc730' make[3]: Entering directory '/cygdrive/f/buildgcc730' rm -f stage_current make[3]: Leaving directory '/cygdrive/f/buildgcc730' make[2]: Leaving directory '/cygdrive/f/buildgcc730' make[2]: Entering directory '/cygdrive/f/buildgcc730' make[3]: Entering directory '/cygdrive/f/buildgcc730/libiberty' make[3]: Entering directory '/cygdrive/f/buildgcc730/intl' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/cygdrive/f/buildgcc730/intl' make[3]: Entering directory '/cygdrive/f/buildgcc730/build-x86_64-unknown-cygwin/libiberty' make[4]: Entering directory '/cygdrive/f/buildgcc730/libiberty/testsuite' make[4]: Nothing to be done for 'all'. make[4]: Leaving directory '/cygdrive/f/buildgcc730/libiberty/testsuite' make[3]: Leaving directory '/cygdrive/f/buildgcc730/libiberty' make[4]: Entering directory '/cygdrive/f/buildgcc730/build-x86_64-unknown-cygwin/libiberty/testsuite' make[4]: Nothing to be done for 'all'. make[4]: Leaving directory '/cygdrive/f/buildgcc730/build-x86_64-unknown-cygwin/libiberty/testsuite' make[3]: Entering directory '/cygdrive/f/buildgcc730/zlib' true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g" "CXXFLAGS=-g" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=-static-libstdc++ -static-libgcc -Wl,--stack,12582912" "LIBCFLAGS=-g -O2" "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-size=500 --split-size=500 --split-size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "EXPECT=expect" "RUNTEST=runtest" "RUNTESTFLAGS=" "exec_prefix=/usr/local" "infodir=/usr/local/share/info" "libdir=/usr/local/lib" "prefix=/usr/local" "tooldir=/usr/local/x86_64-unknown-cygwin" "AR=ar" "AS=as" "CC=gcc" "CXX=g++ -std=gnu++98" "LD=/usr/local/lib/gcc/x86_64-unknown-cygwin/7.2.0/../../../../x86_64-unknown-cygwin/bin/ld.exe" "LIBCFLAGS=-g -O2" "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" DO=all multi-do # make make[3]: Leaving directory '/cygdrive/f/buildgcc730/build-x86_64-unknown-cygwin/libiberty' make[3]: Leaving directory '/cygdrive/f/buildgcc730/zlib' make[3]: Entering directory '/cygdrive/f/buildgcc730/libbacktrace' make[3]: Entering directory '/cygdrive/f/buildgcc730/libdecnumber' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/cygdrive/f/buildgcc730/libdecnumber' make all-am make[4]: Entering directory '/cygdrive/f/buildgcc730/libbacktrace' true DO=all multi-do # make make[4]: Leaving directory '/cygdrive/f/buildgcc730/libbacktrace' make[3]: Leaving directory '/cygdrive/f/buildgcc730/libbacktrace' make[3]: Entering directory '/cygdrive/f/buildgcc730/lto-plugin' make all-am make[3]: Entering directory '/cygdrive/f/buildgcc730/libcpp' test -f config.h || (rm -f stamp-h1 && make stamp-h1) make[4]: Entering directory '/cygdrive/f/buildgcc730/lto-plugin' make[3]: Leaving directory '/cygdrive/f/buildgcc730/libcpp' make[3]: Entering directory '/cygdrive/f/buildgcc730/build-x86_64-unknown-cygwin/fixincludes' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/cygdrive/f/buildgcc730/build-x86_64-unknown-cygwin/fixincludes' make[4]: Leaving directory '/cygdrive/f/buildgcc730/lto-plugin' make[3]: Leaving directory '/cygdrive/f/buildgcc730/lto-plugin' make[3]: Entering directory '/cygdrive/f/buildgcc730/build-x86_64-unknown-cygwin/libcpp' test -f config.h || (rm -f stamp-h1 && make stamp-h1) make[3]: Leaving directory '/cygdri
[Bug c/84179] New: -save-temps breaks implicit-fallthrough comment heuristic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84179 Bug ID: 84179 Summary: -save-temps breaks implicit-fallthrough comment heuristic Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: Patrick.Schluter at ec dot europa.eu Target Milestone: --- The -Wimplicit-fallthrough heuristic to suppress the warning by analyzing comments does not work when -save-temps is specified. Observed with any level of the warning. __attribute__((fallthrough)); is not affected by it.
[Bug rtl-optimization/84071] [7/8 regression] wrong elimination of zero-extension after sign-extended load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071 --- Comment #20 from Eric Botcazou --- > How is this any different from 32-bit operations in say MIPS? The only > difference seems to be that MIPS sign-extends 32-bit operations to 64 bit > while AArch64 zero-extends. If that's correct for MIPS it seems that > WORD_REGISTER_OPERATIONS only applies to types smaller than SImode. Interesting question. One indeed could argue that, if 64-bit MIPS defines it, then Aarch64 could do it too since they are symmetric wrt sign/zero-extension but I don't have a definitive answer as I don't really know the history of WORD_REGISTER_OPERATIONS on MIPS. Maybe worth a try if this brings measurable benefits, typically elimination of redundant 32->64 zero-extensions.
[Bug c++/84182] New: [8 Regression] ICE in variadic lambda inside a template when calling a captured lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84182
Bug ID: 84182
Summary: [8 Regression] ICE in variadic lambda inside a
template when calling a captured lambda
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: benni.buch at gmail dot com
Target Milestone: ---
template < typename ... T > void sink(T ...){}
template < typename >
void f(){
auto const lambda = [](int){ return 1; };
[lambda](auto ... i){
sink(lambda(i) ...);
}(1);
}
int main(){
f< int >();
}
$ g++ -std=c++14 main.cpp
main.cpp: In instantiation of 'f() [with =
int]:: [with auto:1 = {int}]':
main.cpp:9:6: required from 'void f() [with = int]'
main.cpp:13:14: required from here
main.cpp:7:24: internal compiler error: in lookup_template_class_1, at
cp/pt.c:8957
[lambda](auto ... i){
^
0x612f6a lookup_template_class_1
../../gcc/gcc/cp/pt.c:8957
0x612f6a lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:9167
0x940d5a tsubst_aggr_type
../../gcc/gcc/cp/pt.c:12073
0x93873f tsubst_copy
../../gcc/gcc/cp/pt.c:14845
0x92711d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18059
0x93a8e4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:14365
0x93a8e4 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:14365
0x941873 tsubst_decl
../../gcc/gcc/cp/pt.c:13111
0x939eef tsubst_copy
../../gcc/gcc/cp/pt.c:14890
0x925ee0 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18266
0x9275de tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17663
0x934e49 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17100
0x934e49 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16838
0x9436b2 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16030
0x9436b2 gen_elem_of_pack_expansion_instantiation
../../gcc/gcc/cp/pt.c:11175
0x9436b2 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11683
0x927ded tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17684
0x934e49 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17100
0x934e49 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16838
0x933970 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16059
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ g++ --version
g++ (GCC) 8.0.1 20180202 (experimental)
Copyright (C) 2018 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.
Known to work with GCC 6.3 and 5.4:
$ g++-6 --version
g++-6 (Ubuntu/Linaro 6.3.0-18ubuntu2~16.04) 6.3.0 20170519
Copyright (C) 2016 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.
$ g++-5 --version
g++-5 (Ubuntu 5.4.1-2ubuntu1~16.04) 5.4.1 20160904
Copyright (C) 2015 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.
[Bug target/83370] [AARCH64]Tailcall register may be corrupted by epilogue code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83370 Richard Earnshaw changed: What|Removed |Added Target Milestone|--- |6.5
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 --- Comment #5 from Adam Conrad --- (In reply to Javier Serrano Polo from comment #1) > Adam, if you had to come up with multiarch interpreter names for traditional > architectures, which would be the proper place to discuss? As Andrew says, the ABI is fixed. I understand that you run a kernel patch/module to alias interpreters to other paths, but this isn't something we can or should support upstream. If I had a time machine, I could give you a list of interpreter names I would have argued for two decades ago. I don't have a time machine and, thus, such a discussion is pointless and, frankly, now that you've dragged me into this in three different forums, tiresome.
[Bug rtl-optimization/84071] [7/8 regression] wrong elimination of zero-extension after sign-extended load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071 mpf at gcc dot gnu.org changed: What|Removed |Added CC||mpf at gcc dot gnu.org --- Comment #21 from mpf at gcc dot gnu.org --- (In reply to Eric Botcazou from comment #20) > > How is this any different from 32-bit operations in say MIPS? The only > > difference seems to be that MIPS sign-extends 32-bit operations to 64 bit > > while AArch64 zero-extends. If that's correct for MIPS it seems that > > WORD_REGISTER_OPERATIONS only applies to types smaller than SImode. > > Interesting question. One indeed could argue that, if 64-bit MIPS defines > it, then Aarch64 could do it too since they are symmetric wrt > sign/zero-extension > but I don't have a definitive answer as I don't really know the history of > WORD_REGISTER_OPERATIONS on MIPS. I believe the critical part for MIPS is that our 32-bit instructions do care what the upper 32-bits of a 64-bit register contain. It is undefined if they operate on a non-canonical 32-bit form and the instructions that are width agnostic (conditional branch and logical ops) rely on canonical forms to work correctly with 32-bit values. So MIPS fundamentally needs this feature to work correctly; whether AArch64 needs it or may just benefit from it depends on a lot of detailed knowledge of the ISA and architecture. Given Richard Sandiford is currently working on ARM ports but also fully understands the MIPS arch then he may be a good person to consult.
[Bug target/83370] [AARCH64]Tailcall register may be corrupted by epilogue code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83370 Renlin Li changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Renlin Li --- (In reply to Richard Earnshaw from comment #3) > Doesn't this need backporting? Yes, it is needed. The same problem happens in gcc-6 and gcc-7. The backporting is approved and committed now.
[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84181
--- Comment #1 from Benjamin Buch ---
Same with:
template < int ... I >
struct A{};
template < typename T >
void f(){
[](auto ... i){
return A< decltype(i)::x ... >{};
};
}
int main(){
f< int >();
}
$ g++ -std=c++14 main2.cpp
main2.cpp: In instantiation of 'void f() [with T = int]':
main2.cpp:12:14: required from here
main2.cpp:7:40: internal compiler error: in strip_typedefs_expr, at
cp/tree.c:1690
return A< decltype(i)::x ... >{};
^
0x63696d strip_typedefs_expr(tree_node*, bool*)
../../gcc/gcc/cp/tree.c:1690
0x997709 strip_typedefs_expr(tree_node*, bool*)
../../gcc/gcc/cp/tree.c:1795
0x90f33c canonicalize_expr_argument
../../gcc/gcc/cp/pt.c:7489
0x9477db canonicalize_expr_argument
../../gcc/gcc/cp/pt.c:7486
0x9477db convert_template_argument
../../gcc/gcc/cp/pt.c:7823
0x945ada coerce_template_parameter_pack
../../gcc/gcc/cp/pt.c:7971
0x945ada coerce_template_parms
../../gcc/gcc/cp/pt.c:8191
0x93f2b6 lookup_template_class_1
../../gcc/gcc/cp/pt.c:8818
0x93f2b6 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:9167
0x940d5a tsubst_aggr_type
../../gcc/gcc/cp/pt.c:12073
0x93b27e tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13706
0x926e14 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18153
0x934e49 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17100
0x934e49 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16838
0x932ea0 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16055
0x931f61 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f61 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x925b9b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16030
0x925b9b tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:17056
0x927498 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18346
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/84181] New: [8 Regression] ICE in variadic lambda inside a template when constructing a decltype type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84181
Bug ID: 84181
Summary: [8 Regression] ICE in variadic lambda inside a
template when constructing a decltype type
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: benni.buch at gmail dot com
Target Milestone: ---
This is a very serious regression because it affects Boost.Hana directly.
template < int ... I >
struct A{};
template < typename T >
void f(){
[](auto ... i){
return A< decltype(i){} ... >{};
};
}
int main(){
f< int >();
}
$ g++ -std=c++14 main.cpp
main.cpp: In instantiation of 'void f() [with T = int]':
main.cpp:12:14: required from here
main.cpp:7:39: internal compiler error: in strip_typedefs_expr, at
cp/tree.c:1690
return A< decltype(i){} ... >{};
^
0x63696d strip_typedefs_expr(tree_node*, bool*)
../../gcc/gcc/cp/tree.c:1690
0x997709 strip_typedefs_expr(tree_node*, bool*)
../../gcc/gcc/cp/tree.c:1795
0x90f33c canonicalize_expr_argument
../../gcc/gcc/cp/pt.c:7489
0x9477db canonicalize_expr_argument
../../gcc/gcc/cp/pt.c:7486
0x9477db convert_template_argument
../../gcc/gcc/cp/pt.c:7823
0x945ada coerce_template_parameter_pack
../../gcc/gcc/cp/pt.c:7971
0x945ada coerce_template_parms
../../gcc/gcc/cp/pt.c:8191
0x93f2b6 lookup_template_class_1
../../gcc/gcc/cp/pt.c:8818
0x93f2b6 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:9167
0x940d5a tsubst_aggr_type
../../gcc/gcc/cp/pt.c:12073
0x93b27e tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13706
0x926e14 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18153
0x934e49 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17100
0x934e49 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16838
0x932ea0 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16055
0x931f61 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f61 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x925b9b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16030
0x925b9b tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:17056
0x927498 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18346
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ g++ --version
g++ (GCC) 8.0.1 20180202 (experimental)
Copyright (C) 2018 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.
Known to work with GCC 6.3 and 5.4:
$ g++-6 --version
g++-6 (Ubuntu/Linaro 6.3.0-18ubuntu2~16.04) 6.3.0 20170519
Copyright (C) 2016 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.
$ g++-5 --version
g++-5 (Ubuntu 5.4.1-2ubuntu1~16.04) 5.4.1 20160904
Copyright (C) 2015 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.
[Bug testsuite/52641] Test cases fail for 16-bit int targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641 --- Comment #15 from Georg-Johann Lay --- Author: gjl Date: Fri Feb 2 11:36:54 2018 New Revision: 257327 URL: https://gcc.gnu.org/viewcvs?rev=257327&root=gcc&view=rev Log: PR testsuite/52641 * gcc.c-torture/execute/pr81913.c: Use types that also work for int16. * gcc.c-torture/execute/20180112-1.c: Dito. * gcc.c-torture/execute/pr81503.c: Dito. * gcc.dg/store_merging_12.c: Dito. * gcc.dg/tree-ssa/loop-niter-1.c: Dito. * gcc.dg/tree-ssa/loop-niter-2.c: Dito. * gcc.dg/tree-ssa/pr80898.c: Dito. * gcc.dg/tree-ssa/pr82363.c: Dito. * gcc.dg/utf16-4.c: Also allow "short unsigned int" in dg-warning. * gcc.dg/tree-ssa/pr81346-5.c: Special-case int16. * gcc.dg/tree-ssa/ssa-sink-11.c: Dito. * gcc.dg/tree-ssa/ssa-sink-12.c: Dito. * gcc.dg/torture/pr81814.c: Restrict to int32plus. * gcc.dg/tree-ssa/pr80803.c: Dito. * gcc.dg/tree-ssa/pr80898-2.c: Dito. * gcc.dg/tree-ssa/pr81346-4.c: Dito. * gcc.dg/tree-ssa/vrp114.c: Dito. * gcc.dg/tree-ssa/pr82574.c: Restrict to size32plus. * gcc.dg/tree-ssa/ssa-dom-thread-13.c: Dito. * gcc.dg/tree-ssa/ssa-sink-15.c: Dito. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/20180112-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr81503.c trunk/gcc/testsuite/gcc.c-torture/execute/pr81913.c trunk/gcc/testsuite/gcc.dg/store_merging_12.c trunk/gcc/testsuite/gcc.dg/torture/pr81814.c trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-niter-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-niter-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr80803.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr80898-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr80898.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81346-4.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81346-5.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr82363.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr82574.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-13.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-11.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-12.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-15.c trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp114.c trunk/gcc/testsuite/gcc.dg/utf16-4.c
[Bug c/84180] New: -Wimplicit-fallthrough=2 heuristic fails when condition in the case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84180
Bug ID: 84180
Summary: -Wimplicit-fallthrough=2 heuristic fails when
condition in the case
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Patrick.Schluter at ec dot europa.eu
Target Milestone: ---
A case containing a condition recognizes that it may fall through but the
heuristic to suppress the warning doesn't work at level 2. IMO it should.
Simple example to trigger the behaviour
case OPEN_FILE:
if( !access(name, F_OK)) {
...
break;
}
/* fallthrough */
case CREATE_FILE:
...
The warning is suppressed only at level 1 of the -Wimplicit-fallthrough=
option.
[Bug target/84066] Wrong shadow stack register size is saved for x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84066 --- Comment #8 from itsimbal at gcc dot gnu.org --- Author: itsimbal Date: Fri Feb 2 10:06:39 2018 New Revision: 257326 URL: https://gcc.gnu.org/viewcvs?rev=257326&root=gcc&view=rev Log: PR84066 Wrong shadow stack register size is saved for x32 x32 is a 64-bit process with 32-bit software pointer and kernel may place x32 shadow stack above 4GB. We need to save and restore 64-bit shadow stack register for x32. builtin jmp buf size is 5 pointers. We have space to save 64-bit shadow stack pointers: 32-bit SP, 32-bit FP, 32-bit IP, 64-bit SSP for x32. PR target/84066 * gcc/config/i386/i386.md: Replace Pmode with word_mode in builtin_setjmp_setup and builtin_longjmp to support x32. * gcc/testsuite/gcc.target/i386/cet-sjlj-6a.c: New test. * gcc/testsuite/gcc.target/i386/cet-sjlj-6b.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/cet-sjlj-6a.c trunk/gcc/testsuite/gcc.target/i386/cet-sjlj-6b.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug web/84167] bugzilla should have a "next bug" button
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84167 --- Comment #2 from rguenther at suse dot de --- On February 1, 2018 8:05:26 PM GMT+01:00, LpSolit at netscape dot net wrote: >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. That does not work reliably in case there are more than 24 hours between invocations or when you just want to poll 'next'. I guess I'll try to look into doing some Greasemonkey script hacking then...
[Bug tree-optimization/84178] New: [7/8 Regression] ICE in release_bb_predicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84178
Bug ID: 84178
Summary: [7/8 Regression] ICE in release_bb_predicate
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-8.0.0-alpha20180128 snapshot (r257131) and gcc 7.3.0 ICE when compiling the
following snippet w/ -O3 -fno-tree-forwprop:
int zy, h4;
void
r8 (long int mu, int *jr, int *fi, short int dv)
{
do
{
int tx;
tx = !!h4 ? (zy / h4) : 1;
mu = tx;
*jr = (((unsigned char) mu > (254 >> dv)) ? 0 : (unsigned char) tx) +
*fi;
} while (*jr == 0);
r8 (mu, jr, fi, 1);
}
% gcc-8.0.0-alpha20180128 -O3 -fno-tree-forwprop -c rhoqpgf1.c
during GIMPLE pass: ifcvt
rhoqpgf1.c: In function 'r8.constprop':
rhoqpgf1.c:4:1: internal compiler error: in release_bb_predicate, at
tree-if-conv.c:286
r8 (long int mu, int *jr, int *fi, short int dv)
^~
0x664d68 release_bb_predicate
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/tree-if-conv.c:286
0x664d68 free_bb_predicate
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/tree-if-conv.c:300
0x664d68 tree_if_conversion(loop*)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/tree-if-conv.c:2897
0xd092e5 execute
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/tree-if-conv.c:2962
gcc 7 ICEs w/ different backtrace, though.
[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #26 from Jürgen Reuter --- Paul, let me know whether you want me to reduce the "Additional failing test case" any further. Really have to go to sleep now.
