[Bug bootstrap/97262] Build GCC fail: error: cast from 'const ana::region*' to 'long int' loses precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97262 --- Comment #2 from fdlbxtqi --- Let's face it. std::size_t should be the default integer type in both C and C++. type like long should never EVER be used.
[Bug c/97261] gcc-10 produces invalid -Warray-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97261 --- Comment #3 from Dima Kogan --- Hi. Thanks for replying. I don't the warning that I'm claiming is bogus is complaining about the points you raised. If it did, then making g() static or building without -fPIC or -O3 wouldn't make the warning go away. I have some questions about your analysis, if that's ok. g() doesn't know where its ab argument came from, so how can the strict aliasing rules be violated? The only reason the compiler knows anything at all here is that with -O3 it's tracing the flow. With -O0, there's no warning. And g() may as well be in an entirely different compilation unit, in which case it'd compile that unit with no complaint at any optimization level. Similarly, for the undefined behavior. If I have a function that takes some double* x, then is it undefined behavior to refer to x[-1]? If not, then how is this different? Thanks.
[Bug c++/89062] class template argument deduction failure with parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89062
Nikita Lisitsa changed:
What|Removed |Added
CC||lisyarus at gmail dot com
--- Comment #5 from Nikita Lisitsa ---
Any updates on this? Can confirm this on all gcc versions from 7.1 to 10.2 (see
https://godbolt.org/z/4qnfea). Interestingly, for a variadic-template
constructor only the first argument triggers the error, i.e.
template
struct A
{
A(T) {}
};
template
A(T) -> A;
template
struct B
{
template
B(Args const & ...){}
};
void test()
{
B b1(A{0}, A{0}, A{0}); // error
B b2(A{0}, A{0}, A{0}); // ok
}
[Bug tree-optimization/97255] [8/9/10/11 Regression] Vectorizer gives a boolean a value of 255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97255 --- Comment #3 from Richard Biener --- OK, so it's SRA that creates the IL that ultimatively confuses the vectorizer. SRA transforms the bool accesses into unsigned char ones: _32 = in1s_31 != 0; - MEM [(bool &)&x].m_arr[1] = _32; + _7 = VIEW_CONVERT_EXPR(_32); + x$1_16 = _7; ... _5 = out_17(D) + _2; - *_5 = x; + MEM [(struct Array *)_5] = x_15; + MEM [(struct Array *)_5 + 1B] = x$1_16; + MEM [(struct Array *)_5 + 2B] = x$2_23; + MEM [(struct Array *)_5 + 3B] = x$3_28; we do not recognize the VIEW_CONVERT_EXPR as bool pattern. I have a fix.
[Bug target/96795] MVE: issue with polymorphism and integer promotion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96795 SRINATH PARVATHANENI changed: What|Removed |Added Last reconfirmed||2020-10-01 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |sripar01 at gcc dot gnu.org CC||sripar01 at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/97261] gcc-10 produces invalid -Warray-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97261 --- Comment #4 from Richard Biener --- (In reply to Dima Kogan from comment #3) > Hi. Thanks for replying. I don't the warning that I'm claiming is bogus is > complaining about the points you raised. If it did, then making g() static > or building without -fPIC or -O3 wouldn't make the warning go away. It's likely optimized away before warning. > I have some questions about your analysis, if that's ok. g() doesn't know > where its ab argument came from, so how can the strict aliasing rules be > violated? strict aliasing rules are violated because of the actual accesses, not because what a compiler or the function can or cannot see. > The only reason the compiler knows anything at all here is that > with -O3 it's tracing the flow. With -O0, there's no warning. And g() may as > well be in an entirely different compilation unit, in which case it'd > compile that unit with no complaint at any optimization level. But it's still a strict aliasing violation. > Similarly, for the undefined behavior. If I have a function that takes some > double* x, then is it undefined behavior to refer to x[-1]? If not, then how > is this different? It is undefined to refer to x[-1] in case x points to the first element of an array. This is simply how the C abstract machine defines things. "hiding" violations doesn't make them go away, you just might be more lucky in the compiler not taking advantage of the undefinedness and not "miscompiling" your code (or issueing "bogus" diagnostics).
[Bug web/97263] New: For -ffinite-math-only -OFast is not mentioned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97263 Bug ID: 97263 Summary: For -ffinite-math-only -OFast is not mentioned. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: olaf.krzikalla at dlr dot de Target Milestone: --- The description of -ffinite-math-only at https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html reads: "This option is not turned on by any -O option since..." This is not true for -Ofast. Hence it should read: "This option is not turned on by any -O option beside -Ofast since..." See also the description of -ffast-math.
[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
--- Comment #2 from CVS Commits ---
The master branch has been updated by Florian Weimer :
https://gcc.gnu.org/g:324bec558e95584e8c1997575ae9d75978af59f1
commit r11-3578-g324bec558e95584e8c1997575ae9d75978af59f1
Author: Florian Weimer
Date: Thu Oct 1 10:08:24 2020 +0200
PR target/97250: i386: Add support for x86-64-v2, x86-64-v3, x86-64-v4
levels for x86-64
These micro-architecture levels are defined in the x86-64 psABI:
https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9
PTA_NO_TUNE is introduced so that the new processor alias table entries
do not affect the CPU tuning setting in ix86_tune.
The tests depend on the macros added in commit 92e652d8c21bd7e66cbb0f900
("i386: Define __LAHF_SAHF__ and __MOVBE__ macros, based on ISA flags").
gcc/:
PR target/97250
* config/i386/i386.h (PTA_NO_TUNE, PTA_X86_64_BASELINE)
(PTA_X86_64_V2, PTA_X86_64_V3, PTA_X86_64_V4): New.
* common/config/i386/i386-common.c (processor_alias_table):
Add "x86-64-v2", "x86-64-v3", "x86-64-v4".
* config/i386/i386-options.c (ix86_option_override_internal):
Handle new PTA_NO_TUNE processor table entries.
* doc/invoke.texi (x86 Options): Document new -march values.
gcc/testsuite/:
PR target/97250
* gcc.target/i386/x86-64-v2.c: New test.
* gcc.target/i386/x86-64-v3.c: New test.
* gcc.target/i386/x86-64-v3-haswell.c: New test.
* gcc.target/i386/x86-64-v3-skylake.c: New test.
* gcc.target/i386/x86-64-v4.c: New test.
[Bug bootstrap/97262] Build GCC fail: error: cast from 'const ana::region*' to 'long int' loses precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97262
--- Comment #3 from fdlbxtqi ---
Change the line of (long)m_region to this. Compile success. the type long just
considered harmful
hashval_t hash () const
{
return (binding_key::impl_hash () ^ reinterpret_cast(m_region));
}
[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250 Florian Weimer changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Florian Weimer --- Fixed for GCC 11.
[Bug target/96827] [10/11 Regression] __m128i from _mm_set_epi32 is backwards with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96827 --- Comment #13 from CVS Commits --- The releases/gcc-10 branch has been updated by Joel Hutton : https://gcc.gnu.org/g:d0ceb8e276e282a2c9e08eb295ca5c9678d54c63 commit r10-8833-gd0ceb8e276e282a2c9e08eb295ca5c9678d54c63 Author: Joel Hutton Date: Wed Sep 30 16:20:55 2020 +0100 [SLP][VECT] Add check to fix 96827 The following patch adds a simple check to prevent slp stmts from vector constructors being rearranged. vect_attempt_slp_rearrange_stmts tries to rearrange to avoid a load permutation. This fixes PR target/96827 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96827 gcc/ChangeLog: 2020-09-29 Joel Hutton PR target/96827 * tree-vect-slp.c (vect_analyze_slp): Do not call vect_attempt_slp_rearrange_stmts for vector constructors. gcc/testsuite/ChangeLog: 2020-09-29 Joel Hutton PR target/96827 * gcc.dg/vect/bb-slp-49.c: New test. (cherry picked from commit 97b798d80baf945ea28236eef3fa69f36626b579)
[Bug target/96827] [10/11 Regression] __m128i from _mm_set_epi32 is backwards with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96827 Joel Hutton changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #14 from Joel Hutton --- backported to GCC 10.
[Bug middle-end/91433] Performance Regression when upgrading from 8.3.0 to 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91433 Serge Belyshev changed: What|Removed |Added CC||belyshev at depni dot sinp.msu.ru --- Comment #10 from Serge Belyshev --- (In reply to George Fan from comment #8) > Please, give me some advise. Try changing inliner parameters, e.g. add --param=max-inline-insns-single=400 option to the commandline. (The default was switched from 400 to 200 in GCC-9)
[Bug ipa/97264] New: [11 Regression] -fpa-modref breaks va_arg on glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97264
Bug ID: 97264
Summary: [11 Regression] -fpa-modref breaks va_arg on glibc
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
Initially spotted the problem on glibc form master where fscanf() breaks in
complex ways.
I tried to minimize fscanf() down to a single file. Looks like -fno-ipa-modref
changes crashing to non-crashing program.
Full example:
// extracted from glibc's __vfscanf_internal()
void __isoc99_fscanf__ (const char *format, ...) __attribute__((noipa));
void __vfscanf_internal__ (const char *format, __builtin_va_list argptr)
__attribute__((noipa));
#define isd(c) ({ int __c = (c); __c >= '0' && __c <= '9'; })
static int
read_int (const unsigned char **pstr)
{
// read first digit '1'
int retval = **pstr - '0';
// skip digits: executes 0 times and advances pointer once
while (isd (*++(*pstr)))
;
return retval;
}
void __vfscanf_internal__ (const char *f, __builtin_va_list argptr)
{
/* assume input: "1<>\0" */
while (*f != '\0')
{
const unsigned char ** pstr = (const unsigned char **) &f;
// skip digit '1'
read_int (pstr);
/* Find the conversion specifier. */
f++; // skip '<'
char * str = __builtin_va_arg(argptr, char *);
f++; // skip ">"
*str++ = '?';
}
}
void __isoc99_fscanf__ (const char *format, ...)
{
__builtin_va_list arg;
__builtin_va_start (arg, format);
__vfscanf_internal__ (format, arg);
__builtin_va_end (arg);
}
int main (void)
{
char key[10];
__isoc99_fscanf__ ("1<>", key);
return 0;
}
How to crash:
$ gcc-11.0.0 -O2 uname.c -o uname11 && ./uname11
Segmentation fault (core dumped)
$ gcc-11.0.0 -O2 uname.c -o uname11 -fno-ipa-modref && ./uname11
[Bug ipa/97264] [11 Regression] -fpa-modref breaks va_arg on glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97264 --- Comment #1 from Sergei Trofimovich --- Created attachment 49295 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49295&action=edit uname.c
[Bug target/96428] [nvptx] nvptx_gen_shuffle does not handle V2DI mode – Fails with an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96428 Thomas Schwinge changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|REOPENED Resolution|FIXED |--- CC||tschwinge at gcc dot gnu.org Last reconfirmed||2020-10-01 --- Comment #7 from Thomas Schwinge --- First: Tobias, Tom, thanks for fixing this issue! (In reply to Tobias Burnus from comment #3) > Created attachment 48988 [details] > Test case (as diff – two files) These attachment 48988 testcases got included in commit 344f09a756ebd50510cc1eb3db111fd61c527702. I don't understand 'libgomp.oacc-fortran/pr96628-part1.f90': module m2 real*8 :: mysum !$acc declare device_resident(mysum) So 'mysum' lives in device-global memory. contains SUBROUTINE one(t) !$acc routine REAL*8, INTENT(IN):: t(:) mysum = sum(t) END SUBROUTINE one This now writes into device-global 'mysum', potentially from several gang/worker/vector threads in parallel, race condition? SUBROUTINE two(t) !$acc routine seq REAL*8, INTENT(INOUT) :: t(:) t = (100.0_8*t)/sum END SUBROUTINE two end module m2 source-gcc/libgomp/testsuite/libgomp.oacc-fortran/pr96628-part1.f90: In function ‘__m2_MOD_two’: source-gcc/libgomp/testsuite/libgomp.oacc-fortran/pr96628-part1.f90:18: warning: ‘sum’ is used uninitialized [-Wuninitialized] 18 | t = (100.0_8*t)/sum So, is this really testing what it means to be testing? Should the testcase get some 'target openacc_nvidia_accel_selected' 'scan-offload-rtl-dump' added to make sure that we're actually generating the expected PTX instructions? Also, the testcase files should be renamed 'libgomp.oacc-fortran/pr96428-*' to match the PR ID. (In reply to Tom de Vries from comment #4) > FTR, this is not the leanest solution. > followup patch: [...] > we have instead: [simpler] Any plans to apply that as a follow-up?
[Bug c++/97195] construct_at on a union member is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97195 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2805fcb32660bc0cdcd5ba54310f1f02651e039f commit r11-3581-g2805fcb32660bc0cdcd5ba54310f1f02651e039f Author: Jakub Jelinek Date: Thu Oct 1 11:16:44 2020 +0200 c++: Handle std::construct_at on automatic vars during constant evaluation [PR97195] As mentioned in the PR, we only support due to a bug in constant expressions std::construct_at on non-automatic variables, because we VERIFY_CONSTANT the second argument of placement new, which fails verification if it is an address of an automatic variable. The following patch fixes it by not performing that verification, the placement new evaluation later on will verify it after it is dereferenced. 2020-10-01 Jakub Jelinek PR c++/97195 * constexpr.c (cxx_eval_call_expression): Don't VERIFY_CONSTANT the second argument. * g++.dg/cpp2a/constexpr-new14.C: New test.
[Bug c++/96994] Missing code from consteval constructor initializing const variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96994 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:56da736cc6ced0f1c339744321a14ae569db8606 commit r11-3582-g56da736cc6ced0f1c339744321a14ae569db8606 Author: Jakub Jelinek Date: Thu Oct 1 11:18:35 2020 +0200 c++: Fix up default initialization with consteval default ctor [PR96994] > > The following testcase is miscompiled (in particular the a and i > > initialization). The problem is that build_special_member_call due to > > the immediate constructors (but not evaluated in constant expression mode) > > doesn't create a CALL_EXPR, but returns a TARGET_EXPR with CONSTRUCTOR > > as the initializer for it, > > That seems like the bug; at the end of build_over_call, after you > > >call = cxx_constant_value (call, obj_arg); > > You need to build an INIT_EXPR if obj_arg isn't a dummy. That works. obj_arg is NULL if it is a dummy from the earlier code. 2020-10-01 Jakub Jelinek PR c++/96994 * call.c (build_over_call): If obj_arg is non-NULL, return INIT_EXPR setting obj_arg to call. * g++.dg/cpp2a/consteval18.C: New test.
[Bug target/96428] [nvptx] nvptx_gen_shuffle does not handle V2DI mode – Fails with an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96428 --- Comment #8 from Tobias Burnus --- (In reply to Thomas Schwinge from comment #7) > These attachment 48988 [details] testcases got included in commit > 344f09a756ebd50510cc1eb3db111fd61c527702. (part of this PR, commit g:344f09a756ebd50510cc1eb3db111fd61c527702 ) > I don't understand ... > module m2 > real*8 :: mysum > !$acc declare device_resident(mysum) ... That's the disadvantage of turning a full program, which is ICEing during compilation, into a reduced testcase: it can easily happen that the reduced program is no longer sensible or valid. > So, is this really testing what it means to be testing? At least partially: yes – the compiler is no longer ICEing. But it probably should be fixed to be valid code and ... > Should the testcase get some 'target openacc_nvidia_accel_selected' > 'scan-offload-rtl-dump' added to make sure that we're actually generating > the expected PTX instructions? > Also, the testcase files should be renamed 'libgomp.oacc-fortran/pr96428-*' > to match the PR ID. ... does not harm, either. — Are you volunteering to do this?
[Bug ipa/97264] [11 Regression] -fpa-modref breaks va_arg on glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97264 Richard Biener changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |11.0 --- Comment #2 from Richard Biener --- a-t5.c.036t.fre1:ipa-modref: in __vfscanf_internal__/1, call to read_int/0 does not clobber f 2->2 a-t5.c.036t.fre1:ipa-modref: in __vfscanf_internal__/1, call to read_int/0 does not clobber f 2->2 I think this is 'const char *' vs. 'const unsigned char *' being TBAA incompatible. Changing read_int to take 'const char *pstr' fixes things (and changing the type in __vfscanf_internal__ as well). So this seems to be a latent bug in glibc unless somehow C makes those pointers magically compatible wrt TBAA. Joseph?
[Bug driver/97263] For -ffinite-math-only -OFast is not mentioned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97263 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-10-01 Version|unknown |10.2.1 Component|web |driver Status|UNCONFIRMED |NEW Keywords||documentation --- Comment #1 from Richard Biener --- Confirmed.
[Bug ipa/97264] [11 Regression] -fpa-modref breaks va_arg on glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97264
--- Comment #3 from Sergei Trofimovich ---
Oh, that makes sense.
> void __vfscanf_internal__ (const char *f, __builtin_va_list argptr)
> {
> /* assume input: "1<>\0" */
> while (*f != '\0')
> {
> const unsigned char ** pstr = (const unsigned char **) &f;
comes from
https://sourceware.org/git/?p=glibc.git;a=blob;f=stdio-common/vfscanf-internal.c;h=95b46dcbeb55b1724b396f02a940f3047259b926;hb=HEAD#l489
:
"""
274 int
275 __vfscanf_internal (FILE *s, const char *format, va_list argptr,
276 unsigned int mode_flags)
...
487 if (ISDIGIT ((UCHAR_T) *f))
488 {
489 argpos = read_int ((const UCHAR_T **) &f);
"""
[Bug ipa/97264] [11 Regression] -fpa-modref breaks va_arg on glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97264
--- Comment #4 from rguenther at suse dot de ---
On Thu, 1 Oct 2020, slyfox at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97264
>
> --- Comment #3 from Sergei Trofimovich ---
> Oh, that makes sense.
>
> > void __vfscanf_internal__ (const char *f, __builtin_va_list argptr)
> > {
> > /* assume input: "1<>\0" */
> > while (*f != '\0')
> > {
> > const unsigned char ** pstr = (const unsigned char **) &f;
>
> comes from
> https://sourceware.org/git/?p=glibc.git;a=blob;f=stdio-common/vfscanf-internal.c;h=95b46dcbeb55b1724b396f02a940f3047259b926;hb=HEAD#l489
> :
>
> """
> 274 int
> 275 __vfscanf_internal (FILE *s, const char *format, va_list argptr,
> 276 unsigned int mode_flags)
> ...
> 487 if (ISDIGIT ((UCHAR_T) *f))
> 488 {
> 489 argpos = read_int ((const UCHAR_T **) &f);
> """
>From this little context it eventually makes sense to declare
'f' as const unsigned char * in this function.
[Bug c++/97256] auto function return different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97256 --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > Yes, the lambda captures a local variable by value, Duh, sorry, I meant captures a local variables BY REFERENCE. > and then when you invoke > the lambda it refers to a dead variable.
[Bug c++/97256] auto function return different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97256 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely --- Yes, the lambda captures a local variable by value, and then when you invoke the lambda it refers to a dead variable.
[Bug target/96795] MVE: issue with polymorphism and integer promotion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96795 --- Comment #2 from CVS Commits --- The releases/gcc-10 branch has been updated by SRINATH PARVATHANENI : https://gcc.gnu.org/g:db66d2accee1a2f3fcd93b8cb5bcc3aa5b8ac10e commit r10-8835-gdb66d2accee1a2f3fcd93b8cb5bcc3aa5b8ac10e Author: Srinath Parvathaneni Date: Wed Sep 30 15:19:17 2020 +0100 arm: Fix MVE intrinsics polymorphic variants wrongly generating __ARM_undef type (pr96795). This patch fixes (PR96795) MVE intrinsic polymorphic variants vaddq, vaddq_m, vaddq_x, vcmpeqq_m, vcmpeqq, vcmpgeq_m, vcmpgeq, vcmpgtq_m, vcmpgtq, vcmpleq_m, vcmpleq, vcmpltq_m, vcmpltq, vcmpneq_m, vcmpneq, vfmaq_m, vfmaq, vfmasq_m, vfmasq, vmaxnmavq, vmaxnmavq_p, vmaxnmvq, vmaxnmvq_p, vminnmavq, vminnmavq_p, vminnmvq, vminnmvq_p, vmulq_m, vmulq, vmulq_x, vsetq_lane, vsubq_m, vsubq and vsubq_x which are incorrectly generating __ARM_undef and mismatching the passed floating point scalar arguments. Bootstrapped on arm-none-linux-gnueabihf and regression tested on arm-none-eabi and found no regressions. gcc/ChangeLog: 2020-09-30 Srinath Parvathaneni PR target/96795 * config/arm/arm_mve.h (__ARM_mve_coerce2): Define. (__arm_vaddq): Correct the scalar argument. (__arm_vaddq_m): Likewise. (__arm_vaddq_x): Likewise. (__arm_vcmpeqq_m): Likewise. (__arm_vcmpeqq): Likewise. (__arm_vcmpgeq_m): Likewise. (__arm_vcmpgeq): Likewise. (__arm_vcmpgtq_m): Likewise. (__arm_vcmpgtq): Likewise. (__arm_vcmpleq_m): Likewise. (__arm_vcmpleq): Likewise. (__arm_vcmpltq_m): Likewise. (__arm_vcmpltq): Likewise. (__arm_vcmpneq_m): Likewise. (__arm_vcmpneq): Likewise. (__arm_vfmaq_m): Likewise. (__arm_vfmaq): Likewise. (__arm_vfmasq_m): Likewise. (__arm_vfmasq): Likewise. (__arm_vmaxnmavq): Likewise. (__arm_vmaxnmavq_p): Likewise. (__arm_vmaxnmvq): Likewise. (__arm_vmaxnmvq_p): Likewise. (__arm_vminnmavq): Likewise. (__arm_vminnmavq_p): Likewise. (__arm_vminnmvq): Likewise. (__arm_vminnmvq_p): Likewise. (__arm_vmulq_m): Likewise. (__arm_vmulq): Likewise. (__arm_vmulq_x): Likewise. (__arm_vsetq_lane): Likewise. (__arm_vsubq_m): Likewise. (__arm_vsubq): Likewise. (__arm_vsubq_x): Likewise. gcc/testsuite/ChangeLog: PR target/96795 * gcc.target/arm/mve/intrinsics/mve_fp_vaddq_n.c: New Test. * gcc.target/arm/mve/intrinsics/mve_vaddq_n.c: Likewise. * gcc.target/arm/mve/intrinsics/vaddq_m_n_f16-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vaddq_m_n_f32-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vaddq_x_n_f16-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vaddq_x_n_f32-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpeqq_m_n_f16-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpeqq_m_n_f32-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpeqq_n_f16-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpeqq_n_f32-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpgeq_m_n_f16-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpgeq_m_n_f32-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpgeq_n_f16-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpgeq_n_f32-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpgtq_m_n_f16-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpgtq_m_n_f32-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpgtq_n_f16-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpgtq_n_f32-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpleq_m_n_f16-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpleq_m_n_f32-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpleq_n_f16-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpleq_n_f32-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpltq_m_n_f16-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpltq_m_n_f32-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpltq_n_f16-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpltq_n_f32-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpneq_m_n_f16-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpneq_m_n_f32-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpneq_n_f16-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vcmpneq_n_f32-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vfmaq_m_n_f16-1.c: Likewise. * gcc.target/arm/mve/intrinsics/vfm
[Bug target/96795] MVE: issue with polymorphism and integer promotion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96795 SRINATH PARVATHANENI changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from SRINATH PARVATHANENI --- Fixed in trunk and gcc-10.
[Bug tree-optimization/97255] [8/9/10 Regression] Vectorizer gives a boolean a value of 255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97255 Richard Biener changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9/10 Regression] |Vectorizer gives a boolean |Vectorizer gives a boolean |a value of 255 |a value of 255 Known to work||11.0 Priority|P3 |P2 --- Comment #4 from Richard Biener --- commit 36e691d3a62145fda1f4a1b3143d215cc113c10a (origin/master, origin/HEAD) Author: Richard Biener Date: Thu Oct 1 09:29:32 2020 +0200 tree-optimization/97255 - missing vector bool pattern of SRAed bool SRA tends to use VIEW_CONVERT_EXPR when replacing bool fields with unsigned char fields. Those are not handled in vector bool pattern detection causing vector true values to leak. The following fixes this by turning those into b ? 1 : 0 as well. 2020-10-01 Richard Biener * tree-vect-patterns.c (vect_recog_bool_pattern): Also handle VIEW_CONVERT_EXPR. * g++.dg/vect/pr97255.cc: New testcase.
[Bug c/97265] New: new warning with clang build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97265
Bug ID: 97265
Summary: new warning with clang build
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
I just tried a build of gcc trunk with clang. It said
trunk.git/gcc/vec.h:543:13: warning: 'constexpr' non-static member function
will not be implicitly 'const' in C++14; add 'const' to avoid a change in
behavior [-Wconstexpr-not-const]
I don't remember this warning from last week's clang build.
Source code is
CONSTEXPR operator vec () { return vec(); }
My best guess is that
CONSTEXPR operator vec () const { return vec(); }
will shut up clang.
[Bug ipa/97264] [11 Regression] -fpa-modref breaks va_arg on glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97264 --- Comment #5 from Andreas Schwab --- Why doesn't gcc warn about that?
[Bug target/97259] Incorrect ENQCMD and ENQCMDS patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97259 H.J. Lu changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from H.J. Lu --- Never mind. The register operand is a memory-mapped I/O address.
[Bug ipa/97264] [11 Regression] -fpa-modref breaks va_arg on glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97264
--- Comment #6 from Richard Biener ---
(In reply to Andreas Schwab from comment #5)
> Why doesn't gcc warn about that?
It does:
unsigned char **q;
void foo (char *p)
{
q = (unsigned char **)&p;
}
> gcc t.c -fstrict-aliasing -Wstrict-aliasing=2 -S
t.i: In function 'foo':
t.i:4:3: warning: dereferencing type-punned pointer will break strict-aliasing
rules [-Wstrict-aliasing]
q = (unsigned char **)&p;
^
note the default level of -Wstrict-aliasing when enabled is 3 which will
not warn when the pointer is not dereferenced in the same expression.
[Bug target/96827] [10/11 Regression] __m128i from _mm_set_epi32 is backwards with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96827 --- Comment #15 from CVS Commits --- The releases/gcc-10 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:1c959dedbde7cc64747cf13fa76b4e8654be26ea commit r10-8836-g1c959dedbde7cc64747cf13fa76b4e8654be26ea Author: H.J. Lu Date: Wed Sep 30 08:13:21 2020 -0700 Add a testcase for PR target/96827 Add a testcase for PR target/96827 which was fixed by r11-3559: commit 97b798d80baf945ea28236eef3fa69f36626b579 Author: Joel Hutton Date: Wed Sep 30 15:08:13 2020 +0100 [SLP][VECT] Add check to fix 96837 PR target/96827 * gcc.target/i386/pr96827.c: New test. (cherry picked from commit 373b99dc40949efa697326f378e5022a02e0328b)
[Bug target/96428] [nvptx] nvptx_gen_shuffle does not handle V2DI mode – Fails with an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96428 Tom de Vries changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Tom de Vries --- Thomas, these are fine follow-up comments, but given that there's currently no ICE and there's a test-case in place to check that, this is resolved-fixed.
[Bug c/97265] new warning with clang build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97265 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-10-01 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- Yes, your suggested change is correct, making the code mean the same thing in both C++11 and C++14. It also makes the function more consistent whether CONSTEXPR expands to constexpr or not.
[Bug tree-optimization/97228] [11 regression] New ICEs on arm since r11-3426 g:10843f8303509fcba880c6c05c08e4b4ccd24f36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97228 rsandifo at gcc dot gnu.org changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #4 from rsandifo at gcc dot gnu.org --- About to post a patch.
[Bug ipa/97244] [11 Regression] ICE in ipa_edge_args_sum_t::duplicate at gcc/ipa-prop.c:4251 since r11-3478-gada353b87909fd6c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97244 --- Comment #2 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:bc2fcccd9d5cc9d346543a98c98dc00d71e9a5b8 commit r11-3589-gbc2fcccd9d5cc9d346543a98c98dc00d71e9a5b8 Author: Jan Hubicka Date: Thu Oct 1 15:03:19 2020 +0200 Fix ICE in ipa_edge_args_sum_t::duplicate PR ipa/97244 * ipa-fnsummary.c (pass_free_fnsummary::execute): Free also indirect inlining datastructure. * ipa-modref.c (pass_ipa_modref::execute): Do not free them here. * ipa-prop.c (ipa_free_all_node_params): Do not crash when info does not exist. (ipa_unregister_cgraph_hooks): Likewise.
[Bug ipa/97244] [11 Regression] ICE in ipa_edge_args_sum_t::duplicate at gcc/ipa-prop.c:4251 since r11-3478-gada353b87909fd6c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97244 --- Comment #3 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:a12041339e8032f40acd5f1c0365f5b3a1469bf5 commit r11-3590-ga12041339e8032f40acd5f1c0365f5b3a1469bf5 Author: Jan Hubicka Date: Thu Oct 1 15:03:45 2020 +0200 Add -fno-ipa-modref to gcc.dg/ipa/remref-2a.c PR ipa/97244 * gcc.dg/ipa/remref-2a.c: Add -fno-ipa-modref
[Bug ipa/97235] [11 Regression] ICE in duplicate, at ipa-prop.c:4251 since r11-3478-gada353b87909fd6c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97235 Jan Hubicka changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #3 from Jan Hubicka --- This is the same issues at 97244 *** This bug has been marked as a duplicate of bug 97244 ***
[Bug ipa/97244] [11 Regression] ICE in ipa_edge_args_sum_t::duplicate at gcc/ipa-prop.c:4251 since r11-3478-gada353b87909fd6c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97244 Jan Hubicka changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #4 from Jan Hubicka --- *** Bug 97235 has been marked as a duplicate of this bug. ***
[Bug pch/97226] ICE in gt_pch_note_object at ggc-common.c:276
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97226 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-10-01 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Can't reproduce on current master with a cross compiler.
[Bug ipa/97244] [11 Regression] ICE in ipa_edge_args_sum_t::duplicate at gcc/ipa-prop.c:4251 since r11-3478-gada353b87909fd6c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97244 Jan Hubicka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jan Hubicka --- Fixed.
[Bug c++/89062] class template argument deduction failure with parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89062 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #6 from Marek Polacek --- Unfortunately, not yet. I've taken a look at this, and I think I know what the problem is, but haven't written a fix yet.
[Bug libgomp/81778] libgomp.c/for-5.c failure on nvptx -- illegal memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81778
--- Comment #9 from Tom de Vries ---
I ran into this again, and did another round of minimizing. This time, I added
some buffering around where we write, and check the entire buffer afterwards:
...
$ cat libgomp/testsuite/libgomp.c-c++-common/for-5.c
/* { dg-additional-options "-std=gnu99" { target c } } */
#include
#define N 4096
#define MID (N/2)
#define M 4
#pragma omp declare target
int a[N];
#pragma omp end declare target
int
main (void)
{
int i;
for (i = 0; i < N; i++)
a[i] = 0;
#pragma omp target update to(a)
int s = 1;
#pragma omp target simd
for (int i = M - 1; i > -1; i -= s)
a[MID + i] = 1;
#pragma omp target update from(a)
int error_found = 0;
for (i = 0; i < N; i++)
{
int expected = (MID <= i && i < MID + M) ? 1 : 0;
if (a[i] == expected)
continue;
error_found = 1;
printf ("Expected %d, got %u at %d\n", expected, a[i], i);
}
if (error_found)
__builtin_abort ();
return 0;
}
...
Indeed we're writing more than required (for M == 4, we just want the locations
2048..2051):
...
$ LD_LIBRARY_PATH=$(pwd -P)/install/lib64 ./for-5.exe
Expected 0, got 1 at 1955
Expected 0, got 1 at 1986
Expected 0, got 1 at 1987
Expected 0, got 1 at 2017
Expected 0, got 1 at 2018
Expected 0, got 1 at 2019
Aborted (core dumped)
...
Fails for M >= 2.
Managed Service Providers Contact Info
Hi, Are looking for a customer bases of your Competitors Installed Base which will help you reach niche target and also helps you to grab new clients for your latest service and products? We also have an exclusive database of: 1. Cloud Service Providers- CSPs 2. Independent Software Vendors- ISVs 3. System Integrators- SIs and more 4. Managed Service Providers- MSPs 5. Managed Security Service Providers- MSSPs and more Data can be customized based upon your requirement (e.g. Job title, Verticals, Geography etc.) Let me know if you are looking for any other tech users contact information at this point of time. Looking forward to hear from you. Regards, Tracy Lopez Sr Demand Generation Head Note: This email is not expected to be a spam. It would be ideal if you acknowledge our conciliatory sentiments and answer in the subject taking with leave off to be expelled from our Mailing list. Why not try it/us out?
[Bug ipa/97243] [11 Regression] ICE in compute_parm_map at gcc/ipa-modref.c:1368 since r11-3478-gada353b87909fd6c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97243 --- Comment #1 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:73c977cb0a112ac58fae18af44576ade8ab3aa26 commit r11-3592-g73c977cb0a112ac58fae18af44576ade8ab3aa26 Author: Jan Hubicka Date: Thu Oct 1 15:43:56 2020 +0200 Add gcc.c-torture/compile/pr97243.c testcase. PR ipa/97243 * gcc.c-torture/compile/pr97243.c: New test.
[Bug ipa/97243] [11 Regression] ICE in compute_parm_map at gcc/ipa-modref.c:1368 since r11-3478-gada353b87909fd6c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97243 Jan Hubicka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jan Hubicka --- Fixed.
[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #3 from Jan Hubicka --- Martin, the infor about ipa pass being modref is stale. It happens during the final streamout.
[Bug tree-optimization/97236] [10/11 Regression] g:e93428a8b056aed83a7678 triggers vlc miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97236 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:04b99da898a9817e72fedb4063589648b7961ac5 commit r11-3594-g04b99da898a9817e72fedb4063589648b7961ac5 Author: Richard Biener Date: Thu Oct 1 15:12:35 2020 +0200 tree-optimization/97236 - fix bad use of VMAT_CONTIGUOUS This avoids using VMAT_CONTIGUOUS with single-element interleaving when using V1mode vectors. Instead keep VMAT_ELEMENTWISE but continue to avoid load-lanes and gathers. 2020-10-01 Richard Biener PR tree-optimization/97236 * tree-vect-stmts.c (get_group_load_store_type): Keep VMAT_ELEMENTWISE for single-element vectors. * gcc.dg/vect/pr97236.c: New testcase.
[Bug tree-optimization/97236] [10 Regression] g:e93428a8b056aed83a7678 triggers vlc miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97236 Richard Biener changed: What|Removed |Added Known to work||10.1.0, 11.0 Summary|[10/11 Regression] |[10 Regression] |g:e93428a8b056aed83a7678|g:e93428a8b056aed83a7678 |triggers vlc miscompile |triggers vlc miscompile Known to fail||10.2.0 --- Comment #7 from Richard Biener --- Fixed on trunk sofar.
[Bug ipa/97133] [11 Regression] ICE: tree code 'bind_expr' is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97133 --- Comment #3 from Jan Hubicka --- modref is a stale infoa (streaming happens after running the ipa passes and moref is last). It is Maritn Sebor's change.
[Bug c/97261] distinguish invalid subscripts from invalid addresses in -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97261
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Summary|gcc-10 produces invalid |distinguish invalid
|-Warray-bounds warning |subscripts from invalid
||addresses in -Warray-bounds
Last reconfirmed||2020-10-01
Severity|normal |enhancement
--- Comment #5 from Martin Sebor ---
Where pointers (as opposed to arrays) are involved, the IL doesn't
differentiate taking the address of a subscript expression like &pb[-1] from
pointer subtraction like (pb - 1). So changing the text of the warning, while
possible, will come with a trade-off: losing the part about the
invalid/negative subscript in the former cases.
That said, the current detection of out of bounds pointers is incomplete and
could stand to be enhanced to also detect the case below. Let me look into
adjusting the wording when I work on that.
$ cat x.c && gcc -O2 -S -Wall x.c
int a[2];
int* f (int i)
{
i = 3;
return a + i; // warning
}
int* g (int i)
{
if (i < 3)
i = 3;
return a + i; // missing warning
}
x.c: In function ‘f’:
x.c:6:12: warning: array subscript 3 is outside array bounds of ‘int[2]’
[-Warray-bounds]
6 | return a + i;
| ~~^~~
x.c:1:5: note: while referencing ‘a’
1 | int a[2];
| ^
[Bug target/96375] [11 regression] arm/lob[2-5].c fail on some configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96375 --- Comment #6 from CVS Commits --- The master branch has been updated by Andrea Corallo : https://gcc.gnu.org/g:968ec08efefeea6fbc0cdc379e98ce3e28904083 commit r11-3598-g968ec08efefeea6fbc0cdc379e98ce3e28904083 Author: Andrea Corallo Date: Thu Oct 1 17:16:00 2020 +0200 arm: Fix testcase selection for Low Overhead Loop tests [PR96375] gcc/testsuite/ PR target/96375 * gcc.target/arm/lob1.c: Fix missing flag. * gcc.target/arm/lob2.c: Likewise. * gcc.target/arm/lob3.c: Likewise. * gcc.target/arm/lob4.c: Likewise. * gcc.target/arm/lob5.c: Likewise. * gcc.target/arm/lob6.c: Likewise. * lib/target-supports.exp (check_effective_target_arm_v8_1_lob_ok): Return 1 only for cortex-m targets, add '-mthumb' flag.
[Bug lto/97133] [11 Regression] ICE: tree code 'bind_expr' is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97133
Martin Sebor changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW |RESOLVED
Component|ipa |lto
--- Comment #4 from Martin Sebor ---
This is the same ICE as in PR97172:
static void
lto_write_tree (struct output_block *ob, tree expr, bool ref_p)
{
if (!lto_is_streamable (expr))
internal_error ("tree code %qs is not supported in LTO streams",
get_tree_code_name (TREE_CODE (expr)));
and EXPR is BIND_EXPR. It's emitted by the C front end for the VLA parameter
in the definition of
int
qux (int n, int a[(int (*)[n]) { 0 } == 0])
like so:
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type
0x7fffea8105e8 precision:32 min max
pointer_to_this >
public unsigned DI
size
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea8189d8>
used unsigned read decl_0 DI
/src/gcc/master/gcc/testsuite/gcc.dg/pr88701.c:15:17 size unit-size
align:64 warn_if_not_align:0 context
attributes
value
chain
side-effects
arg:0
side-effects
arg:0
side-effects arg:1 >
arg:1
side-effects arg:0 >>
arg:1
/src/gcc/master/gcc/testsuite/gcc.dg/pr88701.c:15:38 start:
/src/gcc/master/gcc/testsuite/gcc.dg/pr88701.c:15:32 finish:
/src/gcc/master/gcc/testsuite/gcc.dg/pr88701.c:15:41 arg-type >
lto_is_streamable() is defined to return false for BIND_EXPR (and SSA_NAME)
like so:
/* Return true if EXPR is a tree node that can be written to disk. */
static inline bool
lto_is_streamable (tree expr)
{
enum tree_code code = TREE_CODE (expr);
/* Notice that we reject SSA_NAMEs as well. We only emit the SSA
name version in lto_output_tree_ref (see output_ssa_names). */
return !is_lang_specific (expr)
&& code != SSA_NAME
&& code != LANG_TYPE
&& code != MODIFY_EXPR
&& code != INIT_EXPR
&& code != TARGET_EXPR
&& code != BIND_EXPR
&& code != WITH_CLEANUP_EXPR
&& code != STATEMENT_LIST
&& (code == CASE_LABEL_EXPR
|| code == DECL_EXPR
|| TREE_CODE_CLASS (code) != tcc_statement);
}
*** This bug has been marked as a duplicate of bug 97172 ***
[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172 --- Comment #4 from Martin Sebor --- *** Bug 97133 has been marked as a duplicate of this bug. ***
[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172 --- Comment #5 from Martin Sebor --- I'm not at all familiar with this part of GCC so I'm not sure what needs to be done here. It seems to me that the streamer is missing support for certain trees under some conditions. It knows how to stream SSA_NAMEs but apparently isn't prepared for them in attributes -- I put more detail in bug 97133 comment #4.
[Bug tree-optimization/97260] [9/10/11 regression] memcmp of constant string and local constant array not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97260 --- Comment #4 from Martin Sebor --- It should be possible to handle in the strlen pass.
[Bug testsuite/96519] [11 regression] new test case gcc.dg/ia64-sync-5.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96519 Thomas Schwinge changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |kcy at codesourcery dot com CC||tschwinge at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Thomas Schwinge --- As far as I can tell, fixed with Kwok's patch to use explicit 'signed char'.
[Bug c++/97230] Invocation of non-static member function on a null instance in core constant expression should not be allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97230 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #3 from Marek Polacek --- https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555282.html
[Bug c++/97014] Class NTTPs not demangled in the compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97014 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Keywords||diagnostic Last reconfirmed||2020-10-01 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/97052] Internal compiler error with substitution failure in template parameter list of concept declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97052
David Stone changed:
What|Removed |Added
CC||david at doublewise dot net
--- Comment #2 from David Stone ---
Turns out the substitution failure is a red herring. Here is a simpler
reproduction:
```
template
concept foo = true;
void f(foo auto) {
}
```
[Bug ipa/96394] [10/11 Regression] ICE in add_new_edges_to_heap, at ipa-inline.c:1746 (-O3 PGO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394 --- Comment #18 from Martin Jambor --- I proposed the patch on the mailing list (I guess I should put Martin's name at least to the testsuite ChangeLog and probably to both): https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555284.html
[Bug c++/94554] spurious -Waddress warning within "if constexpr" function-null compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94554
Marco Trevisan changed:
What|Removed |Added
CC||mail at 3v1n0 dot net
--- Comment #5 from Marco Trevisan ---
I don't think g++ is totally wrong here,
Actually, if any, it should be stronger in making the error clearer and louder,
as per sé it's fine to consider that you're for real not comparing something
constant and the function address may not be known at compile time, so not
wrong to check.
However, something that will not error but work can be something like:
#include
#include
using namespace std;
int meow() { return 1; }
void kitty(int i) { std::cout << "Mowed vlaue " << i << "\n"; }
template
void test() {
using NullType = std::integral_constant;
using ActualType = std::integral_constant;
if constexpr (!std::is_same_v) {
kitty(F());
} else {
kitty(22);
}
}
int main()
{
test();
test();
return 0;
}
[Bug middle-end/95673] missing -Wstring-compare for an impossible strncmp test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95673 Martin Sebor changed: What|Removed |Added Target Milestone|--- |11.0 Keywords||patch --- Comment #7 from Martin Sebor --- Patch to enhance the warning: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555225.html
[Bug c++/97266] New: "enum constant in boolean context" warning seems incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97266
Bug ID: 97266
Summary: "enum constant in boolean context" warning seems
incorrect
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mfarazma.ext at gmail dot com
Target Milestone: ---
```
#include
enum ValidateFlag : int8_t {
a = 0, b , c
};
int main(){
bool t = static_cast(c);
return static_cast(t);
}
```
Compiling the above code with `g++ -Wall test.cc` generates this warning:
warning: enum constant in boolean context [-Wint-in-bool-context]
The behaviour doesn't seem correct as `c` is just an `int8_t` value, and
casting an `int8_t` value to `bool` does not generate any warnings:
```
int8_t c = 2;
bool t = static_cast(c);
return static_cast(t);
```
Having only 2 values in the enum also makes it compile fine:
```
enum ValidateFlag : int8_t {
a = 0, c
};
```
[Bug ipa/96394] [10/11 Regression] ICE in add_new_edges_to_heap, at ipa-inline.c:1746 (-O3 PGO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394 --- Comment #19 from Martin Liška --- (In reply to Martin Jambor from comment #18) > I proposed the patch on the mailing list (I guess I should put Martin's name > at least to the testsuite ChangeLog and probably to both): > Don't worry about it, just leave the patch as is.
[Bug c++/97266] "enum constant in boolean context" warning seems incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97266
--- Comment #1 from Jonathan Wakely ---
(In reply to m farazma from comment #0)
> ```
> #include
>
> enum ValidateFlag : int8_t {
>a = 0, b , c
> };
>
> int main(){
> bool t = static_cast(c);
> return static_cast(t);
> }
> ```
>
> Compiling the above code with `g++ -Wall test.cc` generates this warning:
>
> warning: enum constant in boolean context [-Wint-in-bool-context]
>
> The behaviour doesn't seem correct as `c` is just an `int8_t` value,
No it isn't. In C enumerators are just integers, but in C++ they have the same
type as the enumeration type they belong to.
> and
> casting an `int8_t` value to `bool` does not generate any warnings:
>
> ```
> int8_t c = 2;
> bool t = static_cast(c);
> return static_cast(t);
> ```
I don't know why this is different. I would expect them to be consistent.
> Having only 2 values in the enum also makes it compile fine:
> ```
> enum ValidateFlag : int8_t {
>a = 0, c
> };
In this case c=1 so there's no change in value when casting to bool. The
warning is for uses of integers other than 0 and 1.
[Bug c++/97266] "enum constant in boolean context" warning seems incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97266
--- Comment #2 from m farazma ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to m farazma from comment #0)
> > ```
> > #include
> >
> > enum ValidateFlag : int8_t {
> >a = 0, b , c
> > };
> >
> > int main(){
> > bool t = static_cast(c);
> > return static_cast(t);
> > }
> > ```
> >
> > Compiling the above code with `g++ -Wall test.cc` generates this warning:
> >
> > warning: enum constant in boolean context [-Wint-in-bool-context]
> >
> > The behaviour doesn't seem correct as `c` is just an `int8_t` value,
>
> No it isn't. In C enumerators are just integers, but in C++ they have the
> same type as the enumeration type they belong to.
>
But isn't the type of the enum set to be `int8_t` in this example?
In which case casting from `int8_t` to `bool` should be straight forward and
without warnings.
[Bug gcov-profile/97069] Zero valued #line directive results in excessively large blocks of memory being allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97069 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Martin Liska : https://gcc.gnu.org/g:bc3914f307211c42f31af7e64d2e6cc8a69837cb commit r10-8838-gbc3914f307211c42f31af7e64d2e6cc8a69837cb Author: Martin Liska Date: Mon Sep 21 16:26:10 2020 +0200 gcov: fix streaming corruption gcc/ChangeLog: PR gcov-profile/97069 * profile.c (branch_prob): Line number must be at least 1. gcc/testsuite/ChangeLog: PR gcov-profile/97069 * g++.dg/gcov/pr97069.C: New test. (cherry picked from commit 6b4e8bf88f1172ce8561f57b12fb81063b21a78f)
[Bug tree-optimization/96979] [9/10/11 Regression] Switch with case values derived from constexpr function takes unreasonable time to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96979 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Martin Liska : https://gcc.gnu.org/g:b62c649466f3ae029bf348027ece9530f79d3ce1 commit r10-8839-gb62c649466f3ae029bf348027ece9530f79d3ce1 Author: Martin Liska Date: Thu Sep 24 13:34:13 2020 +0200 switch conversion: make a rapid speed up gcc/ChangeLog: PR tree-optimization/96979 * tree-switch-conversion.c (jump_table_cluster::can_be_handled): Make a fast bail out. (bit_test_cluster::can_be_handled): Likewise here. * tree-switch-conversion.h (get_range): Use wi::to_wide instead of a folding. gcc/testsuite/ChangeLog: PR tree-optimization/96979 * g++.dg/tree-ssa/pr96979.C: New test. (cherry picked from commit e46858e445d35ca4a7df1996186fe884879b)
[Bug gcov-profile/64636] LTO PGO bootstrap fails on linux-sparc64 in stream_out_histogram_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636 --- Comment #17 from CVS Commits --- The releases/gcc-10 branch has been updated by Martin Liska : https://gcc.gnu.org/g:84dc3879f377ddaecb4054a7bf7671114dfb7228 commit r10-8840-g84dc3879f377ddaecb4054a7bf7671114dfb7228 Author: Martin Liska Date: Fri Sep 25 16:21:34 2020 +0200 gcov: fix streaming of HIST_TYPE_IOR histogram type. gcc/ChangeLog: PR gcov-profile/64636 * value-prof.c (stream_out_histogram_value): Allow negative values for HIST_TYPE_IOR. (cherry picked from commit 1921ebcaf6467996aede69e1bbe32400d8a20fe7)
[Bug target/80845] nvptx backend generates cvt.u32.u32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80845
--- Comment #5 from CVS Commits ---
The master branch has been updated by Tom de Vries :
https://gcc.gnu.org/g:b3ec0de08250d7e0599e36895d5cb727016c81d3
commit r11-3601-gb3ec0de08250d7e0599e36895d5cb727016c81d3
Author: Tom de Vries
Date: Thu Oct 1 11:07:20 2020 +0200
[nvptx] Emit mov.u32 instead of cvt.u32.u32 for truncsiqi2
When running:
...
$ gcc.sh src/gcc/testsuite/gcc.target/nvptx/abi-complex-arg.c -S -dP
...
we have in abi-complex-arg.s:
...
//(insn 3 5 4 2
// (set
//(reg:QI 23)
//(truncate:QI (reg:SI 22))) "abi-complex-arg.c":38:1 29 {truncsiqi2}
// (nil))
cvt.u32.u32 %r23, %r22; // 3[c=4] truncsiqi2/0
...
The cvt.u32.u32 can be written shorter and clearer as mov.u32.
Fix this in define_insn "truncsi2".
Tested on nvptx.
gcc/ChangeLog:
2020-10-01 Tom de Vries
PR target/80845
* config/nvptx/nvptx.md (define_insn "truncsi2"): Emit
mov.u32
instead of cvt.u32.u32.
[Bug target/80845] nvptx backend generates cvt.u32.u32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80845 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Tom de Vries --- The committed patch fixes the issue mentioned in comment 0. The issue from comment 3 no longer reproduces. Marking resolved-fixed.
[Bug c++/97014] Class NTTPs not demangled in the compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97014 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/97266] "enum constant in boolean context" warning seems incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97266 --- Comment #3 from Jonathan Wakely --- No, the type is ValidateFlag. It has an underlying type of int8_t, but that just means it has the same size and range of values as int8_t. It's not actually that type.
[Bug c++/97266] "enum constant in boolean context" warning seems incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97266 --- Comment #4 from m farazma --- (In reply to Jonathan Wakely from comment #3) > No, the type is ValidateFlag. It has an underlying type of int8_t, but that > just means it has the same size and range of values as int8_t. It's not > actually that type. Sorry for the confusion, I've tried creating a new variable with the following 2 types: ``` ValidateFlag v = c; bool t = static_cast(v); ``` and ``` int8_t i = c; bool t = static_cast(i); ``` and they both compile whiteout a warning, but using `c` itself causes the issue.
[Bug libgomp/81778] libgomp.c/for-5.c failure on nvptx -- illegal memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81778 --- Comment #10 from Tom de Vries --- Tentative patch: ... diff --git a/gcc/omp-expand.c b/gcc/omp-expand.c index 99cb4f9dda4..034de497390 100644 --- a/gcc/omp-expand.c +++ b/gcc/omp-expand.c @@ -6333,6 +6333,8 @@ expand_omp_simd (struct omp_region *region, struct omp_for_data *fd) /* Collapsed loops not handled for SIMT yet: limit to one lane only. */ if (fd->collapse > 1) simt_maxlane = build_one_cst (unsigned_type_node); + else if (TREE_CODE (fd->loops[0].step) != INTEGER_CST) + simt_maxlane = build_one_cst (unsigned_type_node); else if (safelen_int < omp_max_simt_vf ()) simt_maxlane = build_int_cst (unsigned_type_node, safelen_int); tree vf @@ -6636,6 +6638,10 @@ expand_omp_simd (struct omp_region *region, struct omp_for_data *fd) else t = fold_build2 (PLUS_EXPR, type, fd->loop.v, step); expand_omp_build_assign (&gsi, fd->loop.v, t); + /* The alternative IV needs to to be updated as well, but isn't +currently. Assert that we fall back to simt_maxlane == 1. */ + gcc_assert (altv == NULL_TREE + || tree_int_cst_equal (simt_maxlane, integer_one_node)); } /* Remove GIMPLE_OMP_RETURN. */ ...
[Bug c++/97256] auto function return different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97256 Richard Smith changed: What|Removed |Added CC||richard-gccbugzilla@metafoo ||.co.uk --- Comment #4 from Richard Smith --- The reference to 'b' from within the lambda is not an odr-use, so is not transformed into a use of the lambda's capture. This program has defined behavior and is being miscompiled.
[Bug c++/97256] auto function return different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97256 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Resolution|INVALID |--- Status|RESOLVED|NEW Last reconfirmed||2020-10-02 --- Comment #5 from Marek Polacek --- Re-opening then, thanks.
[Bug target/69286] trunk/libgcc/config/s390/tpf-unwind.h: 28 redundant condition ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69286 Eric Gallager changed: What|Removed |Added Keywords||easyhack Status|UNCONFIRMED |NEW Last reconfirmed||2020-10-02 Ever confirmed|0 |1 CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Ulrich Weigand from comment #2) > Yes, it does appear I checked in this code, but the tpf-unwind.h changes > were actually provided by Jim Johnston on the IBM TPF team: > https://gcc.gnu.org/ml/gcc-patches/2014-07/msg02104.html > > In any case, feel free to make the obvious change here :-) taking this as confirmation
[Bug middle-end/97267] New: Missed tail calls on ppc64 ELFv2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97267
Bug ID: 97267
Summary: Missed tail calls on ppc64 ELFv2
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
static int __attribute__ ((__noclone__, __noinline__))
reg_args (int j1, int j2, int j3, int j4, int j5, int j6, int j7, int j8)
{
return j1 + j2 + j3 + j4 + j5 + j6 + j7 + j8;
}
int __attribute__ ((__noclone__, __noinline__))
stack_args (int j1, int j2, int j3, int j4, int j5, int j6, int j7, int j8,
int j9)
{
if (j9 == 0)
return 0;
return reg_args (j1, j2, j3, j4, j5, j6, j7, j8);
}
This ought to result on a tail call from stack_args to reg_args on ELFv2 like
it does on ELFv1, ppc32, x86_64 and so on. Failure to do so is the result of
an overly restrictive test in calls.c:can_implement_as_sibling_call_p.
[Bug middle-end/97267] Missed tail calls on ppc64 ELFv2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97267 Alan Modra changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-10-02 Ever confirmed|0 |1
[Bug target/96828] Wrong code generated with -fstack-protector and -msingle-pic-base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96828 --- Comment #1 from Ilya Oleinik --- Created attachment 49296 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49296&action=edit patch
[Bug target/96828] Wrong code generated with -fstack-protector and -msingle-pic-base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96828 --- Comment #2 from Ilya Oleinik --- Seems like PR85434 caused this issue. This patch fixes it, however i'm not sure if mov instruction insertion is the right way of fixing armv6m inability to do a load from hiregs.
[Bug c++/97256] auto function return different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97256 --- Comment #6 from Richard Smith --- My apologies, I misread the testcase. Yes, this is UB.
[Bug c++/97268] New: Segfault on 11.0.0 20200930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97268 Bug ID: 97268 Summary: Segfault on 11.0.0 20200930 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ext-gcc at burakarslan dot com Target Milestone: --- Created attachment 49297 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49297&action=edit testcase The following code seems to crash on gcc HEAD: https://wandbox.org/permlink/O9ZzBf1aG9tTwTAl It also doesn't compile with gcc 9.x or 10.x while clang 10 seems to have no problems for reasons unknown to me. Output: ``` during GIMPLE pass: *early_warn_uninitialized prog.cc: In constructor 'BetterObject::BetterObject(const char*, int, Handle&) [with bool CACHED = true]': prog.cc:63:1: internal compiler error: Segmentation fault 63 | } | ^ 0xc2495f crash_signal ../../source/gcc/toplev.c:329 0xceb9ba ao_ref_init_from_ptr_and_size(ao_ref*, tree_node*, tree_node*) ../../source/gcc/tree-ssa-alias.c:747 0xde0352 maybe_warn_pass_by_reference ../../source/gcc/tree-ssa-uninit.c:529 0xde0352 warn_uninitialized_vars ../../source/gcc/tree-ssa-uninit.c:643 0xde0660 execute_early_warn_uninitialized ../../source/gcc/tree-ssa-uninit.c:3018 0xde0660 execute ../../source/gcc/tree-ssa-uninit.c:3053 ```
[Bug c++/97268] Segfault on 11.0.0 20200930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97268
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2020-10-02
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
GCC 10 says
t.C: In instantiation of 'BetterObject::BetterObject(const char*, int,
Handle&) [with bool CACHED = true]':
t.C:61:31: required from here
t.C:53:45: error: use of deleted function 'Handle::Handle(const Handle&)'
53 | , BetterObjectBase(lc_, ln_, env) {}
| ^
t.C:9:5: note: declared here
9 | Handle(const Handle &) = delete;
| ^~
and GCC 11 doesn't crash for me, but you didn't tell us the exact compile
options or the target you are using. So GCC 11 accepts the testcase for me.
