[Bug lto/91313] [10 regression] r273908 breaks lto on power 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91313 Martin Liška changed: What|Removed |Added Keywords||patch --- Comment #4 from Martin Liška --- The issues is known and discussed in this thread: https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01888.html I'm planning to disable jobserver automatic detection.
[Bug sanitizer/91311] __attribute__ ((aligned (128))) results in stack-use-after-scope and stack-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91311 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-08-01 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- I'll take a look, thank you for the report.
[Bug tree-optimization/91169] [10 regression] cd2a31a FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91169 Eric Botcazou changed: What|Removed |Added Component|ada |tree-optimization --- Comment #9 from Eric Botcazou --- Recategorizing.
[Bug lto/91313] [10 regression] r273908 breaks lto on power 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91313 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug ada/87100] FAIL: gnat.dg/config_pragma1.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87100 --- Comment #3 from Helge Deller --- On 31.07.19 18:16, danglin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87100 > > John David Anglin changed: > > What|Removed |Added > > Last reconfirmed|2019-03-10 00:00:00 |2019-7-31 > CC||helge.deller at sap dot com > > --- Comment #2 from John David Anglin --- > On linux, this message is seen on console: > mmap: config_pragma1. (14628): VmData 1018527744 exceed data ulimit 524288000. > Update limits or use boot option ignore_rlimit_data. > > Nominally, ulimit says unlimited. So, I'm not sure where the limit comes > from. Hi Dave, fyi, I dropped my "helge.del...@sap.com" from this BZ, and instead added my private "del...@gmx.de" account... Helge
[Bug tree-optimization/91201] [7/8/9/10 Regression] SIMD not generated for horizontal sum of bytes in array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201 --- Comment #17 from Jakub Jelinek --- Created attachment 46655 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46655&action=edit gcc10-pr91201-extr.patch pextrb is indeed not available (added in sse4.1) in -msse2 only, but we indeed can use movd for the zero element QImode extraction. For HImode already SSE2 has extraction insn.
[Bug tree-optimization/91201] [7/8/9/10 Regression] SIMD not generated for horizontal sum of bytes in array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201 --- Comment #18 from Joel Yliluoma --- Great, thanks. I can test this in a few days, but I would like to make sure that the proper thing still happens if the vector is of bytes but the return value of the function is a larger-than-byte integer type. Will it still generate a movd in this case? Because that would be wrong. :-)
[Bug tree-optimization/91144] [10 regression] 176.gcc miscompare after r273294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91144 Wilco changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-01 Summary|[10 regiression] 176.gcc|[10 regression] 176.gcc |miscompare after r273294|miscompare after r273294 Ever confirmed|0 |1 --- Comment #4 from Wilco --- Confirmed then. Agreed, it does not seem worth looking into. I've changed my SPEC configs to use -fno-strict-aliasing.
[Bug tree-optimization/91201] [7/8/9/10 Regression] SIMD not generated for horizontal sum of bytes in array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201 --- Comment #19 from Joel Yliluoma --- If the function return type is changed to "unsigned short", the AVX code with "vpextrb" will do a spurious "movzx eax, al" at the end — but if the return type is "unsigned int", it will not. The code with "(v)movd" should of course do it, if the vector element size is shorter than the return type.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Bill Schmidt changed: What|Removed |Added Known to fail||7.4.0 --- Comment #23 from Bill Schmidt --- Xiong Hu confirmed this is also broken on GCC 7. I may have been mistaken about this having worked before; we may just never have realized we weren't getting the benefit of the scalar MASS functions.
[Bug tree-optimization/91201] [7/8/9/10 Regression] SIMD not generated for horizontal sum of bytes in array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201
--- Comment #20 from Jakub Jelinek ---
(In reply to Joel Yliluoma from comment #19)
> If the function return type is changed to "unsigned short", the AVX code
> with "vpextrb" will do a spurious "movzx eax, al" at the end — but if the
> return type is "unsigned int", it will not. The code with "(v)movd" should
> of course do it, if the vector element size is shorter than the return type.
With movd there is a non-redundant movzxl %al, %eax after the movd in both
unsigned short and unsigned int cases. For {,v}pextrb there is a pattern that
makes the zero extension explicit in the IL:
(insn 28 27 29 2 (set (subreg:SI (reg:QI 87 [ stmp_r_10.10 ]) 0)
(zero_extend:SI (vec_select:QI (subreg:V16QI (reg:V2DI 121) 0)
(parallel [
(const_int 0 [0])
] 4165 {*vec_extractv16qi_zext}
(expr_list:REG_DEAD (reg:V2DI 121)
(nil)))
and for unsigned int return type the combiner is able to combine that with the
following
(insn 29 28 34 2 (set (reg:SI 122 [ stmp_r_10.10 ])
(zero_extend:SI (reg:QI 87 [ stmp_r_10.10 ]))) "pr91201-4.c":9:11 119
{*zero_extendqisi2}
(expr_list:REG_DEAD (reg:QI 87 [ stmp_r_10.10 ])
(nil)))
but it isn't able to merge that for a different extension in the unsigned short
return type.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #24 from Richard Biener ---
Btw, this is controlled by symtab_node::output_to_lto_symbol_table_p which has
/* FIXME: Builtins corresponding to real functions probably should have
symbol table entries. */
if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
return false;
we could try to do sth like
if (TREE_CODE (decl) == FUNCTION_DECL
&& (fndecl_built_in_p (decl, BUILT_IN_MD)
|| (fndecl_built_in_p (decl, BUILT_IN_NORMAL)
&& !associated_internal_fn (decl
return false;
but that would still leave us with too many undefineds I guess
(gcc_unreachable for one).
We do not currently track builtins that do have a library implementation
(whether that it is used in the end is another thing, but less important).
What we definitely can do is put a whitelist above like via the following
which also catches the case of definitions of builtins.
Index: gcc/symtab.c
===
--- gcc/symtab.c(revision 273968)
+++ gcc/symtab.c(working copy)
@@ -2375,10 +2375,24 @@ symtab_node::output_to_lto_symbol_table_
first place. */
if (VAR_P (decl) && DECL_HARD_REGISTER (decl))
return false;
+
/* FIXME: Builtins corresponding to real functions probably should have
symbol table entries. */
- if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
-return false;
+ if (TREE_CODE (decl) == FUNCTION_DECL
+ && !definition
+ && fndecl_built_in_p (decl))
+{
+ if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
+ switch (DECL_FUNCTION_CODE (decl))
+ {
+ CASE_FLT_FN (BUILT_IN_ATAN2):
+ CASE_FLT_FN (BUILT_IN_SIN):
+ return true;
+ default:
+ break;
+ }
+ return false;
+}
/* We have real symbol that should be in symbol table. However try to trim
down the refernces to libraries bit more because linker will otherwise
[Bug c++/91318] New: warnings about unused internal macros with -Wunused-macros and #pragma GCC optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91318
Bug ID: 91318
Summary: warnings about unused internal macros with
-Wunused-macros and #pragma GCC optimize
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: phd at phd dot re
Target Milestone: ---
GCC shows annoying warnings about unused internal macros when using
-Wunused-macros parameter to compile code containing #pragma GCC optimize
-- a.cpp
---
#pragma GCC optimize ("fast-math")
#pragma GCC optimize ("finite-math-only")
int main() {}
command:
gcc -Wunused-macros a.cpp
-- result
--
a.cpp:2:41: warning: macro "__FAST_MATH__" is not used [-Wunused-macros]
2 | #pragma GCC optimize ("finite-math-only")
| ^
a.cpp:2:41: warning: macro "__NO_MATH_ERRNO__" is not used [-Wunused-macros]
a.cpp:4:13: warning: macro "__FINITE_MATH_ONLY__" is not used [-Wunused-macros]
4 | int main() {}
| ^
live demo:
https://godbolt.org/z/flbv97
[Bug c++/91318] warnings about unused internal macros with -Wunused-macros and #pragma GCC optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91318 --- Comment #1 from Piotr Henryk Dabrowski --- Created attachment 46656 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46656&action=edit 0001-do-not-warn-unused-macros-pragma-gcc-optimize.patch
[Bug lto/91313] [10 regression] r273908 breaks lto on power 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91313 --- Comment #5 from Martin Liška --- @seurer: Can you please test the following patch candidate: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00040.html
[Bug c++/86098] canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86098 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Thu Aug 1 14:37:08 2019 New Revision: 273974 URL: https://gcc.gnu.org/viewcvs?rev=273974&root=gcc&view=rev Log: PR c++/89906 - ICE with template placeholder for TTP. PR c++/86098 - ICE with template placeholder for TTP. * typeck.c (structural_comptypes) [TEMPLATE_TYPE_PARM]: Check CLASS_PLACEHOLDER_TEMPLATE. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/class-deduction58.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/typeck.c
[Bug c++/89906] [8 Regression] template template parameter redeclared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89906 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Thu Aug 1 14:37:08 2019 New Revision: 273974 URL: https://gcc.gnu.org/viewcvs?rev=273974&root=gcc&view=rev Log: PR c++/89906 - ICE with template placeholder for TTP. PR c++/86098 - ICE with template placeholder for TTP. * typeck.c (structural_comptypes) [TEMPLATE_TYPE_PARM]: Check CLASS_PLACEHOLDER_TEMPLATE. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/class-deduction58.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/typeck.c
[Bug c++/89906] [8 Regression] template template parameter redeclared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89906 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Polacek --- Fixed in GCC 8 too.
[Bug c++/88419] [7 Regression] [ICE] "Same canonical type node for different types" for CTAD in noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88419 Bug 88419 depends on bug 89906, which changed state. Bug 89906 Summary: [8 Regression] template template parameter redeclared https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89906 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109
--- Comment #6 from Bernd Edlinger ---
with this patch the relevant part if the reload dump file looks different:
(insn 3414 6591 6682 129 (set (mem/c:SI (reg/f:SI 5 r5 [5715]) [1
s.5566D.5531+0 S4 A32])
(reg:SI 6 r6 [orig:828 _821 ] [828])) "20040709-1.c":13:5 654
{*arm_movsi_vfp}
(nil))
[...]
(insn 6826 3453 6816 129 (parallel [
(set (reg:SI 3 r3 [4187])
(truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (reg:SI 11
fp [4186]))
(zero_extend:DI (reg:SI 7 r7 [4188])))
(const_int 32 [0x20]
(clobber (reg:SI 1 r1 [5970]))
]) "20040709-1.c":108:291 70 {*umulsi3_highpart_v6}
(nil))
[...]
(insn 3509 3530 3531 132 (set (mem/c:SI (reg/f:SI 5 r5 [5715]) [1
s.5566D.5531+0 S4 A32])
(reg:SI 14 lr [orig:692 D.6083 ] [692])) "20040709-1.c":13:5 654
{*arm_movsi_vfp}
(nil))
This time insn 6826 is able to choose a different register than r5,
and most importantly the live-range info is correct, since the
old register r5970 is renamed to r6374 temporarily:
Creating newreg=6374 from oldreg=5970, assigning class GENERAL_REGS to
scratch pseudo copy r6374
6816: r6364:SI=r4187:SI
REG_DEAD r4187:SI
Inserting rematerialization insn before:
6826: {r6364:SI=trunc(zero_extend(r4186:SI)*zero_extend(r4188:SI)
0>>0x20);clobber r6374:SI;}
REG_UNUSED r6374:SI
which is visible in the live ranges (which was not there before):
r6007: [59..59]
r6374: [1572..1572]
Compressing live ranges: from 3802 to 75 - 1%
Ranges after the compression:
[...]
r6007: [1..1]
r6374: [40..40]
However since the re-materialized instruction is able to use r1
there is no conflict any more. So I believe the patch is a
straight improvement over the previous state of affairs.
So, as it looks like, this is a potentially catastrophic bug, and not
related to -flto at all or any specific target architecture.
From my testing it is likely that was already there in gcc-9.0.1.
[Bug target/91306] [MSP430] libgcc/crtstuff.c: Alignment of frame_dummy .init_array entry is too big
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91306 Andrew Pinski changed: What|Removed |Added Target||MSP430 CC||pinskia at gcc dot gnu.org Component|libgcc |target --- Comment #1 from Andrew Pinski --- .ctors will have the same issue. My patch was just copying what was already for .ctors IIRC. This patch has been there for over 8 years now so it is interesting people are only seeing this issue now.
[Bug target/90346] gcc generates the "lfence" instruction on CPUs that don't support it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90346 --- Comment #5 from mikulas at artax dot karlin.mff.cuni.cz --- On non-SSE2 CPUs, it should generate "lock; addl $0,(%esp)" That provides barrier equivalent to "mfence"
[Bug target/91306] [MSP430] libgcc/crtstuff.c: Alignment of frame_dummy .init_array entry is too big
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91306 --- Comment #2 from Andrew Pinski --- Also the patch is still needed. Try with one than one entry and you will see the issue. The patch is not to workaround a GCC bug but rather enforce a smaller alignment than what GCC decides to use. >but the expected alignment of a pointer is 2 bytes. If that is true, then maybe alignof should be used instead of sizeof. Can you try alignof (__alignof__)?
[Bug c++/91319] New: Designated initializer doesn't support direct-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91319
Bug ID: 91319
Summary: Designated initializer doesn't support
direct-initialization
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
This currently fails to compile on trunk:
struct X {
explicit X() { }
};
struct Aggr {
X x;
};
Aggr f() {
return Aggr{.x{}};
}
source>: In function 'Aggr f()':
:10:21: error: converting to 'X' from initializer list would use
explicit constructor 'X::X()'
10 | return Aggr{.x{}};
| ^
Compiler returned: 1
But it's intended to work (this is CWG 2359).
[Bug target/91320] New: [9.1] x86-64 code generation / register allocation regressed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91320
Bug ID: 91320
Summary: [9.1] x86-64 code generation / register allocation
regressed.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
The following code:
#include
size_t g(boost::dynamic_bitset<> const& a, bool value) {
auto count = a.count();
return value ? count : a.size() - count;
}
When compiled with `gcc-8.3 -O3 -std=gnu++17 -mpopcnt` generates the following
assembly:
g(boost::dynamic_bitset >
const&, bool):
mov r9, QWORD PTR [rdi]
mov r8, QWORD PTR [rdi+8]
sub r8, r9
sar r8, 3
je .L5
xor edx, edx
xor eax, eax
.L3:
xor ecx, ecx
popcnt rcx, QWORD PTR [r9+rdx*8]
add rdx, 1
add rax, rcx
cmp r8, rdx
jne .L3
.L2:
testsil, sil
jne .L1
mov rdx, QWORD PTR [rdi+24]
sub rdx, rax
mov rax, rdx
.L1:
ret
.L5:
xor eax, eax
jmp .L2
When compiled with `gcc-9.1 -O3 -std=gnu++17 -mpopcnt` generates the following
assembly:
g(boost::dynamic_bitset >
const&, bool):
mov r9, QWORD PTR [rdi]
mov rcx, QWORD PTR [rdi+8]
sub rcx, r9
sar rcx, 3
je .L5
xor eax, eax
xor r8d, r8d
.L3:
xor edx, edx
popcnt rdx, QWORD PTR [r9+rax*8]
add rax, 1
add r8, rdx
cmp rcx, rax
jne .L3
.L2:
testsil, sil
jne .L1
mov rax, QWORD PTR [rdi+24]
sub rax, r8
mov r8, rax
.L1:
mov rax, r8
ret
.L5:
xor r8d, r8d
jmp .L2
Note the extra `mov rax, r8` instruction. gcc-8.3 better allocates registers,
so that extra instruction is not necessary.
[Bug c++/91319] Designated initializer doesn't support direct-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91319 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-01 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug lto/91313] [10 regression] r273908 breaks lto on power 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91313 --- Comment #6 from seurer at gcc dot gnu.org --- Yes, that fixed things on the previously failing machine.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #25 from rguenther at suse dot de ---
On Wed, 31 Jul 2019, hjl.tools at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>
> --- Comment #19 from H.J. Lu ---
> (In reply to Richard Biener from comment #17)
> > (In reply to Richard Biener from comment #16)
> > > (In reply to Richard Biener from comment #15)
> > > > Honza probably knows where we output the LTO symtab and why we do not
> > > > put
> > > > undefs for builtins there.
> > >
> > > #include
> > > double y, z;
> > > void foo ();
> > > int main()
> > > {
> > > volatile double x = atan2 (y, z);
> > > foo ();
> > > }
> > >
> > > > gcc-8 -c t.c -flto
> > > > gcc-nm t.o
> > > U foo
> > > T main
> > > C y
> > > C z
> > >
> > > where's the
> > >
> > > U atan2
> > >
> > > ?
> >
> > For
> >
> > double atan2 (double x, double y) { return x + y; }
> >
> > it doesn't appear either, this CU has an empty symbol table...
> >
> > I do remember quite some "funs" with builtin handling though, so the
> > current handling may be the least bad of all choices...
>
> [hjl@gnu-cfl-1 pr91287]$ cat foo1.c
> #include
>
> float
> atan2f (float x, float y)
> {
> abort ();
> return x * y;
> }
> [hjl@gnu-cfl-1 pr91287]$ cat foo.c
> float
> atan2f (float x, float y)
> {
> return x * y;
> }
> [hjl@gnu-cfl-1 pr91287]$ cat bar.c
> #include
>
> extern float x, y, z;
>
> void
> bar (void)
> {
> x = atan2f (y, z);
> }
> [hjl@gnu-cfl-1 pr91287]$ cat main.c
> #include
>
> extern void bar (void);
>
> float x, y = 1, z =1;
>
> int
> main (void)
> {
> x = atan2f (y, z);
> bar ();
> return 0;
> }
> [hjl@gnu-cfl-1 pr91287]$ make
> cc -O3 -c -o foo.o foo.c
> ar rc libfoo.a foo.o
> cc -O3 -fpic -c -o bar.o bar.c
> cc -O3 -fpic -c -o foo1.o foo1.c
> ld -shared -o libfoo1.so foo1.o # --version-script foo1.v
> ld -shared -o libbar.so bar.o libfoo1.so
> cc -flto -O3 -o x main.c libfoo.a libbar.so libfoo1.so -Wl,-R,.
> cc -O3 -o y main.c libfoo.a libbar.so libfoo1.so -Wl,-R,.
> ./y
> ./x
> make: *** [Makefile:9: all] Aborted
> [hjl@gnu-cfl-1 pr91287]$
>
> Since atan2f isn't referenced in IR, linker doesn't extract atan2f from
> libfoo.a. atan2f is resolved to definition in libfoo1.so later.
The odd thing is that if you omit libfoo1.so then it will consider
libfoo.a later but not when it can resolve from libfoo1.so.
That's a bit inconsistent but arguably the bug is with GCCs
symbol table creation of the LTO IR.
[Bug web/91321] New: commit mails with PR d/1234 do not get to bugzilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91321 Bug ID: 91321 Summary: commit mails with PR d/1234 do not get to bugzilla Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: ---
[Bug web/91321] commit mails with PR d/1234 do not get to bugzilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91321 Richard Biener changed: What|Removed |Added CC||fche at redhat dot com --- Comment #1 from Richard Biener --- Maybe also check other components (recently) added.
[Bug tree-optimization/91322] New: [10 regression] alias-4 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322 Bug ID: 91322 Summary: [10 regression] alias-4 test failure Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: wilco at gcc dot gnu.org Target Milestone: --- The new alias-4_0.C fails on Arm. Without LTO it also fails with -O2 on AArch64, but it fails with -O2 and -O3 on Arm, so something must be different. Unfortunately even without -flto, the tree dumps don't show the inlining pass running so it's not obvious what is different.
[Bug tree-optimization/91322] [10 regression] alias-4 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |10.0
[Bug c/89549] [7/8/9/10 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #8 from Dávid Bolvanský --- Why this annoying note cannot be disabled using #pragma GCC diagnostic ignored "-Wmisleading-indentation" ? So only solution is -Wno-misleading-indentation?
[Bug target/91323] New: LTGT rtx produces UCOMISS instead of COMISS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
Bug ID: 91323
Summary: LTGT rtx produces UCOMISS instead of COMISS
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
I'm implementing signaling comparisons on S/390 and I'm trying to figure out
whether or not LTGT is supposed to be signaling.
I've decided to check what Intel does, and ran into what appears to be a bug.
Consider the following functions:
int f1(float a, float b) { return a < b || a > b; }
int f2(float a, float b) { return __builtin_isless(a, b) ||
__builtin_isgreater(a, b); }
int f3(float a, float b) { return __builtin_islessgreater(a, b); }
gcc creates LTGT rtx for f1 and UNEQ for f2 and f3.
However, for all 3 variants it then emits UCOMISS instruction.
I would expect f1 to be compiled to COMISS, since I believe that comparison
operators in C are supposed to be signaling.
[Bug c++/90805] Overflow in switch case is not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90805 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Thu Aug 1 16:27:04 2019 New Revision: 273976 URL: https://gcc.gnu.org/viewcvs?rev=273976&root=gcc&view=rev Log: PR c++/90805 - detect narrowing in case values. * decl.c (case_conversion): Detect narrowing in case values. * c-c++-common/pr89888.c: Update expected dg-error. * g++.dg/cpp0x/Wnarrowing17.C: New test. * g++.dg/cpp0x/enum28.C: Update expected dg-error. Added: trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing17.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/pr89888.c trunk/gcc/testsuite/g++.dg/cpp0x/enum28.C
[Bug c++/90805] Overflow in switch case is not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90805 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug target/88962] Invalid/inconsistent PowerPC TLS variable access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88962 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Segher Boessenkool --- Looking at GCC's output: [ cutting away irrelevant (irrelevant here) dot ops: ] geta: stwu 1,-16(1) mflr 0 bcl 20,31,$+8 mflr 3 lwz 9,0(3) add 3,3,9 stw 0,20(1) addi 3,3,a@got@tlsld stw 30,8(1) bl __tls_get_addr(a@tlsld)@plt lwz 0,20(1) lwz 30,8(1) addis 3,3,a@dtprel@ha mtlr 0 addi 3,3,a@dtprel@l lwz 3,0(3) addi 1,1,16 blr getb: stwu 1,-16(1) mflr 0 bcl 20,31,$+8 mflr 3 lwz 9,0(3) add 3,3,9 stw 0,20(1) addi 3,3,b@got@tlsgd stw 30,8(1) bl __tls_get_addr(b@tlsgd)@plt lwz 0,20(1) lwz 30,8(1) lwz 3,0(3) mtlr 0 addi 1,1,16 blr tlsld and tlsgd have quite different semantics, so this isn't a real surprise? What do you think the compiler should do differently? (Closing as invalid, please reopen if you want further action).
[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109 --- Comment #7 from Bernd Edlinger --- I can reproduce this defect with gcc-9 (!) $ ../gcc-9-branch/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-linux64-1 --target=arm-linux-gnueabihf --enable-languages=c,c++ --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard $ TMP=. arm-linux-gnueabihf-gcc -O2 -flto -save-temps -fdump-rtl-all-all 20040709-1.c $ grep same *.reload Assigning the same 6155 to r11 $ vi *.ltrans0.s look for the last umull (it is always the last one): str r5, [fp] umull fp, r3, r7, r8 [...] str r6, [fp] But the same does not happen for gcc-8: $ grep same *.reload the assembler listing looks okay. But the update_scratch_ops looks exactly identical, Therefore the issue is likely just a hidden one there.
[Bug tree-optimization/91201] [7/8/9/10 Regression] SIMD not generated for horizontal sum of bytes in array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201
--- Comment #21 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #20)
> (In reply to Joel Yliluoma from comment #19)
> > If the function return type is changed to "unsigned short", the AVX code
> > with "vpextrb" will do a spurious "movzx eax, al" at the end — but if the
> > return type is "unsigned int", it will not. The code with "(v)movd" should
> > of course do it, if the vector element size is shorter than the return type.
>
> With movd there is a non-redundant movzxl %al, %eax after the movd in both
> unsigned short and unsigned int cases. For {,v}pextrb there is a pattern
> that makes the zero extension explicit in the IL:
> (insn 28 27 29 2 (set (subreg:SI (reg:QI 87 [ stmp_r_10.10 ]) 0)
> (zero_extend:SI (vec_select:QI (subreg:V16QI (reg:V2DI 121) 0)
> (parallel [
> (const_int 0 [0])
> ] 4165 {*vec_extractv16qi_zext}
> (expr_list:REG_DEAD (reg:V2DI 121)
> (nil)))
> and for unsigned int return type the combiner is able to combine that with
> the following
> (insn 29 28 34 2 (set (reg:SI 122 [ stmp_r_10.10 ])
> (zero_extend:SI (reg:QI 87 [ stmp_r_10.10 ]))) "pr91201-4.c":9:11
> 119 {*zero_extendqisi2}
> (expr_list:REG_DEAD (reg:QI 87 [ stmp_r_10.10 ])
> (nil)))
> but it isn't able to merge that for a different extension in the unsigned
> short return type.
I think an insn similar to
(define_insn "*vec_extract_zext"
is missing. Like:
(define_insn "*vec_extractv16qi_zext_hi"
[(set (match_operand:HI 0 "register_operand" "=r,r")
(zero_extend:HI
(vec_select:QI
(match_operand:V16QI 1 "register_operand" "x,v")
(parallel
[(match_operand:SI 2 "const_0_to_15")]]
"TARGET_SSE4_1"
"@
%vpextrb\t{%2, %1, %k0|%k0, %1, %2}
vpextrb\t{%2, %1, %k0|%k0, %1, %2}"
[Bug target/91306] [MSP430] libgcc/crtstuff.c: Alignment of frame_dummy .init_array entry is too big
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91306
--- Comment #3 from Jozef Lawrynowicz ---
(In reply to Andrew Pinski from comment #2)
> If that is true, then maybe alignof should be used instead of sizeof.
> Can you try alignof (__alignof__)?
Thanks, __alignof__ works for me. Below change fixed the issue for
msp430-elf/-mlarge:
> diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c
> index 4927a9f8977..bd5c93c194e 100644
> --- a/libgcc/crtstuff.c
> +++ b/libgcc/crtstuff.c
> @@ -474,7 +474,7 @@ frame_dummy (void)
> CRT_CALL_STATIC_FUNCTION (__LIBGCC_INIT_SECTION_ASM_OP__, frame_dummy)
> #else /* defined(__LIBGCC_INIT_SECTION_ASM_OP__) */
> static func_ptr __frame_dummy_init_array_entry[]
> - __attribute__ ((__used__, section(".init_array"),
> aligned(sizeof(func_ptr
> + __attribute__ ((__used__, section(".init_array"),
> aligned(__alignof__(func_ptr
>= { frame_dummy };
> #endif /* !defined(__LIBGCC_INIT_SECTION_ASM_OP__) */
> #endif /* USE_EH_FRAME_REGISTRY || USE_TM_CLONE_REGISTRY */
The other structures using "aligned(sizeof(func_ptr))" are unused for msp430,
so they aren't causing problems, but alignof does seem like a better keyword to
use for those if it works for the other targets as well.
[Bug target/91323] LTGT rtx produces UCOMISS instead of COMISS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #1 from Uroš Bizjak ---
For x86, we have:
/* Figure out whether to use unordered fp comparisons. */
static bool
ix86_unordered_fp_compare (enum rtx_code code)
{
if (!TARGET_IEEE_FP)
return false;
switch (code)
{
case GT:
case GE:
case LT:
case LE:
return false;
case EQ:
case NE:
case LTGT:
case UNORDERED:
case ORDERED:
case UNLT:
case UNLE:
case UNGT:
case UNGE:
case UNEQ:
return true;
default:
gcc_unreachable ();
}
}
where "true" means we do not trap on unordered operands.
Can you please point me to the normative documentation, so we can fix this?
[Bug c++/90590] enumeration value not handled in switch warning for std::ios_base::seek_dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90590 --- Comment #8 from Matthew Beliveau --- Author: mbelivea Date: Thu Aug 1 18:04:23 2019 New Revision: 273980 URL: https://gcc.gnu.org/viewcvs?rev=273980&root=gcc&view=rev Log: PR c++/90590 * c-warn.c (c_do_switch_warnings): Suppress warning for enumerators with reserved names that are in a system header. * c-c++-common/pr90590-1.c: New test. * c-c++-common/pr90590-1.h: New test. * c-c++-common/pr90590-2.c: New test. * c-c++-common/pr90590-2.h: New test. Added: trunk/gcc/testsuite/c-c++-common/pr90590-1.c trunk/gcc/testsuite/c-c++-common/pr90590-1.h trunk/gcc/testsuite/c-c++-common/pr90590-2.c trunk/gcc/testsuite/c-c++-common/pr90590-2.h Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/c-warn.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/85693] Generation of SAD (Sum of Absolute Difference) instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85693 --- Comment #6 from uros at gcc dot gnu.org --- Author: uros Date: Thu Aug 1 18:07:19 2019 New Revision: 273981 URL: https://gcc.gnu.org/viewcvs?rev=273981&root=gcc&view=rev Log: PR target/85693 * config/i386/mmx.md (usadv8qi): New expander. testsuite/ChangeLog: PR target/85693 * gcc.target/i386/pr85693-1.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr85693-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/mmx.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr85693.c
[Bug c++/90590] enumeration value not handled in switch warning for std::ios_base::seek_dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90590 Matthew Beliveau changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Matthew Beliveau --- Fixed.
[Bug c++/91317] [7/8/9/10 Regression] false-positive maybe-uninitialized warning in destructor with placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91317 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- If the first call to a() throws then no instance of U is constructed and so neither U::~U() nor d() is called. If the second call to a() throws then only the first instance of U will have been constructed and its dtor called, but that instance's p will have been initialized. Does C++ say that the lifetime of an object (lhs in this case) ends as soon as the construction of another object in the same storage begins, even when the construction is not complete? If that were the case, then throwing an exception from the second invocation of U would either prevent the first U from being destroyed, or trigger the destruction of the first instance just before the exception was thrown, which is not what happens (when the exception is caught). Am I missing something?
[Bug target/91323] LTGT rtx produces UCOMISS instead of COMISS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
Uroš Bizjak changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||joseph at codesourcery dot com,
||rguenth at gcc dot gnu.org
--- Comment #2 from Uroš Bizjak ---
(In reply to Ilya Leoshkevich from comment #0)
> I'm implementing signaling comparisons on S/390 and I'm trying to figure out
> whether or not LTGT is supposed to be signaling.
> I've decided to check what Intel does, and ran into what appears to be a bug.
>
> Consider the following functions:
>
> int f1(float a, float b) { return a < b || a > b; }
> int f2(float a, float b) { return __builtin_isless(a, b) ||
> __builtin_isgreater(a, b); }
> int f3(float a, float b) { return __builtin_islessgreater(a, b); }
>
> gcc creates LTGT rtx for f1 and UNEQ for f2 and f3.
> However, for all 3 variants it then emits UCOMISS instruction.
> I would expect f1 to be compiled to COMISS, since I believe that comparison
> operators in C are supposed to be signaling.
Based on the above observation, LTGT should trap, since either LT or GT traps.
It also means that __builtin_islessgreater is confusingly named.
[Bug sanitizer/91203] __asan_set_error_report_callback has no effect on leak messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91203 --- Comment #3 from Diane Meirowitz --- OK, I filed the following feature request. 1121 Ability to capture LSan messages as ASan has https://github.com/google/sanitizers/issues/1121
[Bug c++/91286] invalid use of incomplete type depends on --enable-checking=release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91286
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|2019-07-29 00:00:00 |2019-08-01
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
template class a;
template class b;
template class c;
template class m;
template struct d;
template class e;
template
struct d, h> : d, h> {};
template class i;
template struct d, h> {
d l;
void n() {
d, 1>>,
e, m<1, b, 0>>,
m<1, b, 0>>, int>>,
int>();
}
};
[Bug target/81142] Segmentation fault when using static __thread variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81142 --- Comment #11 from Harald Welte --- more than two years later, we can reproduce and observe this bug in a variety of ARM32 platforms, including raspbian 9 (with any gcc version shipped there, up to 6.3.x) and rapsbian 10 (up to gcc 6.5, but not with gcc-7.3 or gcc-8.3) You can find the lengthy journey of investing several person-days of work at https://osmocom.org/issues/4062 At Osmocom, we're not compiler experts, but it seems to relate to to what kind of ELF relocations gcc emits during code generation. IIRC, TLS was introduced in 2003, I'm surprised it still appears to be such an under-tested/under-used feature. What would be important is to fully understand this issue in order to desing a proper work-around. Dropping support for 32bit ARM systems or for platforms using gcc lower than 7.x is unfortunately not an option :/
[Bug fortran/42546] ALLOCATED statement typo in the docs and for scalar variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42546 --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #4) > I have a patch except for the doc fixes, which I'll nick from Tobias' 10 > year old patch. It seems over the years that we've fixed the documentation, but not the implementation details. I just submitted a patch.
[Bug c++/91314] Confusing warning refers to nonexistent comma operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91314 --- Comment #1 from Keith Thompson --- Irrelevant correction: The post was in comp.lang.c, not comp.lang.c++.
[Bug target/81142] Segmentation fault when using static __thread variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81142 --- Comment #12 from tomas_paukrt at conel dot cz --- Hi Herald, have you tried to cross-compile the library with -mtls-dialect=gnu2 ? We are using this option as a workaround for this bug because no one seems to be interested in fixing it. I have exactly same findings as you and using a different TLS dialect is the best possible solution that I have found so far. Best regards Tomas
[Bug c/54192] -fno-trapping-math by default?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192
--- Comment #4 from joseph at codesourcery dot com ---
On Mon, 24 Jun 2019, rguenth at gcc dot gnu.org wrote:
> so I guess it differs from -frounding-math also in a way that it doesn't
> guard FENV access of the exception state (I'd say that is not implemented
> at all, not even in the -frounding-math way) but it guards whether
> the FENV state is set to trap? So its default should match the
> execution environments default?
flag_trapping_math is about disallowing local transformations that would
add or remove the raising of exception flags. It's nothing to do with
traps, except insofar as some systems may permit exceptions to result in a
trap rather than just the raising of a flag. In particular, F.9#3 should
be considered to apply regarding permitted transformations. ("This
specification does not require support for trap handlers that maintain
information about the order or count of floating-point exceptions.
Therefore, between function calls, floating-point exceptions need not be
precise: the actual order and number of occurrences of floating-point
exceptions (> 1) may vary from what the source code expresses.")
Logically, there should be a separate option that is a stronger version of
-ftrapping-math that also prevents global transformations that change
whether an exception flag is raised between two points where it might be
observed (e.g. any non-const function call might examine floating-point
state unless the called function can be seen not to do so, and if non-pure
might also change that state). This would affect code movement and dead
code elimination, for example, and would be needed to fully implement the
exceptions parts of FENV_ACCESS.
If there were anything supporting trap handlers that determine exactly
when an exception occurred, as opposed to the standard C model where you
can test the exception flag bits by calling appropriate fenv.h functions,
I think that should be yet another option.
It is true that if the execution environment does not support
floating-point exceptions (flag bits or traps) at all then there are
various such transformations GCC could apply unconditionally. (But people
don't tend to be concerned that much with optimizing floating-point
performance for soft-float systems, and systems without floating-point
exceptions are typically soft-float.)
[Bug ada/91324] New: tree check: expected type_decl, have ggc_freed in debug_flush_symbol_queue, at dbxout.c:1481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91324 Bug ID: 91324 Summary: tree check: expected type_decl, have ggc_freed in debug_flush_symbol_queue, at dbxout.c:1481 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 In stage3: /test/gnu/gcc/objdir/./prev-gcc/xgcc -B/test/gnu/gcc/objdir/./prev-gcc/ -B/opt/g nu/gcc/gcc-10/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-10/hppa2.0w-hp-hpux1 1.11/bin/ -B/opt/gnu/gcc/gcc-10/hppa2.0w-hp-hpux11.11/lib/ -isystem /opt/gnu/gcc /gcc-10/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gcc/gcc-10/hppa2.0w-hp-h pux11.11/sys-include -fchecking=1 -c -g -O2 -fchecking=1 -mdisable-indexing -g natpg -gnata -W -Wall -nostdinc -I- -I. -Iada/generated -Iada -I../../gcc/gcc/ad a -I../../gcc/gcc/ada/gcc-interface -Iada/libgnat -I../../gcc/gcc/ada/libgnat .. /../gcc/gcc/ada/exp_fixd.adb -o ada/exp_fixd.o +===GNAT BUG DETECTED==+ | 10.0.0 20190731 (experimental) [trunk revision 273939] (hppa2.0w-hp-hpux11.11) GCC error:| | tree check: expected type_decl, have ggc_freed in| | debug_flush_symbol_queue, at dbxout.c:1481 | | Error detected around ../../gcc/gcc/ada/exp_dist.adb:11185:11| | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). ../../gcc/gcc/ada/libgnat/system.ads ../../gcc/gcc/ada/exp_dist.adb ../../gcc/gcc/ada/exp_dist.ads ../../gcc/gcc/ada/namet.ads ../../gcc/gcc/ada/alloc.ads ../../gcc/gcc/ada/hostparm.ads ../../gcc/gcc/ada/types.ads ../../gcc/gcc/ada/libgnat/unchconv.ads ../../gcc/gcc/ada/libgnat/unchdeal.ads ../../gcc/gcc/ada/table.ads ada/snames.ads ../../gcc/gcc/ada/atree.ads ../../gcc/gcc/ada/sinfo.ads ../../gcc/gcc/ada/uintp.ads ../../gcc/gcc/ada/urealp.ads ../../gcc/gcc/ada/einfo.ads ../../gcc/gcc/ada/elists.ads ../../gcc/gcc/ada/exp_atag.ads ../../gcc/gcc/ada/exp_strm.ads ../../gcc/gcc/ada/exp_tss.ads ../../gcc/gcc/ada/exp_util.ads ../../gcc/gcc/ada/rtsfind.ads ../../gcc/gcc/ada/lib.ads ../../gcc/gcc/ada/nlists.ads ada/nmake.ads ../../gcc/gcc/ada/opt.ads ../../gcc/gcc/ada/libgnat/s-string.ads ../../gcc/gcc/ada/libgnat/ada.ads ../../gcc/gcc/ada/libgnat/a-uncdea.ads ../../gcc/gcc/ada/libgnat/s-wchcon.ads ../../gcc/gcc/ada/sem.ads ../../gcc/gcc/ada/sem_aux.ads ../../gcc/gcc/ada/sem_cat.ads ../../gcc/gcc/ada/sem_ch3.ads ../../gcc/gcc/ada/sem_ch8.ads ../../gcc/gcc/ada/sem_ch12.ads ../../gcc/gcc/ada/inline.ads ../../gcc/gcc/ada/warnsw.ads ../../gcc/gcc/ada/sem_dist.ads ../../gcc/gcc/ada/sem_eval.ads ../../gcc/gcc/ada/sem_util.ads ../../gcc/gcc/ada/stand.ads ../../gcc/gcc/ada/stringt.ads ../../gcc/gcc/ada/tbuild.ads ../../gcc/gcc/ada/ttypes.ads ../../gcc/gcc/ada/get_targ.ads ../../gcc/gcc/ada/set_targ.ads ../../gcc/gcc/ada/libgnat/gnat.ads ../../gcc/gcc/ada/libgnat/g-htable.ads ../../gcc/gcc/ada/libgnat/s-htable.ads ../../gcc/gcc/ada/libgnat/s-exctab.ads ../../gcc/gcc/ada/libgnat/s-stalib.ads ../../gcc/gcc/ada/libgnat/a-unccon.ads ../../gcc/gcc/ada/libgnat/s-unstyp.ads ../../gcc/gcc/ada/libgnat/s-conca2.ads ../../gcc/gcc/ada/libgnat/s-assert.ads ../../gcc/gcc/ada/libgnat/s-secsta.ads ../../gcc/gcc/ada/libgnat/s-parame.ads ../../gcc/gcc/ada/libgnat/s-stoele.ads ../../gcc/gcc/ada/libgnat/s-htable.adb ../../gcc/gcc/ada/libgnat/s-strhas.ads raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:407 mkdir -p ada/ /test/gnu/gcc/objdir/./prev-gcc/xgcc -B/test/gnu/gcc/objdir/./prev-gcc/ -B/opt/gnu/gcc/gcc-10/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-10/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-10/hppa2.0w-hp-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-10/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gcc/gcc-10/hppa2.0w-hp-hpux11.11/sys-include -fchecking=1 -c -g -O2 -fchecking=1 -mdisable-indexing -gnatpg -gnata -W -Wall -nostdinc -I- -I. -Iada/generated -Iada -I../../gcc/gcc/ada -I../../gcc/gcc/ada/gcc-interface -Iada/libgnat -I../../gcc/gcc/ada/libgnat ../../gcc/gcc/ada/exp_imgv.adb -o ada/exp_imgv.o ../../gcc/gcc/ada/gcc-in
[Bug c++/91314] Confusing warning refers to nonexistent comma operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91314 Harald van Dijk changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #2 from Harald van Dijk --- (In reply to Keith Thompson from comment #0) > I've reproduced this problem with all versions of g++ I have access > to, from 4.1.2 to 10.0.0 20190718 (experimental). GCC has generated a warning for this since at least GCC 2, but up to 3.3, the warning was warning: value computed is not used which is correct. In GCC 3.4, the warning changed to warning: right-hand operand of comma has no effect
[Bug target/90993] simd integer division not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90993 --- Comment #2 from joseph at codesourcery dot com --- Note that this is only valid with -fno-trapping-math (since integer division is not permitted to raise the "inexact" exception flag). (With AVX-512 there are instruction variants that suppress exceptions and so could be used even with -ftrapping-math.)
[Bug c++/90947] [9/10 Regression] Simple lookup table of array of strings is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90947 --- Comment #5 from Martin Sebor --- Author: msebor Date: Thu Aug 1 23:45:36 2019 New Revision: 273989 URL: https://gcc.gnu.org/viewcvs?rev=273989&root=gcc&view=rev Log: PR c++/90947 - Simple lookup table of array of strings is miscompiled gcc/cp/ChangeLog: PR c++/90947 * decl.c (reshape_init_array_1): Avoid truncating initializer lists containing string literals. gcc/testsuite/ChangeLog: PR c++/90947 * c-c++-common/array-1.c: New test. * g++.dg/abi/mangle73.C: New test. * g++.dg/cpp2a/nontype-class23.C: New test. * g++.dg/init/array53.C: New test. gcc/ChangeLog: PR c++/90947 * tree.c (type_initializer_zero_p): Define. * tree.h (type_initializer_zero_p): New function. Added: trunk/gcc/testsuite/c-c++-common/array-1.c trunk/gcc/testsuite/g++.dg/abi/mangle73.C trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class23.C trunk/gcc/testsuite/g++.dg/init/array53.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c trunk/gcc/tree.h
[Bug c++/90947] [9 Regression] Simple lookup table of array of strings is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90947 Martin Sebor changed: What|Removed |Added Summary|[9/10 Regression] Simple|[9 Regression] Simple |lookup table of array of|lookup table of array of |strings is miscompiled |strings is miscompiled --- Comment #6 from Martin Sebor --- Fixed for GCC 10 in r273989.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Kewen Lin changed: What|Removed |Added CC||linkw at gcc dot gnu.org --- Comment #26 from Kewen Lin --- > The odd thing is that if you omit libfoo1.so then it will consider > libfoo.a later but not when it can resolve from libfoo1.so. > > That's a bit inconsistent but arguably the bug is with GCCs > symbol table creation of the LTO IR. Do we have option to dump the actual final linking command to link all ltrans objects? I can only see the command to generate ltrans object with as. Is it possible a library order issue in final linking?
[Bug target/81142] Segmentation fault when using static __thread variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81142 --- Comment #13 from Harald Welte --- Created attachment 46657 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46657&action=edit the reproducer created by osmocom
[Bug target/81142] Segmentation fault when using static __thread variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81142 --- Comment #14 from Harald Welte --- Hi Tomas, thanks a lot for your suggested workaround. Indeed -mtls-dialect=gnu2 seems to be working also in our case. -fPIE as suggested earlier is not an option as the __thread variables are used in a shared library (libosmocore from http://git.osmocom.org/libosmocore/ in our case). Originally the reproducer also built a separate .so file, but it turned out this is not needed, i.e. even when stattically linking a -fPIC built .o file into the executable the problem can be seen very clearly.
[Bug c++/66139] destructor not called for members of partially constructed anonymous struct/array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66139 dingd changed: What|Removed |Added CC||ntysdd at qq dot com --- Comment #14 from dingd --- I believe this bug is still there on g++ 9.1.0.
[Bug c++/66139] destructor not called for members of partially constructed anonymous struct/array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66139
--- Comment #15 from dingd ---
This bug may be not so rare as it seems, because it can be triggered when
initializing a vector with an initializer list.
For example,
std::vector v = { A(), A() };
this is enough to trigger it if the constructor throws.
