[Bug c++/94843] if i use pch and specify '-include' twice compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94843 --- Comment #1 from gccshep --- environment: $ uname -a Linux 5user6-7VirtualBox890 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux tested with g++-8/9 : $ g++-8 --version g++-8 (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0 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. $ g++-9 --version g++-9 (Ubuntu 9.3.0-11ubuntu0~18.04.1) 9.3.0 Copyright (C) 2019 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. It seems like it is reproducible with gcc too. Also reproduced this with gcc/++ 5.5.0 on Slackware 64.
[Bug c++/94827] [10 Regression] crash on requires clause in tparam list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94827 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P1 Known to work||9.3.0 Target Milestone|--- |10.0
[Bug target/94826] [8/9/10 regression] ICE in gcc.dg/pr94780.c after r10-7999
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94826 Richard Biener changed: What|Removed |Added Summary|[10 regression] ICE in |[8/9/10 regression] ICE in |gcc.dg/pr94780.c after |gcc.dg/pr94780.c after |r10-7999|r10-7999 Target Milestone|--- |8.5
[Bug lto/94822] [10 Regression] ICE in lto with option -Warray-bounds and -fno-use-linker-plugin since r10-4300-g49fb45c81f4ac068
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94822 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/94843] New: if i use pch and specify '-include' twice compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94843
Bug ID: 94843
Summary: if i use pch and specify '-include' twice compilation
fails
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m+gccbugs at gshep dot ru
Target Milestone: ---
Hi!
The following commands give "cc1plus fatal error ./empty.h No such file or
directory ; compilation terminated."
=
mkdir 111
touch 111/empty.h
echo 'int main(){ return 0; }' > a.cpp
find
g++ -g -Winvalid-pch -x c++-header -o empty.h.gch -c 111/empty.h
g++ -I. -I111 -g -Winvalid-pch -include empty.h -include empty.h -o a.o -c
a.cpp
=
We encountered this issue on our project except that we have 'include
"empty.h"' in cpp source file and one '-include' command line parameter.
Is this a bug or am I missing anything? Thanks in advance.
[Bug target/94838] Failure to optimize out useless zero-ing after register was already zero-ed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94838 --- Comment #4 from Gabriel Ravier --- Oops, seems like there was a weird collision. Don't pay attention to the second to last comment before this one, it's identical to the last comment before this one except for a single comment being added in the last comment before this one.
[Bug c/94842] New: [8/9/10 Regression] internal compiler error: in gimplify_label_expr, at gimplify.c:2573
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94842
Bug ID: 94842
Summary: [8/9/10 Regression] internal compiler error: in
gimplify_label_expr, at gimplify.c:2573
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
_Atomic float x = 5 ;
void foo ( int arg_0 )
{
void bar ( float arg_0 [ ( int ) ( x += 2 ) ] ) { }
}
$ gcc-10 --version
gcc (GCC) 10.0.1 20200419 (experimental)
Copyright (C) 2020 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.
$ gcc-10 test.c
test.c: In function ‘bar’:
test.c:6:27: internal compiler error: in gimplify_label_expr, at
gimplify.c:2573
6 | void bar ( float arg_0 [ ( int ) ( x += 2 ) ] ) { }
| ^~
0x66df8d gimplify_label_expr
../../gcc-10-20200419/gcc/gimplify.c:2573
0xafd7d2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-10-20200419/gcc/gimplify.c:13847
0xb00bd6 gimplify_stmt(tree_node**, gimple**)
../../gcc-10-20200419/gcc/gimplify.c:6825
0xafe48b gimplify_statement_list
../../gcc-10-20200419/gcc/gimplify.c:1869
0xafe48b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-10-20200419/gcc/gimplify.c:14052
0xb12883 gimplify_stmt(tree_node**, gimple**)
../../gcc-10-20200419/gcc/gimplify.c:6825
0xb12883 gimplify_compound_expr
../../gcc-10-20200419/gcc/gimplify.c:6025
0xafdb30 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-10-20200419/gcc/gimplify.c:13598
0xb031b0 internal_get_tmp_var
../../gcc-10-20200419/gcc/gimplify.c:619
0xb057ca get_initialized_tmp_var(tree_node*, gimple**, gimple**, bool)
../../gcc-10-20200419/gcc/gimplify.c:674
0xb057ca gimplify_save_expr
../../gcc-10-20200419/gcc/gimplify.c:6073
0xafdeb6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-10-20200419/gcc/gimplify.c:13908
0xb00bd6 gimplify_stmt(tree_node**, gimple**)
../../gcc-10-20200419/gcc/gimplify.c:6825
0xafe48b gimplify_statement_list
../../gcc-10-20200419/gcc/gimplify.c:1869
0xafe48b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-10-20200419/gcc/gimplify.c:14052
0xb15927 gimplify_stmt(tree_node**, gimple**)
../../gcc-10-20200419/gcc/gimplify.c:6825
0xb15927 gimplify_body(tree_node*, bool)
../../gcc-10-20200419/gcc/gimplify.c:14857
0xb15e53 gimplify_function_tree(tree_node*)
../../gcc-10-20200419/gcc/gimplify.c:15030
0xe49ee0 gimplify_all_functions
../../gcc-10-20200419/gcc/tree-nested.c:3521
0xe49ecf gimplify_all_functions
../../gcc-10-20200419/gcc/tree-nested.c:3524
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/94838] Failure to optimize out useless zero-ing after register was already zero-ed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94838 --- Comment #3 from Gabriel Ravier --- This also occurs on i68* : f(bool, int*): xor eax, eax ; Already 0 cmp BYTE PTR [esp+4], 0 je .L1 mov eax, DWORD PTR [esp+8] ; Could use different caller-saved register such as ecx or edx mov eax, DWORD PTR [eax] test eax, eax setne al movzx eax, al ; This could then be avoided since eax would already be 0 .L1: ret
[Bug target/94838] Failure to optimize out useless zero-ing after register was already zero-ed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94838 Gabriel Ravier changed: What|Removed |Added Target|x86_64-linux-gnu|x86_64-* i?86-*-* --- Comment #2 from Gabriel Ravier --- This also occurs on i68* : f(bool, int*): xor eax, eax ; Already 0 cmp BYTE PTR [esp+4], 0 je .L1 mov eax, DWORD PTR [esp+8] ; Could use different caller-saved register such as ecx or edx mov eax, DWORD PTR [eax] test eax, eax setne al movzx eax, al .L1: ret
[Bug ipa/94818] GCC emits dead bodies of functions whose all calls have been eliminated by optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94818 Andrew Pinski changed: What|Removed |Added Depends on||47205, 89139 --- Comment #2 from Andrew Pinski --- Related to PR 47205, PR 89139 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47205 [Bug 47205] GCC emits optimized out noinline function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89139 [Bug 89139] GCC emits code for static functions that aren't used by the optimized code
[Bug c/94840] Extern var not defined but compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94840 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- The variable definition inside foo declares an auto (local scope) variable. The original variable declaration is not used so it is never referenced so there is no linker failure.
[Bug target/94841] New: [10 Regression]527.cam4_r 7.68% regression on Intel Cascadelaker with -O2, 9.57% regression with -Ofast -march=native -funroll-loops -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94841 Bug ID: 94841 Summary: [10 Regression]527.cam4_r 7.68% regression on Intel Cascadelaker with -O2, 9.57% regression with -Ofast -march=native -funroll-loops -flto Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: crazylht at gmail dot com CC: hjl.tools at gmail dot com, tkoenig at gcc dot gnu.org, wwwhhhyyy333 at gmail dot com Target Milestone: --- Target: i386, x86-64 Starting with commit 06eca1acafa27e19e82dc73927394a7a4d0bdbc5 Author: Thomas König Date: Thu Apr 23 20:30:01 2020 +0200 Fix PR 93956, wrong pointer when returned via function. This one took a bit of detective work. When array pointers point to components of derived types, we currently set the span field and then create an array temporary when we pass the array pointer to a procedure as a non-pointer or non-target argument. (This is inefficient, but that's for another release). Now, the compiler detected this case when there was a direct assignment like p => a%b, but not when p was returned either as a function result or via an argument. This patch fixes that. 2020-04-23 Thomas Koenig PR fortran/93956 * expr.c (gfc_check_pointer_assign): Also set subref_array_pointer when a function returns a pointer. * interface.c (gfc_set_subref_array_pointer_arg): New function. (gfc_procedure_use): Call it. 2020-04-23 Thomas Koenig PR fortran/93956 * gfortran.dg/pointer_assign_13.f90: New test. --
[Bug c/94840] New: Extern var not defined but compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94840
Bug ID: 94840
Summary: Extern var not defined but compiles
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dudu.arbel at ilrd dot co.il
Target Milestone: ---
The following code compiles successfully.
Linker should, of course, fail:
extern int a;
void foo(void)
{
int a = 3;
a += 5;
}
int main()
{
foo();
return 0;
}
[Bug c++/94799] [8/9/10 Regression] Calling a member template function fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94799 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #6 from Marek Polacek --- https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544806.html
[Bug c++/94830] Some concepts diagnostic messages are nondeterministic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94830 Patrick Palka changed: What|Removed |Added Last reconfirmed||2020-04-29 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug analyzer/94839] False positive with -fanalyzer and direct field assignment from calloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94839 Andrew Pinski changed: What|Removed |Added Depends on||94640 --- Comment #1 from Andrew Pinski --- This seems related to PR 94640 even. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94640 [Bug 94640] false-positive leaking FILE pointer assigned to function passed pointer
[Bug analyzer/94839] New: False positive with -fanalyzer and direct field assignment from calloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94839
Bug ID: 94839
Summary: False positive with -fanalyzer and direct field
assignment from calloc
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
struct bitmap
{
int min;
int max;
int *vec;
};
int bitmap_create(struct bitmap *bm, int min, int max)
{
int sz;
sz = (max / sizeof(int)) + 1;
bm->min = min;
bm->max = max;
bm->vec = __builtin_calloc(sz, sizeof(int));
if (!bm->vec)
return (-12);
return 0;
}
- CUT
This gives (at -O2 -fanalyzer -W -Wall ):
In function ‘bitmap_create’:
t_1.c:18:12: warning: leak of ‘’ [CWE-401]
[-Wanalyzer-malloc-leak]
18 | if (!bm->vec)
|^
‘bitmap_create’: events 1-3
|
| 13 | sz = (max / sizeof(int)) + 1;
| | ~^~
| | |
| | (1) allocated here
|..
| 18 | if (!bm->vec)
| |~
| ||
| |(2) assuming ‘’ is non-NULL
| |(3) following ‘false’ branch...
|
‘bitmap_create’: event 4
|
|cc1:
| (4): ...to here
|
‘bitmap_create’: event 5
|
| 18 | if (!bm->vec)
| |^
| ||
| |(5) ‘’ leaks here; was allocated at (1)
|
Except there is no leaking as assign the calloc to bm->vec .
If we change the type of vec to void*, there is no warning.
[Bug c++/94808] [ICE] [Regression] Segfault during diagnostics from concept check failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94808 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |10.0 Resolution|--- |FIXED --- Comment #3 from Patrick Palka --- Fixed.
[Bug c++/94819] [10 Regression] Inherited and constrained constructors are "ambiguous" even if they aren't Pt. 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94819 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Patrick Palka --- Fixed.
[Bug libstdc++/94823] modulo arithmetic bug in random.tcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94823 --- Comment #5 from AK --- > So when __k == 0, then all three of those loads will be _Type(0x8b8b8b8bu) > really; no matter what the values of __n, __p will be. Will it be a good idea to add the explanation in comments, as this may be tricky for someone to comprehend in future?
[Bug c++/94819] [10 Regression] Inherited and constrained constructors are "ambiguous" even if they aren't Pt. 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94819 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:1d2290caad0dba52b285b47057b7c0e4e8d21feb commit r10-8025-g1d2290caad0dba52b285b47057b7c0e4e8d21feb Author: Patrick Palka Date: Tue Apr 28 21:45:59 2020 -0400 c++: Satisfaction caching of inherited ctor [PR94819] As observed in PR94719, an inherited constructor for an instantiation of a constructor template confusingly has as its DECL_INHERITED_CTOR the TEMPLATE_DECL of the constructor template rather than the particular instantiation of the template. This means two inherited constructors for two different instantiations of the same constructor template have the same DECL_INHERITED_CTOR. And since in satisfy_declaration_constraints our decl satisfaction cache is keyed off of the result of strip_inheriting_ctors, we may end up conflating the satisfaction values of the two inherited constructors' constraints. This patch fixes this issue by using the original tree, not the result of strip_inheriting_ctors, as the key to the decl satisfaction cache. gcc/cp/ChangeLog: PR c++/94819 * constraint.cc (satisfy_declaration_constraints): Use saved_t instead of t as the key to decl_satisfied_cache. gcc/testsuite/ChangeLog: PR c++/94819 * g++.dg/cpp2a/concepts-inherit-ctor10.C: New test. * g++.dg/cpp2a/concepts-inherit-ctor11.C: New test.
[Bug c++/94808] [ICE] [Regression] Segfault during diagnostics from concept check failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94808 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:43439d5e8424f3a746003ef8953e1cdc120fbbd7 commit r10-8024-g43439d5e8424f3a746003ef8953e1cdc120fbbd7 Author: Patrick Palka Date: Tue Apr 28 21:45:54 2020 -0400 c++: Parameter pack in requires parameter list [PR94808] When printing the substituted parameter list of a requires-expression as part of the "in requirements with ..." context line during concepts diagnostics, we weren't considering that substitution into a parameter pack can yield zero or multiple parameters. This patch changes the way we print the parameter list of a requires-expression in print_requires_expression_info. We now print the dependent form of the parameter list (along with its template parameter mapping) instead of printing its substituted form. Besides being an improvement in its own, this also sidesteps the substitution issue in the PR altogether. gcc/cp/ChangeLog: PR c++/94808 * error.c (print_requires_expression_info): Print the dependent form of the parameter list with its template parameter mapping, rather than printing the substituted form. gcc/testsuite/ChangeLog: PR c++/94808 * g++.dg/concepts/diagnostic12.C: New test. * g++.dg/concepts/diagnostic5.C: Adjust dg-message.
[Bug target/94838] Failure to optimize out useless zero-ing after register was already zero-ed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94838 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- Most likely it is due to splitting of the setting of eax from the cmp happens after reload. THIS IS a target issue because of that.
[Bug target/93654] Inappropriate "-fcf-protection and -mindirect-branch=thunk are incompatible on x86_64" restriction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 H.J. Lu changed: What|Removed |Added Target Milestone|--- |10.0 URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-April/5 ||44804.html Keywords||patch --- Comment #8 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544804.html
[Bug target/54593] [missed-optimization] Move from SSE to integer register goes through the stack without -march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54593 Andrew Pinski changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment #7 from Andrew Pinski --- *** Bug 94837 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/94837] Failure to optimize out spurious movbe into bswap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94837 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- This is on purpose. Use -mtune=intel to get the result you want. See PR 54593 of the reason why. *** This bug has been marked as a duplicate of bug 54593 ***
[Bug rtl-optimization/94838] New: Failure to optimize out useless zero-ing after register was already zero-ed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94838
Bug ID: 94838
Summary: Failure to optimize out useless zero-ing after
register was already zero-ed
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(bool b, int *p)
{
return b && *p;
}
GCC generates this with -O3:
f(bool, int*):
xor eax, eax
test dil, dil
je .L1
mov edx, DWORD PTR [rsi]
xor eax, eax ; This can be removed, since eax is already 0 here
test edx, edx
setne al
.L1:
ret
[Bug target/94820] [8/9/10 Regression] pr94780.c fails with ICE on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94820 --- Comment #3 from z.zhanghaijian at huawei dot com --- I have an initial fix for aarch64 that is under testing. Will post to gcc-patches when finished.
[Bug rtl-optimization/94837] New: Failure to optimize out spurious movbe into bswap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94837
Bug ID: 94837
Summary: Failure to optimize out spurious movbe into bswap
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
float swapFloat(float x)
{
union
{
float f;
uint32_t u32;
} swapper;
swapper.f = x;
swapper.u32 = __builtin_bswap32(swapper.u32);
return swapper.f;
}
For this function, on x86-64 with `-O3 -mmovbe`, LLVM outputs this :
swapFloat(float): # @swapFloat(float)
movd eax, xmm0
bswap eax
movd xmm0, eax
ret
GCC instead outputs this :
swapFloat(float):
movd DWORD PTR [rsp-4], xmm0
movbe eax, DWORD PTR [rsp-4]
movd xmm0, eax
ret
It seems highly likely to me that a spill to memory is much slower than a
direct `bswap`.
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 --- Comment #31 from Jürgen Reuter --- Created attachment 48402 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48402&action=edit Reproducer 4, down to 210 kb
[Bug libstdc++/94823] modulo arithmetic bug in random.tcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94823 --- Comment #4 from AK --- Makes sense. Thanks for the explanation.
[Bug target/93654] Inappropriate "-fcf-protection and -mindirect-branch=thunk are incompatible on x86_64" restriction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 --- Comment #7 from Andrew Cooper --- Yes - that works. Confirmed that I have both retpolines and endbr64 instructions, and the resulting hypervisor boots. (I don't have CET capable hardware, but that is fine. There is at minimum there is MSR setup to do, so any other issues can be addressed at that time.)
[Bug target/93654] Inappropriate "-fcf-protection and -mindirect-branch=thunk are incompatible on x86_64" restriction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 H.J. Lu changed: What|Removed |Added Attachment #48396|0 |1 is obsolete|| --- Comment #6 from H.J. Lu --- Created attachment 48401 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48401&action=edit A patch I am testing this.
[Bug tree-optimization/94836] New: Failure to optimize condition based on known value of static variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94836
Bug ID: 94836
Summary: Failure to optimize condition based on known value of
static variable
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int x)
{
static int s;
if (s)
s = x;
return s;
}
This can be optimized to `return 0`. This transformation is done by LLVM, but
not by GCC
LLVM -O3 outputs :
f(int): # @f(int)
xor eax, eax
ret
GCC -O3 outputs :
f(int):
mov eax, DWORD PTR f(int)::s[rip]
test eax, eax
je .L1
mov DWORD PTR f(int)::s[rip], edi
mov eax, edi
.L1:
ret
(see also https://godbolt.org/z/FzpjCb)
[Bug c++/94799] [8/9/10 Regression] Calling a member template function fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94799 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Marek Polacek --- Finally I have something that seems to work...
[Bug c++/94835] ICE in vague_linkage_p, at cp/decl2.c:2041
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94835 --- Comment #2 from Stephen Casner --- Created attachment 48400 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48400&action=edit log of compilation with -v (Not sure why the initial attachment was deleted.)
[Bug c++/94835] ICE in vague_linkage_p, at cp/decl2.c:2041
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94835 --- Comment #1 from Stephen Casner --- Created attachment 48398 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48398&action=edit preprocessed source chrono.ii
[Bug c++/94835] New: ICE in vague_linkage_p, at cp/decl2.c:2041
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94835 Bug ID: 94835 Summary: ICE in vague_linkage_p, at cp/decl2.c:2041 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: casner at acm dot org Target Milestone: --- I am working on a pdp11-elf32 target in binutils with the goal of being able to compile C++ for the PDP11 (an effort instigated by Paul Koning, gcc PDP11 maintainer). I have a first implementation running, so now I am trying to build g++ and libstdc++v3 to go with it. I am attempting to build the gcc tree with newlib and libgloss symlinked in and with the binutils components installed at the prefix and with gcc configured as follows: ../configure --target=pdp11-elf32 --prefix=/usr/local --enable-languages=c,c++ --disable-libssp --disable-libgfortran --disable-libobjc --with-gmp=/opt/local/ --with-mpfr=/opt/local/ --with-mpc=/opt/local/ --with-libiconv-prefix=/opt/local --with-newlib My host is running macOS 10.14.6. gcc and g++ build successfully, but while building libstdc++v3 I get: .../libstdc++-v3/include/chrono:544:7: internal compiler error: in vague_linkage_p, at cp/decl2.c:2041 This is with code freshly fetched with git today. 19667c82e479dc2bf8351588ed57aff90220b748
[Bug target/93654] Inappropriate "-fcf-protection and -mindirect-branch=thunk are incompatible on x86_64" restriction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 --- Comment #5 from Andrew Cooper --- Thanks. Just compiling the patch. As a note however, https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html will need adjusting to remove the final note for -mindirect-branch=choice
[Bug libstdc++/91480] Nonconforming definitions of standard library feature-test macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91480 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #3) > (In reply to frankhb1989 from comment #0) > > Also, in , `__cpp_lib_allocator_traits_is_always_equal` is > > wrongly spelled as `__cpp_lib_allocator_is_always_equal`. > > This is incorrect. We *also* define > __cpp_lib_allocator_traits_is_always_equal, in the appropriate places. So we > have an extra, non-standard macro. We don't spell the standard one wrong. > > The allocator_is_always_equal spelling was present in > http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4440.html#recs.cpp17 > and in > http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0096r0.html#detail. > cpp17 but gone in > http://open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0096r1.html#recs.cpp17 I've removed __cpp_lib_allocator_is_always_equal for GCC 10.
[Bug libstdc++/94831] [10 Regression] vector no longer compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94831 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Should now be fixed.
[Bug target/93654] Inappropriate "-fcf-protection and -mindirect-branch=thunk are incompatible on x86_64" restriction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-04-28 Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot com --- Comment #4 from H.J. Lu --- Created attachment 48396 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48396&action=edit A patch Please try this.
[Bug tree-optimization/94824] Failure to optimize with __builtin_bswap32 as well as with a function recognized as such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94824 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2020-04-28 Status|UNCONFIRMED |NEW Keywords||missed-optimization Severity|normal |enhancement Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed, I have seen this before too.
[Bug libstdc++/94831] [10 Regression] vector no longer compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94831 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:162c40a4c127cc55d701bb8760e17708d0ca2fe0 commit r10-8021-g162c40a4c127cc55d701bb8760e17708d0ca2fe0 Author: Jonathan Wakely Date: Tue Apr 28 23:26:21 2020 +0100 libstdc++: Fix regression in std::_Construct (PR 94831) By trying to reuse the existing std::_Construct function as a wrapper for std::construct_at I introduced regressions, because changing std::_Construct to return non-void made it ill-formed for array types. The solution is to revert _Construct to its former state, and change allocator_traits::construct to explicitly call construct_at instead. This decouples all the existing callers of _Construct from the new construct_at requirements. PR libstdc++/94831 * include/bits/alloc_traits.h (_S_construct): Restore placement new-expression for C++11/14/17 and call std::construct_at directly for C++20. * include/bits/stl_construct.h (_Construct): Revert to non-constexpr function returning void. * testsuite/20_util/specialized_algorithms/ uninitialized_value_construct/94831.cc: New test. * testsuite/23_containers/vector/cons/94831.cc: New test.
[Bug libstdc++/91480] Nonconforming definitions of standard library feature-test macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91480 --- Comment #5 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d0330a03606d06dc4084e9c8734a549d22676463 commit r10-8022-gd0330a03606d06dc4084e9c8734a549d22676463 Author: Jonathan Wakely Date: Tue Apr 28 23:31:04 2020 +0100 libstdc++: Fixes for feature test macros (PR 91480) Remove the non-standard __cpp_lib_allocator_is_always_equal macro and add the missing macros for P1032R1. PR libstdc++/91480 * include/bits/allocator.h (__cpp_lib_allocator_is_always_equal): Remove non-standard macro. * include/bits/stl_iterator.h (__cpp_lib_constexpr_iterator): Define to indicate P1032R1 support. * include/bits/stl_pair.h (__cpp_lib_constexpr_utility): Likewise. * include/std/string_view (__cpp_lib_constexpr_string_view): Likewise. * include/std/tuple (__cpp_lib_constexpr_tuple): Likewise. * include/std/version (__cpp_lib_allocator_is_always_equal): Remove. (__cpp_lib_constexpr_iterator, __cpp_lib_constexpr_string_view) (__cpp_lib_constexpr_tuple, __cpp_lib_constexpr_utility): Define. * testsuite/20_util/function_objects/constexpr_searcher.cc: Check feature test macro. * testsuite/20_util/tuple/cons/constexpr_allocator_arg_t.cc: Likewise. * testsuite/21_strings/basic_string_view/operations/copy/char/ constexpr.cc: Likewise. * testsuite/24_iterators/insert_iterator/constexpr.cc: Likewise.
[Bug libstdc++/94823] modulo arithmetic bug in random.tcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94823
--- Comment #3 from Andrew Pinski ---
>In particular when __k is zero we're taking '(2^64 - 1) mod __n', which is not
>necessarily __n - 1, the last position in the buffer, right?
Yes that is correct except when __k is 0, then __begin will the same values so
it does not matter in the end ...
std::fill(__begin, __end, _Type(0x8b8b8b8bu));
.
for (size_t __k = 0; __k < __m; ++__k)
{
_Type __arg = (__begin[__k % __n]
^ __begin[(__k + __p) % __n]
^ __begin[(__k - 1) % __n]);
So when __k == 0, then all three of those loads will be _Type(0x8b8b8b8bu)
really; no matter what the values of __n, __p will be.
So it does not matter in the end.
The rest will be similar.
__n can never be 0 because of:
if (__begin == __end)
return;
If __n is a value which is greater than SSIZE_MAX, that would be an undefined
case (__begin > __end).
[Bug libstdc++/94823] modulo arithmetic bug in random.tcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94823 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Note there are two loops here where we could have an issue but In the first loop, it is ok usage because __k will be only 0 when the array will be filled with the same data (0x8b8b8b8bu) so that usage does not matter. The second loop is where it might matter but __k will never be 0 as __m is will either be greater than or equal to __n.
[Bug tree-optimization/94834] New: Failure to optimize loop bswap pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94834
Bug ID: 94834
Summary: Failure to optimize loop bswap pattern
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
uint32_t load(const uint8_t* data)
{
uint32_t val = 0;
for (int i = 0; i < sizeof(val) * CHAR_BIT; i += CHAR_BIT)
{
val |= *data++ << i;
}
return val;
}
This can be optimized to a single 32-bit load. LLVM does this transformation,
gcc just unrolls the loop and misses the transformation.
LLVM gives :
load(unsigned char const*): # @load(unsigned char const*)
mov eax, dword ptr [rdi]
ret
GCC gives :
load(unsigned char const*):
movzx edx, BYTE PTR [rdi+1]
movzx eax, BYTE PTR [rdi]
sal edx, 8
or edx, eax
movzx eax, BYTE PTR [rdi+2]
sal eax, 16
or edx, eax
movzx eax, BYTE PTR [rdi+3]
sal eax, 24
or eax, edx
ret
See also https://godbolt.org/z/kmYTLZ
[Bug target/94812] ppc incorrect mffs-based emulation of mffsl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94812 --- Comment #2 from CVS Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:50714f45eeaf315a0b55d3db3de3bf8df8e94b04 commit r10-8020-g50714f45eeaf315a0b55d3db3de3bf8df8e94b04 Author: Alexandre Oliva Date: Thu Apr 23 02:19:55 2020 -0300 [rs6000] fix mffsl emulation The emulation of mffsl with mffs, used when !TARGET_P9_MISC, is going through the motions, but not storing the result in the given operands[0]; it rather modifies operands[0] without effect. It also creates a DImode pseudo that it doesn't use, overwriting subregs instead. The patch below fixes all of these, the indentation and a typo. I'm concerned about several issues in the mffsl testcase. First, I don't see that comparing the values as doubles rather than as long longs is desirable. These are FPSCR bitfields, not FP numbers. I understand mffs et al use double because they output to FP registers, and the bit patterns are subnormal FP numbers, so it works, but given the need for bit masking of at least one side, I'm changing the compare to long longs. Another issue with the test is that, if the compare fails, it calls mffsl again to print the value, as if it would yield the same result. But part of the FPSCR that mffsl (emulated with mffs or not) copies to the output FP register is the FPCC, so the fcmpu used to compare the result of the first mffsl will modify FPSCR and thus the result of the second mffsl call. After changing the compare, this is no longer the case, but I still think it's better to make absolutely sure what we print is what we compared. Yet another issue is that the test assumed the mffs bits that are not to be extracted by mffsl to be already zero, instead of masking them out explicitly. This is not about the mffs emulation in the mffsl implementation, but about the mffs use in the test proper. The bits appear to be zero indeed, as the bits left out are for sticky exceptions, but there are reserved parts of FPSCR that might turn out to be set in the future, so we're better off masking them out explicitly, otherwise those bits could cause the compare to fail. If some future mffsl is changed so that it copies additional nonzero bits, the test will fail, and then we'll have a chance to adjust it and the emulation. for gcc/ChangeLog PR target/94812 * gcc/config/rs6000/rs6000.md (rs6000_mffsl): Copy result to output operand in emulation. Don't overwrite pseudos. for gcc/testsuite/ChangeLog PR target/94812 * gcc.target/powerpc/test_mffsl.c: Call mffsl only once. Reinterpret the doubles as long longs for compares. Mask out mffs bits that are not expected from mffsl.
[Bug target/94833] vec_first_match_index does not function as described in its description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94833 Carl Love changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-04-28 Assignee|unassigned at gcc dot gnu.org |carll at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/94833] vec_first_match_index does not function as described in its description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94833 --- Comment #2 from Carl Love --- The ABI has the builtin VEC_FIRST_MATCH_OR_EOS_ INDEX (ARG1, ARG2) which says Returns the element index of the position of either the first character match or an end-of-string (EOS) terminator. If no match or terminator, returns the number of characters as an element count in the vector argument. So, I do agree the builtin in question should be treating the EOS (null) as any other number for comparison purposes.
[Bug c++/90748] [9/10 Regression] ICE in tsubst_copy, at cp/pt.c:15564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90748 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/90992] [9/10 Regression] -Wnoexcept produce false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90992 Jason Merrill changed: What|Removed |Added Target Milestone|9.4 |10.0 Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #14 from Jason Merrill --- Since no other testcase has appeared, I'm calling this fixed in GCC 10.
[Bug target/94826] [10 regression] ICE in gcc.dg/pr94780.c after r10-7999
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94826 Andrew Pinski changed: What|Removed |Added Component|other |target Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Last reconfirmed||2020-04-28 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Similar fix to the powerpc back-end to what was done to the x86 backend needs to happen.
[Bug tree-optimization/94828] Loop fusion is not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94828 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-04-28 Summary|Failure to merge merge-able |Loop fusion is not |loops |implemented --- Comment #1 from Andrew Pinski --- Loop fusion is not implemented correct. See PR 45661 and PR 85531 also.
[Bug libstdc++/94831] [10 Regression] vector no longer compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94831
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> In r277342 I changed std::_Construct for P0784R7, "More constexpr
> containers" and the non-void return type means this no longer compiles:
>
> #include
> std::vector v(1);
>
> This was never valid in C++98, and in C++11 to C++17 it's undefined (because
> the pseudo-destructor call in allocator_traits>::destroy
> is ill-formed for arrays). But for libstdc++ it happened to compile, because
> we elide the calls to trivial destructors.
We should consider making this change in stage 1, to stop silently accepting
that non-standard code in strict mode:
--- a/libstdc++-v3/include/bits/alloc_traits.h
+++ b/libstdc++-v3/include/bits/alloc_traits.h
@@ -734,6 +734,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_Destroy(_ForwardIterator __first, _ForwardIterator __last,
allocator<_Tp>&)
{
+#if __cplusplus >= 201103L && defined __STRICT_ANSI__
+ static_assert(!is_array<_Tp>::value,
+ "arrays are not Erasable from containers using std::allocator");
+#endif
_Destroy(__first, __last);
}
[Bug c++/94832] AVX512 scatter/gather macros lack parentheses when unoptimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94832 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-04-28 --- Comment #1 from Jakub Jelinek --- I'll handle this and look at what other macros are affected.
[Bug target/94812] ppc incorrect mffs-based emulation of mffsl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94812 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2020-04-28 Status|UNCONFIRMED |NEW Known to fail||10.0, 9.3.0 Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Confirmed. On 9 and 10.
[Bug libstdc++/94823] modulo arithmetic bug in random.tcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94823 AK changed: What|Removed |Added CC||hiraditya at msn dot com --- Comment #1 from AK --- Here's the partial stack trace in case it helps ``` in bits/random.tcc:3274:20: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned long' in void std::seed_seq::generate(unsigned int*, unsigned int*) in std::enable_if::value, void>::type __gnu_cxx::simd_fast_mersenne_twister_engine::seed(std::seed_seq&) ext/random.tcc:110 in __gnu_cxx::simd_fast_mersenne_twister_engine::simd_fast_mersenne_twister_engine(std::seed_seq&) ext/random:104 ```
[Bug c/94833] vec_first_match_index does not function as described in its description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94833 --- Comment #1 from Corey Ashford --- When I look at the disassembly, I see it uses vcmpnezb, but maybe it should use vcmpneb instead: int first_match_index = vec_first_match_index(v1, vec_0s); 1504: 07 09 00 10 vcmpnezb v0,v0,v1
[Bug libstdc++/94810] std::cout segmentation fault in __attribute__((constructor)) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #8 from Jonathan Wakely ---
No. The ambiguity only happens if you use the attribute explicitly, as you are
doing.
Just create a global object with a constructor and a destructor, instead of
using functions with __attribute__((constructor)) and
__attribute__((destructor)).
#include
struct X {
X() {
std::cout << "Starting" << std::endl;
}
~X() {
std::cout << "Finishing" << std::endl;
}
};
int main() {
std::cout << "Hello, World!" << std::endl;
}
I'm closing this as invalid, since the attribute is documented to have
unspecified construction order relative to normal globals, which means your
original example is not expected to work.
[Bug c/94833] New: vec_first_match_index does not function as described in its description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94833
Bug ID: 94833
Summary: vec_first_match_index does not function as described
in its description
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cjashfor at linux dot ibm.com
CC: carll at gcc dot gnu.org
Target Milestone: ---
The description in the 64-bit ELF V2 ABI Specification 1.4 says this:
Purpose:
Performs a comparison of equality on each of the corresponding elements of ARG1
and
ARG2, and returns the first position of equality.
Result value:
Returns the element index of the position of the first character match. If no
match, returns
the number of characters as an element count in the vector argument.
Note that it doesn't make any mention of null or EOS characters. By the
description, it ought to compare null characters for equality as well, but it
doesn't. It seems to terminate the comparison when it sees that there's a null
(0x00) in one of the two vector elements. Here's my test case:
#include
#include
int main() {
vector unsigned char v1 = { 0, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40,
0x40, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40 };
vector unsigned char vec_0s = vec_splats((unsigned char)0x0);
int first_match_index = vec_first_match_index(v1, vec_0s);
if (first_match_index != 0) {
printf("Failed: first_match_index should be 0 but it is %d\n",
first_match_index);
} else {
printf("Passed\n");
}
return 0;
}
I compiled it with -mcpu=power9 -maltivec. When the test case is run, it says
this:
Failed: first_match_index should be 0 but it is 16
I don't know whether the description is incomplete or the function isn't
implemented correctly.
[Bug libstdc++/94831] [10 Regression] vector no longer compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94831
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #1 from Jonathan Wakely ---
Here's a testcase that is definitely valid in C++17 and C++20, but fails with
GCC 10:
#include
int main()
{
float i[2];
std::uninitialized_value_construct(&i, &i + 1);
}
The standard says this just uses a new-expression, but we have always
implemented it by a call to _Construct, which now fails in GCC 10.
[Bug c++/94832] New: AVX512 scatter/gather macros lack parentheses when unoptimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94832
Bug ID: 94832
Summary: AVX512 scatter/gather macros lack parentheses when
unoptimized
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at kheafield dot com
Target Milestone: ---
This code behaves differently and produces a warning about void * arithmetic
when compiled without optimization:
#include
void Fail(int *data) {
_mm512_mask_i32scatter_epi32(data - 1, 0x, _mm512_set1_epi32(1),
_mm512_set1_epi32(1), 1);
}
Warning and writes are based at (void*)data - 1:
g++ -mavx512bw example.cc -c -o example.o
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/include/immintrin.h:55,
from example.cc:1:
example.cc: In function ‘void Foo(int*)’:
example.cc:4:37: warning: pointer of type ‘void *’ used in arithmetic
[-Wpointer-arith]
4 | _mm512_mask_i32scatter_epi32(data - 1, 0x, _mm512_set1_epi32(1),
_mm512_set1_epi32(1), 1);
| ^
No warning and writes are based at (void*)(data - 1), the expected behavior:
g++ -mavx512bw example.cc -O3 -c -o example.o
# No output.
If we look at avx512fintrin.h, it becomes clear why:
#ifdef __OPTIMIZE__
/* ... */
extern __inline void
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
_mm512_mask_i32scatter_epi32 (void *__addr, __mmask16 __mask,
__m512i __index, __m512i __v1, int __scale)
{
__builtin_ia32_scattersiv16si (__addr, __mask, (__v16si) __index,
(__v16si) __v1, __scale);
}
/* ... */
#else
/* ... */
#define _mm512_mask_i32scatter_epi32(ADDR, MASK, INDEX, V1, SCALE) \
__builtin_ia32_scattersiv16si ((void *)ADDR, (__mmask16)MASK, \
(__v16si)(__m512i)INDEX, \
(__v16si)(__m512i)V1, (int)SCALE)
/* ... */
#endif
When compiled without optimization, the header uses a macro. And data - 1 is
mapping to (void*)data - 1, producing a warning about type ‘void *’ used in
arithmetic as well as a different address calculation.
Tested on two gcc versions.
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/9.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/9.3.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.3.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.3.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/include/g++-v9
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/9.3.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 9.3.0 p2' --disable-esp --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libada --disable-systemtap
--enable-vtable-verify --enable-lto --without-isl --enable-default-pie
--enable-default-ssp
Thread model: posix
gcc version 9.3.0 (Gentoo 9.3.0 p2)
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8.4.0-1ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx
--enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.4.0 (Ubuntu 8.4.0-1ubuntu1~18.04)
[Bug fortran/94377] Won't compile when deallocating a parameterized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94377 --- Comment #4 from Fred Krogh --- Same error with GNU Fortran (GCC) 10.0.1 20200328 (Red Hat 10.0.1-0.11) Error says internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2830 This one is at a different place in gimplify, but the same error. See comment 2 for the correct code to try.
[Bug libstdc++/94831] [10 Regression] vector no longer compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94831 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2020-04-28 Target Milestone|--- |10.0 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug libstdc++/94831] New: [10 Regression] vector no longer compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94831 Bug ID: 94831 Summary: [10 Regression] vector no longer compiles Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- In r277342 I changed std::_Construct for P0784R7, "More constexpr containers" and the non-void return type means this no longer compiles: #include std::vector v(1); This was never valid in C++98, and in C++11 to C++17 it's undefined (because the pseudo-destructor call in allocator_traits>::destroy is ill-formed for arrays). But for libstdc++ it happened to compile, because we elide the calls to trivial destructors. Since r277342 we impement std::construct_at semantics in std::_Construct which means it returns non-void, but the result of the new-expression for an array type is not convertible to a pointer to the array: /home/jwakely/src/gcc/gcc/libstdc++-v3/include/bits/stl_construct.h:111:31: error: cannot convert 'float*' to 'float (*)[2]' in return 111 | return std::construct_at(__p, std::forward<_Args>(__args)...); | ~^ | | | float* This is arguably OK for C++20 where the specification of std::construct_at is clear, but it's a regression for C++11/14/17. I propose to restore support for vector for c++11/14/17 and gnu++20, so we can at least introduce a period of deprecation before removing the support completely.
[Bug d/94825] libphobos test case failures on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94825 --- Comment #2 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:8b53086ab6a6d0e89d407398c3a126535989f0c1 commit r10-8017-g8b53086ab6a6d0e89d407398c3a126535989f0c1 Author: Iain Buclaw Date: Tue Apr 28 21:42:41 2020 +0200 libphobos: Fix multilib powerpc64 builds Multilibs should not have been split up as two logically different CPU, so at configure time, powerpc64 was being detected, but none of the 32-bit support files were being compiled in. libphobos/ChangeLog: PR d/94825 * configure: Regenerate. * libdruntime/Makefile.am (DRUNTIME_SOURCES_CONFIGURED): Add both switchcontext.S and callwithstack.S if DRUNTIME_CPU_POWERPC. * libdruntime/Makefile.in: Regenerate. * libdruntime/config/powerpc/switchcontext.S: Add !__PPC64__ guards. * libdruntime/config/powerpc64/callwithstack.S: Add __PPC64__ guards. * m4/druntime/cpu.m4 (DRUNTIME_CPU_SOURCES): Define DRUNTIME_CPU_POWER for all powerpc biarchs. Remove DRUNTIME_CPU_POWER64 conditional.
[Bug c++/94830] New: Some concepts diagnostic messages are nondeterministic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94830
Bug ID: 94830
Summary: Some concepts diagnostic messages are nondeterministic
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat testcase.C
template
concept c = __is_same(T, R);
template
requires c
void foo() { }
void bar()
{
foo();
}
$ g++ -std=c++2a testcase.C
testcase.C: In function ‘void bar()’:
testcase.C:10:18: error: use of function ‘void foo() [with T = int; R = char]’
with unsatisfied constraints
10 | foo();
| ^
testcase.C:6:6: note: declared here
6 | void foo() { }
| ^~~
testcase.C:6:6: note: constraints not satisfied
testcase.C: In instantiation of ‘void foo() [with T = int; R = char]’:
testcase.C:10:18: required from here
testcase.C:2:11: required for the satisfaction of ‘c’ [with T = int; R
= char]
testcase.C:2:15: note: ‘int’ is not the same as ‘char’
2 | concept c = __is_same(T, R);
| ^~~
The diagnostic pointing to line 2:11 will on some invocations say "[with T =
int; R = char]" and on other invocations say "[with R = char; T = int]"
[Bug c++/94827] [10 Regression] crash on requires clause in tparam list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94827 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2020-04-28 --- Comment #1 from Nathan Sidwell --- hm, yeah, we're completely unprepared to go inspecting the parm vector during parsing the parameters. Not sure how this worked previously.
[Bug rtl-optimization/94740] ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94740 --- Comment #6 from Segher Boessenkool --- It is of course good to wrap things with CONST whenever possible, but it isn't documented anywhere (afaics) that this would be required, so this is a workaround, not a fix?
[Bug c++/94583] [10 Regression] ICE in get_defaulted_eh_spec, at cp/method.c:2421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94583 --- Comment #6 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:bce54ed494fd0e61f41986e2bdbcfb2d2a3a1cf1 commit r10-8016-gbce54ed494fd0e61f41986e2bdbcfb2d2a3a1cf1 Author: Jason Merrill Date: Tue Apr 28 12:27:27 2020 -0400 c++: Redeclaration of implicit operator== [PR94583] My last patch rejected a namespace-scope declaration of the implicitly-declared friend operator== before the class, but redeclaring it after the class should be OK. gcc/cp/ChangeLog 2020-04-28 Jason Merrill PR c++/94583 * decl.c (use_eh_spec_block): Check nothrow type after DECL_DEFAULTED_FN. * pt.c (maybe_instantiate_noexcept): Call synthesize_method for DECL_MAYBE_DELETED fns here. * decl2.c (mark_used): Not here. * method.c (get_defaulted_eh_spec): Reject DECL_MAYBE_DELETED here.
[Bug analyzer/94816] ICE: Segmentation fault (in ana::region_model::add_region_for_type) since r10-5950-g757bf1dff5e8cee3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94816 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Thanks for filing this. Should be fixed by the above commit.
[Bug c++/94829] New: ICE in poplevel, at cp/decl.c:585
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94829
Bug ID: 94829
Summary: ICE in poplevel, at cp/decl.c:585
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Created attachment 48395
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48395&action=edit
Testcase
g++-10.0.1-alpha20200426 snapshot (g:29f55115583a0dab6cbac749c4f0804fd88e9536)
ICEs when compiling the attached testcase w/ -fcoroutines:
% g++-10.0.1 -fcoroutines -c clang/test/CodeGenCoroutines/coro-lambda.cpp
clang/test/CodeGenCoroutines/coro-lambda.cpp: In instantiation of 'auto
SyncAwait(_AwrT&&) [with _AwrT = suspend_always&]':
clang/test/CodeGenCoroutines/coro-lambda.cpp:50:17: required from here
clang/test/CodeGenCoroutines/coro-lambda.cpp:41:20: error: coroutines require a
traits template; cannot find 'std::coroutine_traits'
41 | try { (void)(co_await A); } catch (...) {}
| ~^~~
clang/test/CodeGenCoroutines/coro-lambda.cpp:41:20: note: perhaps '#include
' is missing
clang/test/CodeGenCoroutines/coro-lambda.cpp:43:26: internal compiler error: in
poplevel, at cp/decl.c:585
43 | Task t = AwaitAsync();
| ^
0x6138a0 poplevel(int, int, int)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/decl.c:585
0xa2ecab do_poplevel(tree_node*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/semantics.c:453
0xa329d9 finish_compound_stmt(tree_node*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/semantics.c:1542
0x9f38c0 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/pt.c:18145
0x9f3f7b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/pt.c:18109
0x9f1312 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/pt.c:17821
0x9f1662 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/pt.c:18140
0x9ee76a instantiate_decl(tree_node*, bool, bool)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/pt.c:25688
0x91fbda maybe_instantiate_decl
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/decl2.c:5370
0x922418 maybe_instantiate_decl
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/tree.h:3402
0x922418 mark_used(tree_node*, int)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/decl2.c:5577
0x875e72 build_over_call
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/call.c:9048
0x87800c build_new_function_call(tree_node*, vec**, int)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/call.c:4599
0xa36734 finish_call_expr(tree_node*, vec**, bool,
bool, int)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/semantics.c:2672
0x9ad191 cp_parser_postfix_expression
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/parser.c:7468
0x98eb69 cp_parser_binary_expression
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/parser.c:9557
0x99081e cp_parser_assignment_expression
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/parser.c:9862
0x990be3 cp_parser_expression
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/parser.c:10030
0x993c38 cp_parser_expression_statement
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/parser.c:11691
0x99f253 cp_parser_statement
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/parser.c:11487
The testcase is unmodified test/CodeGenCoroutines/coro-lambda.cpp from the
clang 10.0.0 testsuite. clang++ 9.0.1 accepts it. I don't really see much
opportunities for reduction here.
[Bug tree-optimization/94828] New: Failure to merge merge-able loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94828
Bug ID: 94828
Summary: Failure to merge merge-able loops
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
void f(int *__restrict a, int *__restrict b, size_t sz)
{
for (int i = 0; i < sz; ++i)
a[i] += b[i];
for (int i = 0; i < sz; ++i)
a[i] += b[i];
}
These two loops could be merged into a single one doing two additions per
iteration. ICC does this transformation, GCC does not.
Also, I'd like to note that from the GCC output, only the first loop is
vectorized, and not the second one.
See https://godbolt.org/z/DfGpSi
[Bug libstdc++/94810] std::cout segmentation fault in __attribute__((constructor)) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810 --- Comment #7 from Geoffrey Casper --- I believe I did misunderstand comment 3. Thanks for your clarification. Do all global objects get marked with the constructor attribute, which leads to the ambiguity?
[Bug c++/94819] [10 Regression] Inherited and constrained constructors are "ambiguous" even if they aren't Pt. 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94819 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-04-28 CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- Confirmed, thanks for the nice testcase. I think the problem lies with how we cache the constraints of an inherited constructor. I am testing the following: --- a/gcc/cp/constraint.cc +++ b/gcc/cp/constraint.cc @@ -2752,7 +2752,7 @@ satisfy_declaration_constraints (tree t, subst_info info) info.in_decl = t; if (info.quiet ()) -if (tree *result = hash_map_safe_get (decl_satisfied_cache, t)) +if (tree *result = hash_map_safe_get (decl_satisfied_cache, saved_t)) return *result; /* Get the normalized constraints. */ @@ -2787,7 +2787,7 @@ satisfy_declaration_constraints (tree t, subst_info info) } if (info.quiet ()) -hash_map_safe_put (decl_satisfied_cache, t, result); +hash_map_safe_put (decl_satisfied_cache, saved_t, result); return result; }
[Bug c++/94827] New: [ICE] [regression] crash on requires clause in tparam list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94827
Bug ID: 94827
Summary: [ICE] [regression] crash on requires clause in tparam
list
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Try the following code with -std=c++2a
template
void foo(T) {}
The result:
:20:44: internal compiler error: tree check: accessed elt 1 of
'tree_vec' with 0 elts in map_arguments, at cp/constraint.cc:553
20 | bool = requires { requires (sizeof(T)==0); } >
|^
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug analyzer/94816] ICE: Segmentation fault (in ana::region_model::add_region_for_type) since r10-5950-g757bf1dff5e8cee3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94816 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:5eae0ac76dcb6aac1d1d6c4edd8852e0035792e4 commit r10-8015-g5eae0ac76dcb6aac1d1d6c4edd8852e0035792e4 Author: David Malcolm Date: Tue Apr 28 10:52:45 2020 -0400 analyzer: fix ICE copying struct [PR 94816] PR analyzer/94816 reports an ICE when attempting to copy a struct containing a field for which add_region_for_type for fails (on an OFFSET_TYPE): the region for the src field comes from make_region_for_unexpected_tree_code which gives it a NULL type, and then the copy calls add_region_for_type which unconditionally dereferences the NULL type. This patch fixes the ICE by checking for NULL types in add_region_for_type. gcc/analyzer/ChangeLog: PR analyzer/94816 * engine.cc (impl_region_model_context::on_unexpected_tree_code): Handle NULL tree. * region-model.cc (region_model::add_region_for_type): Handle NULL type. * region-model.h (test_region_model_context::on_unexpected_tree_code): Handle NULL tree. gcc/testsuite/ChangeLog: PR analyzer/94816 * g++.dg/analyzer/pr94816.C: New test.
[Bug other/94826] New: [10 regression] ICE in gcc.dg/pr94780.c after r10-7999
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94826 Bug ID: 94826 Summary: [10 regression] ICE in gcc.dg/pr94780.c after r10-7999 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- g:9b8e9006bb35641865358e2df4f6b3ae185b239a, r10-7999 spawn -ignore SIGHUP /home3/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home3/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr94780.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O2 -S -o pr94780.s /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr94780.c: In function 'foo': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr94780.c:8:1: internal compiler error: Segmentation fault 0x10b33a33 crash_signal /home/seurer/gcc/git/gcc-test/gcc/toplev.c:328 0x10c32f14 tree_check(tree_node*, char const*, int, char const*, tree_code) /home/seurer/gcc/git/gcc-test/gcc/tree.h:3286 0x10c32f14 convert_nonlocal_reference_op /home/seurer/gcc/git/gcc-test/gcc/tree-nested.c:1064 0x10f5449b walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) /home/seurer/gcc/git/gcc-test/gcc/tree.c:12000 0x1070d9ab walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) /home/seurer/gcc/git/gcc-test/gcc/gimple-walk.c:268 0x1070dd8f walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) /home/seurer/gcc/git/gcc-test/gcc/gimple-walk.c:596 0x1070e147 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) /home/seurer/gcc/git/gcc-test/gcc/gimple-walk.c:51 0x1070dfe3 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) /home/seurer/gcc/git/gcc-test/gcc/gimple-walk.c:605 0x1070e147 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) /home/seurer/gcc/git/gcc-test/gcc/gimple-walk.c:51 0x10c2a0c3 walk_body /home/seurer/gcc/git/gcc-test/gcc/tree-nested.c:713 0x10c2a173 walk_function /home/seurer/gcc/git/gcc-test/gcc/tree-nested.c:724 0x10c2a173 walk_all_functions /home/seurer/gcc/git/gcc-test/gcc/tree-nested.c:789 0x10c369b3 lower_nested_functions(tree_node*) /home/seurer/gcc/git/gcc-test/gcc/tree-nested.c:3551 0x104bbfb3 cgraph_node::analyze() /home/seurer/gcc/git/gcc-test/gcc/cgraphunit.c:676 0x104c0b2b analyze_functions /home/seurer/gcc/git/gcc-test/gcc/cgraphunit.c:1227 0x104c2217 symbol_table::finalize_compilation_unit() /home/seurer/gcc/git/gcc-test/gcc/cgraphunit.c:2974
[Bug other/94825] libphobos test case failures on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94825 Bill Seurer changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #1 from Bill Seurer --- g:1b0cbe05822f349ef8bc32fc1138d2874b2f469c, r10-7970 commit 1b0cbe05822f349ef8bc32fc1138d2874b2f469c Author: Iain Buclaw Date: Sun Apr 26 11:32:57 2020 +0200 libphobos: Add power*-*-linux* as a supported target libphobos/ChangeLog: * configure: Regenerate. * configure.tgt: Add power*-*-linux* as a supported target, only building libdruntime. * m4/druntime/cpu.m4 (DRUNTIME_CPU_SOURCES): Add cases for powerpcle and powerpc64le target cpus.
[Bug rtl-optimization/94804] Failure to elide useless movs in 128-bit addition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94804 --- Comment #4 from Marc Glisse --- (In reply to Gabriel Ravier from comment #3) > Having similar problems with useless movs is from the same non > well-optimized register allocation on function boundaries ? I don't know, but possibly not. I'll shut up because I am not a RA specialist... (and if you expect to see it optimized to bswap64, then obviously it is unrelated to register allocation)
[Bug c++/94819] [10 Regression] Inherited and constrained constructors are "ambiguous" even if they aren't Pt. 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94819
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #2 from Daniel Krügler ---
After removal of any library dependencies:
```c++
template
inline constexpr bool is_same_v = false;
template
inline constexpr bool is_same_v = true;
template
struct alphabet_tuple_base
{
template
requires is_same_v
constexpr alphabet_tuple_base(component_type) {} // commenting out
constexpr works?!
template
requires (!is_same_v)
alphabet_tuple_base(indirect_component_type) {}
};
template
struct structured_rna : alphabet_tuple_base {
using base_type = alphabet_tuple_base;
using base_type::base_type;
};
struct dna4 {};
struct rna4 {};
structured_rna t1{rna4{}}; // commenting out any of these works?!
structured_rna t2{dna4{}}; // commenting out any of these works?!
structured_rna t3{rna4{}}; // commenting out any of these works?!
int main() {}
```
[Bug tree-optimization/84774] [meta-bug] bogus/missing -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774 Bug 84774 depends on bug 94815, which changed state. Bug 94815 Summary: Abusive -Wrestrict warning with sprintf https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94815 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/94815] Abusive -Wrestrict warning with sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94815 Martin Sebor changed: What|Removed |Added Resolution|--- |DUPLICATE Keywords||missed-optimization Blocks||83819 Status|REOPENED|RESOLVED Component|c |middle-end --- Comment #5 from Martin Sebor --- The test case in comment #4 isn't handled yet. Even though the sprintf code has access to the results of the strlen pass computed for prior string built-in function calls and so knows the length of str3, it doesn't expose the lengths of the strings it itself computes to the strlen pass (or track them across statements) yet so it doesn't "know" the length of str2 computed at the prior sprintf statement. When the sprintf pass makes use of attribute alloc_size it will be able to use the array sizes to improve its analysis but as I mentioned in comment #2 this isn't implemented yet either. The effect that we will get once it is can be emulated by replacing buf with a fixed size array (char buf[30]). It doesn't eliminate the warning due to the missing bits above but the output of the -fdump-tree-strlen option confirms that the warning is due to the strlen limitation: pr94815.c:15: sprintf: objsize = 20, fmtstr = "ABC%s" Directive 1 at offset 0: "ABC", length = 3 Result: 3, 3, 3, 3 (3, 3, 3, 3) Directive 2 at offset 3: "%s" Result: 3, 3, 3, 3 (6, 6, 6, 6) Directive 3 at offset 5: "", length = 1 Substituting 6 for return value. pr94815.c:18: sprintf: objsize = 30, fmtstr = "DEF%s" Directive 1 at offset 0: "DEF", length = 3 Result: 3, 3, 3, 3 (3, 3, 3, 3) Directive 2 at offset 3: "%s" Result: 0, 19, 19, 19 (3, 22, 22, 22) <<< str2 length assumed to be up to 19 Directive 3 at offset 5: "", length = 1 PR 92813 tracks the enhancement to make the string length information computed by sprintf across statements (via the strlen pass). *** This bug has been marked as a duplicate of bug 92813 *** Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 [Bug 83819] [meta-bug] missing strlen optimizations
[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 Bug 83819 depends on bug 94815, which changed state. Bug 94815 Summary: Abusive -Wrestrict warning with sprintf https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94815 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/92813] sprintf result not used by strlen pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92813 Martin Sebor changed: What|Removed |Added CC||vincent.riviere at freesbee dot fr --- Comment #2 from Martin Sebor --- *** Bug 94815 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/90591] Avoid unnecessary data transfer out of OMP construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90591
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #4 from Tobias Burnus ---
(In reply to Jakub Jelinek from comment #1)
> We want to add some attribute(s) on the structure types used to pass
> information in and out (or in the fields), and have some specialized IPA
> optimization that tries to optimize such cases.
I concur - and had even today a hello-world example for the copy-in example:
double x = 0.5;
#pragma omp target
printf("%f\n", sin(x);
could be compile-time optimized the sin() call to a constant but doesn't.
[Bug other/94825] New: libphobos test case failures on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94825 Bug ID: 94825 Summary: libphobos test case failures on powerpc64 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- A bunch of the newly activated libphobos test cases fail on powerpc64. I saw this on both BE and LE. FAIL: libphobos.allocations/tls_gc_integration.d execution test FAIL: libphobos.druntime/core/demangle.d execution test FAIL: libphobos.druntime/core/internal/convert.d (test for excess errors) FAIL: libphobos.druntime/core/memory.d execution test FAIL: libphobos.druntime/core/thread.d execution test FAIL: libphobos.druntime/gc/impl/conservative/gc.d execution test FAIL: libphobos.druntime/object.d execution test FAIL: libphobos.druntime/rt/lifetime.d execution test FAIL: libphobos.druntime/rt/util/container/treap.d execution test FAIL: libphobos.druntime_shared/core/demangle.d execution test FAIL: libphobos.druntime_shared/core/internal/convert.d (test for excess errors) FAIL: libphobos.druntime_shared/core/memory.d execution test FAIL: libphobos.druntime_shared/core/thread.d execution test FAIL: libphobos.druntime_shared/gc/impl/conservative/gc.d execution test FAIL: libphobos.druntime_shared/object.d execution test FAIL: libphobos.druntime_shared/rt/lifetime.d execution test FAIL: libphobos.druntime_shared/rt/util/container/treap.d execution test FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test FAIL: libphobos.shared/host.c -ldl -pthread execution test FAIL: libphobos.shared/link.d -I/home/seurer/gcc/git/gcc-test/libphobos/testsuite/libphobos.shared lib.so -shared-libphobos execution test FAIL: libphobos.shared/linkD.c lib.so -ldl -pthread execution test FAIL: libphobos.shared/linkDR.c -shared-libphobos -ldl -pthread execution test FAIL: libphobos.shared/link_linkdep.d -I/home/seurer/gcc/git/gcc-test/libphobosestsuite/libphobos.shared liblinkdep.so lib.so -shared-libphobos execution test FAIL: libphobos.shared/load.d -shared-libphobos -ldl execution test FAIL: libphobos.shared/loadDR.c -ldl -pthread -g execution test FAIL: libphobos.shared/load_linkdep.d -shared-libphobos -ldl execution test FAIL: libphobos.shared/load_loaddep.d -shared-libphobos -ldl execution test FAIL: libphobos.thread/fiber_guard_page.d execution test FAIL: libphobos.thread/tlsgc_sections.d execution test
[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956
--- Comment #16 from Paul Thomas ---
Hi Thomas,
I am sorry that you are having such a hassle with this - perhaps this helps?
>
> I assume that the span is not used correctly in the
> function.
Yes, that is correct. Within 'foo', we have
a.0 = (integer(kind=4)[0:D.3967] * restrict) a->data;
and the sum is inlined as:
while (1)
{
if (S.10 > D.3961) goto L.1;
val.9 = (*a.0)[S.10 * D.3963 + D.3960] + val.9;
S.10 = S.10 + 1;
}
L.1:;
so that the sum becomes: sum(r(1:500)%u) + sum(r(1:500)%v).
This fixes the problem at the expense of more temporaries but regtests fine:
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index a9fa03ad153..8ca2b9bb3cb 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -1098,10 +1098,14 @@ is_subref_array (gfc_expr * e)
bool seen_array;
gfc_symbol *sym;
- if (e->expr_type != EXPR_VARIABLE)
-return false;
- sym = e->symtree->n.sym;
+ if (e->expr_type == EXPR_VARIABLE)
+sym = e->symtree->n.sym;
+ else if (e->expr_type == EXPR_FUNCTION
+ && gfc_expr_attr (e).subref_array_pointer)
+return true;
+ else
+return false;
if (sym->attr.subref_array_pointer)
return true;
@@ -4242,7 +4246,7 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr
*rvalue,
if (rvalue->expr_type == EXPR_NULL)
return true;
- if (rvalue->expr_type == EXPR_VARIABLE && is_subref_array (rvalue))
+ if (is_subref_array (rvalue))
lvalue->symtree->n.sym->attr.subref_array_pointer = 1;
attr = gfc_expr_attr (rvalue);
Paul
[Bug libstdc++/94810] std::cout segmentation fault in __attribute__((constructor)) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810 --- Comment #6 from Jonathan Wakely --- Maybe you misunderstood comment 3, the construction order is only unspecified when you use __attribute__((constructor)). If you just create normal global objects using normal C++ the order within a single translation unit is completely specified, and your program would work as expected. So again, why can't you just use standard C++ instead of attributes that aren't needed in C++, and proposing non-conforming changes to the compiler?
[Bug libstdc++/94810] std::cout segmentation fault in __attribute__((constructor)) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810 --- Comment #5 from Jonathan Wakely --- I don't see how that could conform to the standard's requirements.
[Bug libstdc++/94811] Please make make_tuple noexcept when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94811 Jonathan Wakely changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #5 from Jonathan Wakely --- OK thanks
[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 Bug 89180 depends on bug 79585, which changed state. Bug 79585 Summary: spurious -Wunused-variable on a pointer with attribute unused in function template https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79585 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/90750] [9 Regression] ICE in cp_default_conversion, at cp/typeck.c:2162
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90750 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed for 9.4/10.
[Bug c++/79585] spurious -Wunused-variable on a pointer with attribute unused in function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79585 Jason Merrill changed: What|Removed |Added Target Milestone|10.0|9.4 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed for 9.4/10.
[Bug c++/79585] spurious -Wunused-variable on a pointer with attribute unused in function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79585 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:aa988998be8f85334665a6b049d5d9139408c250 commit r9-8550-gaa988998be8f85334665a6b049d5d9139408c250 Author: Jason Merrill Date: Mon Jan 27 05:45:01 2020 -0500 c++: Avoid ICE with dependent attribute on type. We previously happened to accept this testcase, but never actually did anything useful with the attribute. The patch for PR86379 stopped using TREE_TYPE as USING_DECL_SCOPE, so 'using A::b' no longer had TREE_TYPE set, so the language-independent decl_attributes started crashing on it. GNU attributes are more flexible in their placement than C++11 attributes, so if we encounter a dependent GNU attribute that syntactically appertains to a type rather than the declaration as a whole, move it to the declaration; that's almost certainly what the user meant, anyway. gcc/cp/ChangeLog 2020-01-27 Jason Merrill PR c++/90750 PR c++/79585 * decl.c (grokdeclarator): Move dependent attribute to decl. * decl2.c (splice_template_attributes): No longer static.
[Bug c++/90750] [9 Regression] ICE in cp_default_conversion, at cp/typeck.c:2162
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90750 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:aa988998be8f85334665a6b049d5d9139408c250 commit r9-8550-gaa988998be8f85334665a6b049d5d9139408c250 Author: Jason Merrill Date: Mon Jan 27 05:45:01 2020 -0500 c++: Avoid ICE with dependent attribute on type. We previously happened to accept this testcase, but never actually did anything useful with the attribute. The patch for PR86379 stopped using TREE_TYPE as USING_DECL_SCOPE, so 'using A::b' no longer had TREE_TYPE set, so the language-independent decl_attributes started crashing on it. GNU attributes are more flexible in their placement than C++11 attributes, so if we encounter a dependent GNU attribute that syntactically appertains to a type rather than the declaration as a whole, move it to the declaration; that's almost certainly what the user meant, anyway. gcc/cp/ChangeLog 2020-01-27 Jason Merrill PR c++/90750 PR c++/79585 * decl.c (grokdeclarator): Move dependent attribute to decl. * decl2.c (splice_template_attributes): No longer static.
[Bug tree-optimization/94824] New: Failure to optimize with __builtin_bswap32 as well as with a function recognized as such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94824
Bug ID: 94824
Summary: Failure to optimize with __builtin_bswap32 as well as
with a function recognized as such
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
uint32_t swap32(uint32_t x)
{
return ((x << 24) | ((x << 8) & 0x00FF) | ((x >> 8) & 0xFF00) | (x
>> 24));
}
uint64_t swap64v1(uint64_t x)
{
uint64_t a = __builtin_bswap32(x);
x >>= 32;
a <<= 32;
return __builtin_bswap32(x) | a;
}
uint64_t swap64v2(uint64_t x)
{
uint64_t a = swap32(x);
x >>= 32;
a <<= 32;
return swap32(x) | a;
}
swap64v1 and swap64v2 are identical, since bswap32 is equivalent to
__builtin_bswap32. However, only swap64v2 is optimized to __builtin_bswap64.
swap64v1 is compiled to this by gcc -O3 :
swap64v1(unsigned long):
mov rdx, rdi
mov eax, edi
shr rdx, 32
bswap eax
sal rax, 32
bswap edx
mov edi, edx
or rax, rdi
ret
And swap64v2 gives this :
swap64v2(unsigned long):
mov rax, rdi
bswap rax
ret
[Bug target/94743] IRQ handler doesn't save scratch VFP registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743 --- Comment #7 from Richard Earnshaw --- well, __aeabi_memcpy is required not to clobber the FP state. Sadly, GCC does not know about it...
