[Bug target/66791] [ARM] Replace builtins with gcc vector extensions code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66791 --- Comment #5 from CVS Commits --- The master branch has been updated by Prathamesh Kulkarni : https://gcc.gnu.org/g:a3bac40469b7052bfadc21cad0e53f40b147e937 commit r11-6108-ga3bac40469b7052bfadc21cad0e53f40b147e937 Author: Prathamesh Kulkarni Date: Wed Dec 16 13:16:25 2020 +0530 arm: Replace calls to __builtin_vcgt* by <,> in arm_neon.h [PR66791] gcc/ 2020-12-16 Prathamesh Kulkarni PR target/66791 * config/arm/arm_neon.h: Replace calls to __builtin_vcgt* by <, > operators in vclt and vcgt intrinsics respectively. * config/arm/arm_neon_builtins.def: Remove entry for vcgt and vcgtu.
[Bug target/98310] New: drivers/mtd/tests/subpagetest.c:426:1: error: could not split insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98310
Bug ID: 98310
Summary: drivers/mtd/tests/subpagetest.c:426:1: error: could
not split insn
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rong.a.chen at intel dot com
Target Milestone: ---
The issue is found in linux kernel mainline (commit
3744741adab6d9195551ce30e65e726c7a408421)
nfs@shao2-debian:~/linux$ git show
commit 3744741adab6d9195551ce30e65e726c7a408421
Author: Willy Tarreau
Date: Mon Aug 10 10:27:42 2020 +0200
random32: add noise from network and scheduling activity
With the removal of the interrupt perturbations in previous random32
change (random32: make prandom_u32() output unpredictable), the PRNG
has become 100% deterministic again. While SipHash is expected to be
way more robust against brute force than the previous Tausworthe LFSR,
there's still the risk that whoever has even one temporary access to
the PRNG's internal state is able to predict all subsequent draws till
the next reseed (roughly every minute). This may happen through a side
channel attack or any data leak.
This patch restores the spirit of commit f227e3ec3b5c ("random32: update
the net random state on interrupt and activity") in that it will perturb
the internal PRNG's statee using externally collected noise, except that
it will not pick that noise from the random pool's bits nor upon
interrupt, but will rather combine a few elements along the Tx path
that are collectively hard to predict, such as dev, skb and txq
pointers, packet length and jiffies values. These ones are combined
using a single round of SipHash into a single long variable that is
mixed with the net_rand_state upon each invocation.
The operation was inlined because it produces very small and efficient
code, typically 3 xor, 2 add and 2 rol. The performance was measured
to be the same (even very slightly better) than before the switch to
SipHash; on a 6-core 12-thread Core i7-8700k equipped with a 40G NIC
(i40e), the connection rate dropped from 556k/s to 555k/s while the
SYN cookie rate grew from 5.38 Mpps to 5.45 Mpps.
Link: https://lore.kernel.org/netdev/20200808152628.ga27...@sdf.org/
Cc: George Spelvin
Cc: Amit Klein
Cc: Eric Dumazet
Cc: "Jason A. Donenfeld"
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Linus Torvalds
Cc: ty...@mit.edu
Cc: Florian Westphal
Cc: Marc Plumb
Tested-by: Sedat Dilek
Signed-off-by: Willy Tarreau
diff --git a/include/linux/prandom.h b/include/linux/prandom.h
index cc1e71334e53..bbf4b4ad61df 100644
--- a/include/linux/prandom.h
+++ b/include/linux/prandom.h
@@ -16,6 +16,12 @@ void prandom_bytes(void *buf, size_t nbytes);
void prandom_seed(u32 seed);
void prandom_reseed_late(void);
+DECLARE_PER_CPU(unsigned long, net_rand_noise);
+
+#define PRANDOM_ADD_NOISE(a, b, c, d) \
+ prandom_u32_add_noise((unsigned long)(a), (unsigned long)(b), \
+ (unsigned long)(c), (unsigned long)(d))
+
#if BITS_PER_LONG == 64
/*
* The core SipHash round function. Each line can be executed in
@@ -50,6 +56,18 @@ void prandom_reseed_late(void);
#error Unsupported BITS_PER_LONG
#endif
+static inline void prandom_u32_add_noise(unsigned long a, unsigned long b,
+unsigned long c, unsigned long d)
+{
+ /*
+* This is not used cryptographically; it's just
+* a convenient 4-word hash function. (3 xor, 2 add, 2 rol)
+*/
+ a ^= raw_cpu_read(net_rand_noise);
+ PRND_SIPROUND(a, b, c, d);
+ raw_cpu_write(net_rand_noise, d);
+}
+
struct rnd_state {
__u32 s1, s2, s3, s4;
};
@@ -99,6 +117,7 @@ static inline void prandom_seed_state(struct rnd_state
*state, u64 seed)
state->s2 = __seed(i, 8U);
state->s3 = __seed(i, 16U);
state->s4 = __seed(i, 128U);
+ PRANDOM_ADD_NOISE(state, i, 0, 0);
}
/* Pseudo random number generator from numerical recipes. */
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 3e341af741b9..de37e33a868d 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1706,6 +1706,8 @@ void update_process_times(int user_tick)
{
struct task_struct *p = current;
+ PRANDOM_ADD_NOISE(jiffies, user_tick, p, 0);
+
/* Note: this timer irq context must be accounted for as well. */
account_process_tick(p, user_tick);
run_local_timers();
diff --git a/lib/random32.c b/lib/random32.c
index be9f242a4207..7f047844e494 100644
--- a/lib/random32.c
+++ b/lib/random32.c
@@ -337,6 +337,8 @@ struct siprand_state {
};
static DEFINE_PER_CPU(struct siprand_state,
[Bug target/66791] [ARM] Replace builtins with gcc vector extensions code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66791 --- Comment #4 from CVS Commits --- The master branch has been updated by Prathamesh Kulkarni : https://gcc.gnu.org/g:9f2877adab2b0af2486bedb731c0fc89bdf2 commit r11-6107-g9f2877adab2b0af2486bedb731c0fc89bdf2 Author: Prathamesh Kulkarni Date: Wed Dec 16 11:54:37 2020 +0530 arm: Replace calls to __builtin_vneg* by - in arm_neon.h [PR66791] gcc/ 2020-12-16 Prathamesh Kulkarni PR target/66791 * config/arm/arm_neon.h: Replace calls to __builtin_vneg* by - operator in vneg intrinsics. * config/arm/arm_neon_builtins.def: Remove entry for vneg.
[Bug target/66791] [ARM] Replace builtins with gcc vector extensions code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66791 --- Comment #3 from CVS Commits --- The master branch has been updated by Prathamesh Kulkarni : https://gcc.gnu.org/g:cff6dac28a0699cb26cdaafe1dbae255a7ee8030 commit r11-6106-gcff6dac28a0699cb26cdaafe1dbae255a7ee8030 Author: Prathamesh Kulkarni Date: Wed Dec 16 11:32:25 2020 +0530 arm: Replace calls to __builtin_vcreate* in arm_neon.h [PR66791] gcc/ 2020-12-16 Prathamesh Kulkarni PR target/66791 * config/arm/arm_neon.h: Replace calls to __builtin_vcreate* in vcreate intrinsics. * config/arm/arm_neon_builtins.def: Remove entry for vcreate.
[Bug tree-optimization/88767] 'unroll and jam' not optimizing some loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88767 --- Comment #11 from Jiu Fu Guo --- And the patch(PR98137) also helps a lot for the code in comment 9, since vectorization happens.
[Bug target/98309] New: [AVX512] Missing expander for ldexpm3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98309
Bug ID: 98309
Summary: [AVX512] Missing expander for ldexpm3.
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com, wwwhhhyyy333 at gmail dot com
Target Milestone: ---
Target: x86_64-*-* i?86-*-*
Cat test.c
#include
double
foo (double r, int n)
{
return ldexp(r, n);
}
gcc -Ofast -mavx512f generate
jmp ldexp
But it could be better with
vcvtsi2sd xmm16, xmm16, edi
vscalefsd xmm0, xmm0, xmm16
ret
Similar for ldexpf, except there could be some precison loss in the conversion
from 32-bit integer to float.
Also the instruction vscalefsd would response for situations
1.the result overflow or underflow.
2.the operands is NAN
SCALE(SRC1, SRC2)
{
; Check for denormal operands
TMP_SRC2 := SRC2
TMP_SRC1 := SRC1
IF (SRC2 is denormal AND MXCSR.DAZ) THEN TMP_SRC2=0
IF (SRC1 is denormal AND MXCSR.DAZ) THEN TMP_SRC1=0
/* SRC2 is a 64 bits floating-point value */
DEST[63:0] := TMP_SRC1[63:0] * POW(2, Floor(TMP_SRC2[63:0]))
}
So limit both expander under flag_unsafe_math_optimizations?
Similar for vector version.
cut from Intel SDM
VSCALEFPD—Scale Packed Float64 Values With Float64 Values
---
Performs a floating-point scale of the packed double-precision floating-point
value in the first source operand by
multiplying it by 2 power of the double-precision floating-point value in
second source operand.
The equation of this operation is given by:
xmm1 := xmm2*2 floor(xmm3) . Here
Floor(xmm3) means maximum integer value ≤ xmm3.
If the result cannot be represented in double precision, then the proper
overflow response (for positive scaling
operand), or the proper underflow response (for negative scaling operand) is
issued. The overflow and underflow
responses are dependent on the rounding mode (for IEEE-compliant rounding), as
well as on other settings in
MXCSR (exception mask bits, FTZ bit), and on the SAE bit.
EVEX encoded version: The first source operand is an XMM register. The second
source operand is an XMM register
or a memory location. The destination operand is an XMM register conditionally
updated with writemask k1.
[Bug tree-optimization/88767] 'unroll and jam' not optimizing some loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88767 Jiu Fu Guo changed: What|Removed |Added CC||guojiufu at gcc dot gnu.org --- Comment #10 from Jiu Fu Guo --- The source code is the same as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98137. And the fix for PR98137 helps to improve the run time of this case too (~20% on some machines).
[Bug tree-optimization/98308] New: ICe in in vect_slp_analyze_node_operations, at tree-vect-slp.c:3764 with -O3 -march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98308
Bug ID: 98308
Summary: ICe in in vect_slp_analyze_node_operations, at
tree-vect-slp.c:3764 with -O3 -march=skylake-avx512
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskij at frtk dot ru
Target Milestone: ---
Reproducer:
extern unsigned long long int arr_86[];
extern unsigned long long int arr_87[][15];
void test(bool a, unsigned short c[][15], unsigned char d[]) {
for (short h = 0; h < 10; h++)
for (char i = 0; i < 15; i += 2) {
arr_86[0] = d[0];
arr_87[h][0] = a ? c[h][i] : 0;
}
}
Error:
>$ g++ -c -O3 -march=skylake-avx512 func.cpp
during GIMPLE pass: vect
func.cpp: In function ‘void test(bool, short unsigned int (*)[15], unsigned
char*)’:
func.cpp:4:6: internal compiler error: in vect_slp_analyze_node_operations, at
tree-vect-slp.c:3764
4 | void test(bool a, unsigned short c[][15], unsigned char d[]) {
| ^~~~
0x886a4d vect_slp_analyze_node_operations
gcc_src/gcc/tree-vect-slp.c:3764
0x1425a73 vect_slp_analyze_node_operations
gcc_src/gcc/tree-vect-slp.c:3719
0x1425a73 vect_slp_analyze_node_operations
gcc_src/gcc/tree-vect-slp.c:3719
0x1425a73 vect_slp_analyze_node_operations
gcc_src/gcc/tree-vect-slp.c:3719
0x1427101 vect_slp_analyze_operations(vec_info*)
gcc_src/gcc/tree-vect-slp.c:3914
0x1404939 vect_analyze_loop_2
gcc_src/gcc/tree-vect-loop.c:2391
0x1404939 vect_analyze_loop(loop*, vec_info_shared*)
gcc_src/gcc/tree-vect-loop.c:2929
0x14311f4 try_vectorize_loop_1
gcc_src/gcc/tree-vectorizer.c:1008
0x1431c59 vectorize_loops()
gcc_src/gcc/tree-vectorizer.c:1242
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug fortran/98307] New: use "allocatable" instead of "pointer" (forall_3.f90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98307 Bug ID: 98307 Summary: use "allocatable" instead of "pointer" (forall_3.f90) Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: xiao@compiler-dev.com Target Milestone: --- in the test case "gfortran.fortran-torture/execute/forall_3.f90", if replace "pointer" with "allocatable", the result will be different. program evil_forall implicit none type t logical valid integer :: s !integer, dimension(:), pointer :: p integer, dimension(:), allocatable :: p end type type (t), dimension (5) :: v integer i allocate (v(1)%p(2)) allocate (v(2)%p(8)) !v(3)%p => NULL() allocate (v(4)%p(8)) allocate (v(5)%p(2)) v(:)%valid = (/.true., .true., .false., .true., .true./) v(:)%s = (/1, 8, 999, 6, 2/) v(1)%p(:) = (/9, 10/) v(2)%p(:) = (/1, 2, 3, 4, 5, 6, 7, 8/) v(4)%p(:) = (/13, 14, 15, 16, 17, 18, 19, 20/) v(5)%p(:) = (/11, 12/) forall (i=1:5,v(i)%valid) v(i)%p(1:v(i)%s) = v(6-i)%p(1:v(i)%s) end forall if (any(v(1)%p(:) .ne. (/11, 10/))) STOP 1 if (any(v(2)%p(:) .ne. (/13, 14, 15, 16, 17, 18, 19, 20/))) STOP 2 if (any(v(4)%p(:) .ne. (/1, 2, 3, 4, 5, 6, 19, 20/))) STOP 3 if (any(v(5)%p(:) .ne. (/9, 10/))) STOP 4 ! I should really free the memory I've allocated. end program the result is "STOP 3"
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 --- Comment #51 from Jim Wilson --- Created attachment 49773 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49773=edit untested fix to use instead of levy's combine.c patch Needs testing without Levy's patch to make sure it doesn't accidentally increase code size.
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 --- Comment #50 from Jim Wilson --- The combine change is inconvenient. We can't do that in stage3, and it means we need to make sure that this doesn't break other targets. If the combine change is a good idea, then I think you can just modify is_just_move rather than add a new function. Just skip over a ZERO_EXTEND or SIGN_EXTEND before the the general_operand check. We might need a mode check against UNITS_PER_WORD since extending past the word size is not necessarily a simple move. So the problem stems from the code in combine that is willing to do a 2->2 split if neither original instruction is a simple move. When we add a SIGN_EXTEND or ZERO_EXTEND they aren't considered simple moves anymore. There is still the question of why the instruction cost allows the change. First I noticed that riscv_address_cost has a hook to check for shorten_memrefs but that riscv_rtx_costs isn't calling it. It uses riscv_address_insns instead. So it seems like adding a shorten_memref check to the MEM case riscv_rtx_costs might solve the problem. But riscv_compressed_lw_address_p has a !reload_completed check, and combine runs before reload, so that returns the same result for both the new and old insns. I think that reload_completed check isn't quite right. If we have a pseudo-reg, then we should allow that, but if we have an offset that is clearly not compressible, then we should reject it before reload. So I think the reload_completed check should be moved down to where it checks for a compressible register. With those two changes, I can make the testcase work without a combine change. Though since I changed how shorten_memrefs works we need a check to make sure this patch doens't change code size. I haven't tried to do that yet. With my changes, in the combine dump, I see Successfully matched this instruction: (set (reg/f:DI 92) (plus:DI (reg:DI 96) (const_int 768 [0x300]))) Successfully matched this instruction: (set (reg:DI 82 [ MEM[(intD.1 *)array_5(D) + 800B] ]) (sign_extend:DI (mem:SI (plus:DI (reg:DI 96) (const_int 800 [0x320])) [1 MEM[(intD.1 *)array_5(D) + 800B]+0 S4 A32]))) rejecting combination of insns 27 and 6 original costs 4 + 16 = 20 replacement costs 4 + 20 = 24 so now the replacement gets rejected because of the increased address cost.
[Bug fortran/70863] [F03] Finalization of array of derived type causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70863 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #5 from Ev Drikos --- (In reply to janus from comment #3) > (In reply to Dominique d'Humieres from comment #1) > > related to/duplicate of pr69298? > > Yes, I think it's the same problem. It's my impression that these examples run ie with '-O3': macbook:finalizers suser$ gfc -O3 pr70863-02.f90 && ./a.out > /dev/null macbook:finalizers suser$ gfc -O3 pr70863-04.f90 && ./a.out > /dev/null macbook:finalizers suser$ gfc -O3 pr69298-06.f90 && ./a.out > /dev/null macbook:finalizers suser$ gfc -O3 pr82996-00.f90 && ./a.out > /dev/null macbook:finalizers suser$ gfc -O3 pr82996-01.f90 && ./a.out > /dev/null macbook:finalizers suser$ gfc -O3 pr82996-02.f90 && ./a.out > /dev/null macbook:finalizers suser$ gfc -O3 pr82996-10.f90 && ./a.out > /dev/null Whereas, Valgrind reports no errors. Any ideas? Hope this helps Ev. Drikos
[Bug fortran/97920] [FINAL] -O2 segment fault due to extend derive type's member being partially allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97920 --- Comment #5 from xin liu --- (In reply to Paul Thomas from comment #2) > (In reply to Martin Liška from comment #1) > > Confirmed with valgrind. At least as old as 4.9.0. > > Hi, > > From a quick perusal of the standard, I find in F2003 16.4.2.1: > > "Unless a pointer is initialized (explicitly or by default), it has an > initial association status of undefined. A pointer may be initialized to > have an > association status of disassociated". > > In your testcase, the status of b%b is undefined and so the compiler can do > anything it wants with it, including segfaulting. I think therefore that you > should initialize the derived types in your application as follows: > > type t1 > real, dimension(:), pointer :: a => NULL () > contains > final :: t1f > end type > > type, extends(t1) :: t2 > real, dimension(:), pointer :: b => NULL () > contains > final :: t2f > end type > > This clears the valgrind error "Conditional jump or move depends on > uninitialised value(s)". Also the finalization is invoked so that the > programme completes with zero memory allocation, > > To my surprise (probably due to standard ignorance), leaving the declared > type declarations as you have them, and declaring 'b' as > > type(t2) :: b = t2 (NULL(), NULL()) > > clears the valgrind fault but no finalization occurs. I notice that > finalization does not occur if an entity has the save attribute. gfortran > assigns 'b' the IMPLICIT-SAVE attribute, which is why the finalization does > not occur. I have been unable to find whether or not this is conforming. > > However, initializing 'b' in an assignment: > b = t2(NULL(), NULL()) > > clears the valgrind fault and results in the deallocation of memory. This > confirms my suspicion about the save attribute. > > In conclusion, I do not believe that this is a bug. If you do not use > pointers as pointers, make them allocatable instead. These are automatically > nullified on entry into scope. > > Thanks for the report by the way! > > Paul I get it, Thanks for your explain.
[Bug fortran/97920] [FINAL] -O2 segment fault due to extend derive type's member being partially allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97920 --- Comment #4 from xin liu --- (In reply to Thomas Koenig from comment #3) > Paul is correct, the state of the pointers is undefined. > > What you can do to correct this is to use > > module m > type t1 > real, dimension(:), pointer :: a => NULL() > contains > final :: t1f > end type > > type, extends(t1) :: t2 > real, dimension(:), pointer :: b => NULL() > contains > final :: t2f > end type > > which will then run as expected. OK,Thanks!
[Bug c++/52830] ICE: "canonical types differ for identical types ..." when attempting SFINAE with member type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Marek Polacek --- This was fixed in r11-5942. Alex, please try gcc with this revision. If your test still ICEs, please file a bug or reopen this one. Thanks.
[Bug c/98217] Prefer a warning for when VLAs declared on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217 --- Comment #11 from joseph at codesourcery dot com --- It would seem reasonable to have options both for the case of warning about all VLA declarations, and more specifically for the case of allocating a VLA on the stack. The diagnostics for all VLA declarations, including [*], are needed in any case for -std=c90 -pedantic (as pedwarns, so they become errors with -pedantic-errors) and -Wc90-c99-compat / -Wc++-compat (as warnings).
[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98300 --- Comment #9 from fdlbxtqi --- (In reply to Nathan Sidwell from comment #6) > Created attachment 49769 [details] > potential patch > > Care to give this patch a try? hello??
[Bug c++/98306] invalid use of incomplete type 'struct grammar'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98306 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- It is only a warning (pedwarn in particular, error with -pedantic-errors) in the uninstantiated template, if you instantiate the template and the type is still incomplete, you get hard error.
[Bug c++/98306] New: invalid use of incomplete type 'struct grammar'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98306
Bug ID: 98306
Summary: invalid use of incomplete type 'struct grammar'
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Noticed error-looking warning when was reducing unrelated boost ICE. Minimal
reproducer:
// $ cat bug.cpp
extern struct grammar *target_grammar;
template void define(void) { target_grammar->derived(); }
$ g++-11.0.0 -c bug.cpp; echo $?
bug.cpp: In function 'void define()':
bug.cpp:3:57: warning: invalid use of incomplete type 'struct grammar'
3 | template void define(void) { target_grammar->derived(); }
| ^~
bug.cpp:1:15: note: forward declaration of 'struct grammar'
1 | extern struct grammar *target_grammar;
| ^~~
0
$ clang++ -c bug.cpp; echo $?
clang++
bug.cpp:3:57: error: member access into incomplete type 'struct grammar'
template void define(void) { target_grammar->derived(); }
^
bug.cpp:1:15: note: forward declaration of 'grammar'
extern struct grammar *target_grammar;
^
1 error generated.
1
I read the diagnostic with "invalid use" as clearly incorrect code. Should g++
error out instead of generating a warning?
[Bug c++/98305] New: Incomprehensible -Wmismatched-new-delete warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98305
Bug ID: 98305
Summary: Incomprehensible -Wmismatched-new-delete warning
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
With recent GCC 11 trunk (at git commit
8dede2411195eb2fd672d8d0c758f94732bd6d77):
> $ cat test.cc
> #include
> template struct Reference {};
> template struct S2 {
> static void * operator new(std::size_t);
> static void operator delete(void *);
> S2();
> };
> void f() { new S2>; }
> $ g++ -Wmismatched-new-delete -c test.cc
> test.cc: In function ‘void f()’:
> test.cc:8:16: warning: ‘static void S2< >::operator
> delete(void*) [with = Reference]’ called on
> pointer returned from a mismatched allocation function
> [-Wmismatched-new-delete]
> 8 | void f() { new S2>; }
> |^~
> test.cc:8:16: note: returned from ‘static void* S2<
> >::operator new(std::size_t) [with = Reference]’
(And oddly enough, the warning disappears when Reference is renamed to e.g.
S1.)
[Bug fortran/98284] ICE in get_array_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98284 --- Comment #3 from Steve Kargl --- On Tue, Dec 15, 2020 at 09:01:15PM +, anlauf at gcc dot gnu.org wrote: > --- Comment #2 from anlauf at gcc dot gnu.org --- > Steve, > > https://gcc.gnu.org/pipermail/fortran/2020-December/055427.html > > is mostly your patch, but with adjusted locus. Try data & ... > Looks good to me. I like the simple bugs. :-)
[Bug tree-optimization/98304] New: Failure to optimize bitwise arithmetic pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98304
Bug ID: 98304
Summary: Failure to optimize bitwise arithmetic pattern
Product: gcc
Version: 11.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 f1(int n)
{
return n - (((n > 63) ? n : 63) & -64);
}
This can be optimized to `return (n <= 63) ? n : (n & 63);` (and presumably the
same optimization should be doable with other powers of 2).
PS: I found this optimization while looking at how this :
int f1(int n)
{
while (n >= 64)
n -= 64;
return n;
}
is optimized. LLVM outputs the first example I gave here, while GCC outputs the
optimization I gave here.
[Bug tree-optimization/96094] Failure to optimize bool division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96094 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d41b097350d3c5d03824ea19520cd3b4430c9e62 commit r11-6100-gd41b097350d3c5d03824ea19520cd3b4430c9e62 Author: Jakub Jelinek Date: Tue Dec 15 22:43:46 2020 +0100 match.pd: Optimize X / bool_range_Y to X [PR96094] When the divisor is bool or has [0, 1] range, as division by 0 is UB, the only remaining option in valid programs is division by 1, so we can optimize X / bool_range_Y into X. 2020-12-15 Jakub Jelinek PR tree-optimization/96094 * match.pd (X / bool_range_Y -> X): New simplification. * gcc.dg/tree-ssa/pr96094.c: New test.
[Bug d/98277] d: ICE in gimplify_expr, at gimplify.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98277 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Buclaw --- Fix committed.
[Bug d/98277] d: ICE in gimplify_expr, at gimplify.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98277 --- Comment #3 from CVS Commits --- The releases/gcc-9 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:85b55ae6e87bd5cf6a23175065f634614e96a243 commit r9-9116-g85b55ae6e87bd5cf6a23175065f634614e96a243 Author: Iain Buclaw Date: Tue Dec 15 10:36:00 2020 +0100 d: Fix ICE in gimplify_expr, at gimplify.c (PR98277) The DMD front-end shouldn't, but can sometimes leak manifest constants in the AST passed to the code generator. To prevent this being an issue, the setting of DECL_INITIAL has been moved to the point where the CONST_DECL is used, rather than in the declaration handler. gcc/d/ChangeLog: PR d/98277 * decl.cc (DeclVisitor::visit (VarDeclaration *)): Move setting of DECL_INITIAL for manifest constants to ... (get_symbol_decl): ... here. gcc/testsuite/ChangeLog: PR d/98277 * gdc.dg/pr98277.d: New test. (cherry picked from commit 36c9a3fe3f3c200ad3937d00d339b7269cf07adb)
[Bug d/98277] d: ICE in gimplify_expr, at gimplify.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98277 --- Comment #2 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:d0bdf3a9069f8f42b2ab196db2c4d75937722646 commit r10-9154-gd0bdf3a9069f8f42b2ab196db2c4d75937722646 Author: Iain Buclaw Date: Tue Dec 15 10:36:00 2020 +0100 d: Fix ICE in gimplify_expr, at gimplify.c (PR98277) The DMD front-end shouldn't, but can sometimes leak manifest constants in the AST passed to the code generator. To prevent this being an issue, the setting of DECL_INITIAL has been moved to the point where the CONST_DECL is used, rather than in the declaration handler. gcc/d/ChangeLog: PR d/98277 * decl.cc (DeclVisitor::visit (VarDeclaration *)): Move setting of DECL_INITIAL for manifest constants to ... (get_symbol_decl): ... here. gcc/testsuite/ChangeLog: PR d/98277 * gdc.dg/pr98277.d: New test. (cherry picked from commit 36c9a3fe3f3c200ad3937d00d339b7269cf07adb)
[Bug d/98277] d: ICE in gimplify_expr, at gimplify.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98277 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:36c9a3fe3f3c200ad3937d00d339b7269cf07adb commit r11-6099-g36c9a3fe3f3c200ad3937d00d339b7269cf07adb Author: Iain Buclaw Date: Tue Dec 15 10:36:00 2020 +0100 d: Fix ICE in gimplify_expr, at gimplify.c (PR98277) The DMD front-end shouldn't, but can sometimes leak manifest constants in the AST passed to the code generator. To prevent this being an issue, the setting of DECL_INITIAL has been moved to the point where the CONST_DECL is used, rather than in the declaration handler. gcc/d/ChangeLog: PR d/98277 * decl.cc (DeclVisitor::visit (VarDeclaration *)): Move setting of DECL_INITIAL for manifest constants to ... (get_symbol_decl): ... here. gcc/testsuite/ChangeLog: PR d/98277 * gdc.dg/pr98277.d: New test.
[Bug target/98303] New: [x86] Bad register allocation when reproducing assembly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98303
Bug ID: 98303
Summary: [x86] Bad register allocation when reproducing
assembly code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f1(int n)
{
while (n >= 64)
n -= 64;
return n;
}
On x86, with -O3, this generates :
f1(int):
mov eax, edi
and eax, 63
cmp edi, 63
cmovle eax, edi
ret
This code :
int f2(int n)
{
return (n <= 63) ? n : (n & 63);
}
which behaves equivalently, seems to result in poorer generated code :
f2(int):
mov edx, edi
mov eax, edi
and edx, 63
cmp edi, 63
cmovg eax, edx
ret
[Bug target/98302] [11 Regression] Wrong code on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98302 --- Comment #2 from Martin Liška --- Created attachment 49772 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49772=edit test case 2
[Bug target/98302] [11 Regression] Wrong code on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98302 --- Comment #1 from Martin Liška --- Created attachment 49771 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49771=edit test-case 1
[Bug target/98302] New: [11 Regression] Wrong code on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98302 Bug ID: 98302 Summary: [11 Regression] Wrong code on aarch64 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: rsandifo at gcc dot gnu.org Target Milestone: --- Host: aarch64-linux-gnu Target: aarch64-linux-gnu Started with a costing model change, and I can reproduce it only on aarch64. The test-case is hard to reduce and comes from yarpgen: $ g++ -O3 func.ii -c $ g++ driver.ii -c $ g++ *.o $ ./a.out a.out: driver.cpp:1143: void checksum(): Assertion `var_135 == (unsigned char)0' failed. Aborted (core dumped) It's caused by vect_loop, and g++ -O3 func.ii -c -fdbg-cnt=vect_loop:1 is first value that causes that.
[Bug fortran/98284] ICE in get_array_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98284 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- Steve, https://gcc.gnu.org/pipermail/fortran/2020-December/055427.html is mostly your patch, but with adjusted locus. Try data & ...
[Bug middle-end/93195] -fpatchable-function-entries : __patchable_function_entries should consider comdat groups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93195 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- I believe this broke building the kernel, see https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561974.html for details.
[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98300
--- Comment #8 from fdlbxtqi ---
(In reply to Nathan Sidwell from comment #6)
> Created attachment 49769 [details]
> potential patch
>
> Care to give this patch a try?
make[2]: Leaving directory
'/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/libcc1'
../../gcc-git/c++tools/server.cc: In function 'void crash_signal(int)':
../../gcc-git/c++tools/server.cc:216:32: error: 'strsignal' was not declared in
this scope; did you mean 'strsigno'?
216 | internal_error ("signal %s", strsignal (sig));
|^
|strsigno
../../gcc-git/c++tools/server.cc:217:1: warning: 'noreturn' function does
return
217 | }
| ^
make[2]: *** [Makefile:72: server.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory
'/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/c++tools'
make[1]: *** [Makefile:10586: all-c++tools] Error 2
make[1]: *** Waiting for unfinished jobs
configure: creating cache ./config.cache
checking build system type... x86_64-w64-mingw32
checking host system type... x86_64-w64-mingw32
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking for x86_64-w64-mingw32-ar... /mingw64/x86_64-w64-mingw32/bin/ar
checking for x86_64-w64-mingw32-lipo... lipo
checking for x86_64-w64-mingw32-nm...
/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/nm
checking for x86_64-w64-mingw32-ranlib...
/mingw64/x86_64-w64-mingw32/bin/ranlib
checking for x86_64-w64-mingw32-strip... /mingw64/x86_64-w64-mingw32/bin/strip
checking whether ln -s works... no, using cp -pR
checking for x86_64-w64-mingw32-gcc...
/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/xgcc
-B/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether
/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/xgcc
-B/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-includeaccepts -g... yes
checking for
/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/xgcc
-B/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-includeoption to accept ISO C89... none
needed
checking how to run the C preprocessor...
/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/xgcc
-B/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include-E
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking size of double... 8
checking size of long double... 16
checking for inttypes.h... yes
checking for stdint.h... yes
checking for stdlib.h... yes
checking for ftw.h... yes
checking for unistd.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for string.h... yes
checking for strings.h... yes
checking for memory.h... yes
checking for sys/auxv.h... no
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking whether decimal floating point is supported... yes
checking whether fixed-point is supported... no
checking whether the compiler is configured for setjmp/longjmp exceptions... no
checking for CET support... no
checking if the linker
(/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/collect-ld)
is GNU ld... yes
checking for thread model used by GCC... mcf
checking whether assembler supports CFI directives... yes
checking for target glibc version... 0.0
checking for __attribute__((visibility("hidden")))... no
checking for
[Bug libfortran/98301] random_init() may be non-conforming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98301 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug libfortran/98301] random_init() may be non-conforming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98301 kargl at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-12-15 --- Comment #2 from kargl at gcc dot gnu.org --- See https://gcc.gnu.org/pipermail/fortran/2020-December/055425.html
[Bug libfortran/98301] random_init() may be non-conforming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98301 --- Comment #1 from kargl at gcc dot gnu.org --- Created attachment 49770 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49770=edit random_init() patch
[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98300 --- Comment #7 from fdlbxtqi --- (In reply to Nathan Sidwell from comment #6) > Created attachment 49769 [details] > potential patch > > Care to give this patch a try? I will help you. no problem. BTW. Welcome to join discord so I can show you details. https://discord.gg/vMKhB9Q
[Bug libfortran/98301] New: random_init() may be non-conforming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98301 Bug ID: 98301 Summary: random_init() may be non-conforming Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: kargl at gcc dot gnu.org Target Milestone: ---
[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98300 --- Comment #6 from Nathan Sidwell --- Created attachment 49769 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49769=edit potential patch Care to give this patch a try?
[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98300 --- Comment #5 from fdlbxtqi --- (In reply to Nathan Sidwell from comment #3) > Hm, I thought there was sufficient #ifing to prevent that ... BTW. I tried the example you showed on the GCC module webpage on Linux. It fails to compile. why? cqwrteur@Home-Server:~/myhome/test_module$ vim hello.cc cqwrteur@Home-Server:~/myhome/test_module$ vim a.cc cqwrteur@Home-Server:~/myhome/test_module$ g++ -fmodules-ts hello.cc main.cc -Ofast -std=c++20 -s /usr/bin/ld: /tmp/ccQUwe74.o: in function `_GLOBAL__sub_I_main': main.cc:(.text.startup+0x31): undefined reference to `_ZGIW5helloEv' collect2: error: ld returned 1 exit status My MinGW-w64 msys2 build script Just run makepkg-mingw in the msys2 console and the compiler will get built. https://bitbucket.org/ejsvifq_mabmip/mingw-gcc-mcf-gthread/src/master/
[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98300 --- Comment #4 from fdlbxtqi --- (In reply to Nathan Sidwell from comment #3) > Hm, I thought there was sufficient #ifing to prevent that ... Try the compiler I build before to guard against this.
[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98300 --- Comment #3 from Nathan Sidwell --- Hm, I thought there was sufficient #ifing to prevent that ...
[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98300 --- Comment #2 from fdlbxtqi --- Here was an older version (GCC11 20201204) that can be used for bootstrapping. Please, thank you for fixing this issue ASAP. https://bitbucket.org/ejsvifq_mabmip/mingw-gcc/src/master/
[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98300 fdlbxtqi changed: What|Removed |Added Target||x86_64-msys2-mingw-w64, ||windows 10 Host||x86_64-msys2-mingw-w64, ||windows 10 CC||euloanty at live dot com --- Comment #1 from fdlbxtqi --- The assumption of libcody of POSIX apis do not actually exist on windows. Windows does not represent socket as fd. There is no O_CLOEXEC on Windows. O_INHERIT can be a replacement. no sys/mman.h on Windows
[Bug fortran/95372] ICE in find_array_section, at fortran/expr.c:1687
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95372 --- Comment #3 from anlauf at gcc dot gnu.org --- Playing around with the above patches, I found that the following now gets rejected instead of an ICE: program p type t integer :: a = 1 end type t type(t), parameter :: z(3) = t() type(t):: v(1) = z(2:2) ! Rejected ! type(t):: v(1) = [z(2:2)] ! Rejected print *, v% a end pr95372-1.f90:6:3: 6 | type(t):: v(1) = z(2:2) ! Rejected | 1 Error: Unclassifiable statement at (1) pr95372-1.f90:8:14: 8 | print *, v% a | 1 Error: Symbol 'v' at (1) has no IMPLICIT type This is a consequence of find_array_section returning false instead of true. However, removing the t=false from the patch the original testcase will ICE in a different place. Staring some more at the code in find_array_section, it appears that there is a stale cons = gfc_constructor_first (base); followed later by the critical cons = gfc_constructor_lookup (base, limit); Strange. And "git blame" so far did not really help me much.
[Bug bootstrap/98300] New: GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98300 Bug ID: 98300 Summary: GCC 11 failed to build on Windows 10. I guess the new module completely breaks this. Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: euloanty at live dot com Target Milestone: --- x86_64-w64-mingw32-g++ -fno-PIE -c -DIN_GCC_FRONTEND -march=x86-64 -mtune=generic -O2 -pipe -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -Icp -I../../gcc-git/gcc -I../../gcc-git/gcc/cp -I../../gcc-git/gcc/../include -I../../gcc-git/gcc/../libcpp/include -I../../gcc-git/gcc/../libcody -I/mingw64/include -I/mingw64/include -I/mingw64/include -I../../gcc-git/gcc/../libdecnumber -I../../gcc-git/gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc-git/gcc/../libbacktrace -I/mingw64/include -D__USE_MINGW_ANSI_STDIO=1 -I/mingw64/include -o cp/name-lookup.o -MT cp/name-lookup.o -MMD -MP -MF cp/.deps/name-lookup.TPo ../../gcc-git/gcc/cp/name-lookup.c In file included from ../../gcc-git/gcc/cp/mapper-resolver.cc:27: ../../gcc-git/gcc/cp/../../c++tools/resolver.cc:31:10: fatal error: sys/mman.h: No such file or directory 31 | #include | ^~~~ compilation terminated. make[2]: *** [Makefile:1127: cp/mapper-resolver.o] Error 1 make[2]: *** Waiting for unfinished jobs ../../gcc-git/gcc/cp/mapper-client.cc: In static member function 'static module_client* module_client::open_module_client(location_t, const char*, void (*)(const char*), const char*)': ../../gcc-git/gcc/cp/mapper-client.cc:171:42: error: 'O_CLOEXEC' was not declared in this scope 171 | ? O_RDWR | O_CLOEXEC : O_RDONLY | O_CLOEXEC; | ^ ../../gcc-git/gcc/cp/mapper-client.cc:188:42: error: 'O_CLOEXEC' was not declared in this scope 188 | ? O_RDWR | O_CLOEXEC : O_WRONLY | O_CLOEXEC; | ^ ../../gcc-git/gcc/cp/mapper-client.cc:260:50: error: 'O_CLOEXEC' was not declared in this scope 260 | int fd = open (name.c_str (), O_RDONLY | O_CLOEXEC); | ^ make[2]: *** [Makefile:1127: cp/mapper-client.o] Error 1 ../../gcc-git/gcc/cp/module.cc: In member function 'void bytes_out::printf(const char*, ...)': ../../gcc-git/gcc/cp/module.cc:1088:56: warning: function 'void bytes_out::printf(const char*, ...)' might be a candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format] 1088 | size_t actual = vsnprintf (ptr, len, format, args) + 1; |^ ../../gcc-git/gcc/cp/module.cc: In member function 'const char* elf_in::read(data*, unsigned int, unsigned int)': ../../gcc-git/gcc/cp/module.cc:1659:45: warning: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare] 1659 | if (::read (fd, data->buffer, data->size) != length) | ~~^ ../../gcc-git/gcc/cp/module.cc: In member function 'unsigned int elf_out::write(const data&)': ../../gcc-git/gcc/cp/module.cc:2051:47: warning: comparison of integer expressions of different signedness: 'int' and 'const unsigned int' [-Wsign-compare] 2051 | if (::write (fd, buffer.buffer, buffer.pos) != buffer.pos) | ^ ../../gcc-git/gcc/cp/module.cc:2066:40: warning: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare] 2066 | if (::write (fd, , padding) != padding) | ~^~ rm gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod gcov.pod lto-dump.pod make[2]: Leaving directory '/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/gcc' make[1]: *** [Makefile:4446: all-gcc] Error 2 make[1]: Leaving directory '/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32' make: *** [Makefile:973: all] Error 2 ==> ERROR: A failure occurred in build(). Aborting...
[Bug tree-optimization/98299] Failure to optimize sub loop into modulo-based pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98299
--- Comment #3 from Gabriel Ravier ---
PS: The optimization seems to already occur for simpler cases such as powers of
2, e.g. :
int f1(int n)
{
while (n >= 64)
n -= 64;
return n;
}
is optimized into `return (n <= 63) ? n : (n & 63);`.
[Bug tree-optimization/98299] Failure to optimize sub loop into modulo-based pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98299 --- Comment #2 from Gabriel Ravier --- At the very least, it seems like a worthwhile pattern to recognize in -O3, even if only to avoid vectorizing it, i.e. have similar effects to what happens if you add `if (n >= 1000) __builtin_unreachable();` to the start of f1. Altogether, though, it seems unlikely that the modulo would be costlier than the loop except in very narrow cases, since it is optimized into a multiplication and a few other operations with little cost. Also, the transformation into a modulo seems to occur in the vectorized version too, though it is weirdly optimized.
[Bug tree-optimization/98299] Failure to optimize sub loop into modulo-based pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98299 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The big question is if it is an optimization or not. Perhaps the user wrote it that way because n is always or most of the time small that it will be faster than doing modulo.
[Bug tree-optimization/98299] New: Failure to optimize sub loop into modulo-based pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98299
Bug ID: 98299
Summary: Failure to optimize sub loop into modulo-based pattern
Product: gcc
Version: 11.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 f1(int n)
{
while (n >= 45)
n -= 45;
return n;
}
This can be optimized into a modulo-based pattern, for example this :
int f2(int n)
{
int tmp = n > 44 ? n : 44;
return ((tmp % 45) - tmp) + n;
}
This transformation is done by LLVM, but not by GCC.
[Bug libstdc++/98298] [11 regression] g++.dg/pch/system-1.C assembly comparison fails after r11-6072
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98298 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Jonathan Wakely --- Reverted in r11-6091
[Bug libstdc++/98108] Broken Schwarz counter for iostreams initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98108 --- Comment #6 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:433703843b3fa76bcbba4f1fd782c7ef319b64a8 commit r11-6091-g433703843b3fa76bcbba4f1fd782c7ef319b64a8 Author: Jonathan Wakely Date: Tue Dec 15 18:40:28 2020 + libstdc++: Remove init_priority attribute for Init object [PR 98108] This reverts commit cf4ed3b41594b6935a337fe0aaf8149eadf88751. libstdc++-v3/ChangeLog: PR libstdc++/98108 * include/std/iostream (__ioinit): Remove init_priority attribute.
[Bug c++/98297] [8/9/10/11 Regression] ICE in cp_parser_elaborated_type_specifier, at cp/parser.c:19653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98297 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Last reconfirmed||2020-12-15 Summary|[9/10/11 Regression] ICE in |[8/9/10/11 Regression] ICE |cp_parser_elaborated_type_s |in |pecifier, at|cp_parser_elaborated_type_s |cp/parser.c:19653 |pecifier, at ||cp/parser.c:19653 Target Milestone|--- |8.5 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/98296] ICE: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98296 Marek Polacek changed: What|Removed |Added Last reconfirmed||2020-12-15 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/98295] [8/9/10/11 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:4312
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98295 Marek Polacek changed: What|Removed |Added Target Milestone|--- |8.5 Keywords||ice-on-valid-code Summary|[9/10/11 Regression] ICE in |[8/9/10/11 Regression] ICE |verify_ctor_sanity, at |in verify_ctor_sanity, at |cp/constexpr.c:4312 |cp/constexpr.c:4312 --- Comment #2 from Marek Polacek --- Started with r239267.
[Bug target/98289] [8/9/10/11 Regression] [x86] Suboptimal optimization of stack usage when function call does not occur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98289 --- Comment #3 from Jakub Jelinek --- --- gcc/shrink-wrap.c.jj2020-07-28 15:39:09.983756571 +0200 +++ gcc/shrink-wrap.c 2020-12-15 19:15:00.213861334 +0100 @@ -494,7 +494,7 @@ can_get_prologue (basic_block pro, HARD_ edge e; edge_iterator ei; FOR_EACH_EDGE (e, ei, pro->preds) -if (e->flags & (EDGE_COMPLEX | EDGE_CROSSING) +if (e->flags & EDGE_COMPLEX && !dominated_by_p (CDI_DOMINATORS, e->src, pro)) return false; fixes it for me. Not sure I understand why EDGE_CROSSING has been listed there, if pro is in the cold partition and has EDGE_CROSSING edge leading to it, then why can't the prologue be added to the cold partition and the jump redirected to it?
[Bug c++/98295] [9/10/11 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:4312
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98295 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-12-15 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Confirmed. A vs. A[3] mismatch.
[Bug analyzer/98293] [11 Regression] ICE in get_subregion_within_ctor, at analyzer/store.cc:494
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98293 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-12-15 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- Thanks for filing this; confirmed.
[Bug target/98289] [8/9/10/11 Regression] [x86] Suboptimal optimization of stack usage when function call does not occur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98289 --- Comment #2 from Jakub Jelinek --- That particular change is of course correct, but all that means that shrink-wrapping at least on this testcase doesn't work with -freorder-blocks-and-partition which is on by default. Compiling it with -O2 -fno-reorder-blocks-and-partition (or -O3 + that option) makes it shrink-wrapped again.
[Bug libstdc++/98298] New: [11 regression] g++.dg/pch/system-1.C assembly comparison fails after r11-6072
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98298 Bug ID: 98298 Summary: [11 regression] g++.dg/pch/system-1.C assembly comparison fails after r11-6072 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:cf4ed3b41594b6935a337fe0aaf8149eadf88751, r11-6072 make -k check-gcc RUNTESTFLAGS="pch.exp=g++.dg/pch/system-1.C" FAIL: g++.dg/pch/system-1.C -g assembly comparison FAIL: g++.dg/pch/system-1.C -O2 -g assembly comparison FAIL: g++.dg/pch/system-1.C -O2 assembly comparison # of expected passes9 # of unexpected failures3 spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../ /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/pch/system-1.C -fdiagnostics-plain-output -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 -g -I. -Dwithout_PCH -S -o system-1.s PASS: g++.dg/pch/system-1.C -g -I. -Dwithout_PCH (test for excess errors) line #101 < lwz 9,184(31) > lwz 10,184(31) line #102 < cmpwi 0,9,90 > li 9,0 line #103 < bne 0,.L5 > ori 9,9,0x line #104 < .file 2 "/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/iostream" > cmpw 0,10,9 line #105 < .loc 2 80 34 is_stmt 1 > bne 0,.L5 line #106 < addis 3,2,_ZStL8__ioinit@toc@ha > .file 2 > "/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/iostream" line #107 < addi 3,3,_ZStL8__ioinit@toc@l > .loc 2 80 34 is_stmt 1 line #108 < bl _ZNSt8ios_base4InitC1Ev > addis 3,2,_ZStL8__ioinit@toc@ha line #109 < nop > addi 3,3,_ZStL8__ioinit@toc@l line #110 < .loc 2 80 25 > bl _ZNSt8ios_base4InitC1Ev line #111 < addis 5,2,__dso_handle@toc@ha > nop line #112 < addi 5,5,__dso_handle@toc@l > .loc 2 80 25 line #113 < addis 4,2,_ZStL8__ioinit@toc@ha > addis 5,2,__dso_handle@toc@ha line #114 < addi 4,4,_ZStL8__ioinit@toc@l > addi 5,5,__dso_handle@toc@l line #115 < addis 9,2,.LC2@toc@ha > addis 4,2,_ZStL8__ioinit@toc@ha line #116 < ld 3,.LC2@toc@l(9) > addi 4,4,_ZStL8__ioinit@toc@l line #117 < bl __cxa_atexit > addis 9,2,.LC2@toc@ha line #118 < nop > ld 3,.LC2@toc@l(9) line #119 < .L5: > bl __cxa_atexit line #120 < .loc 1 7 1 > nop line #121 < nop > .L5: line #122 < addi 1,31,128 > .loc 1 7 1 line #123 < .cfi_def_cfa 1, 0 > nop line #124 < ld 0,16(1) > addi 1,31,128 line #125 < mtlr 0 > .cfi_def_cfa 1, 0 line #126 < ld 31,-8(1) > ld 0,16(1) line #127 < blr > mtlr 0 line #128 < .long 0 > ld 31,-8(1) line #129 < .byte 0,9,0,1,128,1,0,1 > blr line #130 < .cfi_endproc > .long 0 line #131 < .LFE2228: > .byte 0,9,0,1,128,1,0,1 line #132 < .size _Z41__static_initialization_and_destruction_0ii,.-.L._Z41__static_initialization_and_destruction_0ii > .cfi_endproc line #133 < .align 2 > .LFE2228: line #134 < .section".opd","aw" > .size > _Z41__static_initialization_and_destruction_0ii,.-.L._Z41__static_initialization_and_destruction_0ii line #135 < .align 3 > .align 2 line #136 < _GLOBAL__sub_I.00090_main: > .section".opd","aw" line #137 < .quad .L._GLOBAL__sub_I.00090_main,.TOC.@tocbase,0 > .align 3 line #138 < .previous > _GLOBAL__sub_I_main: line #139 < .type _GLOBAL__sub_I.00090_main, @function > .quad .L._GLOBAL__sub_I_main,.TOC.@tocbase,0 line #140 < .L._GLOBAL__sub_I.00090_main: > .previous line #141 < .LFB2229: > .type _GLOBAL__sub_I_main, @function line #142 < .loc 1 7 1 > .L._GLOBAL__sub_I_main: line #143 < .cfi_startproc > .LFB2229: line #144 < mflr 0 > .loc 1 7 1 line #145 < std 0,16(1) > .cfi_startproc line #146 < std 31,-8(1) > mflr 0 line #147 < stdu 1,-128(1) > std 0,16(1) line #148 < .cfi_def_cfa_offset 128 > std 31,-8(1) line #149 < .cfi_offset 65, 16 > stdu 1,-128(1) line #150 < .cfi_offset 31, -8 > .cfi_def_cfa_offset 128 line #151 < mr 31,1 > .cfi_offset 65, 16 line #152 <
[Bug c++/98297] New: [9/10/11 Regression] ICE in cp_parser_elaborated_type_specifier, at cp/parser.c:19653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98297 Bug ID: 98297 Summary: [9/10/11 Regression] ICE in cp_parser_elaborated_type_specifier, at cp/parser.c:19653 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to r8 : $ cat z1.cc template class a> struct [[b]] a ; $ g++-11-20201213 -c z1.cc z1.cc:1:50: internal compiler error: Segmentation fault 1 | template class a> struct [[b]] a ; | ^~~ 0xc8f5ff crash_signal ../../gcc/toplev.c:327 0x7507a5 cp_parser_elaborated_type_specifier ../../gcc/cp/parser.c:19653 0x739283 cp_parser_type_specifier ../../gcc/cp/parser.c:18393 0x73a0b6 cp_parser_decl_specifier_seq ../../gcc/cp/parser.c:14990 0x75bd05 cp_parser_single_declaration ../../gcc/cp/parser.c:30321 0x75c095 cp_parser_template_declaration_after_parameters ../../gcc/cp/parser.c:29984 0x75c84b cp_parser_explicit_template_declaration ../../gcc/cp/parser.c:30250 0x75c84b cp_parser_template_declaration_after_export ../../gcc/cp/parser.c:30269 0x75ecf9 cp_parser_declaration ../../gcc/cp/parser.c:13996 0x75e183 cp_parser_translation_unit ../../gcc/cp/parser.c:4926 0x75e183 c_parse_file() ../../gcc/cp/parser.c:45106 0x82acf2 c_common_parse_file() ../../gcc/c-family/c-opts.c:1211
[Bug target/98289] [8/9/10/11 Regression] [x86] Suboptimal optimization of stack usage when function call does not occur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98289 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.5 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-12-15 Summary|[x86] Suboptimal|[8/9/10/11 Regression] |optimization of stack usage |[x86] Suboptimal |when function call does not |optimization of stack usage |occur |when function call does not ||occur CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with r8-1272-g227b76c3b4ef63b1226f4e584dbdf42c9e56ff9f
[Bug c++/98296] New: ICE: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98296
Bug ID: 98296
Summary: ICE: Segmentation fault signal terminated program
cc1plus
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Very old, affects versions down to at least r5 :
(use of appropriate ulimits recommended)
$ cat z1.cc
template struct T
{ template T T ::a; };
$ g++-11-20201213 -c z1.cc
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/98295] New: [9/10/11 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:4312
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98295
Bug ID: 98295
Summary: [9/10/11 Regression] ICE in verify_ctor_sanity, at
cp/constexpr.c:4312
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to r7 :
$ cat z1.cc
struct A { constexpr A(); };
void f ()
{
A b[2][3];
[b] {};
}
$ g++-11-20201213 -c z1.cc
z1.cc: In function 'void f()':
z1.cc:5:3: internal compiler error: in verify_ctor_sanity, at
cp/constexpr.c:4312
5 | [b] {};
| ^~
0x67c29d verify_ctor_sanity
../../gcc/cp/constexpr.c:4306
0x689c3c cxx_eval_bare_aggregate
../../gcc/cp/constexpr.c:4342
0x681259 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6574
0x682adc cxx_eval_array_reference
../../gcc/cp/constexpr.c:3763
0x682adc cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6498
0x681041 cxx_eval_array_reference
../../gcc/cp/constexpr.c:3659
0x681041 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6498
0x6833cd cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6205
0x68a33a cxx_eval_vec_init_1
../../gcc/cp/constexpr.c:4548
0x68a417 cxx_eval_vec_init_1
../../gcc/cp/constexpr.c:4524
0x681d76 cxx_eval_vec_init
../../gcc/cp/constexpr.c:4599
0x681d76 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6584
0x683eab cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:7126
0x686e7f maybe_constant_init_1
../../gcc/cp/constexpr.c:7578
0x7db5ce massage_init_elt
../../gcc/cp/typeck2.c:1309
0x7da80f process_init_constructor_record
../../gcc/cp/typeck2.c:1528
0x7da80f process_init_constructor
../../gcc/cp/typeck2.c:1806
0x7da80f digest_init_r
../../gcc/cp/typeck2.c:1195
0x7a0e36 finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
../../gcc/cp/semantics.c:3001
0x6f1074 build_lambda_object(tree_node*)
../../gcc/cp/lambda.c:118
[Bug c/98294] New: [9/10/11 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98294
Bug ID: 98294
Summary: [9/10/11 Regression] ICE in calculate_line_spans, at
diagnostic-show-locus.c:1296
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Old stuff, affects versions down to r6 :
$ cat z1.c
void f ()
{
#line 9223372036854775807
g ()
+ 1;
}
$ gcc-11-20201213 -c z1.c -Wall
z1.c: In function 'f':
z1.c:3:9: warning: line number out of range
3 | #line 9223372036854775807
| ^~~
z1.c:-1:3: warning: implicit declaration of function 'g'
[-Wimplicit-function-declaration]
z1.c: warning: value computed is not used [-Wunused-value]
z1.c: internal compiler error: in calculate_line_spans, at
diagnostic-show-locus.c:1296
0x1532394 calculate_line_spans
../../gcc/diagnostic-show-locus.c:1296
0x1532394 layout
../../gcc/diagnostic-show-locus.c:1003
0x1532572 diagnostic_show_locus(diagnostic_context*, rich_location*,
diagnostic_t)
../../gcc/diagnostic-show-locus.c:2601
0x6e2435 c_diagnostic_finalizer
../../gcc/c-family/c-opts.c:174
0x152d744 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:1223
0x152de6e diagnostic_impl
../../gcc/diagnostic.c:1366
0x152e392 warning_at(unsigned int, int, char const*, ...)
../../gcc/diagnostic.c:1503
0x64ea89 c_process_expr_stmt(unsigned int, tree_node*)
../../gcc/c/c-typeck.c:11213
0x64eb8d c_finish_expr_stmt(unsigned int, tree_node*)
../../gcc/c/c-typeck.c:11243
0x689d18 c_parser_statement_after_labels
../../gcc/c/c-parser.c:6249
0x68bd0a c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5788
0x68c583 c_parser_compound_statement
../../gcc/c/c-parser.c:5597
0x68de38 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2539
0x694ca7 c_parser_external_declaration
../../gcc/c/c-parser.c:1777
0x6957c9 c_parser_translation_unit
../../gcc/c/c-parser.c:1650
0x6957c9 c_parse_file()
../../gcc/c/c-parser.c:21929
0x6e5532 c_common_parse_file()
../../gcc/c-family/c-opts.c:1211
[Bug analyzer/98293] New: [11 Regression] ICE in get_subregion_within_ctor, at analyzer/store.cc:494
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98293 Bug ID: 98293 Summary: [11 Regression] ICE in get_subregion_within_ctor, at analyzer/store.cc:494 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Following options produce an ICE for several testsuite files, e.g. file pr93399.c (changed between 20201004 and 20201018) : $ gcc-10 -c pr93399.c -fanalyzer -fsanitize=undefined $ $ gcc-11-20201213 -c pr93399.c -fanalyzer -fsanitize=undefined during IPA pass: analyzer pr93399.c: In function 'main': pr93399.c:14:18: internal compiler error: Segmentation fault 14 | char *substr = strstr (argv[0], "\n"); | ^~ 0xb5028f crash_signal ../../gcc/toplev.c:327 0xe936f5 get_subregion_within_ctor ../../gcc/analyzer/store.cc:494 0xe98ef7 ana::binding_map::apply_ctor_pair_to_child_region(ana::region const*, ana::region_model_manager*, tree_node*, tree_node*) ../../gcc/analyzer/store.cc:615 0xe99219 ana::binding_map::apply_ctor_to_region(ana::region const*, tree_node*, ana::region_model_manager*) ../../gcc/analyzer/store.cc:549 0xe990f0 ana::binding_map::apply_ctor_pair_to_child_region(ana::region const*, ana::region_model_manager*, tree_node*, tree_node*) ../../gcc/analyzer/store.cc:617 0xe99219 ana::binding_map::apply_ctor_to_region(ana::region const*, tree_node*, ana::region_model_manager*) ../../gcc/analyzer/store.cc:549 0xe7361c ana::decl_region::get_svalue_for_constructor(tree_node*, ana::region_model_manager*) const ../../gcc/analyzer/region.cc:931 0xe7372a ana::decl_region::get_svalue_for_initializer(ana::region_model_manager*) const ../../gcc/analyzer/region.cc:973 0xe75812 ana::region_model::get_initial_value_for_global(ana::region const*) const ../../gcc/analyzer/region-model.cc:1451 0xe8a4bc ana::reachable_regions::add(ana::region const*, bool) ../../gcc/analyzer/region-model-reachability.cc:137 0xe780c0 ana::region_model::handle_unrecognized_call(gcall const*, ana::region_model_context*) ../../gcc/analyzer/region-model.cc:967 0xe78382 ana::region_model::on_call_post(gcall const*, bool, ana::region_model_context*) ../../gcc/analyzer/region-model.cc:923 0xe5e3a4 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode const*, gimple const*, ana::program_state*) const ../../gcc/analyzer/engine.cc:1210 0xe603ae ana::exploded_graph::process_node(ana::exploded_node*) ../../gcc/analyzer/engine.cc:2948 0xe60a52 ana::exploded_graph::process_worklist() ../../gcc/analyzer/engine.cc:2573 0xe629e2 ana::impl_run_checkers(ana::logger*) ../../gcc/analyzer/engine.cc:4738 0xe6427d ana::run_checkers() ../../gcc/analyzer/engine.cc:4809 0xe57828 execute ../../gcc/analyzer/analyzer-pass.cc:87
[Bug tree-optimization/98292] New: Optimize away C return; in function returning integral/pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98292
Bug ID: 98292
Summary: Optimize away C return; in function returning
integral/pointer
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
This is related to the PR94779, but that one talks just about switches.
int
foo (int x)
{
if (x > 20)
return x;
}
int
bar (int x)
{
if (x > 30)
return 30;
}
int
baz (int x)
{
if (x > 40)
return x + 1U;
}
int
qux (int x)
{
if (x > 50)
return x | 32;
}
is optimized to just the return statement in C++ (because we add
__builtin_unreachable() in that case), but not in C.
I think we should do that also in C, provided that there are no non-debug
non-CLOBBER stmts on the branch with GIMPLE_RETURN without argument, and
provided that on the other branch there are just very few cheap stmts
guaranteed not to invoke UB/trap (appart from debug/CLOBBER stmts) plus the
GIMPLE_RETURN with argument.
LLVM seems to optimize that (though not sure if it isn't because it incorrectly
adds something like __builtin_unreachable () even for C).
[Bug tree-optimization/98291] New: multiple scalar FP accumulators auto-vectorize worse than scalar, including vector load + merge instead of scalar + high-half insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98291
Bug ID: 98291
Summary: multiple scalar FP accumulators auto-vectorize worse
than scalar, including vector load + merge instead of
scalar + high-half insert
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: missed-optimization, ssemmx
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: peter at cordes dot ca
Target Milestone: ---
Target: x86_64-*-*, i?86-*-*
An FP reduction loop with 2 scalar accumulators auto-vectorizes into a mess,
instead of effectively mapping each scalar to an element of one vector
accumulator. (Unless we use -ffast-math, then that happens. clang gets it
right even without -ffast-math).
double dotprod(const double *a, const double *b, unsigned long long n)
{
double d1 = 0.0;
double d2 = 0.0;
for (unsigned long long i = 0; i < n; i += 2) {
d1 += a[i] * b[i];
d2 += a[i + 1] * b[i + 1];
}
return (d1 + d2);
}
https://godbolt.org/z/Kq48j9
With -ffast-math the nice sane loop we expect
.L3:
movupd (%rsi,%rax), %xmm0
movupd (%rdi,%rax), %xmm3
addq$1, %rdx
addq$16, %rax
mulpd %xmm3, %xmm0
addpd %xmm0, %xmm1
cmpq%rcx, %rdx
jb .L3
without:
...
main loop
.L4:
movupd (%rcx,%rax), %xmm1# 16-byte load
movupd (%rsi,%rax), %xmm3
movhpd 16(%rcx,%rax), %xmm1 # overwrite the high half of it!!
movhpd 16(%rsi,%rax), %xmm3
mulpd %xmm3, %xmm1
movupd 16(%rsi,%rax), %xmm3
movlpd 8(%rsi,%rax), %xmm3
addsd %xmm1, %xmm2
unpckhpd%xmm1, %xmm1
addsd %xmm1, %xmm2
movupd 16(%rcx,%rax), %xmm1
movlpd 8(%rcx,%rax), %xmm1
addq$32, %rax
mulpd %xmm3, %xmm1
addsd %xmm1, %xmm0
unpckhpd%xmm1, %xmm1
addsd %xmm1, %xmm0
cmpq%rdx, %rax
jne .L4
The overall strategy is insane, but even some of the details are insane. e.g.
a 16-byte load into XMM1, and then overwriting the high half of that with a
different double before reading it. That's bad enough, but you'd expect movsd
/ movhpd to manually gather 2 doubles, without introducing the possibility of a
cache-line split load for zero benefit.
Similarly, movupd / movlpd should have just loaded in the other order. (Or
since they're contiguous, movupd 8(%rsi,%rax), %xmm3 / shufpd.)
So beyond the bad overall strategy (which is likely worse than unrolled
scalar), it might be worth checking for some of this kind of smaller-scale
insanity somewhere later to make it less bad if some other inputs can trigger
similar behaviour.
(This small-scale detecting of movupd / movhpd and using movsd / movhpd could
be a separate bug, but if it's just a symptom of something that should never
happen in the first place then it's not really its own bug at all.)
[Bug target/98210] [11 Regression] SHF_GNU_RETAIN breaks gold linker generated binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98210 --- Comment #5 from H.J. Lu --- Since gold has been fixed now, you can add a check for broken gold and set HAVE_GAS_SHF_GNU_RETAIN to 0 for broken gold.
[Bug target/98210] [11 Regression] SHF_GNU_RETAIN breaks gold linker generated binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98210 --- Comment #4 from Jozef Lawrynowicz --- Since gold is not built by default, should we just disable SHF_GNU_RETAIN support if gold has been built at all, for Binutils versions without the gold patch. There's 2 weeks between the GCC "used" implying SHF_GNU_RETAIN patch and gold being fixed, so the real fix if you want SHF_GNU_RETAIN support but are using a Binutils version in this timeframe is to just upgrade. Meanwhile we should just completely turn off SHF_GNU_RETAIN if GCC can spot that a broken gold is available.
[Bug fortran/98290] run-time error with optional character arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98290 Andreas Schwab changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug tree-optimization/94779] Bad optimization of simple switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779 --- Comment #13 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #12) > So, for start I think we should do: > 1) query->range_of_expr (m_index_range, m_index_expr, swtch) >where query is address of gimple_ranger passed down from the caller >to figure out range of the index expression; case labels without For starters, you can probably simply create a gimple_ranger on the spot to do the query. At least until everything works the way you want. Its low overhead... we had reasonable success with that early on with some pass conversions, and ultimately we hope by next release to make this more generally accessible without passing a ranger around anyway. > CASE_HIGH for >which m_index_range.contains_p (CASE_LOW (case)) is false can be ignored >for the optimization (well, handled the way it is better for the > optimization) >For CASE_HIGH labels, similarly query if the range overlaps the index > range. >Note, I don't remember exactly in which way the types of the index > expression >and of the case labels can differ, I believe all case labels have to have > the >same type, so probably for the computation of the range if it has > different >type from the case label ones, it needs to call something that would > emulate >the effect of conversion to that type (or vice versa?) >CCing Andrew for the range stuff There are a couple of PRs related to this, I forget the current resolution, but I originally opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87798 for it. Ranger currently punts if the precision of the labels is different than the precision of the switch expr in gimple-range-edge.cc : outgoing_range::get_edge_range In order to convert between types, range-op.h exports the routine extern void range_cast (irange &, tree type); which does an in place conversion to type... supports full cast semantics. there are uses of it sprinkled around. Furthermore, IIRC there can be multiple cases sharing the same edge.. It seems it might be useful to make more use of gimple-range-edge.h here.. (we may need some tweaks in order to get things working with a ranger since this is a private member to ranger) so I would again start by simply creating my own local outgoing_range instance and then you can ask int_range_max range; outgoing_range_instance.edge_range_p (range, switch_edge) where this will give you the cumulative union of all the case-labels on that switch edge. (its unrelated to the index variable... Ranger intersects this range with the index variable range when you ask for the range of the index variable on an edge) If this turns out to be useful, we can probably figure a way to get it exported from ranger to avoid creating a local instance The last useful bit of info that may not be obvious... if you ask ranger for the range of the index variable on the default edge, and if all the cases cover the known range of the index variable, as in the first example, then ranger will return a range of UNDEFINED ... meaning it can never take that edge. ie the function in the first example shows me: === BB 4 x_2(D) unsigned int [0, 2] : switch (x_2(D)) [INV], case 0: [INV], case 1: [INV], case 2: [INV]> 4->7 x_2(D) : UNDEFINED 4->8 x_2(D) : unsigned int [0, 0] 4->5 x_2(D) : unsigned int [1, 1] 4->6 x_2(D) : unsigned int [2, 2] where edge 4->7 is the default case...
[Bug fortran/98290] run-time error with optional character arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98290 Vivek Rao changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Vivek Rao --- Sorry, never mind. When I remove the code vec = "" which is illegal because vec has not yet been allocated, the code runs fine with gfortran.
[Bug fortran/98290] New: run-time error with optional character arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98290
Bug ID: 98290
Summary: run-time error with optional character arguments
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vivekrao4 at yahoo dot com
Target Milestone: ---
With GNU Fortran (GCC) 11.0.0 20200927 (experimental) on Windows from
equation.com, compiling and running the code
function c(x1,x2) result(vec)
! return array of present character variable arguments
character (len=*) , intent(in), optional :: x1,x2
character (len=10), allocatable :: vec(:)
character (len=10), allocatable :: vec_(:)
integer :: n
allocate (vec_(2))
vec = ""
if (present(x1)) vec_(1) = x1
if (present(x2)) vec_(2) = x2
n = count([present(x1),present(x2)])
allocate (vec(n))
if (n > 0) vec = vec_(:n)
end function c
end module util_mod
!
program xc
use util_mod, only: c
implicit none
print*,c("girl","boy")
end program xc
gives
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x
#1 0x
#2 0x
#3 0x
#4 0x
#5 0x
#6 0x
#7 0x
#8 0x
#9 0x
#10 0x
#11 0x
#12 0x
#13 0x
#14 0x
but
gives
girl boy
with g95 and Intel Fortran.
[Bug target/98289] New: [x86] Suboptimal optimization of stack usage when function call to cold function is not needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98289
Bug ID: 98289
Summary: [x86] Suboptimal optimization of stack usage when
function call to cold function is not needed
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
void f(bool cond)
{
if (cond)
__builtin_abort();
}
On x86 with current trunk and -O3, this results in :
f(bool):
sub rsp, 8
test dil, dil
jne .L3
add rsp, 8
ret
f(bool) [clone .cold]:
.L3:
call abort
This seems like a regression over GCC 7.5, which outputs :
f(bool):
test dil, dil
jne .L7
rep ret
.L7:
sub rsp, 8
call abort
Along with LLVM, which has similar output. Only emitting the code to begin the
call upon being asked to do seems quicker in the case where the call doesn't
occur.
[Bug c++/98288] Accidental equality of classes templated by pointer to local static constant of templated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98288 --- Comment #1 from Matthieu M --- The above program leads to an ICE on gcc (trunk): https://godbolt.org/z/dGe1T6, from SO user https://stackoverflow.com/users/4832499/passer-by.
[Bug rtl-optimization/98287] [10/11 Regression] ICE: in expand_expr_real_2, at expr.c:10000 with -O2 -fno-tree-ccp -fno-tree-forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98287
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milestone|--- |10.3
Priority|P3 |P2
--- Comment #1 from Jakub Jelinek ---
Started with r10-2805-ge944354ec05891474b0d204c6c239c04ee7b527b
I think this is another case of harmful folding after last veclower, in this
case during vrp2. After last veclower we need to be careful not to introduce
vector arithmetics that isn't supported by the target, as the expander doesn't
have fallback for that, it relies on tree-vect-generic.c doing its job.
So, either we need to guard all such match.pd etc. simplifications with checks
whether the operations are supported on the vectors if we are after last
veclower
- in this particular case it is the x >> 1 << 1 optimization to x & { ~1 },
where the backend announces V1DImode >> and << but not AND, or schedule another
veclower right before *.optimized dump to cover anything that got broken (or
before isel and hope isel doesn't fold things?), or add fallback to the
expander (the V1* vectors would be fairly easy, but anything else would be hard
and ugly).
[Bug c++/98288] New: Accidental equality of classes templated by pointer to local static constant of templated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98288
Bug ID: 98288
Summary: Accidental equality of classes templated by pointer to
local static constant of templated function
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matthieum.147192 at gmail dot com
Target Milestone: ---
Based on https://stackoverflow.com/q/65306562/147192.
The behavior of GCC (and Clang) is inconsistent (between compile-time and
run-time), however it is unclear to me whether the inconsistency is conforming
with the C++17 standard or not.
The following reduced program is expected to return 0 (invoking g++ with
-std=c++17):
template
struct is_same { static constexpr bool value = false; };
template
struct is_same { static constexpr bool value = true; };
template
static constexpr bool is_same_v = is_same::value;
using uintptr_t = unsigned long long;
template
struct Parameterized { int const* member; };
template
auto create() {
static constexpr int const I = 2;
return Parameterized<>{ };
}
int main() {
auto one = create();
auto two = create();
if (is_same_v) {
return reinterpret_cast(one.member) ==
reinterpret_cast(two.member) ? 1 : 2;
}
return 0;
}
Yet, on all versions of GCC where it compiles (from 7.2 onwards), and for all
optimization levels (from -O0 to -O3), it returns 2, indicating:
- That `one` and `two` have the same type -- which according to 17.4
[temp.type] should mean that they point to the same object.
- Yet they point to different objects -- there are two instances of
`create()::I`, one for `T = short` and one for `T = int`.
The assembly listing clearly contains 2 different instances of
`create()::I`.
Notes:
- If `I` is initialized with `= sizeof(T)`, instead, then the program returns 0
as expected.
- Clang (up to 11.0) fails to compile the program with -O0 (the linker failing
to find a `create()::I` variable), and otherwise produces the same result as
GCC with -O1 to -O3.
[Bug tree-optimization/94779] Bad optimization of simple switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
Jakub Jelinek changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment #12 from Jakub Jelinek ---
So, for start I think we should do:
1) query->range_of_expr (m_index_range, m_index_expr, swtch)
where query is address of gimple_ranger passed down from the caller
to figure out range of the index expression; case labels without CASE_HIGH
for
which m_index_range.contains_p (CASE_LOW (case)) is false can be ignored
for the optimization (well, handled the way it is better for the
optimization)
For CASE_HIGH labels, similarly query if the range overlaps the index range.
Note, I don't remember exactly in which way the types of the index
expression
and of the case labels can differ, I believe all case labels have to have
the
same type, so probably for the computation of the range if it has different
type from the case label ones, it needs to call something that would emulate
the effect of conversion to that type (or vice versa?)
CCing Andrew for the range stuff
2) similarly, cases that refer to blocks which have EDGE_COUNT (bb->succs) == 0
&& gimple_seq_unreachable_p (bb_seq (bb)) should be treated again like cases
one shouldn't need to care about
3) to handle the #c0 testcase in C (C++ already adds __builtin_unreachable),
handle also the case where case refers to block which has EDGE_COUNT
(bb->succs) and ends in GIMPLE_RETURN without expression in a function that
returns integral or pointer value (for simplicity) and has no statements
other than debug stmts or clobber stmts before it. Note, this case can't be
treated completely like a UB case, there is no UB in C unless the caller
checks the return value, but it could be handled conditionally, as long as
the code we emit for that doesn't invoke UB in the function, we really don't
care about the value we return to the caller. So e.g. if we are considering
a linear function and other case labels return that linear value and some
return unspecified value, just use the linear function to cover those too.
4) to be able to optimize the int f1(unsigned x) { if (x >= 3)
__builtin_unreachable();
switch (x) { case 0: return 1; case 1: return 2; case 2: return 3; } }
testcase, we should for consideration virtually undo the evrp optimization
which removed the case 0: and replaced it with default: - here the handled
cases (that should include the really handled ones and ones that and the
UB ones (if the case is outside of range or __builtin_unreachable) cover
everything but one case, assume the default label is that for that single
case rather than handling anything else; similarly, if the whole range
is covered, ignore the default label
[Bug rtl-optimization/98287] New: [10/11 Regression] ICE: in expand_expr_real_2, at expr.c:10000 with -O2 -fno-tree-ccp -fno-tree-forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98287 Bug ID: 98287 Summary: [10/11 Regression] ICE: in expand_expr_real_2, at expr.c:1 with -O2 -fno-tree-ccp -fno-tree-forwprop Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 49768 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49768=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O2 -fno-tree-ccp -fno-tree-forwprop testcase.c during RTL pass: expand testcase.c: In function 'bar': testcase.c:7:22: internal compiler error: in expand_expr_real_2, at expr.c:1 7 | return v >> s << s | v >> s >> 63; | ^~ 0x661c3d expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /repo/gcc-trunk/gcc/expr.c:1 0xc21188 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /repo/gcc-trunk/gcc/expr.c:10201 0xaeb6ab expand_expr /repo/gcc-trunk/gcc/expr.h:282 0xaeb6ab expand_return /repo/gcc-trunk/gcc/cfgexpand.c:3764 0xaeb6ab expand_gimple_stmt_1 /repo/gcc-trunk/gcc/cfgexpand.c:3873 0xaeb6ab expand_gimple_stmt /repo/gcc-trunk/gcc/cfgexpand.c:3999 0xaf0c4b expand_gimple_basic_block /repo/gcc-trunk/gcc/cfgexpand.c:6036 0xaf27c6 execute /repo/gcc-trunk/gcc/cfgexpand.c:6720 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-6041-20201215101608-g69bd5d473d2-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r11-6041-20201215101608-g69bd5d473d2-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.0 20201215 (experimental) (GCC)
[Bug libstdc++/97549] [11 Regression] include/pstl rebase breaking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97549 --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > There are also errors when compiling with the Intel compiler and tbb from > oneAPI (aka tbb 2021.1.1): Which is documented as not working, due to API changes in tbb: https://software.intel.com/content/www/us/en/develop/articles/intel-oneapi-threading-building-blocks-release-notes.html
[Bug libstdc++/97549] [11 Regression] include/pstl rebase breaking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97549 --- Comment #2 from Jonathan Wakely --- There are also errors when compiling with the Intel compiler and tbb from oneAPI (aka tbb 2021.1.1): In file included from /usr/include/c++/10/pstl/parallel_backend.h(16), from /usr/include/c++/10/pstl/algorithm_impl.h(22), from /usr/include/c++/10/pstl/glue_execution_defs.h(50), from /usr/include/c++/10/execution(32), from pstl.C(1): /usr/include/c++/10/pstl/parallel_backend_tbb.h(70): error: name followed by "::" must be a class or namespace name tbb::task::self().group()->cancel_group_execution(); ^ In file included from /usr/include/c++/10/pstl/parallel_backend.h(16), from /usr/include/c++/10/pstl/algorithm_impl.h(22), from /usr/include/c++/10/pstl/glue_execution_defs.h(50), from /usr/include/c++/10/execution(32), from pstl.C(1): /usr/include/c++/10/pstl/parallel_backend_tbb.h(413): error: namespace "tbb" has no member class "task" class __merge_task : public tbb::task ^
[Bug rtl-optimization/78559] [7 Regression] wrong code due to tree if-conversion?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78559 Andreas Krebbel changed: What|Removed |Added CC||stli at linux dot ibm.com --- Comment #15 from Andreas Krebbel --- *** Bug 98269 has been marked as a duplicate of this bug. ***
[Bug c/98269] gcc 6.5.0 __builtin_add_overflow() with small uint32_t values incorrectly detects overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98269
Andreas Krebbel changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
CC||krebbel at gcc dot gnu.org
--- Comment #4 from Andreas Krebbel ---
The problem is a CC mode mismatch generated by combine. After splitting the add
insn 135 generates a CCL1mode cc while the conditional jump consumes it as
CCUmode. This leads to the wrong condition code mask being generated in the
end.
(insn 135 56 136 7 (parallel [
(set (reg:CCL1 33 %cc)
(compare:CCL1 (plus:SI (reg:SI 108)
(mem:SI (plus:DI (reg:DI 88 [ ivtmp.10 ])
(const_int 12 [0xc])) [3 MEM[base: previous_25,
offset: 12B]+0 S4 A32]))
(reg:SI 108)))
(set (reg:SI 109)
(plus:SI (reg:SI 108)
(mem:SI (plus:DI (reg:DI 88 [ ivtmp.10 ])
(const_int 12 [0xc])) [3 MEM[base: previous_25,
offset: 12B]+0 S4 A32])))
]) t.c:31 1358 {*addsi3_carry1_cc}
(expr_list:REG_DEAD (reg:SI 108)
(nil)))
(note 136 135 64 7 NOTE_INSN_DELETED)
(insn 64 136 65 7 (set (mem:SI (plus:DI (reg:DI 88 [ ivtmp.10 ])
(const_int 28 [0x1c])) [3 MEM[base: previous_25, offset: 28B]+0
S4 A32])
(reg:SI 109)) t.c:31 1077 {*movsi_zarch}
(nil))
(note 65 64 66 7 NOTE_INSN_DELETED)
(jump_insn 66 65 67 7 (set (pc)
(if_then_else (geu (reg:CCU 33 %cc)
(const_int 0 [0]))
(label_ref 78)
(pc))) t.c:31 1661 {*cjump_64}
(int_list:REG_BR_PROB 9500 (expr_list:REG_DEAD (reg:CCZ 33 %cc)
(nil)))
The failure disappears with:
commit bf7499197fbb065123257c374064f6bb715c951b
Author: Dominik Vogt
Date: Mon Jul 4 14:25:22 2016 +
S/390: Add support for z13 instructions lochi and locghi.
The attached patch adds patterns to make use of the z13 LOCHI and
LOCGHI instructions.
...
But that one only hides the problem. The mere presence of the lochi
alternatives lead to different RTL being emitted (although the alternative is
not enabled for -march=z196). The split then doesn't happen anymore.
Reverting the patch and continue bisecting. The failure finally disappears
with:
3f54004b095d1cd513e63753ee0f8f9f13698347 is the first bad commit
commit 3f54004b095d1cd513e63753ee0f8f9f13698347
Author: Bin Cheng
Date: Fri Jan 27 14:42:23 2017 +
re PR rtl-optimization/78559 (wrong code due to tree if-conversion?)
PR rtl-optimization/78559
* combine.c (try_combine): Discard REG_EQUAL and REG_EQUIV for
other_insn in combine.
This looks like the actual fix to me. The wrong CC mode survives as part of a
REG_EQUAL note:
Successfully matched this instruction:
(set (reg:SI 93 [ _27+4 ])
(if_then_else:SI (geu (reg:CCL1 33 %cc)
(const_int 0 [0]))
(reg:SI 93 [ _27+4 ])
(reg:SI 118)))
allowing combination of insns 56 and 135
original costs 4 + 4 = 16
replacement cost 8
deferring deletion of insn with uid = 56.
modifying other_insn 136: r93:SI={(geu(%cc:CCL1,0))?r93:SI:r118:SI}
REG_DEAD %cc:CCU
REG_EQUAL ltu(%cc:CCU,0)
deferring rescan insn with uid = 136.
modifying insn i3 135:
{%cc:CCL1=cmp(r108:SI+[r88:DI+0xc],r108:SI);r109:SI=r108:SI+[r88:DI+0xc];}
REG_DEAD r108:SI
deferring rescan insn with uid = 135.
So we probably should mark it as duplicate of PR78559.
*** This bug has been marked as a duplicate of bug 78559 ***
[Bug c++/90782] internal compiler error: in dependent_type_p, at cp/pt.c:25409
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90782
--- Comment #6 from getchar_gnu at hotmail dot com ---
https://gcc.godbolt.org/z/qzG9jj
template
struct bar {
template
bar(B& obj, void(B::*f)(A...)const=::operator()){}
};
int main() {
const auto f1 = [](){};
bar f8(f1);
}
This compiles on clang and ice on gcc
[Bug libstdc++/98108] Broken Schwarz counter for iostreams initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98108 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- I've added the init_priority attribute on trunk, which makes this (broken) program work as expected.
[Bug c++/78173] Hard error subtracting pointers to incomplete type in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78173 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:fa452a843d26a64a5ca0fd7c17ea1bd6e1b81a69 commit r11-6074-gfa452a843d26a64a5ca0fd7c17ea1bd6e1b81a69 Author: Jonathan Wakely Date: Tue Dec 15 11:40:07 2020 + libstdc++: Remove workaround for PR c++/78173 Now that the G++ bug is fixed we no longer need to protect this partial specialization from complaining about subtracting void pointers. libstdc++-v3/ChangeLog: * include/bits/iterator_concepts.h (incrementable_traits): Remove workaround for PR c++/78173.
[Bug libstdc++/98108] Broken Schwarz counter for iostreams initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98108 --- Comment #4 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:cf4ed3b41594b6935a337fe0aaf8149eadf88751 commit r11-6072-gcf4ed3b41594b6935a337fe0aaf8149eadf88751 Author: Jonathan Wakely Date: Tue Dec 15 11:40:06 2020 + libstdc++: Use init_priority attribute for Init object [PR 98108] This causes the global objects that run the initialization code to be constructed earlier, which avoids some bugs in user code due to incorrectly relying on static initialization order. libstdc++-v3/ChangeLog: PR libstdc++/98108 * include/std/iostream (__ioinit): Add init_priority attribute.
[Bug libstdc++/65118] Android target build is broken with "guard.cc:36:22: fatal error: syscall.h: No such file or directory"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65118 Jonathan Wakely changed: What|Removed |Added Resolution|--- |WORKSFORME Status|WAITING |RESOLVED --- Comment #4 from Jonathan Wakely --- OK, thanks.
[Bug target/97827] bootstrap error building the amdgcn-amdhsa offload compiler with LLVM 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827 --- Comment #11 from Tobias Burnus --- For completeness, the LLVM 'main' patch was backported/cherry-picked for LLVM 11.0.1 with commit 700baa009dc685a0adc5f94d258be4ae24742471 Regarding the .section discussion, see also last few comments in https://reviews.llvm.org/D92052 Thanks again for the bug report report, Matthias – and to those providing background information and helping to reach a good solution :-)
[Bug lto/98275] -flto=auto fails if nthreads_var is zero, must not pass -j0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98275 --- Comment #4 from Pekka S --- (I wrote this prior the ticked was modifed and the patch committed.) Thanks. Applied the patch on the latest trunk, built aarch64-none-gcc cross compiler (mingw64). Using -flto=auto -v reports `LTO parallelism level set to 1' and `make -f -j1 all'; Linking now succeeds. Tested using GNU make 4.2.93 and 4.3 (msys2). I do not know whether or not the number of processors should be actually detectable. I presume I'll be simply using -flto=N (N>1) as it appears to work just fine. As a side note behaviour is now slightly different between -flto=auto if nthreads_var<=1 and -flto=N where N<=1.
[Bug c++/98282] [8/9/10/11 Regression] Segmentation fault when compiling with optimization >= 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98282
Jakub Jelinek changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
So, the ICE is because compute_avail gets called twice on VIEW_CONVERT_EXPR
from NULL to decltype(nullptr):
stmt:
_7 = VIEW_CONVERT_EXPR Unknown tree: nullptr_type (0B);
rhs1:
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set 14 canonical-type
0x7fffea1a3c78
pointer_to_this reference_to_this
>
constant
arg:0
constant 0>
pr98282.ii:19:13 start: pr98282.ii:19:13 finish: pr98282.ii:19:16>
TREE_TYPE (TREE_OPERAND (rhs1, 0)):
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea05f5e8 precision:32 min max
pointer_to_this >
public unsigned DI
size constant 64>
unit-size constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea0679d8>
TYPE_CANONICAL (TREE_TYPE (TREE_OPERAND (rhs1, 0))):
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set 10 canonical-type
0x7fffea05f5e8 precision:32 min max
pointer_to_this >
unsigned DI
size constant 64>
unit-size constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set 4 canonical-type
0x7fffea0679d8>
The alias-set 4 above means get_alias_set on the VCE returns 4.
Second case:
stmt:
_8 = VIEW_CONVERT_EXPR Unknown tree: nullptr_type (0B);
rhs1:
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set 14 canonical-type
0x7fffea1a3c78
pointer_to_this reference_to_this
>
constant
arg:0
constant 0>
pr98282.ii:15:15 start: pr98282.ii:15:15 finish: pr98282.ii:15:15>
TREE_TYPE (TREE_OPERAND (rhs1, 0)):
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set 17 canonical-type
0x7fffea1b5dc8
fields
addressable used nothrow public static weak autoinline decl_3
decl_5 QI defer-output pr98282.ii:60:8 align:16 warn_if_not_align:0 context
initial result
full-name "h& h::operator=(h&&)" chain > context
full-name "struct h"
needs-constructor X() X(constX&) this=(X&) n_parents=0 use_template=0
interface-unknown
pointer_to_this reference_to_this
chain >
public unsigned DI
size constant 64>
unit-size constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea1bf000>
TYPE_CANONICAL (TREE_TYPE (TREE_OPERAND (rhs1, 0))):
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set 17 canonical-type
0x7fffea1b5dc8
fields
addressable used nothrow public static weak autoinline decl_3
decl_5 QI defer-output pr98282.ii:60:8 align:16 warn_if_not_align:0 context
initial result
full-name "h& h::operator=(h&&)" chain > context
full-name "struct h"
needs-constructor X() X(constX&) this=(X&) n_parents=0 use_template=0
interface-unknown
pointer_to_this reference_to_this
chain >
public unsigned type_6 DI
size constant 64>
unit-size constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0x7fffea1bf000>
And the alias-set 1 means get_alias_set on the second VCE returns 1.
I think at least for the VCE of constant case (but VCE of SSA_NAME etc. would
as well) we shouldn't consider alias set at all.
So, one possible fix is:
--- gcc/tree-ssa-pre.c.jj 2020-11-30 10:48:31.0 +0100
+++ gcc/tree-ssa-pre.c 2020-12-15 10:51:51.061206572 +0100
@@ -4176,13 +4176,17 @@ compute_avail (void)
&& ref2->opcode != MEM_REF
&& ref2 != [0])
--ref2;
- if ((ref1->opcode == TARGET_MEM_REF
- || ref1->opcode == MEM_REF)
- && (TYPE_ALIGN (ref1->type)
- > TYPE_ALIGN (ref2->type)))
- ref1->type
- = build_aligned_type (ref1->type,
- TYPE_ALIGN (ref2->type));
+ if (ref1->opcode == TARGET_MEM_REF
+ || ref1->opcode == MEM_REF)
+ {
+ if (TYPE_ALIGN (ref1->type)
+ > TYPE_ALIGN (ref2->type))
+ ref1->type
+ = build_aligned_type (ref1->type,
+ TYPE_ALIGN (ref2->type));
+ }
+ else
+ set = ref->set;
/* TBAA behavior is an obvious part so make sure
that the hashtable one covers this as well
by
[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Andrea Corallo : https://gcc.gnu.org/g:41a2a54476cba88376c4b30ca8b94b4a088a66ce commit r10-9153-g41a2a54476cba88376c4b30ca8b94b4a088a66ce Author: Andrea Corallo Date: Wed Dec 9 17:59:12 2020 +0100 ira.c: Fix ICE in ira-color [PR97092] 2020-12-10 Andrea Corallo gcc/ChangeLog 2020-12-10 Andrea Corallo PR rtl-optimization/97092 * ira-color.c (update_costs_from_allocno): Do not carry over mode between subsequent iterations. gcc/testsuite/ChangeLog 2020-12-10 Andrea Corallo * gcc.target/aarch64/sve/pr97092.c: New test.
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 Levy changed: What|Removed |Added Attachment #49543|0 |1 is obsolete|| Attachment #49575|0 |1 is obsolete|| Attachment #49757|0 |1 is obsolete|| --- Comment #49 from Levy --- Created attachment 49767 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49767=edit Auto-extend Patch Combined all three patches. = Summary of gcc testsuite = | # of unexpected case / # of unique unexpected case | gcc | g++ | gfortran | rv64imafdc/ lp64d/ medlow |0 / 0 |0 / 0 | - | (May require some work on coding style)
[Bug target/98274] -march=x86-64-v[234] incompatible with target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98274 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug target/98274] -march=x86-64-v[234] incompatible with target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98274
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:69bd5d473d22157d0737fc20e98eb3347cbd6ab5
commit r11-6041-g69bd5d473d22157d0737fc20e98eb3347cbd6ab5
Author: Jakub Jelinek
Date: Tue Dec 15 10:16:08 2020 +0100
i386: Fix up -march=x86-64-v[234] vs. target attribute [PR98274]
The following testcase fails to compile. The problem is that
when ix86_option_override_internal is called the first time for command
line, it sees -mtune= wasn't present on the command line and so as fallback
sets ix86_tune_string to ix86_arch_string value ("x86-64-v2"), but
ix86_tune_specified is false, so we don't find the tuning in the table
but don't error on it.
When processing the target attribute, ix86_tune_string is what
it was earlier left with, but this time ix86_tune_specified is true and
so we error on it.
The following patch does what is done already e.g. for "x86-64" march,
in particular default the tuning to "generic".
2020-12-15 Jakub Jelinek
PR target/98274
* config/i386/i386-options.c (ix86_option_override_internal): Set
ix86_tune_string to "generic" even when it wasn't specified and
ix86_arch_string is "x86-64-v2", "x86-64-v3" or "x86-64-v4".
Remove useless {}s around a single statement.
* gcc.target/i386/pr98274.c: New test.
[Bug c++/98286] g++ accepts 'void d(void) { typename foo; }' as valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98286 Andrew Pinski changed: What|Removed |Added Known to fail||7.5.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||accepts-invalid Last reconfirmed||2020-12-15 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/98176] Loop invariant memory could not be hoisted when nonpure_call in loop body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98176
--- Comment #7 from Hongyu Wang ---
(In reply to Richard Biener from comment #5)
> Yes.
>
> For a LIM testcase an example with a memcpy might be more practically
> relevant.
>
> For refactoring I'd start with classifying the unanalyzable refs as
> separate ref ID, marking it with another bit like ref_unanalyzed in
> in_mem_ref and asserting there's a single access of such refs.
> The mem_refs_may_alias_p code then needs to use stmt-based alias
> queries instead of refs_may_alias_p_1 using accesses_in_loop[0]->stmt.
>
> And code testing for UNANALYZABLE_MEM_ID now needs to look at the
> ref_unanalyzed flag to not consider those refs for transforms.
>
> Note this may blow up the memory requirements for testcases with lots
> of "unanalyzable" refs.
>
> The nonpure-call code is more difficult to improve, even sincos can not
> return
> when the access to s or c traps. Analyzing the arguments might help here.
> If you disregard that detail I think all ECF_LEAF|ECF_NOTHROW functions
> return normally.
Thanks for the suggestion, I did some refactor accordingly and this case could
be vectorized.
diff --git a/gcc/tree-ssa-loop-im.c b/gcc/tree-ssa-loop-im.c
index 92e5a8dd774..3e3e81bc36f 100644
--- a/gcc/tree-ssa-loop-im.c
+++ b/gcc/tree-ssa-loop-im.c
@@ -119,6 +119,8 @@ public:
(its index in memory_accesses.refs_list) */
unsigned ref_canonical : 1; /* Whether mem.ref was canonicalized. */
unsigned ref_decomposed : 1; /* Whether the ref was hashed from mem. */
+ unsigned ref_unanalyzed : 1; /* Whether the ref was unanalyzed memory. */
+
hashval_t hash; /* Its hash value. */
/* The memory access itself and associated caching of alias-oracle
@@ -260,7 +262,14 @@ static bool refs_independent_p (im_mem_ref *, im_mem_ref
*, bool = true);
#define UNANALYZABLE_MEM_ID 0
/* Whether the reference was analyzable. */
-#define MEM_ANALYZABLE(REF) ((REF)->id != UNANALYZABLE_MEM_ID)
+#define MEM_ANALYZABLE(REF) ((REF)->id != UNANALYZABLE_MEM_ID \
+&& !(REF)->ref_unanalyzed)
+
+#define REF_ID_UNANALYZABLE(id)
\
+ (id == UNANALYZABLE_MEM_ID \
+ || ((memory_accesses.refs_list[id]) \
+ && (memory_accesses.refs_list[id]->ref_unanalyzed)) \
+ )
static struct lim_aux_data *
init_lim_data (gimple *stmt)
@@ -829,7 +838,8 @@ set_profitable_level (gimple *stmt)
set_level (stmt, gimple_bb (stmt)->loop_father, get_lim_data
(stmt)->max_loop);
}
-/* Returns true if STMT is a call that has side effects. */
+/* Returns true if STMT is a call that has side effects, or it is
+ not a function call with ECF_LEAF | ECF_NOTHROW. */
static bool
nonpure_call_p (gimple *stmt)
@@ -837,6 +847,11 @@ nonpure_call_p (gimple *stmt)
if (gimple_code (stmt) != GIMPLE_CALL)
return false;
+ /* Simplified here, better to analyze call parameter. */
+ int flags = gimple_call_flags (stmt);
+ if (flags & (ECF_LEAF | ECF_NOTHROW))
+return false;
+
return gimple_has_side_effects (stmt);
}
@@ -1377,6 +1392,7 @@ mem_ref_alloc (ao_ref *mem, unsigned hash, unsigned id)
ref->id = id;
ref->ref_canonical = false;
ref->ref_decomposed = false;
+ ref->ref_unanalyzed = false;
ref->hash = hash;
ref->stored = NULL;
ref->loaded = NULL;
@@ -1461,9 +1477,13 @@ gather_mem_refs_stmt (class loop *loop, gimple *stmt)
mem = simple_mem_ref_in_stmt (stmt, _stored);
if (!mem)
{
- /* We use the shared mem_ref for all unanalyzable refs. */
- id = UNANALYZABLE_MEM_ID;
- ref = memory_accesses.refs_list[id];
+ /* Mark unanaylzable refs with different id and skip analysis. */
+ id = memory_accesses.refs_list.length ();
+ ref = mem_ref_alloc (NULL, 0, id);
+ ref->ref_unanalyzed = true;
+ memory_accesses.refs_list.safe_push (ref);
+ record_mem_ref_loc (ref, stmt, NULL);
+
if (dump_file && (dump_flags & TDF_DETAILS))
{
fprintf (dump_file, "Unanalyzed memory reference %u: ", id);
@@ -1576,7 +1596,7 @@ gather_mem_refs_stmt (class loop *loop, gimple *stmt)
mark_ref_stored (ref, loop);
}
/* A not simple memory op is also a read when it is a write. */
- if (!is_stored || id == UNANALYZABLE_MEM_ID)
+ if (!is_stored || REF_ID_UNANALYZABLE (id))
{
bitmap_set_bit (_accesses.refs_loaded_in_loop[loop->num],
ref->id);
mark_ref_loaded (ref, loop);
@@ -1701,6 +1721,31 @@ mem_refs_may_alias_p (im_mem_ref *mem1, im_mem_ref
*mem2,
poly_widest_int size1, size2;
aff_tree off1, off2;
+ /* For refs marked as unanalyzed, use stmt_based alias analysis
+ and returns false when one mem_ref used by this unanalyzed stmt*/
+ if (mem1->ref_unanalyzed
+ || mem2->ref_unanalyzed)
+{
+ if (mem1->ref_unanalyzed
+ &&
[Bug c++/98286] New: g++ accepts 'void d(void) { typename foo; }' as valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98286
Bug ID: 98286
Summary: g++ accepts 'void d(void) { typename foo; }' as valid
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Extracted from larger confusing boost example where g++ and clang++ disagree on
syntactic validity. Filing a small one:
$ cat bug.cpp
void d(void) { typename foo; }
$ g++-11.0.0 -c bug.cpp -Wall -Wextra
bug.cpp: In function 'void d()':
bug.cpp:1:25: warning: unused variable 'foo' [-Wunused-variable]
1 | void d(void) { typename foo; }
| ^~~
$ clang++ -c bug.cpp -Wall -Wextra
bug.cpp:1:25: error: expected a qualified name after 'typename'
void d(void) { typename foo; }
^
bug.cpp:1:25: error: C++ requires a type specifier for all declarations
2 errors generated.
It looks like g++ interpreted 'typename foo;' as 'int foo'.
Should the example compile?
