[Bug c++/94835] ICE in vague_linkage_p, at cp/decl2.c:2041
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94835 --- Comment #4 from Stephen Casner --- I verified that the compilation of chrono:544 is the first time in the build that the failing assert is executed, so that likely implies that the problem is general and not specific to the particular source code. The only mentions of COMDAT in the pdp11 backend are the macros #define TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT hook_bool_void_false #define TARGET_CXX_LIBRARY_RTTI_COMDAT hook_bool_void_false These are in the direction that make the assert true rather than false, so changing those to the default hook_bool_void_true wouldn't help (and would presumably cause something else to fail). I'm way out of my league here, so any suggestions would be appreciated.
[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 --- Comment #5 from Jason Merrill --- Created attachment 48413 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48413=edit diagnostic patch diagnostic improvement, waiting for gcc 11.
[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 --- Comment #4 from Jason Merrill --- Created attachment 48412 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48412=edit fix fix, waiting for gcc 11
[Bug c++/94867] New: New (since gcc 8) false positive with -Wnull-dereference in very simple code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94867
Bug ID: 94867
Summary: New (since gcc 8) false positive with
-Wnull-dereference in very simple code
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
Consider:
% cat -n gcc-null-deref.cpp
1 #include
2
3 void test()
4 {
5 std::vector p;
6 p.push_back(1);
7 std::vector q(p.size());
8 q[0] = p[0];
9 }
% g++-9 -O2 -c gcc-null-deref.cpp -Wnull-dereference
gcc-null-deref.cpp: In function ‘void test()’:
gcc-null-deref.cpp:8:10: warning: potential null pointer dereference
[-Wnull-dereference]
8 | q[0] = p[0];
This is with gcc version 9.3.0 (Debian 9.3.0-11). It doesn't happen with g++-8
but does still happen with the latest version available in Debian which is gcc
version 10.0.1 20200418 (experimental) [master revision
27c171775ab:4c277008be0:c5bac7d127f288fd2f8a1f15c3f30da5903141c6] (Debian
10-20200418-1)
FWIW it looks like -Wnull-dereference really doesn't like push_back() for
whatever reason. Even initializing the vector with fixed size doesn't help to
make the warning go away -- however doing this _and_ removing push_back() does
help.
[Bug target/94866] New: Failure to optimize pinsrq of 0 with index 1 into movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94866
Bug ID: 94866
Summary: Failure to optimize pinsrq of 0 with index 1 into movq
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
typedef int64_t v2di __attribute__((vector_size(16)));
typedef int32_t v2si __attribute__((vector_size(8)));
v2di _mm_move_epi64(v2di a)
{
return v2di{a[0], 0LL};
}
LLVM with `-O3 -msse4.1` compiles this to this :
_mm_move_epi64(long __vector(2)): # @_mm_move_epi64(long __vector(2))
movq xmm0, xmm0 # xmm0 = xmm0[0],zero
ret
GCC gives :
_mm_move_epi64(long __vector(2)):
xor eax, eax
pinsrq xmm0, rax, 1
ret
GCC's output seems like it would naturally be much slower, so unless there is
something seriously messed up with x86 chips that I've missed, LLVM's version
should be faster
[Bug rtl-optimization/94863] Failure to use blendps over mov when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94863 --- Comment #1 from Gabriel Ravier --- Note: The given outputs for LLVM and GCC are when compiling with `-O3 -msse4.1`
[Bug tree-optimization/94864] Failure to combine vunpckhpd+movsd into single vunpckhpd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94864 --- Comment #1 from Gabriel Ravier --- Note : The compilation options were `-O3 -mavx`
[Bug tree-optimization/94865] New: Failure to combine unpckhpd+unpcklpd into blendps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94865
Bug ID: 94865
Summary: Failure to combine unpckhpd+unpcklpd into blendps
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: ---
typedef double v2df __attribute__((vector_size(16)));
v2df move_sd(v2df a, v2df b)
{
v2df result = a;
result[1] = b[1];
return result;
}
With `-O3 -msse4.1`, LLVM gives :
move_sd(double __vector(2), double __vector(2)): # @move_sd(double __vector(2),
double __vector(2))
blendps xmm0, xmm1, 12 # xmm0 = xmm0[0,1],xmm1[2,3]
ret
GCC gives :
move_sd(double __vector(2), double __vector(2)):
unpckhpd xmm1, xmm1
unpcklpd xmm0, xmm1
ret
[Bug tree-optimization/94864] New: Failure to combine vunpckhpd+movsd into single vunpckhpd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94864
Bug ID: 94864
Summary: Failure to combine vunpckhpd+movsd into single
vunpckhpd
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: ---
typedef double v2df __attribute__((vector_size(16)));
v2df move_sd(v2df a, v2df b)
{
v2df result = a;
result[0] = b[1];
return result;
}
LLVM outputs this :
move_sd(double __vector(2), double __vector(2)): # @move_sd(double __vector(2),
double __vector(2))
vunpckhpd xmm0, xmm1, xmm0 # xmm0 = xmm1[1],xmm0[1]
ret
GCC outputs this :
move_sd(double __vector(2), double __vector(2)):
vunpckhpd xmm1, xmm1, xmm1
vmovsd xmm0, xmm0, xmm1
ret
[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 #34 from Jürgen Reuter --- Created attachment 48411 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48411=edit Final reproducer, less than 300 lines ;) This one should be sufficient. No further files or input is necessary, it seems that the problem lies in the combination of inheriting derived types, allocatables and pointers. All the fun.
[Bug rtl-optimization/94863] New: Failure to use blendps over mov when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94863
Bug ID: 94863
Summary: Failure to use blendps over mov when possible
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: ---
typedef double v2df __attribute__((vector_size(16)));
v2df move_sd(v2df a, v2df b)
{
v2df result = a;
result[0] = b[0];
return result;
}
LLVM -O3 compiles this as such :
move_sd(double __vector(2), double __vector(2)): # @move_sd(double __vector(2),
double __vector(2))
blendps xmm0, xmm1, 3 # xmm0 = xmm1[0,1],xmm0[2,3]
ret
GCC gives this :
move_sd(double __vector(2), double __vector(2)):
movsd xmm0, xmm1
ret
Using `blendps` here should be a worthy tradeoff. Here is a table of
throughputs for various CPU architectures formatted as "arch-name:
blendps-throughput, movsd-throughput" :
Wolfdale: 1, 0.33
Nehalem: 1, 1
Westmere: 1, 1
Sandy Bridge: 0.5, 1
Ivy Bridge: 0.5, 1
Haswell: 0.33, 1
Broadwell: 0.33, 1
Skylake: 0.33, 1
Skylake-X: 0.33, 1
Kaby Lake: 0.33, 1
Coffee Lake: 0.33, 1
Cannon Lake: 0.33, 0.33
Ice Lake: 0.33, 0.33
Zen+: 0.5, 0.25
Zen 2: 0.33, 0.25
Unless there is an important factor other than thoughput that could affect
this, this should improve performance or keep it identical on every
architecture except Zen+
[Bug rtl-optimization/94861] Don't make undefined values 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94861 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Component|tree-optimization |rtl-optimization Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- GCC does this at the RTL level to make dataflow easy to process; RTL is not a SSA. This has been since at least GCC 4.3.0.
[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 Peter Bergner changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-April/5 ||44894.html --- Comment #7 from Peter Bergner --- Richard has a much better patch which we're both testing.
[Bug c/94842] [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 --- Comment #3 from joseph at codesourcery dot com --- Side-effects in the array sizes of variably modified parameters are valid and occur on entry to the function. I don't think being a nested function should make any difference there. (gcc.dg/atomic/pr65345-4.c has corresponding tests to this bug for the case of arguments to non-nested functions.)
[Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859
Thomas Schwinge changed:
What|Removed |Added
Keywords||openmp
Last reconfirmed|2019-06-20 00:00:00 |2020-4-29
--- Comment #3 from Thomas Schwinge ---
I've come across this again. And again, I'm just documenting this here, don't
have bandwidth right now to figure out what's going on.
(In reply to Thomas Schwinge from comment #0)
> I noticed the following (with OpenACC, not yet tried to reproduce with
> OpenMP 'target').
Now also reproduced for OpenMP.
> Is there something wrong, or can that behavior be
> explained?
>
> Only 'sizeof array' appears in the offloaded region, yet for 'target { c &&
> { ! lp64 } }' (only!), the gimplifier also creates a mapping for the array
> itself.
Now also reproduced on x86_64-pc-linux-gnu with default '-m64' instead of
'-m32'.
(In reply to Thomas Schwinge from comment #2)
> Experimenting on x86_64-pc-linux-gnu with '-m32', this depends on the data
> type used for 'array_so'. If I change 'uint32_t' to 'unsigned int', I see
> the same strange behavior. If however I change it to 'unsigned long', the
> issue goes away, as it does for 'unsigned short', for example. The code
> inside the region is the same (aside from some type casting); in particular
> there aren't any 'array' references.
Similarly, with test case:
#include
static void
vla (int array_li)
{
_Complex double array[array_li];
TYPE array_so;
#pragma omp target \
map(from:array_so)
{
array_so = sizeof array;
}
if (array_so != sizeof array)
__builtin_abort ();
}
... compiled with '-fopenmp -O0 -fdump-tree-gimple -DTYPE=int64_t', we get:
#pragma omp target num_teams(1) thread_limit(0) map(from:array_so [len: 8])
firstprivate(array_li.0)
{
sizetype D.2157;
sizetype D.2158;
long int array_so.2;
D.2157 = (sizetype) array_li.0;
D.2158 = D.2157 * 16;
array_so.2 = (long int) D.2158;
array_so = array_so.2;
}
..., but compiled with '-fopenmp -O0 -fdump-tree-gimple -DTYPE=uint64_t', we
get:
#pragma omp target num_teams(1) thread_limit(0) map(from:array_so [len: 8])
firstprivate(array_li.0) map(tofrom:(*array.1) [len: D.2153])
map(firstprivate:array [pointer assign, bias: 0])
{
sizetype D.2157;
sizetype array_so.2;
D.2157 = (sizetype) array_li.0;
array_so.2 = D.2157 * 16;
array_so = array_so.2;
}
..., that is, in the latter case, the 'array' itself gets mapped additionally,
even though unused inside the region.
[Bug target/94850] Failure to optimize operation corresponding to shrd to shrd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94850 --- Comment #3 from Segher Boessenkool --- Did combine try combining four insns here? If not, would it have helped?
[Bug fortran/93366] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93366 --- Comment #4 from Steve Kargl --- On Wed, Apr 29, 2020 at 08:57:44PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93366 > > anlauf at gcc dot gnu.org changed: > >What|Removed |Added > > CC||anlauf at gcc dot gnu.org > > --- Comment #3 from anlauf at gcc dot gnu.org --- > (In reply to kargl from comment #2) > > patch against last SVN revision. > Steve, > > do you still care? > It is not that I don't care. It is that I no longer have an ability to commit patches or checkout top-of-tree. The recent io.c discuss that I participated in shows that top-of-tree and svn r280157 have started to diverge substantially. So, my time is done. It is time for a younger generation to step up.
[Bug c++/94862] New: [concepts] Extraneous/wrong template parameters printed in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94862
Bug ID: 94862
Summary: [concepts] Extraneous/wrong template parameters
printed in diagnostic
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
struct remove_reference
{ using type = R; };
template
using remove_reference_t = remove_reference::type;
template
inline constexpr bool blah = false;
template
requires blah>
void foo(remove_reference_t = {}) { }
void bar() { foo (); }
$ g++ -std=c++2a testcase.C
testcase.C: In function ‘void bar()’:
testcase.C:15:24: error: use of function ‘void foo(remove_reference_t) [with
T = int; remove_reference_t = int]’ with unsatisfied constraints
15 | void bar() { foo (); }
|^
testcase.C:13:8: note: declared here
13 | void foo(remove_reference_t = {}) { }
|^~~
testcase.C:13:8: note: constraints not satisfied
testcase.C: In instantiation of ‘void foo(remove_reference_t) [with T = int;
remove_reference_t = int]’:
testcase.C:15:24: required from here
testcase.C:13:8: required by the constraints of ‘template requires
blah::type> void foo(remove_reference_t)’
testcase.C:12:12: note: the expression ‘blah::type> [with R = int; T = int]’ evaluated to ‘false’
12 | requires blah>
|^~~
We pretty print the constraint
blah>
with the alias template specialization stripped:
blah::type>
but doing so introduces the unrelated template parameter 'R' from the
definition of the alias template remove_reference.
So it seems it would be better to not strip alias template specializations when
pretty printing constraints. It would also be more consistent, since we don't
strip them when printing e.g. function parameter types.
[Bug target/94860] Failure to recognize bzhi pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94860 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement Component|rtl-optimization|target Depends on||93346 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93346 [Bug 93346] gcc does not generate BZHI
[Bug fortran/93366] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93366 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #2) > patch against last SVN revision. Steve, do you still care?
[Bug tree-optimization/94861] New: Don't make undefined values 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94861
Bug ID: 94861
Summary: Don't make undefined values 0
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 = x;
return x;
}
LLVM compiles this to a return instruction, not bothering to initialize the
result register as its value is undefined. GCC instead does `return 0` for
this.
[Bug fortran/94246] [9 Regression] valgrind error for ./gfortran.dg/bessel_5.f90 since r9-1566-g87c789f1c0b2df41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||10.0 Summary|[9/10 Regression] valgrind |[9 Regression] valgrind |error for |error for |./gfortran.dg/bessel_5.f90 |./gfortran.dg/bessel_5.f90 |since |since |r9-1566-g87c789f1c0b2df41 |r9-1566-g87c789f1c0b2df41 Known to fail|10.0| --- Comment #12 from anlauf at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #11) > This issue was solved for GCC 10 = mainline by the following commit. > > commit r10-7444-g7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65 Thus marking as 9 regression.
[Bug rtl-optimization/94860] Failure to recognize bzhi pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94860 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- PR93346 contains a different pattern that GCC 10 now matches as bzhi.
[Bug fortran/94397] [9/10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to markeggleston from comment #6) > Thanks Steve. Should've tried your patch earlier, it is much simpler than > mine and I've verified that it works. There was a nagging feeling that my > solution was incomplete. I'm happy to add test cases to your patch and send > it upstream for approval. Any progress?
[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855 --- Comment #8 from Jonathan Wakely --- That's one possible reading, but I don't think the text you quote is precise enough to say that reading is definitely correct or not. If that is what it says, it might be unintentional. That paragraph is hardly a paragon of precision. The current wording was added by https://wg21.link/lwg456 to address the problem that the original wording didn't reflect reality and was effectively unimplementable for some vendors. I see nothing in 456 that implies your reading was intended (and nothing impying it wasn't). It doesn't really make any difference anyway, since I already plan to change libstdc++ to resolve the original problem described above.
[Bug target/94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:48e54fea7ba4a7cb7b3d1505951383120220e394
commit r10-8057-g48e54fea7ba4a7cb7b3d1505951383120220e394
Author: Jakub Jelinek
Date: Wed Apr 29 22:38:01 2020 +0200
s390: Fix up -Wpsabi diagnostics + [[no_unique_address]] empty member fix
[PR94704]
So, based on the yesterday's discussions, similarly to powerpc64le-linux
I've done some testing for s390x-linux too.
First of all, I found a bug in my patch from yesterday, it was printing
the wrong type like 'double' etc. rather than the class that contained such
the element. Fix below.
For s390x-linux, I was using
struct X { };
struct Y { int : 0; };
struct Z { int : 0; Y y; };
struct U : public X { X q; };
struct A { double a; };
struct B : public X { double a; };
struct C : public Y { double a; };
struct D : public Z { double a; };
struct E : public U { double a; };
struct F { [[no_unique_address]] X x; double a; };
struct G { [[no_unique_address]] Y y; double a; };
struct H { [[no_unique_address]] Z z; double a; };
struct I { [[no_unique_address]] U u; double a; };
struct J { double a; [[no_unique_address]] X x; };
struct K { double a; [[no_unique_address]] Y y; };
struct L { double a; [[no_unique_address]] Z z; };
struct M { double a; [[no_unique_address]] U u; };
#define T(S, s) extern S s; extern void foo##s (S); int bar##s () { foo##s
(s); return 0; }
T (A, a)
T (B, b)
T (C, c)
T (D, d)
T (E, e)
T (F, f)
T (G, g)
T (H, h)
T (I, i)
T (J, j)
T (K, k)
T (L, l)
T (M, m)
as testcase and looking for "\tld\t%f0,".
While g++ 9 with -std=c++17 used to pass in fpr just
A, g++ 9 -std=c++14, as well as current trunk -std=c++14 & 17
and clang++ from today -std=c++14 & 17 all pass A, B, C
in fpr and nothing else. The intent stated by Jason seems to be
that A, B, C, F, G, J, K should all be passed in fpr.
Attached are two (updated) versions of the patch on top of the
powerpc+middle-end patch just posted.
The first one emits two separate -Wpsabi warnings like powerpc, one for
the -std=c++14 vs. -std=c++17 ABI difference and one for GCC 9 vs. 10
[[no_unique_address]] passing changes, the other one is silent about the
second case.
2020-04-29 Jakub Jelinek
PR target/94704
* config/s390/s390.c (s390_function_arg_vector,
s390_function_arg_float): Use DECL_FIELD_ABI_IGNORED instead of
cxx17_empty_base_field_p. In -Wpsabi diagnostics use the type
passed to the function rather than the type of the single element.
Rename cxx17_empty_base_seen variable to empty_base_seen, change
type to int, and adjust diagnostics depending on if the field
has [[no_unique_attribute]] or not.
* g++.target/s390/s390.exp: New file.
* g++.target/s390/pr94704-1.C: New test.
* g++.target/s390/pr94704-2.C: New test.
* g++.target/s390/pr94704-3.C: New test.
* g++.target/s390/pr94704-4.C: New test.
[Bug fortran/93581] [9 Regression] ICE in gfc_get_dataptr_offset, at fortran/trans-array.c:6951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93581 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[9/10 Regression] ICE in|[9 Regression] ICE in |gfc_get_dataptr_offset, at |gfc_get_dataptr_offset, at |fortran/trans-array.c:6951 |fortran/trans-array.c:6951 --- Comment #8 from anlauf at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #7) > And committed as r10-7081-g9de42a8e995451cb13dceb3970ae23ff88240bff > [As far as I could see, it was not yet backported to GCC 9.] Thus marking a 9 regression.
[Bug rtl-optimization/94860] New: Failure to recognize bzhi pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94860
Bug ID: 94860
Summary: Failure to recognize bzhi pattern
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: ---
uint32_t bzhi32(uint32_t x, uint32_t y)
{
return ((x << (32 - y)) >> (32 - y));
}
LLVM with -O3 -mbmi2 optimizes this to :
bzhi32(unsigned int, unsigned int): # @bzhi32(unsigned int, unsigned int)
bzhi eax, edi, esi
ret
GCC outputs this :
bzhi32(unsigned int, unsigned int):
mov eax, 32
sub eax, esi
shlx edi, edi, eax
shrx eax, edi, eax
ret
It should be optimized down to bzhi.
This optimization can be applied to :
- x86-64 (with bzhi)
- i686 (with bzhi)
- AMDGCN (with v_bfe_u32)
[Bug ipa/94856] [10 Regression] ICE: Segmentation fault (in clone_of_p); or ICE: verify_cgraph_node failed (error: edge points to wrong declaration) since r10-4944-g1e83bd7003e03160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94856 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||jamborm at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #2 from Martin Liška --- I can take a look tomorrow.
[Bug ipa/94856] [10 Regression] ICE: Segmentation fault (in clone_of_p); or ICE: verify_cgraph_node failed (error: edge points to wrong declaration) since r10-4944-g1e83bd7003e03160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94856 Martin Liška changed: What|Removed |Added Known to work||9.3.0 Summary|[10 Regression] ICE:|[10 Regression] ICE: |Segmentation fault (in |Segmentation fault (in |clone_of_p); or ICE:|clone_of_p); or ICE: |verify_cgraph_node failed |verify_cgraph_node failed |(error: edge points to |(error: edge points to |wrong declaration) |wrong declaration) since ||r10-4944-g1e83bd7003e03160 Last reconfirmed||2020-4-29 CC||hubicka at gcc dot gnu.org Known to fail||10.0 Target Milestone|--- |10.0 --- Comment #1 from Martin Liška --- Started with r10-4944-g1e83bd7003e03160.
[Bug analyzer/94858] False report of memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94858 Andrew Pinski changed: What|Removed |Added Depends on||94839 --- Comment #1 from Andrew Pinski --- I think this is an almost exact dup of bug 94839 (which I filed yesterday). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94839 [Bug 94839] False positive with -fanalyzer and direct field assignment from calloc
[Bug middle-end/94855] provide an option to initialize automatic variable for security purpose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94855 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 87210. *** This bug has been marked as a duplicate of bug 87210 ***
[Bug c/87210] [RFE] introduce build time options to zero initialize automatic stack variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210 Andrew Pinski changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #5 from Andrew Pinski --- *** Bug 94855 has been marked as a duplicate of this bug. ***
[Bug c/94859] zero-length bit fields conflict with standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94859 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jakub Jelinek --- int is not the declarator, but declaration-specifiers. What the standard says is that int b : 0; is invalid.
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 Thomas Koenig changed: What|Removed |Added Status|WAITING |NEW --- Comment #33 from Thomas Koenig --- So, the first error in your reduced test case is ==8972== Invalid free() / delete / delete[] / realloc() ==8972==at 0x4C2F3B9: free (vg_replace_malloc.c:540) ==8972==by 0x5B2D05: __simulations_uti_MOD_simulations_10 (main_ut.f90:26224) ==8972==by 0x5B494E: MAIN__ (main_ut.f90:26298) ==8972==by 0x5B49BC: main (main_ut.f90:26288) ==8972== Address 0x7ed0510 is 0 bytes inside a block of size 8 free'd ==8972==at 0x4C2F3B9: free (vg_replace_malloc.c:540) ==8972==by 0x5B06F9: __simulations_uti_MOD_simulations_10 (main_ut.f90:26263) ==8972==by 0x5B494E: MAIN__ (main_ut.f90:26298) ==8972==by 0x5B49BC: main (main_ut.f90:26288) ==8972== Block was alloc'd at ==8972==at 0x4C2E221: malloc (vg_replace_malloc.c:309) ==8972==by 0x57D64E: __rt_data_MOD_rt_data_activate (main_ut.f90:24161) ==8972==by 0x5AFED1: __simulations_uti_MOD_simulations_10 (main_ut.f90:26250) ==8972==by 0x5B494E: MAIN__ (main_ut.f90:26298) ==8972==by 0x5B49BC: main (main_ut.f90:26288) where the invalid free is given in the line type(rt_data_t), dimension(1), target :: alt_env and the first one in call simulation%init ([procname1], .true., .true., global, alt_env=alt_env) type(rt_data_t) has a finalizer, rt_global_data_final. Hm, not tonight, but this is something to go on (I think).
[Bug c/94859] zero-length bit fields conflict with standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94859
--- Comment #1 from doug mcilroy ---
gcc accepts
struct X {int a; int :0;} x;
and rejects
struct Y {int a; :0;} y;
in conflict with the final sentence in this quote from the C standard, Section
6.7.2.1, Structure and union specifiers, paragraph #4:
"The expression that specifies the width of a bit-field shall be an integer
constant expression with a nonnegative value that does not exceed the width of
an object of the type that would be specified were the colon and expression
omitted. If the value is zero, the declaration shall have no declarator."
See also Section 3.14 memory location, paragraph #4 EXAMPLE.
[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855 --- Comment #7 from James Y Knight --- Ugh, GCC doesn't wrap quoted text? Re-posting the quote from http://eel.is/c++draft/headers#5 without a quote marker... """ Except as noted in [library] through [thread] and [depr], the contents of each header cname is the same as that of the corresponding header name.h as specified in the C standard library. In the C++ standard library, however, the declarations (except for names which are defined as macros in C) are within namespace scope of the namespace std. It is unspecified whether these names (including any overloads added in [support] through [thread] and [depr]) are first declared within the global namespace scope and are then injected into namespace std by explicit using-declarations. """
[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855 --- Comment #6 from James Y Knight --- Someone has pointed out to me that the standard actually says "name", which I had internalized as meaning "declaration", but it doesn't. This arguably does make the GCC implementation non-compliant with the spec. >From http://eel.is/c++draft/headers#5 > Except as noted in [library] through [thread] and [depr], the contents of > each header cname is the same as that of the corresponding header name.h as > specified in the C standard library. In the C++ standard library, however, > the declarations (except for names which are defined as macros in C) are > within namespace scope of the namespace std. It is unspecified whether these > names (including any overloads added in [support] through [thread] and > [depr]) are first declared within the global namespace scope and are then > injected into namespace std by explicit using-declarations. I think that text implies that all of the overloads of a particular name must consistently either be defined in the global namespace (and then imported into std with a using-declaration) or defined in the std namespace.
[Bug c/94859] New: zero-length bit fields conflict with standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94859 Bug ID: 94859 Summary: zero-length bit fields conflict with standard Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: doug at cs dot dartmouth.edu Target Milestone: ---
[Bug target/94852] -ffloat-store on x64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94852 --- Comment #6 from Ivan Sorokin --- (In reply to Richard Biener from comment #1) > @item -ffloat-store > @opindex ffloat-store > Do not store floating-point variables in registers, and inhibit other > options that might change whether a floating-point value is taken from a > register or memory. > > I think it does what it says? This is a follow-up for my previous comment. Perhaps I haven't explained myself properly, let me explain why I find the existing behavior a bit confusing. >From the documentation on -ffloat-store: "This option prevents undesirable excess precision on machines such as the 68000 where the floating registers (of the 68881) keep more precision than a double is supposed to have. Similarly for the x86 architecture." When a person uses -ffloat-store the desired effect is not the additional loads/stores, but the reproducible results across different compiler version/optimization options. It just happened that the cheapest way to go so is adding additional loads/stores. I'm pretty sure most users would be in favor of removing extra loads/stores when they don't affect the results. I understand that perhaps there are reasons why -ffloat-store should work the way it works now. If this is true, I would recommend updating the documentation by reflecting the cases (if they exists) when one might want to use -ffloat-store on x86-64. From what I understand now using -ffloat-store on x86-64 is just a mistake.
[Bug libstdc++/94854] Comment in basic_string.tcc incorrectly says std::string doesn't have explicit instantiation in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94854 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-04-29 Ever confirmed|0 |1
[Bug libstdc++/94854] Comment in basic_string.tcc incorrectly says std::string doesn't have explicit instantiation in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94854 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8f1591763fd50b143af0dc1770741f326a97583a commit r10-8056-g8f1591763fd50b143af0dc1770741f326a97583a Author: Jonathan Wakely Date: Wed Apr 29 18:57:34 2020 +0100 libstdc++: Fix outdated comment about std::string instantiations (PR 94854) PR libstdc++/94854 * include/bits/basic_string.tcc: Update comment about explicit instantiations.
[Bug target/94852] -ffloat-store on x64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94852 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Just marking as a dup of bug 323 and moving on. *** This bug has been marked as a duplicate of bug 323 ***
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 Andrew Pinski changed: What|Removed |Added CC||vanyacpp at gmail dot com --- Comment #218 from Andrew Pinski --- *** Bug 94852 has been marked as a duplicate of this bug. ***
[Bug target/94852] -ffloat-store on x64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94852 --- Comment #4 from Ivan Sorokin --- (In reply to Richard Biener from comment #1) > @item -ffloat-store > @opindex ffloat-store > Do not store floating-point variables in registers, and inhibit other > options that might change whether a floating-point value is taken from a > register or memory. > > I think it does what it says? Yes, the behavior of the compiler and the documentation matches very well. The compiler works as intended. My report is not about a bug, but about a possible improvement. If ignoring or implementing a warning is considered undesirable, I would suggest expanding the documentation by clarifying the interaction between -ffloat-store and -mfpmath=sse. Something like this in the documentation would help: "If used together with -mfpmath=sse, -ffloat-store doesn't change the results of floating point operations. The only effect it has is severely pessimizing the generated code."
[Bug analyzer/94858] New: False report of memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94858
Bug ID: 94858
Summary: False report of memory leak
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: addw at phcomp dot co.uk
Target Milestone: ---
Report of a memory leak - that does not happen.
If malloc()/realloc() fails then td->hs_index is left untouched.
#include
#define FALSE 0
#define TRUE1
#define HASH_EMPTY -1
typedef short hashNx;
typedef struct hashSt {
hashNx* hs_index; // Indicies into table - hashed to find index
int hs_used;// Entries used in hs_index
int hs_slots; // Available slots in hs_index
} hashSt;
voidhashEmpty(hashSt* td);
int hashAlloc(hashSt* td, int slots)
{
hashNx* index;
// Is the index already at least that big ?
if(slots > td->hs_slots) {
// New or reallocate ?
if(td->hs_index != NULL)
index = realloc(td->hs_index, (size_t)slots *
sizeof(hashNx));
else
index = malloc((size_t)slots * sizeof(hashNx));
if(index == NULL)
return(FALSE);
// If we get here malloc()/realloc() worked
td->hs_index = index;
td->hs_slots = slots;
}
hashEmpty(td); // Clear the index
return(TRUE);
}
/* Mark everything in the hash index as empty.
* This is useful if you have deleted something and need to reindex.
* It is OK to call this on a table that has not been initialised.
*/
voidhashEmpty(hashSt* td)
{
hashNx* index;
int slots;
for(slots = td->hs_slots, index = td->hs_index; --slots >= 0; )
*index++ = HASH_EMPTY;
td->hs_used = 0;
}
cc -O2 -Wall -Wno-pointer-sign -Wconversion -fanalyzer -c -o hasha.o hasha.c
In function ‘hashAlloc’:
hasha.c:54:14: warning: leak of ‘index’ [CWE-401] [-Wanalyzer-malloc-leak]
54 | td->hs_used = 0;
| ^~~
‘hashAlloc’: events 1-9
|
| 22 | if(slots > td->hs_slots) {
| |^
| ||
| |(1) following ‘true’ branch...
|..
| 25 | if(td->hs_index != NULL)
| | ~
| | | |
[Bug c++/94775] [8/9/10 Regression] ICE in strip_typedefs, at cp/tree.c:1734 since r8-4668-g8a5ee94a082b3d48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #9 from Marek Polacek --- Thanks, I'll try to obtain some more data. Mine for now.
[Bug rtl-optimization/94857] New: Failure to optimize load+add+store into add on memory when getting carry flag afterwards on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94857
Bug ID: 94857
Summary: Failure to optimize load+add+store into add on memory
when getting carry flag afterwards on x86
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: ---
bool f(unsigned *p, unsigned x)
{
unsigned u = *p;
*p += x;
return u > *p;
}
With -O3, LLVM outputs :
f(unsigned int*, unsigned int): # @f(unsigned int*, unsigned int)
add dword ptr [rdi], esi
setb al
ret
GCC outputs :
f(unsigned int*, unsigned int):
add esi, DWORD PTR [rdi]
mov DWORD PTR [rdi], esi
setc al
ret
[Bug tree-optimization/64072] wrong cgraph node profile count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64072 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #1 from Arseny Solokha --- Is it still an issue?
[Bug ipa/94856] New: [10 Regression] ICE: Segmentation fault (in clone_of_p); or ICE: verify_cgraph_node failed (error: edge points to wrong declaration)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94856
Bug ID: 94856
Summary: [10 Regression] ICE: Segmentation fault (in
clone_of_p); or ICE: verify_cgraph_node failed (error:
edge points to wrong declaration)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
1.
g++-10.0.1-alpha20200426 snapshot (g:29f55115583a0dab6cbac749c4f0804fd88e9536)
ICEs when compiling gcc/testsuite/g++.dg/other/pr47218.C w/ -O2 -fgnu-tm
-fopenacc -fno-tree-dse --param early-inlining-insns=3 --param
uninlined-function-insns=0:
% g++-10.0.1 -O2 -fgnu-tm -fopenacc -fno-tree-dse --param
early-inlining-insns=3 --param uninlined-function-insns=0 -c
gcc/testsuite/g++.dg/other/pr47218.C
during IPA pass: inline
gcc/testsuite/g++.dg/other/pr47218.C: In destructor 'virtual Foo3::~Foo3()':
gcc/testsuite/g++.dg/other/pr47218.C:10:1: internal compiler error:
Segmentation fault
10 | }
| ^
0xfebacf crash_signal
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/toplev.c:328
0xb85dd9 clone_of_p
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cgraph.c:3108
0xb85dd9 cgraph_edge::verify_corresponds_to_fndecl(tree_node*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cgraph.c:3196
0xb8d780 cgraph_node::verify_node()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cgraph.c:3719
0xb7fcf4 symtab_node::verify()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/symtab.c:1312
0x1074525 expand_call_inline
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/tree-inline.c:4820
0x1076ee9 gimple_expand_calls_inline
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/tree-inline.c:5251
0x1076ee9 optimize_inline_calls(tree_node*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/tree-inline.c:5424
0xddbef3 inline_transform(cgraph_node*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/ipa-inline-transform.c:734
0xf182dd execute_one_ipa_transform_pass
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/passes.c:2233
0xf182dd execute_all_ipa_transforms(bool)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/passes.c:2272
0xb86644 cgraph_node::get_body()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cgraph.c:3970
0x11df6f1 ipa_pta_execute
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/tree-ssa-structalias.c:8140
0x11df6f1 execute
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/tree-ssa-structalias.c:8557
2.
Omission of -fopenacc from the command line yields the following instead:
% g++-10.0.1 -O2 -fgnu-tm -fno-tree-dse --param early-inlining-insns=3 --param
uninlined-function-insns=0 -c gcc/testsuite/g++.dg/other/pr47218.C
gcc/testsuite/g++.dg/other/pr47218.C: In destructor 'Foo3::~Foo3()':
gcc/testsuite/g++.dg/other/pr47218.C:7:1: error: edge points to wrong
declaration:
7 | Foo3::~Foo3 ()
| ^~~~
>
QI
size
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f81105887e0
arg-types >>
readonly addressable asm_written used nothrow static decl_5 QI
gcc/testsuite/g++.dg/other/pr47218.C:12:6 align:16 warn_if_not_align:0 context
initial
abstract_origin
(mem:QI (symbol_ref:DI ("_ZN4Foo33BarEv.constprop.0") [flags 0x3]
) [0 S1 A8])>
Instead of: >
QI
size
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f8110570690 method basetype
arg-types
chain >>
pointer_to_this >
readonly addressable used nothrow public ignored virtual decl_5 QI
gcc/testsuite/g++.dg/other/pr47218.h:32:16 align:8 warn_if_not_align:0 context
initial
result
ignored VOID gcc/testsuite/g++.dg/other/pr47218.C:19:1
align:8 warn_if_not_align:0 context >
full-name "virtual void Foo3::_ZThn8_N4Foo33BarEv()"
arguments
readonly public unsigned DI
size
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f8110570a80>
readonly unsigned read DI gcc/testsuite/g++.dg/other/pr47218.C:12:16
size unit-size
align:64 warn_if_not_align:0 context arg-type >
struct-function 0x7f8110561bb0>
_ZN4Foo3D2Ev/44 (Foo3::~Foo3()) @0x7f81105a09d8
Type:
[Bug middle-end/91146] [9/10 Regression] -Werror=array-bounds if compile with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91146 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Priority|P3 |P2
[Bug c++/94775] [8/9/10 Regression] ICE in strip_typedefs, at cp/tree.c:1734 since r8-4668-g8a5ee94a082b3d48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- (In reply to Marek Polacek from comment #7) > So a fix could be this, but maybe it would make us create a lot more > variants (?): > > --- a/gcc/tree.c > +++ b/gcc/tree.c > @@ -6493,7 +6493,8 @@ check_base_type (const_tree cand, const_tree base) > TYPE_ATTRIBUTES (base))) > return false; >/* Check alignment. */ > - if (TYPE_ALIGN (cand) == TYPE_ALIGN (base)) > + if (TYPE_ALIGN (cand) == TYPE_ALIGN (base) > + && TYPE_USER_ALIGN (cand) == TYPE_USER_ALIGN (base)) > return true; >/* Atomic types increase minimal alignment. We must to do so as well > or we get duplicated canonical types. See PR88686. */ > @@ -6528,6 +6529,7 @@ check_aligned_type (const_tree cand, const_tree base, > unsigned int align) > && TYPE_CONTEXT (cand) == TYPE_CONTEXT (base) > /* Check alignment. */ > && TYPE_ALIGN (cand) == align > + && TYPE_USER_ALIGN (cand) == TYPE_USER_ALIGN (base) > && attribute_list_equal (TYPE_ATTRIBUTES (cand), >TYPE_ATTRIBUTES (base)) > && check_lang_type (cand, base)); It looks like the right thing to me. I guess if we really wanted, we could instrument the compiler to see how common this was (though best in a separate build from just the above patch), i.e. when we would create a new type only with this patch and not without.
[Bug middle-end/94855] provide an option to initialize automatic variable for security purpose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94855 --- Comment #1 from qinzhao at gcc dot gnu.org --- this is a request to provide a new option in GCC to initialize automatic variables for security purpose. Motivations for this request: 1. Kees Cook's slide: https://outflux.net/slides/2019/lca/danger.pdf https://outflux.net/slides/2019/lpc/gcc-and-clang.pdf 2. LLVM's implementation: https://reviews.llvm.org/D54604 3. Kernal's plugin https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/gcc-plugins/structleak_plugin.c)
[Bug c++/94775] [8/9/10 Regression] ICE in strip_typedefs, at cp/tree.c:1734 since r8-4668-g8a5ee94a082b3d48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775 --- Comment #7 from Marek Polacek --- So a fix could be this, but maybe it would make us create a lot more variants (?): --- a/gcc/tree.c +++ b/gcc/tree.c @@ -6493,7 +6493,8 @@ check_base_type (const_tree cand, const_tree base) TYPE_ATTRIBUTES (base))) return false; /* Check alignment. */ - if (TYPE_ALIGN (cand) == TYPE_ALIGN (base)) + if (TYPE_ALIGN (cand) == TYPE_ALIGN (base) + && TYPE_USER_ALIGN (cand) == TYPE_USER_ALIGN (base)) return true; /* Atomic types increase minimal alignment. We must to do so as well or we get duplicated canonical types. See PR88686. */ @@ -6528,6 +6529,7 @@ check_aligned_type (const_tree cand, const_tree base, unsigned int align) && TYPE_CONTEXT (cand) == TYPE_CONTEXT (base) /* Check alignment. */ && TYPE_ALIGN (cand) == align + && TYPE_USER_ALIGN (cand) == TYPE_USER_ALIGN (base) && attribute_list_equal (TYPE_ATTRIBUTES (cand), TYPE_ATTRIBUTES (base)) && check_lang_type (cand, base));
[Bug middle-end/94855] New: provide an option to initialize automatic variable for security purpose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94855 Bug ID: 94855 Summary: provide an option to initialize automatic variable for security purpose Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: qinzhao at gcc dot gnu.org Target Milestone: ---
[Bug c++/94775] [8/9/10 Regression] ICE in strip_typedefs, at cp/tree.c:1734 since r8-4668-g8a5ee94a082b3d48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775 --- Comment #6 from Marek Polacek --- The TYPE_USER_ALIGN (t) assert was there even before my change, but I agree this is a latent problem not directly caused by r8-4668-g8a5ee94a082b3d48. Here strip_typedefs gets "const d[0]" with TYPE_USER_ALIGN=0. But the result built by result = build_cplus_array_type (type, t0); is "const char[0]" with TYPE_USER_ALIGN=1. When we strip_typedefs the element of the array "const d", we see it's a typedef_variant_p, so we look at its DECL_ORIGINAL_TYPE, which is char, but we need to add the const qualifier, so we call cp_build_qualified_type -> build_qualified_type where get_qualified_type checks to see if we already have such a type by walking the variants list, which in this case is: char -> c -> const char -> const char -> d -> const d Because check_base_type only checks TYPE_ALIGN and not TYPE_USER_ALIGN, we choose the first const char, which has TYPE_USER_ALIGN set. If the element type of an array has TYPE_USER_ALIGN, the array type gets it too. Thus the discrepancy.
[Bug libstdc++/94854] New: Comment in basic_string.tcc incorrectly says std::string doesn't have explicit instantiation in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94854 Bug ID: 94854 Summary: Comment in basic_string.tcc incorrectly says std::string doesn't have explicit instantiation in C++17 Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redbeard0531 at gmail dot com Target Milestone: --- https://github.com/gcc-mirror/gcc/blob/0c8217b16f307c3eedce8f22354714938613f701/libstdc%2B%2B-v3/include/bits/basic_string.tcc#L1612-L1617 Looks like the code changed in this commit https://github.com/gcc-mirror/gcc/commit/1a289fa36294627c252492e4c18d7877a7c80dc1#diff-56639139bdefbe09b8f41c465ebf1ab5, but the comment wasn't adjusted to match. While I recognize this isn't an issue for 99.9% of users, hopefully if this is fixed it will save someone else that minute or two of staring at the code trying to reconcile it with the comment.
[Bug target/94852] -ffloat-store on x64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94852 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- (In reply to Andreas Schwab from comment #2) > For avoiding issues with excess precision there is > -fexcess-precision=standard now. Only for C, for C++ we don't have it. And -fexcess-precision=standard actually doesn't avoid the excess precision, but just enforces it consistently.
[Bug testsuite/94853] [10 regression] excess errors in gfortran.dg/analyzer/pr93993.f90 since r10-8012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94853 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Fails on i686-linux too.
[Bug target/94852] -ffloat-store on x64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94852 --- Comment #2 from Andreas Schwab --- For avoiding issues with excess precision there is -fexcess-precision=standard now.
[Bug testsuite/94853] New: [10 regression] excess errors in gfortran.dg/analyzer/pr93993.f90 since r10-8012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94853 Bug ID: 94853 Summary: [10 regression] excess errors in gfortran.dg/analyzer/pr93993.f90 since r10-8012 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- commit g:78b9783774bfd3540f38f5b1e3c7fc9f719653d7, r10-8012 spawn -ignore SIGHUP /home3/seurer/gcc/git/build/gcc-test2/gcc/testsuite/gfortran/../../gfortran -B/home3/seurer/gcc/git/build/gcc-test2/gcc/testsuite/gfortran/../../ -B/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O -fanalyzer -fdiagnostics-path-format=separate-events -Wanalyzer-too-complex -fanalyzer-call-summaries -S -o pr93993.s /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:21:0: Warning: leak of 'tm' [CWE-401] [-Wanalyzer-malloc-leak] /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:26:0: note: (1) entry to 'main' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:26:0: note: (2) calling 'a5' from 'main' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:25:0: note: (3) entry to 'a5' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:32:0: note: (4) calling 'hv' from 'a5' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:15:0: note: (5) entry to 'hv' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:19:0: note: (6) following 'false' branch... /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:19:0: note: (7) ...to here /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:19:0: note: (8) following 'false' branch... /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:19:0: note: (9) ...to here /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:21:0: note: (10) 'tm' leaks here /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:33:0: Warning: leak of '(struct Pdtet_8 *) qb' [CWE-401] [-Wanalyzer-malloc-leak] /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:26:0: note: (1) entry to 'main' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:26:0: note: (2) calling 'a5' from 'main' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:25:0: note: (3) entry to 'a5' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:32:0: note: (4) calling 'hv' from 'a5' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:15:0: note: (5) entry to 'hv' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:19:0: note: (6) following 'false' branch... /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:19:0: note: (7) ...to here /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:19:0: note: (8) allocated here /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:19:0: note: (9) allocated here /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:19:0: note: (10) state of '(struct Pdtet_8 *) qb': 'start' -> 'nonnull' (origin: NULL) /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:19:0: note: (11) following 'false' branch... /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:19:0: note: (12) ...to here /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:19:0: note: (13) state of '(struct Pdtet_8 *) qb': 'start' -> 'nonnull' (origin: NULL) /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:21:0: note: (14) state of '(struct Pdtet_8 *) qb': 'start' -> 'nonnull' (origin: NULL) /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:32:0: note: (15) returning to 'a5' from 'hv' f951: note: (16) state of '(struct Pdtet_8 *) qb': 'start' -> 'nonnull' (origin: NULL) /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:33:0: note: (17) state of '(struct Pdtet_8 *) qb': 'start' -> 'nonnull' (origin: NULL) /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:33:0: note: (18) state of '(struct Pdtet_8 *) qb': 'start' -> 'nonnull' (origin: NULL) /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:33:0: note: (19) '(struct Pdtet_8 *) qb' leaks here; was allocated at (9) PASS:
[Bug target/94850] Failure to optimize operation corresponding to shrd to shrd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94850
Richard Biener changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Component|rtl-optimization|target
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-04-29
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
Probably a missing combine helper or a non-canonical pattern. It looks like
(define_insn "x86_64_shrd"
[(set (match_operand:DI 0 "nonimmediate_operand" "+r*m")
(ior:DI (lshiftrt:DI (match_dup 0)
(match_operand:QI 2 "nonmemory_operand" "Jc"))
(ashift:DI (match_operand:DI 1 "register_operand" "r")
(minus:QI (const_int 64) (match_dup 2)
(clobber (reg:CC FLAGS_REG))]
it tries for example
Failed to match this instruction:
(parallel [
(set (reg:DI 93)
(ior:DI (ashift:DI (reg:DI 102)
(minus:QI (subreg:QI (reg:SI 95) 0)
(subreg:QI (reg/v:SI 92 [ x ]) 0)))
(reg:DI 97)))
(clobber (reg:CC 17 flags))
])
or
Failed to match this instruction:
(parallel [
(set (reg:DI 93)
(ior:DI (lshiftrt:DI (reg:DI 103)
(subreg:QI (reg/v:SI 92 [ x ]) 0))
(ashift:DI (reg:DI 102)
(subreg:QI (reg:SI 94) 0
(clobber (reg:CC 17 flags))
])
but the insn with basically four ops is likely too complex for combines
little mind. Ah here:
(set (reg:DI 93)
(ior:DI (lshiftrt:DI (reg:DI 103)
(subreg:QI (reg/v:SI 92 [ x ]) 0))
(ashift:DI (reg:DI 102)
(minus:QI (subreg:QI (reg:SI 95) 0)
(subreg:QI (reg/v:SI 92 [ x ]) 0)
but no (const 64) which is still separate here:
(insn 11 8 12 2 (set (reg:SI 95)
(const_int 64 [0x40])) "y.c":8:31 67 {*movsi_internal}
(nil))
not sure if combine could help out here by propagating constants?
[Bug target/94852] -ffloat-store on x64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94852 Richard Biener changed: What|Removed |Added Target||x86_64-*-* i?86-*-* --- Comment #1 from Richard Biener --- @item -ffloat-store @opindex ffloat-store Do not store floating-point variables in registers, and inhibit other options that might change whether a floating-point value is taken from a register or memory. I think it does what it says?
[Bug rtl-optimization/90706] [9/10 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 --- Comment #9 from Georg-Johann Lay --- (In reply to Berni from comment #8) > I just compiled AVR gcc 9.3.0 and tested the code again. Still no > improvement! Don't expect anything from v9 (or from v10 for that matter). The problem is in the middle-end, and problems there that affect targets like avr will not be fixed -- except in the rare case you manage to show that the issue affects a target that is important enough and report it for that target. And don't expect anything from v11+ either. The avr backend will likely be removed from the compiler, see PR92729. The depreciation is for v11 and wasn't even worth a mention in the v10 release notes caveats https://gcc.gnu.org/gcc-10/changes.html The general recommendation is to switch to clang / llvm where the respective backend is improving and has left experimental status;and is not suffering from self-destruction...
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 67860, which changed state. Bug 67860 Summary: [concepts] bug with overloaded, refined function with explicit and variadic template arguments https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67860 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/67860] [concepts] bug with overloaded, refined function with explicit and variadic template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67860 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |10.0 Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- Fixed for GCC 10 then.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 67774, which changed state. Bug 67774 Summary: [concepts] ICE when mismatching template arguments to concept https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67774 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/67774] [concepts] ICE when mismatching template arguments to concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67774 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 CC||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- Fixed for GCC 10 then.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 84810, which changed state. Bug 84810 Summary: [concepts][c++20] constraints of lambdas with explicit template parameters are not checked https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84810 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/84810] [concepts][c++20] constraints of lambdas with explicit template parameters are not checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84810 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 CC||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- Looks like this is fixed for GCC 10.
[Bug target/94852] New: -ffloat-store on x64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94852
Bug ID: 94852
Summary: -ffloat-store on x64 target
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
At the moment -ffloat-store significantly pessimizes the code generation
regardless of whether -mfpmath=sse -msse2 are used or not:
float f(float a, float b)
{
return a + b;
}
-O2:
addss xmm0, xmm1
ret
-O2 -ffloat-store:
movss DWORD PTR [rsp-20], xmm0
movss xmm0, DWORD PTR [rsp-20]
movss DWORD PTR [rsp-24], xmm1
addss xmm0, DWORD PTR [rsp-24]
movss DWORD PTR [rsp-4], xmm0
movss xmm0, DWORD PTR [rsp-4]
ret
Note that -mfpmath=sse -msse2 are the defaults on x86-64. My understanding is
that -ffloat-store doesn't affect the result of floating point operations when
SSE math is used. If this is true -ffloat-store pessimizes generated code
without any change in observable behavior.
Recently I have found a steam game that targets x86-64 and was compiled with
-ffloat-store (presumably by mistake). For details see:
https://forums.factorio.com/viewtopic.php?f=30=81134 . When -ffloat-store was
removed a developer reported a 35% speedup of the Linux version of the game.
My guess is -ffloat-store might be used by mistake when someone tries to get
reproducible results on x86 without realizing that the same flags affects the
performance negatively on x86-64.
To prevent issues like this in the future I think GCC could do two things:
1. Ignore -ffloat-store when it doesn't affect the result of floating-point
operations pretending that redundant loads/stores are optimized.
2. Issue a warning when -ffloat-store doesn't affect the result of
floating-point operations. Because there is no point in using a flag which only
effect is pessimizing code generation.
[Bug sanitizer/94849] Improper parameter validation in libsanitizer for fopen64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94849 --- Comment #7 from Rachel Mant --- Continuing to think on this a bit, and.. if it is undefined behaviour as you say, then granted this is not a bug on ASAN/TSAN.. but it is still a bug as UBSAN does and says nothing when faced with this even though it clearly should terminate the program for invoking UB, with a suitable diagnostic.
[Bug testsuite/94763] UNRESOLVED scan assembler tests on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94763 --- Comment #2 from vvinayag at arm dot com --- (In reply to Christophe Lyon from comment #1) > How do you configure GCC, and what flags to you use to run the tests? > They work for me, on several configuration of arm-non-eabi-gcc as > cross-compiler. Sorry for the late reply. The tests appear to pass when I invoke them locally. They only failed as part of our buildbot run tests. It could be a glitch in our test system. But I was wondering whether there were any recent changes in the testsuites.
[Bug target/94832] AVX512 scatter/gather macros lack parentheses when unoptimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94832 --- Comment #7 from Jakub Jelinek --- Fixed for 10+ so far.
[Bug target/94832] AVX512 scatter/gather macros lack parentheses when unoptimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94832
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0c8217b16f307c3eedce8f22354714938613f701
commit r10-8055-g0c8217b16f307c3eedce8f22354714938613f701
Author: Jakub Jelinek
Date: Wed Apr 29 17:31:26 2020 +0200
x86: Fix -O0 remaining intrinsic macros [PR94832]
A few other macros seem to suffer from the same issue. What I've done was:
cat gcc/config/i386/*intrin.h | sed -e ':x /\\$/ { N; s/\\\n//g ; bx }' \
| grep '^[[:blank:]]*#[[:blank:]]*define[[:blank:]].*(' | sed 's/[
]\+/ /g' \
> /tmp/macros
and then looking for regexps:
)[a-zA-Z]
) [a-zA-Z]
[a-zA-Z][-+*/%]
[a-zA-Z] [-+*/%]
[-+*/%][a-zA-Z]
[-+*/%] [a-zA-Z]
in the resulting file.
2020-04-29 Jakub Jelinek
PR target/94832
* config/i386/avx512bwintrin.h (_mm512_alignr_epi8,
_mm512_mask_alignr_epi8, _mm512_maskz_alignr_epi8): Wrap macro
operands
used in casts into parens.
* config/i386/avx512fintrin.h (_mm512_cvt_roundps_ph,
_mm512_cvtps_ph,
_mm512_mask_cvt_roundps_ph, _mm512_mask_cvtps_ph,
_mm512_maskz_cvt_roundps_ph, _mm512_maskz_cvtps_ph,
_mm512_mask_cmp_epi64_mask, _mm512_mask_cmp_epi32_mask,
_mm512_mask_cmp_epu64_mask, _mm512_mask_cmp_epu32_mask,
_mm512_mask_cmp_round_pd_mask, _mm512_mask_cmp_round_ps_mask,
_mm512_mask_cmp_pd_mask, _mm512_mask_cmp_ps_mask): Likewise.
* config/i386/avx512vlbwintrin.h (_mm256_mask_alignr_epi8,
_mm256_maskz_alignr_epi8, _mm_mask_alignr_epi8,
_mm_maskz_alignr_epi8,
_mm256_mask_cmp_epu8_mask): Likewise.
* config/i386/avx512vlintrin.h (_mm_mask_cvtps_ph,
_mm_maskz_cvtps_ph,
_mm256_mask_cvtps_ph, _mm256_maskz_cvtps_ph): Likewise.
* config/i386/f16cintrin.h (_mm_cvtps_ph, _mm256_cvtps_ph):
Likewise.
* config/i386/shaintrin.h (_mm_sha1rnds4_epu32): Likewise.
[Bug target/94832] AVX512 scatter/gather macros lack parentheses when unoptimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94832
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:78cef09019cc9c80d1b39a49861f8827a2ee2e60
commit r10-8054-g78cef09019cc9c80d1b39a49861f8827a2ee2e60
Author: Jakub Jelinek
Date: Wed Apr 29 17:30:22 2020 +0200
x86: Fix -O0 intrinsic *gather*/*scatter* macros [PR94832]
As reported in the PR, while most intrinsic -O0 macro argument uses
are properly wrapped in ()s or used in context where having a complex
expression passed as the argument doesn't pose a problem (e.g. when
macro argument use is in between commas, or between ( and comma, or
between comma and ) etc.), especially the gather/scatter macros don't do
this and if one passes to some macro e.g. x + y as argument, the
corresponding inline function would do cast on the argument, but
the macro does (int) ARG, then it is (int) x + y rather than (int) (x + y).
The following patch fixes those issues in *gather/*scatter*; additionally,
the AVX2 macros were passing incorrect mask of e.g.
(__v2df)_mm_set1_pd((double)(long long int) -1)
which is IMHO equivalent to
(__v2df){-1.0, -1.0}
when it really wants to pass __v2df vector with all bits set.
I've used what the inline functions use for those cases.
2020-04-29 Jakub Jelinek
PR target/94832
* config/i386/avx2intrin.h (_mm_mask_i32gather_pd,
_mm256_mask_i32gather_pd, _mm_mask_i64gather_pd,
_mm256_mask_i64gather_pd, _mm_mask_i32gather_ps,
_mm256_mask_i32gather_ps, _mm_mask_i64gather_ps,
_mm256_mask_i64gather_ps, _mm_i32gather_epi64,
_mm_mask_i32gather_epi64, _mm256_i32gather_epi64,
_mm256_mask_i32gather_epi64, _mm_i64gather_epi64,
_mm_mask_i64gather_epi64, _mm256_i64gather_epi64,
_mm256_mask_i64gather_epi64, _mm_i32gather_epi32,
_mm_mask_i32gather_epi32, _mm256_i32gather_epi32,
_mm256_mask_i32gather_epi32, _mm_i64gather_epi32,
_mm_mask_i64gather_epi32, _mm256_i64gather_epi32,
_mm256_mask_i64gather_epi32): Surround macro parameter uses with
parens.
(_mm_i32gather_pd, _mm256_i32gather_pd, _mm_i64gather_pd,
_mm256_i64gather_pd, _mm_i32gather_ps, _mm256_i32gather_ps,
_mm_i64gather_ps, _mm256_i64gather_ps): Likewise. Don't use
as mask vector containing -1.0 or -1.0f elts, but instead vector
with all bits set using _mm*_cmpeq_p? with zero operands.
* config/i386/avx512fintrin.h (_mm512_i32gather_ps,
_mm512_mask_i32gather_ps, _mm512_i32gather_pd,
_mm512_mask_i32gather_pd, _mm512_i64gather_ps,
_mm512_mask_i64gather_ps, _mm512_i64gather_pd,
_mm512_mask_i64gather_pd, _mm512_i32gather_epi32,
_mm512_mask_i32gather_epi32, _mm512_i32gather_epi64,
_mm512_mask_i32gather_epi64, _mm512_i64gather_epi32,
_mm512_mask_i64gather_epi32, _mm512_i64gather_epi64,
_mm512_mask_i64gather_epi64, _mm512_i32scatter_ps,
_mm512_mask_i32scatter_ps, _mm512_i32scatter_pd,
_mm512_mask_i32scatter_pd, _mm512_i64scatter_ps,
_mm512_mask_i64scatter_ps, _mm512_i64scatter_pd,
_mm512_mask_i64scatter_pd, _mm512_i32scatter_epi32,
_mm512_mask_i32scatter_epi32, _mm512_i32scatter_epi64,
_mm512_mask_i32scatter_epi64, _mm512_i64scatter_epi32,
_mm512_mask_i64scatter_epi32, _mm512_i64scatter_epi64,
_mm512_mask_i64scatter_epi64): Surround macro parameter uses with
parens.
* config/i386/avx512pfintrin.h (_mm512_prefetch_i32gather_pd,
_mm512_prefetch_i32gather_ps, _mm512_mask_prefetch_i32gather_pd,
_mm512_mask_prefetch_i32gather_ps, _mm512_prefetch_i64gather_pd,
_mm512_prefetch_i64gather_ps, _mm512_mask_prefetch_i64gather_pd,
_mm512_mask_prefetch_i64gather_ps, _mm512_prefetch_i32scatter_pd,
_mm512_prefetch_i32scatter_ps, _mm512_mask_prefetch_i32scatter_pd,
_mm512_mask_prefetch_i32scatter_ps, _mm512_prefetch_i64scatter_pd,
_mm512_prefetch_i64scatter_ps, _mm512_mask_prefetch_i64scatter_pd,
_mm512_mask_prefetch_i64scatter_ps): Likewise.
* config/i386/avx512vlintrin.h (_mm256_mmask_i32gather_ps,
_mm_mmask_i32gather_ps, _mm256_mmask_i32gather_pd,
_mm_mmask_i32gather_pd, _mm256_mmask_i64gather_ps,
_mm_mmask_i64gather_ps, _mm256_mmask_i64gather_pd,
_mm_mmask_i64gather_pd, _mm256_mmask_i32gather_epi32,
_mm_mmask_i32gather_epi32, _mm256_mmask_i32gather_epi64,
_mm_mmask_i32gather_epi64, _mm256_mmask_i64gather_epi32,
_mm_mmask_i64gather_epi32, _mm256_mmask_i64gather_epi64,
_mm_mmask_i64gather_epi64, _mm256_i32scatter_ps,
[Bug analyzer/94851] -fanalyzer erroniously reporting NULL dereference - simple test case attached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94851 --- Comment #1 from Alain D D Williams --- Created attachment 48410 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48410=edit Compiler output
[Bug analyzer/94851] New: -fanalyzer erroniously reporting NULL dereference - simple test case attached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94851 Bug ID: 94851 Summary: -fanalyzer erroniously reporting NULL dereference - simple test case attached Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: addw at phcomp dot co.uk Target Milestone: --- Created attachment 48409 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48409=edit C source showing error Attached is a simplified part of a bigger program. Compiled on Fedora 32: cc -O2 -Wall -Wno-pointer-sign -Wconversion -fanalyzer -c -o pmark.o pmark.c Output also attached.
[Bug target/94743] IRQ handler doesn't save scratch VFP registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743 Christophe Lyon changed: What|Removed |Added Last reconfirmed||2020-04-29 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |clyon at gcc dot gnu.org --- Comment #8 from Christophe Lyon --- Patch sent: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544872.html This is a simple improvement, hopefully simple enough for stage 4, yet useful for the end-users.
[Bug target/57002] ARM back end has extra entries in attribute interrupt array.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57002 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #3 from Christophe Lyon --- Patch sent: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544871.html
[Bug c++/94835] ICE in vague_linkage_p, at cp/decl2.c:2041
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94835 --- Comment #3 from Stephen Casner --- I'm working with unmodified gcc sources, but if no other targets are seeing this problem then it may be caused by pdp11-specific code somewhere else. I guess that g++ and libstdc++v3 have never been successfully built for pdp11. Any suggestions for debugging this? Perhaps backing off on some compiler feature that might be tickling the bug?
[Bug sanitizer/94849] Improper parameter validation in libsanitizer for fopen64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94849 --- Comment #6 from Rachel Mant --- Ok, fair enough - though I'd like to know your thoughts then on the rest of the f*open() family and the fact the sanitizers do check for nullptr paths/filenames even though the wording is the same. The fopen64() sanitizer interceptor is the only one of the lot that does not.
[Bug sanitizer/94849] Improper parameter validation in libsanitizer for fopen64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94849 --- Comment #5 from Jakub Jelinek --- So it might be well defined on Windows, but unless glibc documents it as an extension, it is not valid on Linux. C clearly says: "The fopen function opens the file whose name is the string pointed to by filename" and NULL is not a pointer to a string. Same POSIX, e.g. in 1003.1-2017. So, just don't do this, you invoke undefined behavior, and one such behavior is that it crashes with the sanitizers.
[Bug rtl-optimization/94850] Failure to optimize operation corresponding to shrd to shrd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94850 --- Comment #1 from Gabriel Ravier --- PS : The same optimization can apply to i686, just replace all occurences of "64" with "32" and you could use shld/shrd there too
[Bug fortran/94769] Possible use of uninitialized variable num
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94769 --- Comment #9 from CVS Commits --- The master branch has been updated by Stefan Schulze Frielinghaus : https://gcc.gnu.org/g:27594524d8a93cddb197ad8c9d4075c5870f1473 commit r10-8053-g27594524d8a93cddb197ad8c9d4075c5870f1473 Author: Stefan Schulze Frielinghaus Date: Tue Apr 28 13:14:28 2020 +0200 fortran/io.c: Fix use of uninitialized variable num [PR94769] While bootstrapping GCC on S/390 the following warning occurs: gcc/fortran/io.c: In function 'bool gfc_resolve_dt(gfc_code*, gfc_dt*, locus*)': gcc/fortran/io.c:3857:7: error: 'num' may be used uninitialized in this function [-Werror=maybe-uninitialized] 3857 | if (num == 0) | ^~ gcc/fortran/io.c:3843:11: note: 'num' was declared here 3843 | int num; Since gfc_resolve_dt is a non-static function we cannot assume anything about argument DT. Argument DT gets passed to function check_io_constraints which passes values depending on DT, namely dt->asynchronous->value.character.string to function compare_to_allowed_values as well as argument warn which is true as soon as DT->dterr is true. Thus both arguments depend on DT. If function compare_to_allowed_values is called with dt->asynchronous->value.character.string not being an allowed value, and ALLOWED_F2003 as well as ALLOWED_GNU being NULL (which is the case at the particular call side), and WARN equals true, then the function returns with a non-zero value and leaves num uninitialized which renders the warning true. Initialized num to -1 and added an assert statement. gcc/fortran/ChangeLog: 2020-04-29 Stefan Schulze Frielinghaus PR fortran/94769 * io.c (check_io_constraints): Initialize local variable num to -1 and assert that it receives a meaningful value by function compare_to_allowed_values.
[Bug sanitizer/94849] Improper parameter validation in libsanitizer for fopen64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94849 --- Comment #4 from Rachel Mant --- Glibc, MSVCRT and other CRTs all check for this condition in userspace and NOP it by short-circuiting the call with a return of nullptr. MSVCRT even documents this (https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-wfopen?view=vs-2019) I agree that the fopen() man page leaves it as unspecified behaviour however. That said.. this is not actually fopen() itself, but its 64-bit cousin fopen64(). Again, Glibc and other CRTs agree to handle a nullptr file argument by NOP'ing the call and returning nullptr.
[Bug sanitizer/94849] Improper parameter validation in libsanitizer for fopen64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94849 --- Comment #3 from Martin Liška --- (In reply to Jakub Jelinek from comment #2) > I think it is undefined behavior and just doesn't crash because the pathname > is passed to a syscall which will fail then. > So IMHO nothing we should support. Agree with that. One possible improvement can be decoration of the filename with non-null argument (in Glibc).
[Bug rtl-optimization/94850] New: Failure to optimize operation corresponding to shrd to shrd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94850
Bug ID: 94850
Summary: Failure to optimize operation corresponding to shrd to
shrd
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: ---
struct testStruct {
uint64_t a;
uint64_t b;
};
uint64_t f(testStruct t, int x)
{
return ((t.a << (64 - x)) | (t.b >> (x)));
}
LLVM produces this :
f(testStruct, int): # @f(testStruct, int)
mov ecx, edx
mov rax, rsi
shrd rax, rdi, cl
ret
GCC produces this :
f(testStruct, int):
mov ecx, 64
mov rax, rsi
sub ecx, edx
sal rdi, cl
mov ecx, edx
shr rax, cl
or rax, rdi
ret
A similar optimization can be done for shld for this code :
uint64_t f(uint64_t a, uint64_t b, int x)
{
return ((a << (x)) | (b >> (64 - x)));
}
[Bug sanitizer/94849] Improper parameter validation in libsanitizer for fopen64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94849 --- Comment #2 from Jakub Jelinek --- I think it is undefined behavior and just doesn't crash because the pathname is passed to a syscall which will fail then. So IMHO nothing we should support.
[Bug sanitizer/94849] Improper parameter validation in libsanitizer for fopen64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94849 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-04-29 --- Comment #1 from Martin Liška --- (In reply to Rachel Mant from comment #0) > Created attachment 48408 [details] > A simple fix for the bug > > fopen() (actually fopen64 because of macro remapping) as implemented by > Glibc and other C run-times allows the first "path" or "filename" parameter > to be nullptr and causes the function to simply do nothing and return > nullptr itself when this happens. > Thank you for the report. Can you please find where is the behavior documented? I can't find anything about NULL pointer argument at: man fopen.
[Bug sanitizer/94849] New: Improper parameter validation in libsanitizer for fopen64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94849
Bug ID: 94849
Summary: Improper parameter validation in libsanitizer for
fopen64
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: rachel at rachelmant dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Created attachment 48408
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48408=edit
A simple fix for the bug
fopen() (actually fopen64 because of macro remapping) as implemented by Glibc
and other C run-times allows the first "path" or "filename" parameter to be
nullptr and causes the function to simply do nothing and return nullptr itself
when this happens.
Because of this, I have a test case in a project that is specifically verifying
this bad, but allowed, use of fopen64() as a way to guarantee it returns
nullptr for some further tests and for code coverage reasons.
The simplest form of failing program is:
```
#include
int main()
{
return !fopen(nullptr, "w") ? 0 : 1;
}
```
which when compiled with `g++ -D_FILE_OFFSET_BITS=64 -o test test.cxx` runs and
returns 0, but when compiled with `g++ -D_FILE_OFFSET_BITS=64 -o test
-fsanitize=address test.cxx` or the thread sanitizer, instead crashes:
```
$ ./test; echo $?
AddressSanitizer:DEADLYSIGNAL
=
==2187382==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x7f8867d791e5 bp 0x7ffcc8f95db0 sp 0x7ffcc8f95528 T0)
==2187382==The signal is caused by a READ memory access.
==2187382==Hint: address points to the zero page.
#0 0x7f8867d791e4 in __strlen_avx2 (/usr/lib/libc.so.6+0x1611e4)
#1 0x7f886817cc35 in __interceptor_fopen64
/build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:5757
#2 0x56367982918d in main (/tmp/test+0x118d)
#3 0x7f8867c3f022 in __libc_start_main (/usr/lib/libc.so.6+0x27022)
#4 0x5636798290ad in _start (/tmp/test+0x10ad)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/usr/lib/libc.so.6+0x1611e4) in __strlen_avx2
==2187382==ABORTING
1
```
This is on GCC 9.3.0, but I have reproduced this on everything from GCC 5
through to 9. Please note: This is not a problem when the non-64-bit fopen() is
used. This is specifically a problem with fopen64().
Unfortunately, libsanitizer does not properly validate the path parameter and
ends up calling strlen() on a nullptr - which is UB that on x86 crashes with
SEGV as seen above.
After triggering the bug and doing some research, it appears that since the
introduction of libsanitizer, this has been a thing:
https://github.com/gcc-mirror/gcc/blob/master/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc#L5882
Attached is a patch that would fix this bugged behaviour.
[Bug target/94826] [8/9 regression] ICE in gcc.dg/pr94780.c after r10-7999
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94826 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 regression] ICE in |[8/9 regression] ICE in |gcc.dg/pr94780.c after |gcc.dg/pr94780.c after |r10-7999|r10-7999 --- Comment #4 from Jakub Jelinek --- Fixed for 10+ so far.
[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 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c7137fcc7cbc1f1f14f9fed75adcc6bd8f1d418c commit r10-8051-gc7137fcc7cbc1f1f14f9fed75adcc6bd8f1d418c Author: Jakub Jelinek Date: Wed Apr 29 15:55:39 2020 +0200 rs6000: Fix rs6000_atomic_assign_expand_fenv [PR94826] This is the rs6000 version of the earlier committed x86, aarch64 and arm fixes, as create_tmp_var_raw is used because the C FE can call this outside of function context, we need to make sure the first references to those VAR_DECLs are through a TARGET_EXPR, so that it gets gimple_add_tmp_var marked in whatever function it gets expanded in. Without that DECL_CONTEXT is NULL and the vars aren't added as local decls of the containing function. 2020-04-29 Jakub Jelinek PR target/94826 * config/rs6000/rs6000.c (rs6000_atomic_assign_expand_fenv): Use TARGET_EXPR instead of MODIFY_EXPR for first assignment to fenv_var, fenv_clear and old_fenv variables. For fenv_addr take address of TARGET_EXPR of fenv_var with void_node initializer. Formatting fixes.
[Bug tree-optimization/94774] Uninitialized variable retval in function try_substitute_return_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94774 --- Comment #3 from CVS Commits --- The master branch has been updated by Stefan Schulze Frielinghaus : https://gcc.gnu.org/g:1657178f59bf0c5b269a668bcdcc432fac3bbdd0 commit r10-8050-g1657178f59bf0c5b269a668bcdcc432fac3bbdd0 Author: Stefan Schulze Frielinghaus Date: Mon Apr 27 18:09:07 2020 +0200 tree-optimization: Fix use of uninitialized variable [PR94774] Array retval is not necessarily initialized by function is_call_safe and may be used afterwards. Thus, initialize it explicitly. gcc/ChangeLog: 2020-04-29 Stefan Schulze Frielinghaus PR tree-optimization/94774 * gimple-ssa-sprintf.c (try_substitute_return_value): Initialize variable retval.
[Bug lto/94848] New: [Offloading][LTO] partial var elimination errors / -ftree-pre causes link errors | libgomp.fortran/use_device_ptr-optional-3.f90 failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94848
Bug ID: 94848
Summary: [Offloading][LTO] partial var elimination errors /
-ftree-pre causes link errors |
libgomp.fortran/use_device_ptr-optional-3.f90 failures
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Compiling
gfortran -fopenmp libgomp.fortran/use_device_ptr-optional-3.f90 \
-O1 -foffload=-lgfortran -ftree-pre
with actual offloading (amdgcn, nvidia) fails with:
/tmp/ccUEo7uX.o:(.gnu.offload_vars+0x10): undefined reference to `A.12.5'
It works with -fno-tree-pre (or when compiling without actual offloading).
The optimization happens on the host side as -foffload="-O0 -lgfortran"
does not solve the issue.
In the Fortran code, this array (A.12) appears in a device function ("omp
declare target") as:
if (any (c_z /= [1,2,3])) stop 37
As mentioned below, the other array (A.9) appears in:
if (any (x /= [3,4,6,2])) stop 44
And in the dump as:
static integer(kind=4) A.12[3] = {1, 2, 3};
static integer(kind=4) A.9[4] = {3, 4, 6, 2};
…
_20 = A.9[S.10];
…
_26 = A.12[S.13_67];
In the optimized dump (-fno-tree-pre):
ivtmp.333_78 = (unsigned long)
…
ivtmp.325_89 = (unsigned long)
But with -ftree-pre, the last assignment is gone – but
[local count: 428295]:
_gfortran_stop_numeric (37, 0);
still exists. Here, the array has been "unrolled", i.e.:
if (_61 != 1)
goto ; [5.50%]
(Followed by the conditions for "2" and "3".)
That's perfectly fine and optimizes "A.12" away.
* * *
If I look at the dumps (-fdump-tree-all) on the device side, those (still)
contain:
pretmp_157 = A.12[_15];
…
if (_134 != pretmp_157)
goto ; [5.50%]
My impression is that the local static variable "A.12" is removed before
writing the LTO data – based on the -ftree-pre analysis.
But the LTO expression usage is written before that removal. – At least that
would explain why it fails on the device side.
[Bug target/94789] Failure to take advantage of shift operand semantics to turn subtraction into negate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94789
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #4 from Wilco ---
(In reply to Gabriel Ravier from comment #0)
> int r(int x, unsigned b)
> {
> int const m = CHAR_BIT * sizeof(x) - b;
> return (x << m);
> }
>
> `CHAR_BIT * sizeof(x) - b;` can be optimized to `-b`. LLVM does this
> transformation, not GCC.
>
> Comparison here : https://godbolt.org/z/5byJ2E
AArch64 already generates:
neg w1, w1
lsl w0, w0, w1
ret
[Bug c/94842] [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 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- ICEs since r0-126350-g267bac1078ce623767a9effa063d5b63fbbeb6ca
[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 Resolution|--- |FIXED Target Milestone|--- |10.0 Status|ASSIGNED|RESOLVED --- Comment #2 from Patrick Palka --- Fixed.
[Bug c++/94830] Some concepts diagnostic messages are nondeterministic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94830 --- Comment #1 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:a7201a085cc30f89944931d8fb1d7936f02a169f commit r10-8049-ga7201a085cc30f89944931d8fb1d7936f02a169f Author: Patrick Palka Date: Wed Apr 29 09:04:58 2020 -0400 c++: Nondeterministic concepts diagnostics [PR94830] This patch makes the order in which template parameters appear in the TREE_LIST returned by find_template_parameters deterministic between runs. The current nondeterminism is semantically harmless, but it has the undesirable effect of causing some concepts diagnostics which print a constraint's parameter mapping via pp_cxx_parameter_mapping to also be nondeterministic, as in the testcases below. gcc/cp/ChangeLog: PR c++/94830 * pt.c (find_template_parameter_info::parm_list): New field. (keep_template_parm): Use the new field to build up the parameter list here instead of ... (find_template_parameters): ... here. Return ftpi.parm_list. gcc/testsuite/ChangeLog: PR c++/94830 * g++.dg/concepts/diagnostics12.C: Clarify the dg-message now that the corresponding diagnostic is deterministic. * g++.dg/concepts/diagnostics13.C: New test.
[Bug target/94820] [8/9 Regression] pr94780.c fails with ICE on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94820 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] |[8/9 Regression] pr94780.c |pr94780.c fails with ICE on |fails with ICE on aarch64 |aarch64 | CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Fixed on the trunk (so far).
