[Bug c/24293] Undefined behaviour not diagnosed with -fsyntax-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24293 Andrew Pinski changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #9 from Andrew Pinski --- *** Bug 70749 has been marked as a duplicate of this bug. ***
[Bug c/70749] error: storage size of ‘a’ isn’t known goes away with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70749 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |6.0 Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup of bug 24293. *** This bug has been marked as a duplicate of bug 24293 ***
[Bug c/32122] indirect goto to an integer accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32122 --- Comment #5 from Andrew Pinski --- Created attachment 51472 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51472=edit Patch which I am testing It passes all of gcc.dg/dg.exp I am doing a full bootstrap/test right now.
[Bug target/58889] GCC 4.9 fails to compile certain functions with intrinsics with __attribute__((target))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58889 --- Comment #3 from Hongtao.liu --- It seems to be fixed in GCC.4.9.0 https://godbolt.org/z/MbqPzeTEP
[Bug c/32122] indirect goto to an integer accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32122 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Andrew Pinski --- Mine, I have a patch.
[Bug tree-optimization/102381] unexpected -Wmaybe-uninitialized with noreturn inside loop and conditional setting of variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102381 --- Comment #2 from Andrew Pinski --- The noreturn messes up the anlysis fully.
[Bug tree-optimization/102381] unexpected -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102381 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-17 --- Comment #1 from Andrew Pinski --- Confirmed. [AFTER NORMALIZATION -- [DEF]: ipp_28 = PHI is guarded by : i2.2_26 > 0 (.AND.) i1_10(D) != 0 [AFTER NORMALIZATION -- [USE]: ipp_27 = PHI is guarded by : i1_10(D) != 0 (.AND.) (.NOT.) i4_17 < prephitmp_25 (.AND.) _2 == 0 (.OR.) i1_10(D) != 0 (.AND.) (.NOT.) i4_17 < prephitmp_25 (.AND.) i3.0_1 & 1 ... _2 = i3.0_1 & 1; So there is a missing simplification It should have been: i1_10(D) != 0 (.AND.) (.NOT.) i4_17 < prephitmp_25 prephitmp_25 is defined as: # prephitmp_25 = PHI So i2.2_26 (as i2.2_21 is the one on the branch which would have been uninitialized). So we are down to: i1_10(D) != 0 (.AND.) (.NOT.) i4_17 < i2.2_26 i4_17 is the loop IV so it should be discarded.
[Bug tree-optimization/102383] Missing optimization for PRE after enable O2 vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102383 --- Comment #1 from Hongtao.liu --- Similar issue for gfortran.dg/pr77498.f?(not quite sure)
[Bug tree-optimization/102364] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102364 --- Comment #3 from Jiu Fu Guo --- We may be able to mark this as a duplicate of PR100740/PR102131.
[Bug tree-optimization/102364] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102364
--- Comment #2 from Jiu Fu Guo ---
This is also the case that two ivs are combined into inaccurate step:
"{3,+,1} < {11,+,2}" was transformed to "{3,+,-1} < {11,+,0}".
The new condition is not same with the original one.
[Bug tree-optimization/102384] New: Missing optimization for pcom after enable O2 vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102384
Bug ID: 102384
Summary: Missing optimization for pcom after enable O2
vectorization
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
testcase is from gcc.dg/tree-ssa/predcom-dse-3.c
void __attribute__((noinline)) foo4 (int *a)
{
int i;
for (i = 0; i < 100; i++)
{
a[i] = 0;
a[i + 3] = -1;
}
}
novectorize vs vectorize dump
@@ -1576,111 +1576,86 @@ void foo3 (int * a)
;; Function foo4 (foo4, funcdef_no=4, decl_uid=2022, cgraph_uid=5,
symbol_order=12)
Processing loop 1
-Creating dr for *_3
...skipping...
- _5 = _4 * 4;
- _6 = a_10(D) + _5;
- i_13 = i_17 + 1;
- ivtmp_15 = ivtmp_16 - 1;
- if (ivtmp_15 != 0)
-goto ; [98.99%]
+ vect_cst__14 = { 0, 0 };
+ vect_cst__22 = { -1, -1 };
+ vectp_a.59_23 = a_10(D) + 12;
+
+ [local count: 536870800]:
+ # vectp_a.56_19 = PHI
+ # vectp_a.58_24 = PHI
+ # ivtmp_27 = PHI
+ MEM [(int *)vectp_a.56_19] = vect_cst__14;
+ MEM [(int *)vectp_a.58_24] = vect_cst__22; this is bad
+ vectp_a.56_20 = vectp_a.56_19 + 8;
+ vectp_a.58_25 = vectp_a.58_24 + 8;
+ ivtmp_28 = ivtmp_27 + 1;
+ if (ivtmp_28 < 50)
+goto ; [98.00%]
else
-goto ; [1.01%]
+goto ; [2.00%]
- [local count: 1052266996]:
+ [local count: 526133384]:
goto ; [100.00%]
[local count: 10737416]:
- MEM[(int *)a_10(D) + 400B] = -1; this is good
- MEM[(int *)a_10(D) + 404B] = -1;
- MEM[(int *)a_10(D) + 408B] = -1;
return;
[Bug tree-optimization/102383] New: Missing optimization for PRE after enable O2 vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102383
Bug ID: 102383
Summary: Missing optimization for PRE after enable O2
vectorization
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-*-* i?86-*-*
testcase is form gcc.dg/tree-ssa/predcom-1.c
void abort (void);
unsigned fib[1000];
__attribute__ ((noinline))
void count_fib(void)
{
int i;
fib[0] = 0;
fib[1] = 1;
for (i = 2; i < 1000; i++)
fib[i] = (fib[i-1] + fib[i - 2]) & 0x;
}
git diff novectorize vectorize dump
diff --git a/../novectorize/predcom-1.c.248t.optimized
b/./predcom-1.c.248t.optimized
index 9e4783d..7846af6 100644
--- a/../novectorize/predcom-1.c.248t.optimized
+++ b/./predcom-1.c.248t.optimized
@@ -5,53 +5,57 @@ Removing basic block 5
__attribute__((noinline))
void count_fib ()
{
- sizetype ivtmp.13;
+ sizetype ivtmp.16;
+ unsigned int fib_I_lsm1.6;
unsigned int fib_I_lsm0.5;
int i;
- unsigned int _2;
- unsigned int _4;
unsigned int _5;
unsigned int _6;
- unsigned int prephitmp_21;
- unsigned int prephitmp_24;
- unsigned int _41;
+ unsigned int _19;
+ unsigned int _20;
+ unsigned int _21;
+ unsigned int _37;
+ int _38;
+ unsigned int _46;
unsigned int _47;
- unsigned int _48;
- unsigned int _59;
- int _65;
- unsigned int pretmp_66;
+ int _54;
+ unsigned int _55;
+ unsigned int _56;
+ unsigned int _57;
[local count: 10737416]:
- MEM [(unsigned int *)] = 4294967296;
+ MEM [(unsigned int *)] = { 0, 1 };
[local count: 10737417]:
- # prephitmp_21 = PHI <1(2), _48(3)>
- # prephitmp_24 = PHI <0(2), _6(3)>
- # fib_I_lsm0.5_38 = PHI <1(2), _48(3)>
- # ivtmp.13_7 = PHI <4(2), ivtmp.13_8(3)>
- _5 = prephitmp_21 + prephitmp_24;
+ # fib_I_lsm0.5_32 = PHI <0(2), _6(3)>
+ # fib_I_lsm1.6_33 = PHI <1(2), _47(3)>
+ # ivtmp.16_11 = PHI <4(2), ivtmp.16_10(3)>
+ _5 = fib_I_lsm0.5_32 + fib_I_lsm1.6_33;
_6 = _5 & 65535;
- MEM[(unsigned int *) + -8B + ivtmp.13_7 * 4] = _6;
- _47 = _6 + fib_I_lsm0.5_38;
- _48 = _47 & 65535;
- MEM[(unsigned int *) + -4B + ivtmp.13_7 * 4] = _48;
- ivtmp.13_8 = ivtmp.13_7 + 2;
- if (ivtmp.13_8 != 1000)
+ MEM[(unsigned int *) + -8B + ivtmp.16_11 * 4] = _6;
+ _46 = _6 + fib_I_lsm1.6_33;
+ _47 = _46 & 65535;
+ MEM[(unsigned int *) + -4B + ivtmp.16_11 * 4] = _47;
+ ivtmp.16_10 = ivtmp.16_11 + 2;
+ if (ivtmp.16_10 != 1000)
goto ; [98.00%]
else
goto ; [2.00%]
[local count: 10737416]:
- i_51 = (int) ivtmp.13_7;
- _41 = _6 + _48;
- _59 = _41 & 65535;
- fib[i_51] = _59;
- i_61 = i_51 + 1;
- _65 = i_51 + -1;
- pretmp_66 = fib[_65];
- _2 = _59 + pretmp_66;
- _4 = _2 & 65535;
- fib[i_61] = _4;
+ i_50 = (int) ivtmp.16_11;
+ _38 = i_50 + -1;
+ _37 = fib[_38]; - missing optimization here
+ _54 = i_50 + -2;
+ _55 = fib[_54]; - and here.
+ _56 = _37 + _55;
+ _57 = _56 & 65535;
+ fib[i_50] = _57;
+ i_59 = i_50 + 1;
+ _19 = fib[_38];
+ _20 = _19 + _57;
+ _21 = _20 & 65535;
+ fib[i_59] = _21;
return;
}
[Bug tree-optimization/102382] New: Missing optimization for strlen after enable O2 vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102382
Bug ID: 102382
Summary: Missing optimization for strlen after enable O2
vectorization
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
testcase is from strlenopt-85.c
void* elim_strlen_calloc_store_memset_1 (unsigned a, unsigned b)
{
char *p = __builtin_calloc (a, 1);
p[0] = '\0';
p[1] = '\0';
p[2] = '\0';
p[3] = '\0';
__builtin_memset (p, 0, b);
n0 = __builtin_strlen (p);
return p;
}
diff --git a/strlenopt-85.c.193t.strlen1
b/../vectorize/strlenopt-85.c.193t.strlen1
index 2c8bc4a..6591d9e 100644
--- a/strlenopt-85.c.193t.strlen1
+++ b/../vectorize/strlenopt-85.c.193t.strlen1
@@ -10,6 +10,8 @@
;; 2 succs { 1 }
void * elim_strlen_calloc_store_memset_1 (unsigned int a, unsigned int b)
{
+ vector(4) char * vectp.5;
+ vector(4) char * vectp_p.4;
char * p;
long unsigned int _1;
long unsigned int _2;
@@ -19,11 +21,10 @@ void * elim_strlen_calloc_store_memset_1 (unsigned int a,
unsigned int b)
[local count: 1073741824]:
_1 = (long unsigned int) a_5(D);
p_8 = __builtin_calloc (_1, 1);
- MEM[(char *)p_8 + 1B] = 0;
- MEM[(char *)p_8 + 2B] = 0;
- MEM[(char *)p_8 + 3B] = 0;
+ MEM [(char *)p_8] = { 0, 0, 0, 0 };
_2 = (long unsigned int) b_13(D);
- _3 = 0;
+ __builtin_memset (p_8, 0, _2);
+ _3 = __builtin_strlen (p_8);
_4 = (unsigned int) _3;
n0 = _4;
return p_8;
It seems to be a missing optimization here.
[Bug c/102381] New: unexpected -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102381
Bug ID: 102381
Summary: unexpected -Wmaybe-uninitialized
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hv at crypt dot org
Target Milestone: ---
This is reduced from perl source code. Reduction was a challenge, so there's a
risk the essence may have been lost.
The following code gives a -Wmaybe-uninitialized warning with each of "gcc-7
(Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0", "gcc-9 (Ubuntu 9.2.1-17ubuntu1~18.04.1)
9.2.1 20191102" and self-built "gcc (GCC) 11.2.0".
% cat test.c
extern void fail(void) __attribute__((__noreturn__));
int** f(void);
extern int *ip;
extern int i2, i3;
void test(int i1) {
int **ipp;
if (i1) {
ipp = f();
}
for (int i4 = 0; i4 < i2; i4++) {
if (((i3 & 1) != 1) && ((i3 & 3) != 3))
fail();
}
if (i1) {
ip = *ipp;
}
return;
}
% gcc -c -Wmaybe-uninitialized -O1 test.c
test.c: In function 'test':
test.c:18:14: warning: 'ipp' may be used uninitialized in this function
[-Wmaybe-uninitialized]
ip = *ipp;
^~~~
%
I think it should be clear that i1 does not change within this code, and the
'ip = *ipp' therefore cannot be reached without also previously having reached
'ipp = f()'. The sensitivity of the intervening code suggests this must be a
bug, eg replacing 'if (((i3 & 1) != 1) && ((i3 & 3) != 3))' with 'if ((i3 & 3)
!= 3)' makes the warning disappear.
[Bug libstdc++/102270] std::tuple<>::swap missing constexpr specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102270
--- Comment #4 from 康桓瑋 ---
(In reply to CVS Commits from comment #3)
> The master branch has been updated by Jonathan Wakely :
>
> https://gcc.gnu.org/g:734b2c2eedca50d966e22540fc136158c3633393
>
> commit r12-3592-g734b2c2eedca50d966e22540fc136158c3633393
> Author: Jonathan Wakely
> Date: Wed Sep 15 21:53:35 2021 +0100
>
> libstdc++: Add missing 'constexpr' to std::tuple [PR102270]
>
> Signed-off-by: Jonathan Wakely
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/102270
> * include/std/tuple (_Head_base, _Tuple_impl): Add
> _GLIBCXX20_CONSTEXPR to allocator-extended constructors.
> (tuple<>::swap(tuple&)): Add _GLIBCXX20_CONSTEXPR.
> * testsuite/20_util/tuple/cons/102270.C: New test.
tuple#L332:
template
_Tuple_impl(allocator_arg_t __tag, const _Alloc& __a,
const _Head& __head, const _Tail&... __tail)
: _Inherited(__tag, __a, __tail...),
_Base(__use_alloc<_Head, _Alloc, _Head>(__a), __head)
{ }
[Bug middle-end/102200] [12 Regression] ice in put_ref, at pointer-query.cc:1351 since r12-3300-gece28da924ddda8b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102200 Martin Sebor changed: What|Removed |Added Blocks||88443 Keywords||patch Component|tree-optimization |middle-end --- Comment #4 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579629.html Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug c/86695] Calls to builtins do not use visibility information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86695 Andrew Pinski changed: What|Removed |Added Depends on||67220 --- Comment #2 from Andrew Pinski --- Similar to PR 67220. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220 [Bug 67220] GCC fails to properly handle libcall symbol visibility of builtin functions
[Bug middle-end/102380] [meta-bug] visibility (fvisibility=* and attributes) issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102380 Bug 102380 depends on bug 91766, which changed state. Bug 91766 Summary: -fvisibility=hidden during -fpic still uses GOT indirection on arm64 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91766 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/91766] -fvisibility=hidden during -fpic still uses GOT indirection on arm64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91766 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Andrew Pinski --- -fno-common became the default with GCC 10 so closing as fixed.
[Bug middle-end/102380] [meta-bug] visibility (fvisibility=* and attributes) issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102380 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- There is already a keyword ...
[Bug middle-end/102380] New: [meta-bug] visibility (fvisibility=* and attributes) issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102380 Bug ID: 102380 Summary: [meta-bug] visibility (fvisibility=* and attributes) issues Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: ---
[Bug ipa/92497] Aggregate IPA-CP and inlining do not play well together, transformation is lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92497 Andrew Pinski changed: What|Removed |Added Depends on||94818 --- Comment #1 from Andrew Pinski --- Very similar (if not the same as PR 94818). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94818 [Bug 94818] GCC emits dead bodies of functions whose all calls have been eliminated by optimisations
[Bug ipa/101941] [12 Regression] Linux kernel build failure due to retaining fnsplit fragment with __attribute__((__error__))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101941 Andrew Pinski changed: What|Removed |Added CC||dac324 at yahoo dot de --- Comment #6 from Andrew Pinski --- *** Bug 102361 has been marked as a duplicate of this bug. ***
[Bug ipa/102361] Errors compiling Linux kernel 5.14.4 with CONFIG_FORTIFY=y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #12 from Andrew Pinski --- Actually this is an exact dup of bug 101941. *** This bug has been marked as a duplicate of bug 101941 ***
[Bug ipa/102361] Errors compiling Linux kernel 5.14.4 with CONFIG_FORTIFY=y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361 Andrew Pinski changed: What|Removed |Added Depends on||94818, 101941 Blocks|94818 | --- Comment #11 from Andrew Pinski --- (In reply to Andrew Pinski from comment #9) > I Knew I had saw this before. Yes I did, PR 101941. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94818 [Bug 94818] GCC emits dead bodies of functions whose all calls have been eliminated by optimisations https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101941 [Bug 101941] [12 Regression] Linux kernel build failure due to retaining fnsplit fragment with __attribute__((__error__))
[Bug ipa/102361] Errors compiling Linux kernel 5.14.4 with CONFIG_FORTIFY=y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361 Andrew Pinski changed: What|Removed |Added Blocks||94818 --- Comment #10 from Andrew Pinski --- Similar to PR 94818 and 92497. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94818 [Bug 94818] GCC emits dead bodies of functions whose all calls have been eliminated by optimisations
[Bug middle-end/102361] Errors compiling Linux kernel 5.14.4 with CONFIG_FORTIFY=y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361 Andrew Pinski changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0
[Bug middle-end/102361] Errors compiling Linux kernel 5.14.4 with CONFIG_FORTIFY=y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361
--- Comment #9 from Andrew Pinski ---
[local count: 329188777]:
uncharge_batch (ug_26(D));
p_size_95 = __builtin_object_size (ug_26(D), 0);
if (p_size_95 <= 39)
goto ; [0.00%]
else
goto ; [100.00%]
[local count: 329188777]:
__builtin_memset (ug_26(D), 0, 40);
goto ; [100.00%]
[count: 0]:
uncharge_gather_clear.part.0 ();
uncharge_gather_clear.part.0 has
;; Function uncharge_gather_clear.part.0 (uncharge_gather_clear.part.0,
funcdef_no=6447, decl_uid=102103, cgraph_uid=6834, symbol_order=7294) (unlikely
executed)
__attribute__((no_instrument_function, unused, gnu_inline))
void uncharge_gather_clear.part.0 ()
{
[count: 0]:
__write_overflow ();
fortify_panic (&__func__);
}
I Knew I had saw this before.
[Bug tree-optimization/102238] alias_offset in gimple-ssa-sprintf.c is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102238 Martin Sebor changed: What|Removed |Added Blocks|102216 | --- Comment #8 from Martin Sebor --- (In reply to Andrew Pinski from comment #7) > This issue is blocking the patch which I have created for PR 102216 and that > is how I found this issue so yes it is still blocking PR 102216. I don't see what this problem has to do with pr102216 or how it's blocking your progress on it. pr102216 is a GCC 12 regression that apparently results in a -Warray-bounds false positive. The problem here is a false negative due to a limitation that was introduced in GCC 10 (in r278098) with the initial implementation of -Wrestrict for sprintf. The two have nothing in common that I can see. Is your fix causing an existing test to fail because it changes the IL in a way that prevents the warning from triggering? (That shouldn't make it a blocker as the test could be xfailed until this is fixed, but if you need me to do something you need to explain what and why.) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102216 [Bug 102216] [12 Regression] missed optimization causing Warray-bounds
[Bug fortran/102366] [10/11/12 Regression] large arrays no longer become static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 Andrew Pinski changed: What|Removed |Added Summary|[10/11/12 Regression] |[10/11/12 Regression] large |Illegal instruction with|arrays no longer become |large arrays|static Target Milestone|--- |10.4
[Bug bootstrap/102242] [12 regression] analyzer/engine.cc built with clang: /usr/include/c++/v1/typeinfo:346:5: error: no member named 'fancy_abort'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102242 --- Comment #5 from CVS Commits --- The master branch has been updated by Gerald Pfeifer : https://gcc.gnu.org/g:745781d24cd7562202687cfbe05597ee673d4537 commit r12-3598-g745781d24cd7562202687cfbe05597ee673d4537 Author: Maxim Blinov Date: Fri Sep 17 00:32:58 2021 +0200 analyzer: Fix bootstrap with clang gcc/analyzer/ChangeLog: PR bootstrap/102242 * engine.cc (INCLUDE_UNIQUE_PTR): Define.
[Bug libstdc++/102377] FAIL: 29_atomics/atomic_flag/cons/56012.cc with -std=gnu++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102377
--- Comment #2 from Thomas Rodgers ---
(In reply to Jonathan Wakely from comment #1)
> The reason we don't see it in every test is that this one uses:
>
> // { dg-options "-Wsystem-headers -Wnarrowing" }
>
> But I think the warning is pointing out a real issue. Since the interference
> sizes vary with -mtune options, we shouldn't use them in , since
> that's defining a public ABI (or will be, once our C++20 support is
> non-experimental).
Agreed.
[Bug c++/102378] missing -Waddress in template code at definition time rather than instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102378
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2021-09-16
Target Milestone|--- |12.0
Ever confirmed|0 |1
--- Comment #4 from Martin Sebor ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > GCC warns only at instantiation time.
>
> And it has been that way since at least 4.4.0.
Not quite. It depends on where a warning is implemented. As the test case
below shows, G++ does diagnose some problems in uninstantiated templates but
not others. Jason's suggestion in the review I pointed to is to try to do
better and the purpose of this bug is to capture that limitation and
improvement for the work I'm doing.
$ cat t.C && gcc -S -Wall -Wredundant-tags t.C
struct A { A (); ~A (); };
template
void f ()
{
volatile struct A a;// -Wredundant-tags (good)
register int n = sizeof a; // -Wregister (good)
__builtin_memset (, 0, n);// missing -Wclass-memaccess and volatile A*
to A* conversion warning
}
t.C: In function ‘void f()’:
t.C:6:12: warning: redundant class-key ‘struct’ in reference to ‘struct A’
[-Wredundant-tags]
6 | volatile struct A a;// -Wredundant-tags (good)
|^~
|--
t.C:7:16: warning: ISO C++17 does not allow ‘register’ storage class specifier
[-Wregister]
7 | register int n = sizeof a; // -Wregister (good)
|^
[Bug libstdc++/102354] std::advance overloaded for path::iterator will never be called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102354 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |9.5 --- Comment #2 from Jonathan Wakely --- Fixed by r12-3593 on trunk.
[Bug libstdc++/102280] span's range deduction guide is missing ranges::contiguous_range constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102280 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |10.4
[Bug libstdc++/102270] std::tuple<>::swap missing constexpr specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102270 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |10.4
[Bug c++/102378] missing -Waddress in template code at definition time rather than instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102378
--- Comment #3 from Martin Sebor ---
With the correct explicit instantiation directive things look much better:
$ cat pr102378.C && gcc -S -Wall pr102378.C
int f ()
{
int a[2];
return == 0; // -Waddress (good)
}
template
int g ()
{
{
int a[2];
return == 0;// missing -Waddress
}
{
T t;
return == 0;// no -Waddress for type-dependent expr (good)
}
{
T a[2];
return == 0;// missing -Waddress
}
}
template
int h ()
{
{
int a[2];
return == 0;// -Waddress (good)
}
{
T t;
return == 0;// -Waddress (good)
}
{
T a[2];
return == 0;// -Waddress (good)
}
}
template int h ();
pr102378.C: In function ‘int f()’:
pr102378.C:4:13: warning: the address of ‘a’ will never be NULL [-Waddress]
4 | return == 0; // -Waddress (good)
| ~~~^~~~
pr102378.C: In instantiation of ‘int h() [with T = int]’:
pr102378.C:45:22: required from here
pr102378.C:31:15: warning: the address of ‘a’ will never be NULL [-Waddress]
31 | return == 0;// -Waddress (good)
|~~~^~~~
pr102378.C:36:15: warning: the address of ‘t’ will never be NULL [-Waddress]
36 | return == 0;// -Waddress (good)
|~~~^~~~
pr102378.C:41:15: warning: the address of ‘a’ will never be NULL [-Waddress]
41 | return == 0;// -Waddress (good)
|~~~^~~~
[Bug libstdc++/102270] std::tuple<>::swap missing constexpr specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102270 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:734b2c2eedca50d966e22540fc136158c3633393 commit r12-3592-g734b2c2eedca50d966e22540fc136158c3633393 Author: Jonathan Wakely Date: Wed Sep 15 21:53:35 2021 +0100 libstdc++: Add missing 'constexpr' to std::tuple [PR102270] Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/102270 * include/std/tuple (_Head_base, _Tuple_impl): Add _GLIBCXX20_CONSTEXPR to allocator-extended constructors. (tuple<>::swap(tuple&)): Add _GLIBCXX20_CONSTEXPR. * testsuite/20_util/tuple/cons/102270.C: New test.
[Bug libstdc++/102280] span's range deduction guide is missing ranges::contiguous_range constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102280 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e67917f5df9d84f5aed3513b3931a82870d25135 commit r12-3591-ge67917f5df9d84f5aed3513b3931a82870d25135 Author: Jonathan Wakely Date: Wed Sep 15 21:49:29 2021 +0100 libstdc++: Add missing constraint to std::span deduction guide [PR102280] Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/102280 * include/std/span (span(Range&&)): Add constraint to deduction guide.
[Bug c++/95975] -Wstrict-aliasing=1 false negative for std::pair member at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95975 W E Brown changed: What|Removed |Added CC||webrown.cpp at gmail dot com Andrew Pinski changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Richard Biener --- The warning is correct as far as I can see, not sure what std::get<0>(x) does, never heard of std::get ... but certainly wrapping a function call around this point defeats the warning which is issued from the frontend. So I fear there's nothing to be done about this here...
[Bug target/101761] Random hang with 29_atomics/atomic_ref/wait_notify.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761 --- Comment #13 from CVS Commits --- The master branch has been updated by Thomas Rodgers : https://gcc.gnu.org/g:f9f1a6efaaeeec06d5c07378734cb8eb47b976a7 commit r12-3587-gf9f1a6efaaeeec06d5c07378734cb8eb47b976a7 Author: Thomas Rodgers Date: Thu Sep 16 14:42:58 2021 -0700 libstdc++: Fix UB in atomic_ref/wait_notify.cc [PR101761] Remove UB in atomic_ref/wait_notify test. Signed-off-by: Thomas Rodgers libstdc++-v3/ChangeLog: PR libstdc++/101761 * testsuite/29_atomics/atomic_ref/wait_notify.cc (test): Use va and vb as arguments to wait/notify, remove unused bb local.
[Bug c++/78244] Narrowing conversion is accepted in a function template, but it should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78244 Andrew Pinski changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #13 from Andrew Pinski --- *** Bug 102379 has been marked as a duplicate of this bug. ***
[Bug c++/102379] missing -Wnarrowing even in instantiated template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102379 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 78244. *** This bug has been marked as a duplicate of bug 78244 ***
[Bug c++/55783] Warnings instead of compiler errors for narrowing conversions within list-initializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55783 Andrew Pinski changed: What|Removed |Added CC||antoshkka at gmail dot com --- Comment #16 from Andrew Pinski --- *** Bug 96452 has been marked as a duplicate of this bug. ***
[Bug c++/96452] Narrowing conversion is not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96452 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #8 from Andrew Pinski --- *** This bug has been marked as a duplicate of bug 55783 ***
[Bug c++/102379] missing -Wnarrowing even in instantiated template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102379 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Andrew Pinski --- I think this was done on purpose
[Bug c++/102379] New: missing -Wnarrowing even in instantiated template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102379
Bug ID: 102379
Summary: missing -Wnarrowing even in instantiated template
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Prompted by pr102378 (and looking for examples where G++ does issue diagnostics
for template code): G++ fails to diagnose the following invalid code, in both
the uninstantiated template and in the explicitly instantiated one.
$ cat t.C && gcc -O2 -S -Wall -std=c++11 -Wnarrowing t.C
template
int f ()
{
int i = { 2.2 }; // missing -Wnarrowing
return i;
}
template
int g ()
{
int i = { 2.2 }; // missing -Wnarrowing despite explicit instantiation
return i;
}
template int g ();
Clang diagnoses both:
$ clang -S -Wall t.C
t.C:4:13: error: type 'double' cannot be narrowed to 'int' in initializer list
[-Wc++11-narrowing]
int i = { 2.2 }; // missing -Wnarrowing
^~~
t.C:4:13: note: insert an explicit cast to silence this issue
int i = { 2.2 }; // missing -Wnarrowing
^~~
static_cast( )
t.C:4:13: warning: implicit conversion from 'double' to 'int' changes value
from
2.2 to 2 [-Wliteral-conversion]
int i = { 2.2 }; // missing -Wnarrowing
~ ^~~
t.C:11:13: error: type 'double' cannot be narrowed to 'int' in initializer list
[-Wc++11-narrowing]
int i = { 2.2 }; // missing -Wnarrowing despite explicit instantiation
^~~
t.C:11:13: note: insert an explicit cast to silence this issue
int i = { 2.2 }; // missing -Wnarrowing despite explicit instantiation
^~~
static_cast( )
t.C:11:13: warning: implicit conversion from 'double' to 'int' changes value
from 2.2 to 2 [-Wliteral-conversion]
int i = { 2.2 }; // missing -Wnarrowing despite explicit instantiation
~ ^~~
2 warnings and 2 errors generated.
[Bug c++/102378] missing -Waddress in template code at definition time rather than instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102378 Andrew Pinski changed: What|Removed |Added Summary|missing -Waddress in|missing -Waddress in |template code |template code at definition ||time rather than ||instantiation Severity|normal |enhancement Keywords||diagnostic --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > GCC warns only at instantiation time. And it has been that way since at least 4.4.0.
[Bug c++/102378] missing -Waddress in template code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102378 --- Comment #1 from Andrew Pinski --- GCC warns only at instantiation time.
[Bug c++/102378] New: missing -Waddress in template code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102378
Bug ID: 102378
Summary: missing -Waddress in template code
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
While implementing the suggestion in the review below I noticed that G++ fails
to issue -Waddress in template code even when it could:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579082.html
$ cat t.C && gcc -O2 -S -Wall -Waddress t.C
int f ()
{
int a[2];
return == 0; // -Waddress (good)
}
template
int g ()
{
{
int a[2];
return == 0;// missing -Waddress
}
{
T t;
return == 0;// no -Waddress for type-dependent expr (good)
}
{
T a[2];
return == 0;// missing -Waddress
}
}
template
int h ()
{
{
int a[2];
return == 0;// missing -Waddress
}
{
T t;
return == 0;// missing -Waddress for T = int
}
{
T a[2];
return == 0;// missing -Waddress
}
}
template int h ();
t.C: In function ‘int f()’:
t.C:4:13: warning: the address of ‘a’ will never be NULL [-Waddress]
4 | return == 0; // -Waddress (good)
| ~~~^~~~
In contrast, Clang issues three warnings:
t.C:4:11: warning: comparison of address of 'a' equal to a null pointer is
always false [-Wtautological-pointer-compare]
return == 0; // -Waddress (good)
^~
t.C:12:13: warning: comparison of address of 'a' equal to a null pointer is
always false [-Wtautological-pointer-compare]
return == 0;// missing -Waddress
^~
t.C:31:13: warning: comparison of address of 'a' equal to a null pointer is
always false [-Wtautological-pointer-compare]
return == 0;// missing -Waddress
^~
3 warnings generated.
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 --- Comment #9 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #8) > Potential fix for comment#0: I'm getting many regressions for this change. Investigating.
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 --- Comment #8 from anlauf at gcc dot gnu.org --- Potential fix for comment#0: diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c index bed61e2325d..54309646aad 100644 --- a/gcc/fortran/trans-decl.c +++ b/gcc/fortran/trans-decl.c @@ -709,6 +709,11 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym) } } + /* Implicit SAVE (F2018, 8.5.16 SAVE attribute, clause 4). */ + if (sym->ns->proc_name && sym->ns->proc_name->attr.is_main_program + && sym->attr.save == SAVE_NONE) +sym->attr.save = SAVE_IMPLICIT; + /* Derived types are a bit peculiar because of the possibility of a default initializer; this must be applied each time the variable comes into scope it therefore need not be static. These variables Works for me, but not regtested yet. Does that help? Of course that handles only part of that clause, and we need extended testcases.
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #6)
> Seems it changed with r12-3129-gf95946afd160e2a1f4beac4ee5e6d5633307f39a
Looking at the tree dump, it appears that there is a latent issue.
void MAIN__ ()
{
real(kind=4) a[16776325];
However, that standard says:
F2018 8.5.16 SAVE attribute
(4) A variable, common block, or procedure pointer declared in the scoping unit
of a main program, [...] implicitly has the SAVE attribute
My interpretations of the issue is that we miss to set the SAVE_IMPLICIT,
which is confirmed by running under the debugger, which shows that a
has SAVE_NONE.
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 Jakub Jelinek changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Seems it changed with r12-3129-gf95946afd160e2a1f4beac4ee5e6d5633307f39a
[Bug libstdc++/102377] FAIL: 29_atomics/atomic_flag/cons/56012.cc with -std=gnu++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102377
--- Comment #1 from Jonathan Wakely ---
The reason we don't see it in every test is that this one uses:
// { dg-options "-Wsystem-headers -Wnarrowing" }
But I think the warning is pointing out a real issue. Since the interference
sizes vary with -mtune options, we shouldn't use them in , since that's
defining a public ABI (or will be, once our C++20 support is non-experimental).
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 --- Comment #5 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #4) > And you are trying to use 65532 kbytes long array on the stack, leaving no > stack space for anything else. Clearly user error. out of curiosity, why did this work previously? (was the array previously allocated on the heap?) we are not being very helpful to the user who made the error (neither Linux nor Darwin give any stack overflow), but I guess that's hard to arrange robustly.
[Bug libstdc++/102377] New: FAIL: 29_atomics/atomic_flag/cons/56012.cc with -std=gnu++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102377 Bug ID: 102377 Summary: FAIL: 29_atomics/atomic_flag/cons/56012.cc with -std=gnu++20 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org CC: rodgertq at gcc dot gnu.org Target Milestone: --- In file included from /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/atomic_base.h:41,^M from /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/atomic:41,^M from /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/56012.cc:21:^M /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/atomic_wait.h:194: warning: use of 'std::hardware_destructive_interference_size' [-Winterference-size]^M /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/atomic_wait.h:194: note: its value can vary between compiler versions or with different '-mtune' or '-mcpu' flags^M /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/atomic_wait.h:194: note: if this use is part of a public ABI, change it to instead use a constant variable you define^M /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/atomic_wait.h:194: note: the default value for the current CPU tuning is 64 bytes^M /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/atomic_wait.h:194: note: you can stabilize this value with '--param hardware_destructive_interference_size=64', or disable this warning with '-Wno-interference-size'^M FAIL: 29_atomics/atomic_flag/cons/56012.cc (test for excess errors) Excess errors: /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/atomic_wait.h:194: warning: use of 'std::hardware_destructive_interference_size' [-Winterference-size] This is because uses hardware_destructive_interference_size, which we probably don't want to do in the library headers.
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- And you are trying to use 65532 kbytes long array on the stack, leaving no stack space for anything else. Clearly user error.
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 --- Comment #3 from Dominique d'Humieres --- > What is your stack size? 65532 kbytes > Does it help if you declare a SAVEd? The illegal instruction is gone.
[Bug target/101761] Random hang with 29_atomics/atomic_ref/wait_notify.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761 --- Comment #12 from Jonathan Wakely --- (In reply to Thomas Rodgers from comment #11) > Yes. I will submit a patch for this test shortly. The a.wait(aa) to a.wait(va) change is pre-approved, please just push when it's ready.
[Bug c++/98486] Variable template specialization doesn't account for primary's constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98486 --- Comment #1 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:2e2e65a46d2674bed53afd211493876ee2b79453 commit r12-3585-g2e2e65a46d2674bed53afd211493876ee2b79453 Author: Patrick Palka Date: Thu Sep 16 15:03:55 2021 -0400 c++: constrained variable template issues [PR98486] This fixes some issues with constrained variable templates: - Constraints aren't checked when explicitly specializing a variable template. - Constraints aren't attached to a static data member template at parse time. - Constraints don't get propagated when (partially) instantiating a static data member template, so we need to make sure to look up constraints using the most general template during satisfaction. PR c++/98486 gcc/cp/ChangeLog: * constraint.cc (get_normalized_constraints_from_decl): Always look up constraints using the most general template. * decl.c (grokdeclarator): Set constraints on a static data member template. * pt.c (determine_specialization): Check constraints on a variable template. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-var-templ1.C: New test. * g++.dg/cpp2a/concepts-var-templ1a.C: New test. * g++.dg/cpp2a/concepts-var-templ1b.C: New test.
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 --- Comment #2 from anlauf at gcc dot gnu.org --- What is your stack size? Does it help if you declare a SAVEd?
[Bug fortran/102369] VALUE attribute for arrays not allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102369 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-16 Ever confirmed|0 |1 --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. F2018: 8.5.18 VALUE attribute C863 An entity with the VALUE attribute shall be a dummy data object. It shall not be an assumed-size array, a coarray, or a variable with a coarray ultimate component. Thus assumed-shape is allowed. We need to adjust the checks.
[Bug c++/102367] types can be defined in lambdas in unevaluated expression (decltype/sizeof) in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102367 Andrew Pinski changed: What|Removed |Added Summary|Types may be defined in |types can be defined in |`decltype` or `sizeof` |lambdas in unevaluated |expressions in C++20|expression ||(decltype/sizeof) in C++20 Last reconfirmed||2021-09-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- I thought there was a dup of this bug somewhere. Anyways confirmed.
[Bug fortran/101327] ICE in find_array_element, at fortran/expr.c:1355
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101327 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:5595cc9eb709c4aef1c7bbbfc6b106cf6d5bee91 commit r10-10132-g5595cc9eb709c4aef1c7bbbfc6b106cf6d5bee91 Author: Harald Anlauf Date: Tue Sep 7 20:51:49 2021 +0200 Fortran - improve error recovery determining array element from constructor gcc/fortran/ChangeLog: PR fortran/101327 * expr.c (find_array_element): When bounds cannot be determined as constant, return error instead of aborting. gcc/testsuite/ChangeLog: PR fortran/101327 * gfortran.dg/pr101327.f90: New test. (cherry picked from commit 2a1537a19cb2fa85823cfa18ed40baa4b259b4e3)
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490 --- Comment #14 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c38626f7a66dea400e54f671bfe32dc46e11ad44 commit r10-10131-gc38626f7a66dea400e54f671bfe32dc46e11ad44 Author: Harald Anlauf Date: Thu Sep 9 21:34:01 2021 +0200 Fortran - out of bounds in array constructor with implied do loop gcc/fortran/ChangeLog: PR fortran/98490 * trans-expr.c (gfc_conv_substring): Do not generate substring bounds check for implied do loop index variable before it actually becomes defined. gcc/testsuite/ChangeLog: PR fortran/98490 * gfortran.dg/bounds_check_23.f90: New test. (cherry picked from commit 5fe0865ab788bdc387b284a3ad57e5a95a767b18)
[Bug target/102376] New: [aarch64] using target("sve") attribute without a + is not very helpful on what is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102376
Bug ID: 102376
Summary: [aarch64] using target("sve") attribute without a + is
not very helpful on what is wrong
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-*-*
Take:
void calculate(void) __attribute__ ((__target__ ("sve")));
Currently GCC produces:
:1:57: error: pragma or attribute 'target("sve")' is not valid
1 | void calculate(void) __attribute__ ((__target__ ("sve")));
| ^
But maybe it should tell you that you need to add a + in front of sve.
Also this is inconstitant with x86_64 where you don't need the + sign.
[Bug target/102375] New: (aarch64) Should allow space in target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375
Bug ID: 102375
Summary: (aarch64) Should allow space in target attribute
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-*-*
Take:
void calculate(void) __attribute__ ((__target__ ("+sve, +sve2")));
Currently we produce:
:1:65: error: pragma or attribute 'target(" +sve2")' is not valid
1 | void calculate(void) __attribute__ ((__target__ ("+sve, +sve2")));
| ^
It is not so obvious the space is not allowed here but maybe it should be.
[Bug target/102374] New: Should ignore spaces in target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102374
Bug ID: 102374
Summary: Should ignore spaces in target attribute
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
void calculate_sse(void) __attribute__ ((__target__ ("no-avx, sse2")));
Currently we error out:
:1:6: error: attribute ' sse2' argument 'target' is unknown
1 | void calculate_sse(void) __attribute__ ((__target__ ("no-avx, sse2")));
| ^
It was not so obvious why though, the problem is there is a space after the
comma.
[Bug fortran/85130] Substrings out of range are not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85130 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3bc4ed085145e1cb6089841c811094633eea7431 commit r11-9009-g3bc4ed085145e1cb6089841c811094633eea7431 Author: Harald Anlauf Date: Mon Sep 13 19:26:35 2021 +0200 Fortran - fix handling of substring start and end indices gcc/fortran/ChangeLog: PR fortran/85130 * expr.c (find_substring_ref): Handle given substring start and end indices as signed integers, not unsigned. gcc/testsuite/ChangeLog: PR fortran/85130 * gfortran.dg/substr_6.f90: Revert commit r8-7574, adding again test that was erroneously considered as illegal. (cherry picked from commit 8d93ba93d3b13ac3d3c34404cad87732c809605b)
[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:58c76fb477b51adeb9241de0b175a817e9c73b8a commit r11-9008-g58c76fb477b51adeb9241de0b175a817e9c73b8a Author: Harald Anlauf Date: Mon Sep 13 19:28:10 2021 +0200 Fortran - ensure simplification of bounds of array-valued named constants gcc/fortran/ChangeLog: PR fortran/82314 * decl.c (add_init_expr_to_sym): For proper initialization of array-valued named constants the array bounds need to be simplified before adding the initializer. gcc/testsuite/ChangeLog: PR fortran/82314 * gfortran.dg/pr82314.f90: New test. (cherry picked from commit 104c05c5284b7822d770ee51a7d91946c7e56d50)
[Bug target/59697] Function attribute __target_(("no-avx)) does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59697
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|Function attribute |Function attribute
|__target_(("no-avx)) work |__target_(("no-avx)) does
|on Windows/mingw but fails |not work
|on Linux. |
Keywords||rejects-valid
Last reconfirmed||2021-09-16
Status|UNCONFIRMED |NEW
--- Comment #2 from Andrew Pinski ---
Confirmed. The target header files don't turn off what was turned on via the
command line which causes the inline functions not to be usable that way.
In older versions of GCC this produced wrong code but in newer versions GCC
rejects the code.
Note clang has the same behavior ...
[Bug fortran/102287] optional allocatable array arguments (intent out) of derived types with allocatable components are not properly passed to subroutines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102287 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:cfea7b86f2430b9cb8018379b071f4004233119c commit r12-3584-gcfea7b86f2430b9cb8018379b071f4004233119c Author: Harald Anlauf Date: Thu Sep 16 20:12:21 2021 +0200 Fortran - fix handling of optional allocatable DT arguments with INTENT(OUT) gcc/fortran/ChangeLog: PR fortran/102287 * trans-expr.c (gfc_conv_procedure_call): Wrap deallocation of allocatable components of optional allocatable derived type procedure arguments with INTENT(OUT) into a presence check. gcc/testsuite/ChangeLog: PR fortran/102287 * gfortran.dg/intent_out_14.f90: New test.
[Bug debug/102373] Segmentation fault in dwarf2out.c, line 32744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102373 --- Comment #2 from dave.anglin at bell dot net --- On 2021-09-16 1:38 p.m., jakub at gcc dot gnu.org wrote: > This looks wrong, comp_unit_die () should have DW_AT_producer at this point. > gen_compile_unit_die should have added it... I did change dwarf_version to 4.
[Bug bootstrap/67102] Parallel build fails in libffi/configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67102 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- Fixed.
[Bug bootstrap/67102] Parallel build fails in libffi/configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67102 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:db1a65d9364fe72c2fff65fb2dec051728b6f3fa commit r12-3583-gdb1a65d9364fe72c2fff65fb2dec051728b6f3fa Author: Andrew Pinski Date: Wed Sep 15 09:51:08 2021 + Fix PR 67102: Add libstdc++ dependancy to libffi The error message is obvious -funconfigured-libstdc++-v3 is used on the g++ command line. So we just add the dependancy. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. ChangeLog: PR bootstrap/67102 * Makefile.def: Have configure-target-libffi depend on all-target-libstdc++-v3. * Makefile.in: Regenerate.
[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64089 Eric Gallager changed: What|Removed |Added Resolution|--- |FIXED CC||egallager at gcc dot gnu.org Status|ASSIGNED|RESOLVED --- Comment #23 from Eric Gallager --- (In reply to Eric Gallager from comment #22) > (In reply to Eric Gallager from comment #20) > > (In reply to m...@gcc.gnu.org from comment #19) > > > I'm fine with Backporting for affected branches. > > > > So... that's still 6 and 7 at this point? > > Er well just 7 now, since 6 is closed 7 is closed now, too, so I think that's all affected branches closed, meaning this ought to be fixed on all open branches... closing as FIXED.
[Bug c++/102283] Inconsistent/wrong overload resolution when using an initializer list and a defaulted template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102283 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #4 from Jason Merrill --- (In reply to Patrick Palka from comment #1) > According to http://eel.is/c++draft/over.ics.rank#3.3 the two ICSes should > be incomparable since they initialize different classes, so at least > according to that paragraph it appears GCC is behaving correctly here. I agree with your reading.
[Bug other/92435] % format codes for diagnostics are not documented in the GCC internals manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92435 --- Comment #4 from Eric Gallager --- (In reply to Martin Sebor from comment #3) > See also the following question: > https://gcc.gnu.org/pipermail/gcc/2021-September/237281.html > It would be helpful to document the GCC specific directives somewhere. The > -Wformat-diag GCC-developer warning option could also stand to be documented. Yeah I was trying to convince the Wesnoth devs to look at -Wformat-diag for inspiration for their own message-strings linter, but since it wasn't documented, they didn't really know what to do, so I agree that documenting that would be useful, too
[Bug tree-optimization/102238] alias_offset in gimple-ssa-sprintf.c is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102238 Andrew Pinski changed: What|Removed |Added Blocks||102216 --- Comment #7 from Andrew Pinski --- (In reply to Martin Sebor from comment #5) > Confirmed with the simplified test case below. DOM3 is the last pass to run > before strlen. The strlen output shows the sprintf call is being folded to > strcpy. I'm not sure what the relationship of this bug is to pr102216 but a > missing -Wrestrict cannot be a cause of a missed optimization. I've moved > pr102216 to See Also. This issue is blocking the patch which I have created for PR 102216 and that is how I found this issue so yes it is still blocking PR 102216. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102216 [Bug 102216] [12 Regression] missed optimization causing Warray-bounds
[Bug debug/102373] Segmentation fault in dwarf2out.c, line 32744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102373 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Comment on attachment 51471 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51471 Fix NULL pointer dereference This looks wrong, comp_unit_die () should have DW_AT_producer at this point. gen_compile_unit_die should have added it...
[Bug debug/102373] New: Segmentation fault in dwarf2out.c, line 32744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102373
Bug ID: 102373
Summary: Segmentation fault in dwarf2out.c, line 32744
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: danglin at gcc dot gnu.org
Target Milestone: ---
Host: hppa64-hp-hpux*
Target: hppa64-hp-hpux*
Build: hppa64-hp-hpux*
Created attachment 51471
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51471=edit
Fix NULL pointer dereference
The fault occurs on trunk with the following:
int
main (void)
{
return 0;
}
/home/dave/gnu/gcc/objdir64/./gcc/cc1 -fpreprocessed xxx.i -quiet -dumpbase xxx
.c -dumpbase-ext .c -g -O2 -version -fno-checking -o xxx.s
GNU C17 (GCC) version 12.0.0 20210907 (experimental) (hppa64-hp-hpux11.11)
compiled by GNU C version 12.0.0 20210907 (experimental), GMP version
6.
1.1, MPFR version 3.1.5, MPC version 1.0.3, isl version isl-0.22.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 12.0.0 20210907 (experimental) (hppa64-hp-hpux11.11)
compiled by GNU C version 12.0.0 20210907 (experimental), GMP version
6.
1.1, MPFR version 3.1.5, MPC version 1.0.3, isl version isl-0.22.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 64b9df7c6b0f1e93f698a828b6c17964
xxx.c:5:1: internal compiler error: Segmentation fault
5 | }
| ^
(gdb) r
Starting program: /home/dave/gnu/gcc/objdir64/gcc/cc1 -fpreprocessed xxx.i
-quiet -dumpbase xxx.c -dumpbase-ext .c -g -O2 -version -fno-checking -o xxx.s
GNU C17 (GCC) version 12.0.0 20210907 (experimental) (hppa64-hp-hpux11.11)
compiled by GNU C version 12.0.0 20210907 (experimental), GMP version
6.1.1, MPFR version 3.1.5, MPC version 1.0.3, isl version isl-0.22.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 12.0.0 20210907 (experimental) (hppa64-hp-hpux11.11)
compiled by GNU C version 12.0.0 20210907 (experimental), GMP version
6.1.1, MPFR version 3.1.5, MPC version 1.0.3, isl version isl-0.22.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 64b9df7c6b0f1e93f698a828b6c17964
Program received signal SIGSEGV, Segmentation fault.
0x406939b4 in dwarf2out_early_finish (
filename=0x800100313eb0 "xxx.c") at ../../gcc/gcc/dwarf2out.c:32744
32744 producer_string = gen_producer_string (lang_hooks.name,
(gdb) disass
Dump of assembler code for function dwarf2out_early_finish(char const*):
0x406938c8 <+0>: std rp,-10(sp)
0x406938cc <+4>: addil L%-16800,dp,r1
0x406938d0 <+8>: ldo 180(sp),sp
0x406938d4 <+12>:std r13,-c8(sp)
0x406938d8 <+16>:ldd 2b0(r1),r13
0x406938dc <+20>:addil L%-16000,dp,r1
0x406938e0 <+24>:std r7,-98(sp)
0x406938e4 <+28>:ldd 230(r1),r7
0x406938e8 <+32>:std r6,-90(sp)
0x406938ec <+36>:std r18,-f0(sp)
0x406938f0 <+40>:std r17,-e8(sp)
0x406938f4 <+44>:std r16,-e0(sp)
0x406938f8 <+48>:std r15,-d8(sp)
0x406938fc <+52>:std r14,-d0(sp)
0x40693900 <+56>:std r12,-c0(sp)
0x40693904 <+60>:std r11,-b8(sp)
0x40693908 <+64>:std r10,-b0(sp)
0x4069390c <+68>:std r9,-a8(sp)
0x40693910 <+72>:std r8,-a0(sp)
0x40693914 <+76>:std r5,-88(sp)
0x40693918 <+80>:std r4,-80(sp)
0x4069391c <+84>:std r3,-78(sp)
---Type to continue, or q to quit---
0x40693920 <+88>:ldb 0(r13),r19
0x40693924 <+92>:std r19,-108(sp)
0x40693928 <+96>:ldb 0(r7),ret0
0x4069392c <+100>: cmpib,<> 0,ret0,0x40695434
0x40693930 <+104>: copy r26,r6
0x40693934 <+108>: ldi 1,ret0
0x40693938 <+112>: stb ret0,0(r13)
0x4069393c <+116>: addil L%-16000,dp,r1
0x40693940 <+120>: ldd 238(r1),r11
0x40693944 <+124>: ldd 0(r11),r26
0x40693948 <+128>: cmpb,*= r0,r26,0x40694c60
0x4069394c <+132>: ldo -30(sp),ret1
0x40693950 <+136>: copy dp,r4
0x40693954 <+140>: ldo -30(sp),ret1
0x40693958 <+144>: b,l 0x40640ec0 ,rp
0x4069395c <+148>: ldi 25,r25
0x40693960 <+152>: copy r4,dp
0x40693964 <+156>: addil L%-27800,dp,r1
0x40693968 <+160>: ldd 440(r1),r31
0x4069396c <+164>: addil L%-27800,dp,r1
---Type to continue, or q to quit---
0x40693970 <+168>: copy ret0,r3
0x40693974 <+172>: ldd
[Bug tree-optimization/102238] alias_offset in gimple-ssa-sprintf.c is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102238 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #6 from Martin Sebor --- Let me handle this.
[Bug tree-optimization/102238] alias_offset in gimple-ssa-sprintf.c is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102238
Martin Sebor changed:
What|Removed |Added
Blocks|102216 |84774
Last reconfirmed||2021-09-16
Status|UNCONFIRMED |NEW
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=102216
Ever confirmed|0 |1
--- Comment #5 from Martin Sebor ---
Confirmed with the simplified test case below. DOM3 is the last pass to run
before strlen. The strlen output shows the sprintf call is being folded to
strcpy. I'm not sure what the relationship of this bug is to pr102216 but a
missing -Wrestrict cannot be a cause of a missed optimization. I've moved
pr102216 to See Also.
$ cat pr102238.c && gcc -O2 -S -Wall -fdump-tree-dom3=/dev/stdout pr102238.c
struct A
{
char a[4];
};
struct B
{
struct A a1, a2;
};
void f (struct B *p)
{
enum { off = __builtin_offsetof (struct B, a2.a) };
char *s = (char*)p + off;
char *d = p->a2.a;
__builtin_sprintf (d, "%s", s); // missing -Wrestrict
}
;; Function f (f, funcdef_no=0, decl_uid=1983, cgraph_uid=1, symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
void f (struct B * p)
{
char * d;
char * s;
[local count: 1073741824]:
s_2 = p_1(D) + 4;
d_3 = _1(D)->a2.a;
__builtin_sprintf (d_3, "%s", s_2);
return;
}
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
[Bug 84774] [meta-bug] bogus/missing -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102216
[Bug 102216] [12 Regression] missed optimization causing Warray-bounds
[Bug target/102353] powerpc64le-linux-gnu build failure when build != host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102353 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Tobias Burnus --- Should be FIXED :-) @Bill: Thanks for testing the native build!
[Bug target/102353] powerpc64le-linux-gnu build failure when build != host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102353 --- Comment #7 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:acd7e7b33fd576b336ca0bf5ec51f77b32ba51cc commit r12-3581-gacd7e7b33fd576b336ca0bf5ec51f77b32ba51cc Author: Tobias Burnus Date: Thu Sep 16 18:35:34 2021 +0200 PowerPC: Fix rs6000-gen-builtins with build != host [PR102353] This mimics what the main Makefile.in does: compile the generator files under build (with Makefile.in's 'build/%.o' rule for compilation). It also adds $(RUN_GEN) to optionally run it with valgrind and the $(build_exeext) suffix. Before, the .o files were compiled with $(COMPILE), causing link error with $(LINKER_FOR_BUILD) for build != host. gcc/ PR target/102353 * config/rs6000/t-rs6000 (build/rs6000-gen-builtins.o, build/rbtree.o): Added 'build/' to target, use build/%.o rule. (build/rs6000-gen-builtins$(build_exeext)): Add 'build/' and '$(build_exeext)' to target and 'build/' for the *.o files. (rs6000-builtins.c): Update for those changes; run rs6000-gen-builtins with $(RUN_GEN).
[Bug c++/39270] Explicit instantiation rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39270 Patrick Palka changed: What|Removed |Added Blocks||102184 --- Comment #4 from Patrick Palka --- PR102184 is probably due to the same underlying bug Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102184 [Bug 102184] Explicit template instantiation thinks there is an ambiguous template specialization when there is none for concepts
[Bug c++/39270] Explicit instantiation rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39270
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #3 from Patrick Palka ---
Slightly more reduced rejects-valid testcase:
template
void f(U); // #1
template
void f(int) { } // #2
template void f(int);
more_specialized_inst is unable to determine that #2 is more specialized than
#1. Perhaps we should be passing the explicitly specified template arguments
to get_bindings? But that ends up breaking
gcc/testsuite/g++.old-deja/g++.pt/explicit22.C among others..
[Bug tree-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178 --- Comment #4 from Martin Jambor --- (In reply to Martin Jambor from comment #3) > ...I'll have a very brief look at what is actually happening just so that I > have more reasons to believe this is not a code placement issue again. The hot function is at the same address when compiled by both revisions and the newer version looks sufficiently different. I even tried sprinkling it with nops and it did not help. I am no saying we are not bumping against some michro-architectural peculiarity but it does not seem to be a code placement issue.
[Bug fortran/102371] Error for type spec in FORALL statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102371 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||kargl at gcc dot gnu.org Priority|P3 |P4 Last reconfirmed||2021-09-16 --- Comment #1 from kargl at gcc dot gnu.org --- This is likely a du0plicate of PR 78219. Comment #7 of that PR contains a patch, which should fix both PR 78219 and this PR. Don't know if anyone will ever get around to actually committed the patch.
[Bug target/102372] New: [12 regression] ICE in gfortran.dg/ISO_Fortran_binding_1.f90 after r12-3482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102372 Bug ID: 102372 Summary: [12 regression] ICE in gfortran.dg/ISO_Fortran_binding_1.f90 after r12-3482 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:5f6a6c91d7c592cb49f7c519f289777eac09bb74, r12-3482 This revision causes ICEs on power7 BE. I did not see any failures on power 8 BE nor any power LE machines. make -k check-gcc-fortran RUNTESTFLAGS="dg.exp=gfortran.dg/ISO_Fortran_binding_1.f90" FAIL: gfortran.dg/ISO_Fortran_binding_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) FAIL: gfortran.dg/ISO_Fortran_binding_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_1.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/ISO_Fortran_binding_1.f90 -O3 -g (test for excess errors) # of expected passes8 # of unexpected failures4 # of unresolved testcases 2 spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../ -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.f90 -fdiagnostics-plain-output -fdiagnostics-plain-output -O3 -g -pedantic-errors /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.c -dumpbase -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libatomic/.libs -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs -lm -o ./ISO_Fortran_binding_1.exe during GIMPLE pass: slp /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.f90:6:33: internal compiler error: in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:5215 0x11136277 rs6000_builtin_vectorization_cost /home/seurer/gcc/git/gcc-test/gcc/config/rs6000/rs6000.c:5215 0x10f8f367 builtin_vectorization_cost /home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.h:1520 0x10f8f367 record_stmt_cost(vec*, int, vect_cost_for_stmt, _stmt_vec_info*, tree_node*, int, vect_cost_model_location) /home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.c:109 0x10f8fad7 record_stmt_cost /home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.h:1913 0x10f8fad7 vect_get_store_cost(vec_info*, _stmt_vec_info*, int, unsigned int*, vec*) /home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.c:1049 0x10fb065b vect_model_store_cost /home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.c:972 0x10fb065b vectorizable_store /home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.c:7421 0x10fba8ef vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*, _slp_instance*, vec*) /home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.c:10972 0x11009bab vect_slp_analyze_node_operations_1 /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4523 0x11009bab vect_slp_analyze_node_operations /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4681 0x1100dc87 vect_slp_analyze_operations(vec_info*) /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4920 0x11011153 vect_slp_analyze_bb_1 /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:5860 0x11011153 vect_slp_region /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:5907 0x110130d7 vect_slp_bbs /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:6099 0x11013733 vect_slp_function(function*) /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:6187 0x1101ee77 execute /home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.c:1454 Pl commit 5f6a6c91d7c592cb49f7c519f289777eac09bb74 Author: Richard Earnshaw Date: Fri Sep 3 17:06:15 2021 +0100 gimple: allow more folding of memcpy [PR102125]
[Bug fortran/102371] New: Error for type spec in FORALL statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102371 Bug ID: 102371 Summary: Error for type spec in FORALL statement Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- > cat test.f90 program main implicit none integer, parameter :: long = selected_int_kind(18) integer(long), parameter :: very_large = 128_long integer, allocatable, dimension(:,:) :: ary allocate(ary(very_large, 2)) forall(integer(long) :: i=1:very_large, j=1:2) ary(i, j) = i * j end forall print *, ary(5, 2) deallocate(ary) end program main > ifort test.f90 > ./a.out 10 > gfortran test.f90 test.f90:7:8: 7 | forall(integer(long) :: i=1:very_large, j=1:2) |1 Error: Syntax error in FORALL statement at (1) test.f90:9:3: 9 | end forall | 1 Error: Expecting END PROGRAM statement at (1) test.f90:8:5: 8 | ary(i, j) = i * j | 1 Error: Symbol 'i' at (1) has no IMPLICIT type test.f90:8:8: 8 | ary(i, j) = i * j |1 Error: Symbol 'j' at (1) has no IMPLICIT type I assume all the errors are a cascade from the first error, which is the issue in this bug. FORALL statements are supposed to allow a type spec.
[Bug demangler/102370] New: Runtime failure with allocatable component of allocatable parent and MOVE_ALLOC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102370 Bug ID: 102370 Summary: Runtime failure with allocatable component of allocatable parent and MOVE_ALLOC Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- > cat test.f90 program main implicit none type mytype real :: val integer :: idx type(mytype), allocatable :: next end type mytype type (mytype), allocatable :: top, temp temp = mytype (5.0, 5, temp ) call move_alloc(top, temp%next) call move_alloc(temp, top) print *, temp%val end program main # Cray compiler > ftn test.f90 > ./a.out 5. > gfortran test.f90 > ./a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7f88d658e49f in ??? #1 0x7f88d72fc5c0 in get_float_string at ../../../cray-gcc-11.2.0-202108140355.9bf1fd589a5c1/libgfortran/io/write_float.def:1110 #2 0x7f88d72fec65 in list_formatted_write_scalar at ../../../cray-gcc-11.2.0-202108140355.9bf1fd589a5c1/libgfortran/io/write.c:1903 #3 0x400c91 in ??? #4 0x401145 in ??? #5 0x7f88d6579349 in ??? #6 0x4007c9 in ??? at ../sysdeps/x86_64/start.S:120 #7 0x in ??? Segmentation fault (core dumped)
[Bug fortran/102369] VALUE attribute for arrays not allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102369 --- Comment #1 from Bill Long --- I assume the cascade of error messages all originate with the first one. The combination of VALUE for an array is allowed in F08 and later versions.
[Bug fortran/102369] New: VALUE attribute for arrays not allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102369 Bug ID: 102369 Summary: VALUE attribute for arrays not allowed Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- > cat test.f90 module mymod contains pure real function myfunc(x) integer, value, dimension(:), intent(in) :: x myfunc = x(1) end function myfunc end module mymod program main use mymod implicit none integer, parameter :: sz = 10 integer, dimension(sz) :: foo foo = 42 print *, myfunc(foo) end program main > ifort test.f90 > ./a.out 42.0 > gfortran test.f90 test.f90:4:14: 4 | integer, value, dimension(:), intent(in) :: x | 1 Error: VALUE attribute conflicts with DIMENSION attribute at (1) test.f90:3:27: 3 | pure real function myfunc(x) | 1 Error: Dummy procedure 'x' of PURE procedure at (1) must also be PURE test.f90:5:9: 5 | myfunc = x(1) | 1 Error: Reference to impure function 'x' at (1) within a PURE procedure test.f90:9:5: 9 | use mymod | 1 Fatal Error: Cannot open module file 'mymod.mod' for reading at (1): No such file or directory compilation terminated. > gfortran --version GNU Fortran (GCC) 11.2.0 20210728 (Cray Inc.) Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug fortran/102368] New: Failure to compile program using the C_SIZEOF function in ISO_C_BINDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102368 Bug ID: 102368 Summary: Failure to compile program using the C_SIZEOF function in ISO_C_BINDING Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- > cat test.f90 program main use,intrinsic :: iso_c_binding implicit none character(kind=c_char, len=*), parameter :: blergh = 'abc' print *, c_sizeof(blergh) print *, c_sizeof(.true.) print *, c_sizeof(5) print *, c_sizeof(5.0) print *, c_sizeof(5.0d0) end program main > gfortran test.f90 test.f90:7:18: 7 | print *, c_sizeof(blergh) | 1 Error: 'x' argument of 'c_sizeof' intrinsic at (1) must be an interoperable data entity: Type shall have a character length of 1 > ifort test.f90 > ./a.out 3 4 4 4 8 gfortran appears to be using pre-F08 rules for C_SIZEOF.
[Bug c++/102367] New: Types may be defined in `decltype` or `sizeof` expressions in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102367
Bug ID: 102367
Summary: Types may be defined in `decltype` or `sizeof`
expressions in C++20
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
Since C++20 lambdas are allowed in not-evaluated context. So the code as
follows must be valid:
```
using T = decltype( []{ struct S{}; return S{}; }() );
[[maybe_unused]] constexpr auto N
= sizeof( []{ struct S{}; return S{}; }() );
```
It is indeed accepted by MSVC and Clang, but rejected by GCC, demo:
https://gcc.godbolt.org/z/jYjxcr1eP
The error is
```
error: types may not be defined in 'decltype' expressions
1 | using T = decltype( []{ struct S{}; return S{}; }() );
| ^
: In lambda function:
:4:33: error: types may not be defined in 'sizeof' expressions
4 | = sizeof( []{ struct S{}; return S{}; }() );
|
```
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 Iain Sandoe changed: What|Removed |Added Target||x86_64-darwin, ||x86_64-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-16 Ever confirmed|0 |1 Keywords||wrong-code CC||iains at gcc dot gnu.org --- Comment #1 from Iain Sandoe --- also fails on x86_64 linux (with a segv rather than a ill). Linux: (gdb) r Starting program: /home/iains/t Program received signal SIGSEGV, Segmentation fault. 0x0040118c in MAIN__ () at dom1.f90:2 2 a=1.0_8 Darwin: Process 14098 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7ffeebbff900) frame #0: 0x00010ec2 t`MAIN__ at dom1.f90:2:7 1REAL(KIND=4) :: a(16,1024,1024), s -> 2a=1.0_8 3END Target 0: (t) stopped.
[Bug fortran/102366] New: [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 Bug ID: 102366 Summary: [10/11/12 Regression] Illegal instruction with large arrays Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr Target Milestone: --- The following test REAL(KIND=4) :: a(16776325), s a=1.0_8 END gives at run time Illegal instruction a(16775301) to a(16776324) gives Segmentation fault and below a(16776323) the code run as expected. This occurred between r12-3046 (OK) and r12-3430 and r10-10049 (OK) and r10-10122. It also affects r11-8981. Note that REAL(KIND=4) :: a(16776325), s a(16776325)=1.0_8 END compiles and runs witout problem.
[Bug c/102361] Errors compiling Linux kernel 5.14.4 with CONFIG_FORTIFY=y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361 --- Comment #8 from DAC324 --- This is the first error; if make is used with -j greater than 1, several of those errors occur (see introduction).
