[Bug ada/102078] affinity.c:59:19: error: Signed integer overflow ?

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102078

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
@Jakub: Can you please take a look?

[Bug ipa/102118] [12 Regression] ice in merge, at ipa-modref-tree.h:203

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102118

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Martin Liška  ---
Fixed in r12-3202-gf5ff3a8ed4ca9173.

[Bug ada/102078] affinity.c:59:19: error: Signed integer overflow ?

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102078

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This is about gcc/ada/affinity.c, not about libgomp/affinity.c nor
libgomp/config/linux/affinity.c.
I don't see a need to change anything, while the file extension is .c, we are
compiling it with C++, and in C++ 1 << 31 is well defined in all versions I
believe.
1UL would be confusing when mask is unsigned, 1U << index might be ok.

[Bug c/102098] ICE when #include with -fmodules-ts -std=c++20

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102098

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2021-08-30
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Please attach the source files..

[Bug ada/102078] affinity.c:59:19: error: Signed integer overflow ?

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102078

--- Comment #3 from Jakub Jelinek  ---
Actually no, it is in libada and built only for VxWorks, maybe it is built with
C rather than C++.  In that case it would indeed be UB.

[Bug tree-optimization/102121] switch conversion to load table should do integer compression

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102121

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-08-30
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Confirmed.

[Bug tree-optimization/68050] SLP vectorization should negate constants to match up + vs -

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68050

--- Comment #3 from Richard Biener  ---
We don't really do it as you show - instead of

  vect__5.7_12 = vect__1.5_14 + { -3.0e+0, -3.0e+0 };
  vect__2.6_13 = vect__1.5_14 + { 3.0e+0, 3.0e+0 };
  _7 = VEC_PERM_EXPR ;

we'd like to see

  _7 = vect__1.5_14 + { 3.0e+0, -3.0e+0 };

which is what we should cost as well.

[Bug go/102102] [12 Regression] trunk 20210827 ftbfs libgo on x86_64-linux-gnux32

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102102

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug c/102098] ICE when #include with -fmodules-ts -std=c++20

[pilarlatiesa at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102098

Pilar Latiesa  changed:

   What|Removed |Added

 CC||pilarlatiesa at gmail dot com

--- Comment #2 from Pilar Latiesa  ---
I can reproduce with:

$ cat test.cpp

module;

#include 

export module foo;

[Bug ipa/85509] fails to promote local static to const

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85509

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2018-04-24 00:00:00 |2021-8-30
  Component|tree-optimization   |ipa
 CC||marxin at gcc dot gnu.org

--- Comment #7 from Richard Biener  ---
CCP2 is after IPA promoting the variable 'const', but CCP2 is too late for
inlining (and IPA opts don't do value-numbering to discover the indirect
inline target).

[Bug tree-optimization/36188] missed optimistic value-numbering on global vars

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36188

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2009-04-22 21:49:30 |2021-8-30
 CC||hubicka at gcc dot gnu.org
Summary|missed CCP on global vars   |missed optimistic
   ||value-numbering on global
   ||vars

--- Comment #10 from Richard Biener  ---
IIRC we had talked about IPA discovering variables used only in a single
function so we could treat them optimistically (with the complication of
recursion representing backedges).  Eventually IPA REFs give us enough info
already
but then IPA REFs are not available to scalar (post-IPA) passes.

[Bug rtl-optimization/102031] [12 Regression] ICE in simplify_truncation, at simplify-rtx.c:620 since r12-3074-g7e5f9ead16d7514b3baa0254084de94f0bfcd216

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102031

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Martin Liška  ---
Fixed now.

[Bug libffi/83636] libffi/mips/n32: don't .set mips4 for mips r6

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83636

--- Comment #3 from CVS Commits  ---
The master branch has been updated by YunQiang Su :

https://gcc.gnu.org/g:d7e56b084d0b230ae5ee280f569d679fa0f09f4d

commit r12-3219-gd7e56b084d0b230ae5ee280f569d679fa0f09f4d
Author: YunQiang Su 
Date:   Sat Aug 28 08:17:18 2021 -0400

libffi: Fix MIPS r6 support

for some instructions, MIPS r6 uses different encoding other than
the previous releases.

1. mips/n32.S disable .set mips4: since it casuses old insn encoding
   is used.
   https://github.com/libffi/libffi/pull/396 has been accepted as:
 94c102aa69b04337f63498e0e6551fcdce549ae5
2. mips/ffi.c: the encoding for JR is hardcoded: we need to use
   different value for r6 and pre-r6.
   https://github.com/libffi/libffi/pull/401 has been accpeted as:
 746dbe3a6a79a41931c03b51df2972be4d5e5028

libffi/
PR libffi/83636
* src/mips/n32.S: disable .set mips4
* src/mips/ffi.c: use different JR encoding for r6.

[Bug c/102124] New: GCC 11.2.1 -ftree-loop-vectorize Causing Data To Lose Sign Bit

[changyp6 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102124

Bug ID: 102124
   Summary: GCC 11.2.1 -ftree-loop-vectorize Causing Data To Lose
Sign Bit
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: changyp6 at gmail dot com
  Target Milestone: ---

Created attachment 51374
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51374&action=edit
Test program for gcc 11.2.1 on AARCH64

Description of problem:
When I'm building libgcrypt 1.9.4 with GCC 11.2.1 on my AARCH64 box(armv8.2
cortex-a76), I'm using -O3 compile options. however, -O3 generated code failed
to pass "basic" test of libgcrypt, it fails on "gcry_cipher_checktag" function.
After investigation, I found that, the problem occurs in buf_eq_const()
function in file cipher/bufhelp.h of libgcrypt-1.9.4

 362 /* Constant-time compare of two buffers.  Returns 1 if buffers are equal,
 363and 0 if buffers differ.  */
 364 static inline int
 365 buf_eq_const(const void *_a, const void *_b, size_t len)
 366 {
 367   const byte *a = _a;
 368   const byte *b = _b;
 369   int ab, ba;
 370   size_t i;
 371 
 372   /* Constant-time compare. */
 373   for (i = 0, ab = 0, ba = 0; i < len; i++)
 374 {
 375   /* If a[i] != b[i], either ab or ba will be negative. */
 376   ab |= a[i] - b[i];
 377   ba |= b[i] - a[i];
 378 }
 379 
 380   /* 'ab | ba' is negative when buffers are not equal. */
 382   return (ab | ba) >= 0;
 383 }

The calculation of 2 different array becomes >= 0 on the return value, however,
it should be negative value.

After I change -O3 to -O2, this function works again.
Then I compile libgcrypt 1.9.4 with -O2 plus additional GCC options which are
added by -O3 to locate the actual option that causing this issue, finally I
found that, if "-ftree-loop-vectorize" is used to compile this code, the
calculated result is a positive value, if removing "-ftree-loop-vectorize", the
calculated result is negative.

Then I downgraded GCC to 10.x, -ftree-loop-vectorize won't cause such issue.
So I'm sure this is a GCC bug.

It seems that "-ftree-loop-vectorize" causing "|=" operation ignore the "sign
bit" of "a[i] - b[i]" or "b[i] - a[i]".

I have summarized a test-case, which is attached


I have also compiled a cross-toolchain, using gcc git version
(98e482761b083dbc35ae59704ee1eeb0b8eeb5d1), which is also gcc 11.2.1, this git
version also has such issue.



Version-Release number of selected component (if applicable):
GCC 11.2.1

Additional Info:
GCC 11 for x86 / x86_64 doesn't have such issue.
GCC 10.x for aarch64 doesn't have such issue.

I have also submitted this bug to Fedora bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1998964

[Bug c/102124] GCC 11.2.1 -ftree-loop-vectorize Causing Data To Lose Sign Bit

[changyp6 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102124

--- Comment #1 from Tomas Chang  ---
Test Program is as below:
#include 
#include 
#include 

typedef uint8_t byte;
int buf_eq_const(const void *_a, const void *_b, size_t len)
 {
   const byte *a = _a; 
   const byte *b = _b; 
   int ab, ba; 
   size_t i;

   /* Constant-time compare. */
   for (i = 0, ab = 0, ba = 0; i < len; i++)
 {
   /* If a[i] != b[i], either ab or ba will be negative. */
   ab |= a[i] - b[i];
   ba |= b[i] - a[i];
 }   

   /* 'ab | ba' is negative when buffers are not equal. */
   printf("(ab | ba) = %d(%08x), ab = %d(%08x), ba = %d(%08x)\n", (ab | ba),
(ab | ba), ab, ab, ba, ba);
   return (ab | ba) >= 0;
 }

void print_array(const char *name, uint8_t *a, size_t len)
{
printf("%s[%lu] = {", name, len);
for (size_t i = 0; i < len; ++ i) {
printf("\'%c\', ", a[i]);
}
printf("}\n");
}

int main(int argc, char *argv[])
{
uint8_t a[32] = {'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a',
'a', 'a', 'a', 'a', 'a'};
uint8_t b[32] = {'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a',
'a', 'a', 'a', 'a', 'a'};
uint8_t c[32] = {'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b',
'b', 'b', 'b', 'b', 'b'};

printf("Comparing array a and array b:\n");
print_array("a", a, 16);
print_array("b", b, 16);
if (buf_eq_const(a, b, 16)) {
printf("a == b\n");
} else {
printf("a != b\n");
}

printf("Comparing array a and array c:\n");
print_array("a", a, 16);
print_array("c", c, 16);
if (buf_eq_const(a, c, 16)) {
printf("a == c\n");
} else {
printf("a != c\n");
}

return 0;
}

Compile this file with the following command:
gcc -Wall -O2 -march=armv8.2-a+crypto+fp16+rcpc+dotprod -mtune=cortex-a76 -o $@
$<

Running Results:
./test-gcc-O2
Comparing array a and array b:
a[16] = {'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a',
'a', 'a', }
b[16] = {'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a',
'a', 'a', }
(ab | ba) = 0(), ab = 0(), ba = 0()
a == b
Comparing array a and array c:
a[16] = {'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a',
'a', 'a', }
c[16] = {'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b',
'b', 'b', }
(ab | ba) = -1(), ab = -1(), ba = 1(0001)
a != c


Compile this file with the following command:
test-gcc-O2-tree-loop-vectorize: test-gcc.c
gcc -Wall -O2 -march=armv8.2-a+crypto+fp16+rcpc+dotprod
-mtune=cortex-a76 -ftree-loop-vectorize -o $@ $<

Running Results:
./test-gcc-O2-tree-loop-vectorize 
Comparing array a and array b:
a[16] = {'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a',
'a', 'a', }
b[16] = {'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a',
'a', 'a', }
(ab | ba) = 0(), ab = 0(), ba = 0()
a == b
Comparing array a and array c:
a[16] = {'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a',
'a', 'a', }
c[16] = {'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b',
'b', 'b', }
(ab | ba) = 65535(), ab = 65535(), ba = 1(0001)
a == c

[Bug c/102125] New: (ARM Cortex-M3 and newer) missed optimization. memcpy not needed operations

[jankowski938 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102125

Bug ID: 102125
   Summary: (ARM Cortex-M3 and newer) missed optimization. memcpy
not needed operations
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jankowski938 at gmail dot com
  Target Milestone: ---

uint64_t bar64(const uint8_t *rData1)
{
uint64_t buffer;
memcpy(&buffer, rData1, sizeof(buffer));
return buffer;
}

compiler options: 
-Ox -mthumb -mcpu=cortex-my

where x : 2,3,s   y:3,4,7

```
bar64:
sub sp, sp, #8
mov r2, r0
ldr r0, [r0]  @ unaligned
ldr r1, [r2, #4]  @ unaligned
mov r3, sp
stmia   r3!, {r0, r1}
ldrdr0, [sp]
add sp, sp, #8
bx  lr
```

it is enough to:

```
mov r3, r0
ldr r0, [r0]  @ unaligned
ldr r1, [r3, #4]  @ unaligned
bx  lr
```

32 bit memcpy is optimized correctly:

Full example code:

```
uint64_t foo64(const uint8_t *rData1)
{
uint64_t buffer;
buffer =  (((uint64_t)rData1[7]) << 56)|((uint64_t)(rData1[6]) <<
48)|((uint64_t)(rData1[5]) << 40)|(((uint64_t)rData1[4]) << 32)|
(((uint64_t)rData1[3]) <<
24)|(((uint64_t)rData1[2]) << 16)|((uint64_t)(rData1[1]) << 8)|rData1[0];
return buffer;
}

uint64_t bar64(const uint8_t *rData1)
{
uint64_t buffer;
memcpy(&buffer, rData1, sizeof(buffer));
return buffer;
}

uint32_t foo32(const uint8_t *rData1)
{
uint32_t buffer;
buffer = (((uint32_t)rData1[3]) << 24)|(((uint32_t)rData1[2]) <<
16)|((uint32_t)(rData1[1]) << 8)|rData1[0];
return buffer;
}

uint32_t bar32(const uint8_t *rData1)
{
uint32_t buffer;
memcpy(&buffer, rData1, sizeof(buffer));
return buffer;
}
```

compiler output:
```
foo64:
mov r3, r0
ldr r0, [r0]  @ unaligned
ldr r1, [r3, #4]  @ unaligned
bx  lr
bar64:
sub sp, sp, #8
mov r2, r0
ldr r0, [r0]  @ unaligned
ldr r1, [r2, #4]  @ unaligned
mov r3, sp
stmia   r3!, {r0, r1}
ldrdr0, [sp]
add sp, sp, #8
bx  lr
foo32:
ldr r0, [r0]  @ unaligned
bx  lr
bar32:
ldr r0, [r0]  @ unaligned
bx  lr
```

Clang compiles without overhead:

https://godbolt.org/z/P7G7Whxqz

[Bug c/102098] ICE when #include with -fmodules-ts -std=c++20 since r11-7530-g1e5cdb9f896fb220

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102098

Martin Liška  changed:

   What|Removed |Added

Summary|ICE when #include   |ICE when #include
   | with   | with
   |-fmodules-ts -std=c++20 |-fmodules-ts -std=c++20
   ||since
   ||r11-7530-g1e5cdb9f896fb220
 Status|WAITING |NEW

--- Comment #3 from Martin Liška  ---
Confirmed, reduced test-case:

$ cat pr102098.ii
module;
# 1 "" 1 3
struct Trans_NS__V2_error_category {
  virtual equivalent();
};
struct error_condition {
  Trans_NS__V2_error_category &category() const;
};
struct error_category {
  friend Trans_NS__V2_error_category const &to_std_category();
};
template  struct _Rb_tree_iterator {
  typedef _Rb_tree_iterator _Self;
  friend operator==(_Self, _Self) {}
};
template  struct _Rb_tree {
  typedef _Rb_tree_iterator<_Val> iterator;
};
template  struct map {
  typedef typename _Rb_tree<_Key>::iterator iterator;
};
struct std_category {
  bool equivalent(const error_condition &) const;
};
map::iterator __trans_tmp_2;
inline Trans_NS__V2_error_category const &to_std_category() {
  map::iterator i;
  i == __trans_tmp_2;
}
inline bool std_category::equivalent(const error_condition &condition) const {
  dynamic_cast(&condition.category());
}
# 0 "" 2
export module foo;

Started with r11-7530-g1e5cdb9f896fb220.

[Bug target/102124] [11/12 Regression] -ftree-loop-vectorize Causing Data To Lose Sign Bit on AARCH64 Platform

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102124

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||joelh at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
   Priority|P3  |P2
   Target Milestone|--- |11.3
Summary|GCC 11.2.1  |[11/12 Regression]
   |-ftree-loop-vectorize   |-ftree-loop-vectorize
   |Causing Data To Lose Sign   |Causing Data To Lose Sign
   |Bit on AARCH64 Platform |Bit on AARCH64 Platform
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-08-30

--- Comment #2 from Jakub Jelinek  ---
Started with r11-5160-g9fc9573f9a5e9432e53c7de93985cfbd267f0309 .

Slightly reduced testcase:
int
foo (const unsigned char *a, const unsigned char *b, unsigned long len)
{
  int ab, ba; 
  unsigned long i;
  for (i = 0, ab = 0, ba = 0; i < len; i++)
{
  ab |= a[i] - b[i];
  ba |= b[i] - a[i];
}   
  return (ab | ba) >= 0;
}

int main ()
{
  unsigned char a[32] = {'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a',
'a', 'a', 'a', 'a', 'a'};
  unsigned char b[32] = {'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a',
'a', 'a', 'a', 'a', 'a'};
  unsigned char c[32] = {'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b', 'b',
'b', 'b', 'b', 'b', 'b'};
  if (!foo (a, b, 16))
__builtin_abort ();
  if (foo (a, c, 16))
__builtin_abort ();
  return 0;
}

[Bug c/102125] (ARM Cortex-M3 and newer) missed optimization. memcpy not needed operations

[jankowski938 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102125

--- Comment #1 from Piotr  ---
IMO it is quite important as `memcpy` type punning is considered as the safest

[Bug target/102124] [11/12 Regression] -ftree-loop-vectorize Causing Data To Lose Sign Bit on AARCH64 Platform

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102124

--- Comment #3 from Jakub Jelinek  ---
Before vectorization the loop body is:
  _1 = a_19(D) + i_29;
  _2 = *_1;
  _3 = (int) _2;
  _4 = b_20(D) + i_29;
  _5 = *_4;
  _6 = (int) _5;
  _7 = _3 - _6;
  ab_21 = _7 | ab_25;
  _10 = _6 - _3;
  ba_22 = _10 | ba_27;
where _2 and _5 are unsigned char and _3, _6, _7, _10 are int.
It is vectorized as
  vect_patt_54.17_61 = WIDEN_MINUS_LO_EXPR ;
  vect_patt_54.17_62 = WIDEN_MINUS_HI_EXPR ;
  vect_patt_53.18_63 = [vec_unpack_lo_expr] vect_patt_54.17_61;
  vect_patt_53.18_64 = [vec_unpack_hi_expr] vect_patt_54.17_61;
  vect_patt_53.18_65 = [vec_unpack_lo_expr] vect_patt_54.17_62;
  vect_patt_53.18_66 = [vec_unpack_hi_expr] vect_patt_54.17_62;
  _7 = _3 - _6;
  vect_ab_21.19_67 = vect_patt_53.18_63 | vect_ab_25.9_13;
  vect_ab_21.19_68 = vect_patt_53.18_64 | vect_ab_21.19_67;
  vect_ab_21.19_69 = vect_patt_53.18_65 | vect_ab_21.19_68;
  vect_ab_21.19_70 = vect_patt_53.18_66 | vect_ab_21.19_69;
  ab_21 = _7 | ab_25;
which means it is vectorized as if it was instead of (int) _2 - (int) _6
(int) (unsigned short) ((unsigned short) _2 - (unsigned short) _6).

[Bug middle-end/102126] New: Wrong optimization of multiplication by 1 and -1 with -ftrapping-math when an underflow is possible

[vincent-gcc at vinc17 dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126

Bug ID: 102126
   Summary: Wrong optimization of multiplication by 1 and -1 with
-ftrapping-math when an underflow is possible
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

Without -fsignaling-nans, GCC optimizes the floating-point multiplication by 1
as a no-op, even when it may generate a trap due to underflow. This is wrong.

Testcase:

#define _GNU_SOURCE
#include 
#include 
#include 
#pragma STDC FENV_ACCESS ON

double f (double x)
{
  return x * 1.0;
}

double g (double x)
{
  volatile double one = 1.0;
  return x * one;
}

int main (void)
{
  volatile double x = DBL_MIN / 2, y;

  feenableexcept (FE_UNDERFLOW);
  y = f(x);
  printf ("f: %d\n", y != 0);
  y = g(x);
  printf ("g: %d\n", y != 0);

  return 0;
}

Here, x is a subnormal, so that its multiplication by 1 signals an underflow.
Note that since the result is exact, the underflow flag is not raised under the
default exception handling, so that without -ftrapping-math and
-fsignaling-nans, f() may be optimized to no-op. With -fsignaling-nans, GCC
disables the optimization as expected. But with -ftrapping-math, it doesn't
(the optimization is done at any optimization level, even -O0); this can be
seen in the generated asm code, with -S.

When executing the code (with -O3 -ftrapping-math -lm):

f: 1
Floating point exception (core dumped)

showing that f() was incorrectly optimized, and that g(), which is not
optimized due to volatile, gives a floating-point exception as expected.

Similar issue with the multiplication by -1 (at least on x86_64), where GCC
just negates the value.

Bug reproducible from at least GCC 4.6 to GCC 11.2.0.

[Bug target/80689] 128 bit loads generated for structure copying with gcc 7.1.0 and leads to STLF stalls in avx2 targets.

[jamborm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80689

--- Comment #11 from Martin Jambor  ---
(In reply to Andrew Pinski from comment #10)
> Even LLVM does this same thing.

What do you mean by "does this same thing?" Does it copy the structure
element-wise or does it copy it is a block like GCC does (and suffers the same
problem)?

[Bug target/102127] New: [12 Regression] ICE when compiling powerpc/440-mulchw-1.c

[iains at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127

Bug ID: 102127
   Summary: [12 Regression] ICE when compiling
powerpc/440-mulchw-1.c
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

/home/iains/gcc-master/bld/gcc/xgcc -B/home/iains/gcc-master/bld/gcc/
/home/iains/gcc-master/src/gcc/testsuite/gcc.target/powerpc/440-mulchw-1.c -m32
-fdiagnostics-plain-output -O2 -mdejagnu-cpu=440 
-ffat-lto-objects -fno-ident -S -o 440-mulchw-1.s
: internal compiler error: Segmentation fault
0x10b123fb crash_signal
../../src/gcc/toplev.c:328
0x10f5dc50 build_function_type(tree_node*, tree_node*)
../../src/gcc/tree.c:7306
0x10f5e013 build_function_type_list_1
../../src/gcc/tree.c:7366
0x10f5e013 build_function_type_list(tree_node*, ...)
../../src/gcc/tree.c:7383
0x1114653b rs6000_init_generated_builtins()
/home/iains/gcc-master/bld/gcc/rs6000-builtins.c:37716
0x1113e027 rs6000_init_builtins()
../../src/gcc/config/rs6000/rs6000-call.c:13652
0x10302383 c_define_builtins
../../src/gcc/c-family/c-common.c:4152
0x10302383 c_common_nodes_and_builtins()
../../src/gcc/c-family/c-common.c:4639
0x101fbb9b c_init_decl_processing()
../../src/gcc/c/c-decl.c:4485
0x10273a6f c_objc_common_init()
../../src/gcc/c/c-objc-common.c:62
0x101dc31b lang_dependent_init
../../src/gcc/toplev.c:1921
0x101dc31b do_compile
../../src/gcc/toplev.c:2218

[Bug middle-end/102126] Wrong optimization of FP multiplication and division by 1 and -1 with -ftrapping-math when an underflow is possible

[vincent-gcc at vinc17 dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126

--- Comment #1 from Vincent Lefèvre  ---
Division by 1 and -1 is affected too (as being equivalent to multiplication).

Note that F.9.2 "Expression transformations" in ISO C17 says:

  1 × x and x/1 → x The expressions 1 × x, x/1, and x are equivalent
(on IEC 60559 machines, among others).374)

   374) Strict support for signaling NaNs — not required by this
   specification — would invalidate these and other transformations
   that remove arithmetic operators.

and the current C2x draft (N2596) has something similar. But this is incorrect
as it misses the underflow case with enabled trap (allowed by F.8).

[Bug target/102127] [12 Regression] ICE when compiling (m32) powerpc/440-mulchw-1.c

[iains at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127

Iain Sandoe  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Last reconfirmed||2021-08-30
Summary|[12 Regression] ICE when|[12 Regression] ICE when
   |compiling   |compiling (m32)
   |powerpc/440-mulchw-1.c  |powerpc/440-mulchw-1.c
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 Target||powerpc64-linux-gnu,
   ||powerpc-aix, powerpc-darwin

--- Comment #1 from Iain Sandoe  ---
between r12-3052 and r12-3205

[Bug target/102124] [11/12 Regression] -ftree-loop-vectorize Causing Data To Lose Sign Bit on AARCH64 Platform

[changyp6 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102124

--- Comment #4 from Tomas Chang  ---
(In reply to Jakub Jelinek from comment #3)
> Before vectorization the loop body is:
>   _1 = a_19(D) + i_29;
>   _2 = *_1;
>   _3 = (int) _2;
>   _4 = b_20(D) + i_29;
>   _5 = *_4;
>   _6 = (int) _5;
>   _7 = _3 - _6;
>   ab_21 = _7 | ab_25;
>   _10 = _6 - _3;
>   ba_22 = _10 | ba_27;
> where _2 and _5 are unsigned char and _3, _6, _7, _10 are int.
> It is vectorized as
>   vect_patt_54.17_61 = WIDEN_MINUS_LO_EXPR ;
>   vect_patt_54.17_62 = WIDEN_MINUS_HI_EXPR ;
>   vect_patt_53.18_63 = [vec_unpack_lo_expr] vect_patt_54.17_61;
>   vect_patt_53.18_64 = [vec_unpack_hi_expr] vect_patt_54.17_61;
>   vect_patt_53.18_65 = [vec_unpack_lo_expr] vect_patt_54.17_62;
>   vect_patt_53.18_66 = [vec_unpack_hi_expr] vect_patt_54.17_62;
>   _7 = _3 - _6;
>   vect_ab_21.19_67 = vect_patt_53.18_63 | vect_ab_25.9_13;
>   vect_ab_21.19_68 = vect_patt_53.18_64 | vect_ab_21.19_67;
>   vect_ab_21.19_69 = vect_patt_53.18_65 | vect_ab_21.19_68;
>   vect_ab_21.19_70 = vect_patt_53.18_66 | vect_ab_21.19_69;
>   ab_21 = _7 | ab_25;
> which means it is vectorized as if it was instead of (int) _2 - (int) _6
> (int) (unsigned short) ((unsigned short) _2 - (unsigned short) _6).

Thank you very much for confirming this issue so quicky!
Hope this issue can be fixed soon!

[Bug middle-end/102126] Wrong optimization of FP multiplication and division by 1 and -1 with -ftrapping-math when an underflow is possible

[vincent-gcc at vinc17 dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126

--- Comment #2 from Vincent Lefèvre  ---
In the testcase, I forgot

#pragma STDC FP_CONTRACT OFF

Anyway, it is currently ignored by GCC.

[Bug target/102127] [12 Regression] ICE when compiling (m32) powerpc/440-mulchw-1.c since g:ff6bb9dde10ab665a35bb75527313cd9f7d52f8e

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127

Martin Liška  changed:

   What|Removed |Added

Summary|[12 Regression] ICE when|[12 Regression] ICE when
   |compiling (m32) |compiling (m32)
   |powerpc/440-mulchw-1.c  |powerpc/440-mulchw-1.c
   ||since
   ||g:ff6bb9dde10ab665a35bb7552
   ||7313cd9f7d52f8e
 CC||marxin at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with g:ff6bb9dde10ab665a35bb75527313cd9f7d52f8e.

[Bug tree-optimization/102128] New: [12 Regression] Huge performance drop for 519.lbm_r since r12-3116-g9216ee6d1195d48388f825cf1b072e570129cbbe

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102128

Bug ID: 102128
   Summary: [12 Regression] Huge performance drop for 519.lbm_r
since
r12-3116-g9216ee6d1195d48388f825cf1b072e570129cbbe
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---

Since the revision, the benchmark is slower with -Ofast PGO (and LTO) on AMD
and Intel machines:

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=14.477.0&plot.1=16.477.0&;

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=286.477.0&plot.1=16.477.0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/102128] [12 Regression] Huge performance drop for 519.lbm_r since r12-3116-g9216ee6d1195d48388f825cf1b072e570129cbbe

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102128

--- Comment #1 from Martin Liška  ---
Created attachment 51375
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51375&action=edit
Optimized dump on znver3 - bad

[Bug tree-optimization/102128] [12 Regression] Huge performance drop for 519.lbm_r since r12-3116-g9216ee6d1195d48388f825cf1b072e570129cbbe

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102128

--- Comment #2 from Martin Liška  ---
Created attachment 51376
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51376&action=edit
Optimized dump on znver3 - good

[Bug target/102124] [11/12 Regression] -ftree-loop-vectorize Causing Data To Lose Sign Bit on AARCH64 Platform

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102124

--- Comment #5 from Jakub Jelinek  ---
I think the bug is in vect_recog_widen_op_pattern.
When we have half_type unsigned, for PLUS_EXPR, MULT_EXPR (and supposedly
LSHIFT_EXPR) it is ok that itype is twice the precision and same sign as
half_type, say
unsigned char uc1 = 0xfe, uc2 = 0xff;
int t1 = uc1, t2 = uc2;
t1 + t2 (or t1 * t2) wants to perform the widening operation and then
zero-extend to the result type.
But MINUS_EXPR seems to be special,
t1 - t2
is negative despite half_type being unsigned (and, even if type is unsigned,
such as for
unsigned u1 = uc1, u2 = uc2;
u1 - u2
wants sign-extension from unsigned short (aka itype) to unsigned int (aka type)
rather than zero-extension.

[Bug target/100952] [12 regression] several test case failures after r12-1202

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952

--- Comment #12 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Segher Boessenkool
:

https://gcc.gnu.org/g:c27080718d480ef08986b9224c0d146b75791c25

commit r11-8941-gc27080718d480ef08986b9224c0d146b75791c25
Author: Haochen Gui 
Date:   Thu Jul 29 14:56:12 2021 +0800

Fix failed test cases caused by disabling mode promotion for pseudos
[PR100952]

gcc/testsuite
PR target/100952
* gcc.target/powerpc/pr56605.c: Change matching
conditions.
* gcc.target/powerpc/pr81348.c: Likewise.

(cherry picked from commit f0529d96f56758e56151f409c55bab3034163210)

[Bug tree-optimization/102124] [11/12 Regression] -ftree-loop-vectorize Causing Data To Lose Sign Bit on AARCH64 Platform

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102124

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
  Component|target  |tree-optimization
 Status|NEW |ASSIGNED

[Bug tree-optimization/102128] [12 Regression] Huge performance drop for 519.lbm_r since r12-3116-g9216ee6d1195d48388f825cf1b072e570129cbbe

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102128

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-08-30
   Target Milestone|--- |12.0
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Interesting - it must be the grouping of all SLP instances affecting this.

[Bug tree-optimization/102124] [11/12 Regression] -ftree-loop-vectorize Causing Data To Lose Sign Bit on AARCH64 Platform

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102124

--- Comment #6 from Jakub Jelinek  ---
Created attachment 51377
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51377&action=edit
gcc12-pr102124.patch

Untested fix.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918

--- Comment #7 from Rimvydas (RJ)  ---
The suggested removal of -fdefault-real-8 -fdefault-double-8 options would be
very problematic for many climate modeling libraries where similar '-r8' option
works as users expect in different compilers: promoting only default types
where no explicit kind is provided.  Often coupling interfaces between
different climate modeling software libraries are already using explicit kinds
for correct data passing, while types in intermediate internal computations are
left at compiler default types.  This allows the use of narrower types for
operational climate simulations (when quicker model execution time is
necessary) and use wider types for more precise calculations in offline runs,
without extensive use of C preprocessor that is not a standard Fortran feature.
 Note, there is no option to silence warnings about numerical constants (not
using explicit kinds) when constants can be converted without loss of precision
including for powers of 2 in floating types.

It is puzzling that some of gfortran developers often are advocating the use of
options like -freal-4-real-8 or -freal-8-real-4 instead.  These options are as
useful as -finteger-4-integer-8 for anything but simple single source programs.
 Consider the following with -O0 -finteger-4-integer-8 -fdump-tree-original -c:

program foo
integer :: t
call bar(t)
end program

subroutine bar(n) ! C callable
use iso_c_binding,only: c_int
implicit none
character(len=4) :: mode = 'test'
integer(kind=c_int) :: n
n = -floor(6.)
call c_func(n, mode)
end subroutine

might as well promote integer types in main() too.  It is nearly impossible to
use -freal-* -finteger-* options when code needs to link with libraries like
BLAS/LAPACK or optimized variants like OpenBLAS, especially when these options
prevents *any* use of the given type kind and even break fundamental feature
like ISO_C_BINDING without giving some indication that frontend is doing this. 
In many bigger climate packages it is common to use different kinds for IO,
computation, coupling etc:
ones based on defaults for given architecture/ABI:
  logical
  integer
  real
  double precision
  quad precision (when it becomes part of the standard, since hardware is
becoming available for scientific computations)
ones based on minimal precision required:
  real, parameter :: jprf = selected_real_kind(6,37)
  real, parameter :: jprd = selected_real_kind(13,300)
  integer, parameter :: jpii = selected_int_kind(9)
  integer, parameter :: jpil = selected_int_kind(13)
ones based on Fortran internal storage (a.k.a "works on compilers tested"):
  real, parameter :: jpr4 = 4
  real, parameter :: jpr8 = 8
  integer, parameter :: jpi4 = 4
  integer, parameter :: jpi8 = 8
ones based on C/Fortran bindings through iso_c_binding
  integer(kind=c_int)
  integer(kind=c_long)
  real(kind=c_float)
  real(kind=c_double)

Users usually do not expect numeric kinds to match between all these groups for
all architectures/ABIs, but it is expected that the compiler should convert
variable types (including numeric constants) with different kinds or give a
diagnostic when it is not possible, otherwise whole use of different explicit
kinds is redundant if those internally map to the same kind that can be
overridden silently by a single option.  If it is indeed just an LTO
implementation limitation, then users need to be careful when checking what
dynamic or static different climate libraries (possibly using -flto) are being
used when linking final executables.
Even added diagnostics when the user makes a typo like:
  integer(kind=selected_real_kind(13,300)) :: i
would help a lot.  At least some common examples of what to look for in
documentation about "gfortran -fdefault-real-8 -fdefault-double-8" limitations
(if these options are really that broken) would be very appreciated by the
software porters :)

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918

--- Comment #8 from Rimvydas (RJ)  ---
If we can agree that use of -fdefault-real-8 -fdefault-double-8 with -flto does
not magically recompile intrinsic subroutines in runtime libgfortran.so
library, it looks like it is a frontend issue not providing correct information
for LTO.  Somewhat more trivial example for different intrinsic runtime call:
$ cat foo.f90
program foo
implicit none
double precision, dimension (1:4) :: b = 1
double precision, dimension (1:2, 1:2) :: h
h = reshape( b, (/ 2, 2 /))
call bar()
end program

$ cat bar.f90
subroutine bar
implicit none
real, dimension (1:4) :: b = 1
real, dimension (1:2, 1:2) :: h
h = reshape( b, (/ 2, 2 /))
end subroutine

$ gfortran -Wall -Wextra -flto -fdefault-real-8 -fdefault-double-8 -c bar.f90
$ gfortran -Wall -Wextra -flto foo.f90 bar.o
bar.f90:5:27: warning: type of '_gfortran_reshape_r8' does not match original
declaration [-Wlto-type-mismatch]
5 | h = reshape( b, (/ 2, 2 /))
  |   ^
foo.f90:5:27: note: '_gfortran_reshape_r8' was previously declared here
5 | h = reshape( b, (/ 2, 2 /))
  |   ^
foo.f90:5:27: note: code may be misoptimized unless '-fno-strict-aliasing' is
used

The -fdump-tree-original match exactly and both report: _gfortran_reshape_r8/4
function body not available.  The same happens even when bar.f90 is using
real(c_double) from ISO_C_BINDINGS.
Maybe it would be possible to provide interfaces for calls to intrinsics in the
runtime library, even if that would require use of "!GCC$ ATTRIBUTES
NO_ARG_CHECK :: VARIABLE" like it is already done for "USE MPI" bindings?

[Bug fortran/97571] long parsing phase for simple array constructor

[rimvydas.jas at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571

--- Comment #13 from Rimvydas (RJ)  ---
I agree that it is preferred to rewrite such look up table initialization,
however it is not always possible due to licensing restrictions preventing
making local modifications to the source code provided.  From user perspective
user requested to create consecutive integer array constructor that should be
called to ACOS() intrinsic and not vise versa create real (possibly double or
even quad precision) array constructor containing acos() values.

Something like a runtime limit variable to prevent compile time hogging would
be acceptable provided if user would get warned under say -Wsurprising that
intrinsic evaluation on array constructor was skipped due to excessive use of
MPFR library function calls or was considered not beneficial.

[Bug tree-optimization/102128] [12 Regression] Huge performance drop for 519.lbm_r since r12-3116-g9216ee6d1195d48388f825cf1b072e570129cbbe

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102128

--- Comment #4 from Richard Biener  ---
I see now extra .REDUC_PLUS vectorized likely because of that.  I'm testing sth
to keep the separate subgraph costing.

[Bug target/102127] [12 Regression] ICE when compiling (m32) powerpc/440-mulchw-1.c since g:ff6bb9dde10ab665a35bb75527313cd9f7d52f8e

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127

Richard Biener  changed:

   What|Removed |Added

Version|10.2.1  |12.0
   Target Milestone|--- |12.0

[Bug middle-end/102126] Wrong optimization of FP multiplication and division by 1 and -1 with -ftrapping-math when an underflow is possible

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126

--- Comment #3 from Richard Biener  ---
(In reply to Vincent Lefèvre from comment #2)
> In the testcase, I forgot
> 
> #pragma STDC FP_CONTRACT OFF
> 
> Anyway, it is currently ignored by GCC.

You can use -ffp-contract=off but I don't think these transforms are affected.

Note FENV_ACCESS is also ignored but then -ftrapping-math should indeed make
your testcase valid.  Are denormals standardized or left towards the
implementation?  One could argue the underflow exception with * 1 on a denormal
isn't covered?

[Bug fortran/97571] long parsing phase for simple array constructor

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571

--- Comment #14 from anlauf at gcc dot gnu.org ---
(In reply to Rimvydas (RJ) from comment #13)
> I agree that it is preferred to rewrite such look up table initialization,
> however it is not always possible due to licensing restrictions preventing
> making local modifications to the source code provided.

AFAICS there is no such restriction for RTTOV.

> Something like a runtime limit variable to prevent compile time hogging
> would be acceptable provided if user would get warned under say -Wsurprising
> that intrinsic evaluation on array constructor was skipped due to excessive
> use of MPFR library function calls or was considered not beneficial.

So far no patch has been developed and submitted for review.

[Bug target/102125] (ARM Cortex-M3 and newer) missed optimization. memcpy not needed operations

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102125

Richard Biener  changed:

   What|Removed |Added

  Component|c   |target
   Last reconfirmed||2021-08-30
 Target||arm
   Keywords||missed-optimization
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Richard Biener  ---
One common source of missed optimizations is gimple_fold_builtin_memory_op
which has

  /* If we can perform the copy efficiently with first doing all loads
 and then all stores inline it that way.  Currently efficiently
 means that we can load all the memory into a single integer
 register which is what MOVE_MAX gives us.  */
  src_align = get_pointer_alignment (src);
  dest_align = get_pointer_alignment (dest);
  if (tree_fits_uhwi_p (len)
  && compare_tree_int (len, MOVE_MAX) <= 0
...
  /* If the destination pointer is not aligned we must be able
 to emit an unaligned store.  */
  && (dest_align >= GET_MODE_ALIGNMENT (mode)
  || !targetm.slow_unaligned_access (mode, dest_align)
  || (optab_handler (movmisalign_optab, mode)
  != CODE_FOR_nothing)))

where here likely the MOVE_MAX limit applies (it is 4).  Since we actually
do need to perform two loads the code seems to do what is intended (but
that's of course "bad" for 64bit copies on 32bit archs and likewise for
128bit copies on 64bit archs).

It's usually too late for RTL memcpy expansion to fully elide stack storage.

[Bug fortran/56985] gcc/fortran/resolve.c:920: "'%s' in cannot appear in COMMON ..."

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56985

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 ---
Actually the following seems better to me, as the location is that of the
declaration and not of the COMMON block:

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index f641d0d4dae..8e5ed1c032c 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -979,7 +979,7 @@ resolve_common_vars (gfc_common_head *common_block, bool
named_common)
}

   if (UNLIMITED_POLY (csym))
-   gfc_error_now ("%qs in cannot appear in COMMON at %L "
+   gfc_error_now ("%qs at %L cannot appear in COMMON "
   "[F2008:C5100]", csym->name, &csym->declared_at);

   if (csym->ts.type != BT_DERIVED)

The message is checked in gcc/testsuite/gfortran.dg/unlimited_polymorphic_2.f03

[Bug tree-optimization/102128] [12 Regression] Huge performance drop for 519.lbm_r since r12-3116-g9216ee6d1195d48388f825cf1b072e570129cbbe

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102128

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:89f33f44addbf9853bc3e6677db1fa941713cb6c

commit r12-3222-g89f33f44addbf9853bc3e6677db1fa941713cb6c
Author: Richard Biener 
Date:   Mon Aug 30 12:56:26 2021 +0200

tree-optimization/102128 - rework if-converted BB vect heuristic

This reworks the previous attempt to avoid leaving around if-converted
scalar code in BB vectorized loop bodies to keep costing independent
subgraphs which should address the observed regression with 519.lbm_r.

For this to work we now first cost all subgraphs and only after
doing that proceed to emit vectorized code.

2021-08-30  Richard Biener  

PR tree-optimization/102128
* tree-vect-slp.c (vect_bb_vectorization_profitable_p):
Move scanning for if-converted scalar code to the caller
and instead delay clearing the visited flag for profitable
subgraphs.
(vect_slp_region): Cost all subgraphs before scheduling.
For if-converted BB vectorization scan for scalar COND_EXPRs
and do not vectorize if any found and the cost model is
very-cheap.

[Bug tree-optimization/102128] [12 Regression] Huge performance drop for 519.lbm_r since r12-3116-g9216ee6d1195d48388f825cf1b072e570129cbbe

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102128

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Richard Biener  ---
Fixed.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 102128, which changed state.

Bug 102128 Summary: [12 Regression] Huge performance drop for 519.lbm_r since 
r12-3116-g9216ee6d1195d48388f825cf1b072e570129cbbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102128

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/100089] [11/12 Regression] 30% performance regression for denbench/mp2decoddata2 with -O3

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100089
Bug 100089 depends on bug 102128, which changed state.

Bug 102128 Summary: [12 Regression] Huge performance drop for 519.lbm_r since 
r12-3116-g9216ee6d1195d48388f825cf1b072e570129cbbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102128

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug target/102127] [12 Regression] ICE when compiling (m32) powerpc/440-mulchw-1.c since g:ff6bb9dde10ab665a35bb75527313cd9f7d52f8e

[wschmidt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127

--- Comment #3 from Bill Schmidt  ---
Also reported for AIX over the weekend.  Seems to occur on all BE targets.  
I'll try to look at this later today.

[Bug middle-end/102126] Wrong optimization of FP multiplication and division by 1 and -1 with -ftrapping-math when an underflow is possible

[vincent-gcc at vinc17 dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126

--- Comment #4 from Vincent Lefèvre  ---
(In reply to Richard Biener from comment #3)
> You can use -ffp-contract=off but I don't think these transforms are
> affected.

I confirm that the test behaves in the same way with -ffp-contract=off too.
BTW, -ftrapping-math is documented to be the default.

> Note FENV_ACCESS is also ignored but then -ftrapping-math should indeed make
> your testcase valid.  Are denormals standardized or left towards the
> implementation?  One could argue the underflow exception with * 1 on a
> denormal isn't covered?

Subnormals are actually even standardized in the main C specification, but are
required only for float and double if __STDC_IEC_559__ is defined (Annex F):
float and double match IEC 60559 (= IEEE 754) single and double formats
respectively, and all IEEE 754 formats have subnormals.

But what is important here is more the specification of underflow.

In C17, F.10:

  The “underflow” floating-point exception is raised whenever a result is tiny
  (essentially subnormal or zero) and suffers loss of accuracy.377)

  377) IEC 60559 allows different definitions of underflow. They all result in
  the same values, but differ on when the floating-point exception is raised.

However, IMHO, if the processor has some definition of underflow (typically
conforming to the IEEE 754 one), optimization should not yield a different one.

IEEE 754-2019 (which has a simpler definition than 754-1985, by eliminating
choices that have never been used in practice, according to discussions in the
stds-754 list) says: "The underflow exception shall be signaled when a tiny
non-zero result is detected." It still allows differences about tininess
detection (i.e. either after rounding or before rounding, the difference being
for exact values close to the minimum normal number in magnitude), but this
does not matter on my example.

It also says: "In addition, under default exception handling for underflow, if
the rounded result is inexact — that is, it differs from what would have been
computed were both exponent range and precision unbounded — the underflow flag
shall be raised and the inexact (see 7.6) exception shall be signaled. If the
rounded result is exact, no flag is raised and no inexact exception is
signaled. This is the only case in this standard of an exception signal
receiving default handling that does not raise the corresponding flag. Such an
underflow signal has no observable effect under default handling."

When the underflow trap is enabled, this is not the default exception handling
for underflow. Thus, whether the result is exact or not, the exception is
expected to be signaled in the same way, here with a trap.

[Bug c++/101460] Useless cascade of overload resolution errors for invalid expression

[jason at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101460

Jason Merrill  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 CC||jason at gcc dot gnu.org
 Status|NEW |ASSIGNED

[Bug target/102127] [12 Regression] ICE when compiling (m32) powerpc/440-mulchw-1.c since g:ff6bb9dde10ab665a35bb75527313cd9f7d52f8e

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127

--- Comment #4 from Segher Boessenkool  ---
Program received signal SIGSEGV, Segmentation fault.
0x10f9b10c in ._Z19build_function_typeP9tree_nodeS0_ ()
(gdb) bt
#0  0x10f9b10c in ._Z19build_function_typeP9tree_nodeS0_ ()
#1  0x10f9b488 in ._Z24build_function_type_listP9tree_nodez ()
#2  0x1118519c in ._Z30rs6000_init_generated_builtinsv ()
#3  0x1117dcec in ._Z20rs6000_init_builtinsv ()
#4  0x1032b88c in ._Z27c_common_nodes_and_builtinsv ()
#5  0x10227648 in ._Z22c_init_decl_processingv ()
#6  0x1029f630 in ._Z18c_objc_common_initv ()
#7  0x102079ac in ._ZN6toplev4mainEiPPc ()
#8  0x10209e90 in .main ()

build_function_type(tree_node*, tree_node*) is called with a zero value_type
and that crashes pretty much immediately.

[Bug target/102127] [12 Regression] ICE when compiling (m32) powerpc/440-mulchw-1.c since g:ff6bb9dde10ab665a35bb75527313cd9f7d52f8e

[wschmidt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127

--- Comment #5 from Bill Schmidt  ---
This will be similar to some other issues that arose in the past -- there are
function types that shouldn't be built when the type of an operand or return
value doesn't exist.  I must have missed some such combination here.

[Bug c++/101144] Coroutine compiler error

[liuyaoxin1976 at qq dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101144

Yaoxin Liu  changed:

   What|Removed |Added

 CC||liuyaoxin1976 at qq dot com

--- Comment #1 from Yaoxin Liu  ---
#include 
#include 
#include 

using namespace std::literals;

struct task {
  struct promise_type {
auto initial_suspend() noexcept { return std::suspend_always{}; }
auto final_suspend() noexcept { return std::suspend_always{}; }
void return_void() {}
task get_return_object() { return task{}; }
void unhandled_exception() noexcept {}
  };

  bool await_ready() const noexcept { return false; }
  void await_suspend(std::coroutine_handle<>) noexcept {}
  void await_resume() noexcept {}
};

task f(std::vector) { co_return; }

task f(std::vector) { co_return; }

task g() {
  co_await f(std::vector{1, 2, 3});  // ok
  co_await f(std::vector{}); // ok

  auto s1 = "hello1"s;
  auto s2 = "hello2"s;
  auto s3 = "hello3"s;
  co_await f(std::vector{s1, s2, s3}); // error
}

See https://godbolt.org/z/z9x8Y96j6

[Bug middle-end/102129] New: -ftrapping-math is broken or badly documented

[vincent-gcc at vinc17 dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102129

Bug ID: 102129
   Summary: -ftrapping-math is broken or badly documented
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

Testcase:

void g (void);
double f (double x)
{
  double r = x * 5.0;
  g ();
  return r;
}

In the generated code with -O1 and above, one can see that the multiplication
is done after g is called, even if -ftrapping-math is used (which is the
default). This is incorrect as x * 5.0 may trap, terminating the program with a
floating-point exception, in which case g must not be executed.

There is a similar discussion in PR29186 (which is actually about flag
reading), and -ftrapping-math is also mentioned in PR34678 ("I suspect that if
-ftrapping-math actually implemented everything required for the floating-point
exceptions aspects of FENV_ACCESS, [...]").

The STDC FENV_ACCESS pragma is not implemented, but by definition of
-ftrapping-math, it should imply some behavior similar to this pragma being on.
This bug is different from PR34678 because not everything from this pragma
needs to be implemented, just a subset of the "when a program might [...] run
under non-default floating-point control modes." part. This seems to be the
whole purpose of this option.

Note also that https://gcc.gnu.org/wiki/FloatingPointMath doesn't mention a
limitation for traps (only for the change of the rounding mode).

For the reference, the current documentation:

  -fno-trapping-math

Compile code assuming that floating-point operations cannot generate
user-visible traps. These traps include division by zero, overflow, underflow,
inexact result and invalid operation. This option requires that
-fno-signaling-nans be in effect. Setting this option may allow faster code if
one relies on “non-stop” IEEE arithmetic, for example.

This option should never be turned on by any -O option since it can result
in incorrect output for programs that depend on an exact implementation of IEEE
or ISO rules/specifications for math functions.

The default is -ftrapping-math.

(from https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html).

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918

--- Comment #9 from Steve Kargl  ---
On Mon, Aug 30, 2021 at 10:26:59AM +, rimvydas.jas at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
> 
> --- Comment #7 from Rimvydas (RJ)  ---
> The suggested removal of -fdefault-real-8 -fdefault-double-8 options would be
> very problematic for many climate modeling libraries where similar '-r8' 
> option
> works as users expect in different compilers: promoting only default types
> where no explicit kind is provided.  Often coupling interfaces between
> different climate modeling software libraries are already using explicit kinds
> for correct data passing, while types in intermediate internal computations 
> are
> left at compiler default types.  This allows the use of narrower types for
> operational climate simulations (when quicker model execution time is
> necessary) and use wider types for more precise calculations in offline runs,
> without extensive use of C preprocessor that is not a standard Fortran 
> feature.

And, here is the problem with these options.  Users think it
is a great idea to try to promote types without understanding
what the options, so they then just naively use those options
and complain when something goes wrong.

If you use these options with any one file in a project, you must
use them with all files.

> It is puzzling that some of gfortran developers often are advocating
> the use of options like -freal-4-real-8 or -freal-8-real-4 instead.
> These options are as useful as -finteger-4-integer-8 for anything
> but simple single source programs.

These options are preferred (at least by me) because they 
promote all real(4) to real(8) (or real(8) to real(4)) 
regardless of declarations in the code.  There is no ambiguity.
There is no breaking the storage association rules of Fortran;
where the -fdefault-* break storage association.

But, again, if you compile one file with one of these option,
then likely you must compile all files with these options.

>  Consider the following with -O0 -finteger-4-integer-8
> -fdump-tree-original -c:
> 
> program foo
> integer :: t
> call bar(t)
> end program
> 
> subroutine bar(n) ! C callable
> use iso_c_binding,only: c_int
> implicit none
> character(len=4) :: mode = 'test'
> integer(kind=c_int) :: n
> n = -floor(6.)
> call c_func(n, mode)
> end subroutine
> 
> might as well promote integer types in main() too.  It is nearly
> impossible to use -freal-* -finteger-* options when code needs to
> link with libraries like BLAS/LAPACK or optimized variants like
> OpenBLAS, especially when these options prevents *any* use of the
> given type kind and even break fundamental feature like ISO_C_BINDING
> without giving some indication that frontend is doing this. 

It is assumed that the user reads the documentation that comes
with his compiler.  Quoting from gfortran.info


-freal-* family of options

   ...  These options should be used with care and may not be suitable
   for your codes.  Areas of possible concern include calls to external
   procedures, alignment in 'EQUIVALENCE' and/or 'COMMON', generic
   interfaces, BOZ literal constant conversion, and I/O and calls to
   intrinsic procedures when passing a value to the 'kind=' dummy
   argument.  Inspection of the intermediate representation of the
   translated Fortran code, produced by '-fdump-fortran-original' or
   '-fdump-tree-original', is suggested.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[kargl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918

--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to Rimvydas (RJ) from comment #8)
> If we can agree that use of -fdefault-real-8 -fdefault-double-8 with -flto
> does not magically recompile intrinsic subroutines in runtime libgfortran.so
> library, it looks like it is a frontend issue not providing correct
> information for LTO.

No, it is not a frontend issue.  It is a user expectation issues.


> $ gfortran -Wall -Wextra -flto -fdefault-real-8 -fdefault-double-8 -c bar.f90
> $ gfortran -Wall -Wextra -flto foo.f90 bar.o

You need to use -fdefault-real-8 -fdefault-double-8 when compiling both
files.  How is the 2nd invocation of gfortran to know that your first
invocation of gfortran used imcompatiable options?

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[kargl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918

--- Comment #11 from kargl at gcc dot gnu.org ---
(In reply to Rimvydas (RJ) from comment #7)
At least some common examples of what to look for in
> documentation about "gfortran -fdefault-real-8 -fdefault-double-8"
> limitations (if these options are really that broken) would be very
> appreciated by the software porters :)

% cat foo.f90
program foo
   x = 1.
   y = 3.14159
   a = 1._4
   b = 3.14159_4
   print *, a / b
   print *, x/ y
end program foo
% gfcx -o z a.f90 && ./z
  0.318310142
  0.318310142
% gfcx -o z -fdefault-real-8 a.f90 && ./z
  0.31831014305159744 
  0.31831015504887655 
% gfcx -o z -freal-4-real-8 a.f90 && ./z
  0.31831015504887655 
  0.31831015504887655 

One of these is no like the others. Yes, the behavior is documented,
and the unlike other result is likely the result that is no desired
unless the user enjoys chancing numerical precision issues.

[Bug middle-end/102129] -ftrapping-math is broken or badly documented

[vincent-gcc at vinc17 dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102129

--- Comment #1 from Vincent Lefèvre  ---
Additional surprising behavior...

On the following C code:

void g (void);
double f (void)
{
  double x = 0.0, y = 0.0;
  double r = x / y;
  g ();
  return r;
}

one can see with -ftrapping-math (the default) that a 0.0 / 0.0 is done before
the call to g, which is the expected behavior (this time, the order of the
operations has been preserved):

pxor%xmm0, %xmm0
divsd   %xmm0, %xmm0
movsd   %xmm0, 8(%rsp)
callg@PLT
movsd   8(%rsp), %xmm0

(note that with -fno-trapping-math, a NaN is just generated at compile time).

But on the following C code:

void g (void);
double f (void)
{
  double x = 1.0, y = 3.0;
  double r = x / y;
  g ();
  return r;
}

GCC behaves as with -fno-trapping-math, i.e. g is called, then the rounded
value of 1/3 is returned, while there should have been an inexact exception
(the GCC manual explicitly mentions inexact as one of the possible traps).

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918

--- Comment #12 from Rimvydas (RJ)  ---
(In reply to kargl from comment #11)
> One of these is no like the others. Yes, the behavior is documented,
> and the unlike other result is likely the result that is no desired
> unless the user enjoys chancing numerical precision issues.
$ cat foo.f90 
program foo
   implicit none
   real(kind=4) :: a, b
   real :: x, y
   x = 1.
   y = 3.14159
   a = 1._4
   b = 3.14159_4
   print *, a / b
   print *, x/ y
end program foo
$ gfortran foo.f90 && ./a.out
  0.318310142
  0.318310142
$ gfortran foo.f90 -fdefault-real-8 && ./a.out
  0.318310142
  0.31831015504887655 
$ gfortran foo.f90 -freal-4-real-8 && ./a.out
  0.31831015504887655 
  0.31831015504887655

Looks pretty consistent for me if proper types are used to match the kinds used
in constants like 3.14159_4. The same would apply for plain DOUBLE PRECISION
and 3.14159D numerical constants. Is this the only catch for -fdefault-* family
of options?

> You need to use -fdefault-real-8 -fdefault-double-8 when compiling both
> files.  How is the 2nd invocation of gfortran to know that your first
> invocation of gfortran used incompatible options?
Incompatible how?  As far as executable linking is concerned the final link
could be performed by plain ld(1) on both foo.o and bar.o (or foo.o libbar.a)
provided that user links in the libgfortran.so too.  The -fdump-tree-original
-c outputs on both sources indicate that dump trees are identical (including
calls to _gfortran_reshape_r8() in libgfortran.so).

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918

--- Comment #13 from Steve Kargl  ---
On Mon, Aug 30, 2021 at 03:23:59PM +, rimvydas.jas at gmail dot com wrote:
> 
> > You need to use -fdefault-real-8 -fdefault-double-8 when compiling both
> > files.  How is the 2nd invocation of gfortran to know that your first
> > invocation of gfortran used incompatible options?
> Incompatible how?  As far as executable linking is concerned the final link
> could be performed by plain ld(1) on both foo.o and bar.o (or foo.o libbar.a)
> provided that user links in the libgfortran.so too.  The -fdump-tree-original
> -c outputs on both sources indicate that dump trees are identical (including
> calls to _gfortran_reshape_r8() in libgfortran.so).
> 

The -fdefault-* options change the storage association rules
in a way that breaks Fortran.  Places of concern include, but
are not limited, to COMMON, EQUIVALENCE, maybe the TRANSFER
intrinsic, BOZ conversion, calling external routines, etc.

And, no, I'm not wasting my time contriving examples to prove
that these options should be avoided.

[Bug target/80689] 128 bit loads generated for structure copying with gcc 7.1.0 and leads to STLF stalls in avx2 targets.

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80689

--- Comment #12 from Andrew Pinski  ---
(In reply to Martin Jambor from comment #11)
> (In reply to Andrew Pinski from comment #10)
> > Even LLVM does this same thing.
> 
> What do you mean by "does this same thing?" Does it copy the structure
> element-wise or does it copy it is a block like GCC does (and suffers the
> same problem)?

It does a block copy like GCC.

[Bug target/102107] protocol register (r12) corrupted before a tail call

[pc at us dot ibm.com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107

--- Comment #5 from Paul Clarke  ---
Fails with "-mcpu=power10" and "-O2" or "-O3".

[Bug ada/102078] affinity.c:59:19: error: Signed integer overflow ?

[dcb314 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102078

--- Comment #4 from David Binderman  ---
Full cppcheck error message is

gcc/ada/affinity.c:59:19: error: Signed integer overflow for expression
'1<

[Bug ada/102078] affinity.c:59:19: error: Signed integer overflow ?

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102078

--- Comment #5 from Jakub Jelinek  ---
index doesn't go to 32, just to 31.
And whether 1 << 31 or -1 << 31 etc. is or isn't UB heavily depends on the
language and standard version, C++20 and later accepts both, C89 and C++98 were
fuzzy, 1 << 31 is well defined in C++11..17 but -1 << 31 is UB, and both are UB
in C99/11/17.
1 << 32 or 1 << -1 is UB in all language versions.

[Bug target/102127] [12 Regression] ICE when compiling (m32) powerpc/440-mulchw-1.c since g:ff6bb9dde10ab665a35bb75527313cd9f7d52f8e

[wschmidt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127

--- Comment #6 from Bill Schmidt  ---
OK, I see.  This involves vector_pair_type_node and
vector_quad_type_node...which are not getting initialized because
TARGET_EXTRA_BUILTINS is false.  This is a patch-ordering problem in the series
that I missed.  Patch 18/34 (approved but not yet committed) should solve this
problem by always initializing these builtins.  Will catch up on commits and
make sure the problems are fixed.

[Bug target/102127] [12 Regression] ICE when compiling (m32) powerpc/440-mulchw-1.c since g:ff6bb9dde10ab665a35bb75527313cd9f7d52f8e

[wschmidt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127

--- Comment #7 from Bill Schmidt  ---
...by always initializing these types, not builtins...

[Bug demangler/102130] New: [c++filt] Stack overflow in demangle_path

[irfanariq at kaist dot ac.kr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102130

Bug ID: 102130
   Summary: [c++filt] Stack overflow in demangle_path
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: irfanariq at kaist dot ac.kr
  Target Milestone: ---

Created attachment 51378
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51378&action=edit
poc and full stack trace

Hello,

We are currently working on fuzz testing feature, and we found a crash on
c++filt.

The stack traces are as follow:
==617==ERROR: AddressSanitizer: stack-overflow on address 0x7fffe1fa7ff8 (pc
0x555911cd5385 bp 0x7fffe1fa8140 sp 0x7fffe1fa8000 T0)
#0 0x555911cd5384 in demangle_path rust-demangle.c:674
#1 0x555911cd5e48 in demangle_path rust-demangle.c:774
#2 0x555911cd56a1 in demangle_path rust-demangle.c:696
#3 0x555911cd5e48 in demangle_path rust-demangle.c:774
#4 0x555911cd56a1 in demangle_path rust-demangle.c:696
...
#247 0x555911cd5e48 in demangle_path rust-demangle.c:774
#248 0x555911cd56a1 in demangle_path rust-demangle.c:696
#249 0x555911cd5e48 in demangle_path rust-demangle.c:774
#250 0x555911cd56a1 in demangle_path rust-demangle.c:696
We also attach the full stack trace in the attachment.

**Step to reproduce**

We configured c++filt using 

$ CFLAGS="-g -O0 -fsanitize=address" ./configure --disable-shared
--enable-targets=all

,and built it using 

$ make -j10; make install 

,and run it with:

$ ./c++filt @

The input file is in the attachment.

**Environment**
- OS: Ubuntu 18.04.5 LTS
- GCC version: gcc 7.5.0
- binutils version: commit (7de7786bb7db5159fc8a7bfa3df72381ff16a38c) of master
branch on sourceware git
(https://sourceware.org/git/?p=binutils-gdb.git;a=tree;h=7de7786bb7db5159fc8a7bfa3df72381ff16a38c;hb=7de7786bb7db5159fc8a7bfa3df72381ff16a38c)

Thank you.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918

--- Comment #14 from Rimvydas (RJ)  ---
(In reply to Steve Kargl from comment #13)
> The -fdefault-* options change the storage association rules
> in a way that breaks Fortran.  Places of concern include, but
> are not limited, to COMMON, EQUIVALENCE, maybe the TRANSFER
> intrinsic, BOZ conversion, calling external routines, etc.
Actually the
https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html and
gfortran.1 manpage list this definition for -freal-*-real-* options, while:

-fdefault-real-8
Set the default real type to an 8 byte wide type. This option also affects
the kind of non-double real constants like 1.0. This option promotes the
default width of DOUBLE PRECISION and double real constants like 1.d0 to 16
bytes if possible. If -fdefault-double-8 is given along with fdefault-real-8,
DOUBLE PRECISION and double real constants are not promoted. Unlike
-freal-4-real-8, fdefault-real-8 does not promote variables with explicit kind
declarations.

> And, no, I'm not wasting my time contriving examples to prove
> that these options should be avoided.
Fair enough, but these Fortran legacy features like COMMON, EQUIVALENCE, BOZ
and calling external user routines without interface have nothing in common
with original PR report or more trivial _gfortran_reshape_r8 example in Comment
#8

I tried to get more information with lto-dump(1) tool, however
lto-dump -dump-body=foo foo.o
lto-dump -dump-body=bar bar.o
outputs do not indicate any tree differences either.  Is there a way to get
more LTO information to understand the issue at hand?

[Bug tree-optimization/102131] New: wrong code at -O1 and above on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102131

Bug ID: 102131
   Summary: wrong code at -O1 and above on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

This appears to be a recent regression.

[594] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210830 (experimental) [master revision
02dbf5d1273:023508d4548:d73c44800b53c7e130da29e4eff1960b8311ffcd] (GCC) 
[595] % 
[595] % gcctk -O0 small.c; ./a.out
[596] % 
[596] % gcctk -O1 small.c
[597] % ./a.out
Aborted
[598] % 
[598] % cat small.c
int a;
int main() {
  unsigned b = 0;
  int c = 1;
  for (; b < 3; b++) {
while (c < b)
  __builtin_abort ();
for (a = 0; a < 3; a++)
  c++;
  }
  return 0;
}

[Bug demangler/102132] New: [nm] Stack overflow in demangler_path

[irfanariq at kaist dot ac.kr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102132

Bug ID: 102132
   Summary: [nm] Stack overflow in demangler_path
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: irfanariq at kaist dot ac.kr
  Target Milestone: ---

Created attachment 51379
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51379&action=edit
poc and full stack trace

Hello,

We are currently working on fuzz testing feature, and we found a stack overflow
error on nm.

The stack traces are as follow:
==618==ERROR: AddressSanitizer: stack-overflow on address 0x7fff51a74ea8 (pc
0x7f55b9e42509 bp 0x7fff51a75710 sp 0x7fff51a74e80 T0)
#0 0x7f55b9e42508  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x79508)
#1 0x5592e730643c in str_buf_append rust-demangle.c:1493
#2 0x5592e7306483 in str_buf_demangle_callback rust-demangle.c:1500
#3 0x5592e72fffc4 in print_str rust-demangle.c:273
#4 0x5592e7302b82 in demangle_path rust-demangle.c:746
#5 0x5592e7302c00 in demangle_path rust-demangle.c:756
#6 0x5592e7303d65 in demangle_type rust-demangle.c:1031
#7 0x5592e7303cd3 in demangle_type rust-demangle.c:1024
#8 0x5592e7303348 in demangle_type rust-demangle.c:903
#9 0x5592e7302b91 in demangle_path rust-demangle.c:747
#10 0x5592e7302c00 in demangle_path rust-demangle.c:756
#11 0x5592e7303d65 in demangle_type rust-demangle.c:1031
#12 0x5592e7303cd3 in demangle_type rust-demangle.c:1024
#13 0x5592e7303348 in demangle_type rust-demangle.c:903
#14 0x5592e7302b91 in demangle_path rust-demangle.c:747
#15 0x5592e7302c00 in demangle_path rust-demangle.c:756
...

The full stack trace is attached.

**Step to reproduce**

We configured nm using 

$ CFLAGS="-g -O0 -fsanitize=address" ./configure --disable-shared
--enable-targets=all 

, and built it using 

$ make -j10; make install

, and run it with:

$ ./nm -C 

The input file is attached.

**Environment**
- OS: Ubuntu 18.04.5 LTS
- GCC version: gcc 7.5.0
- binutils version: commit (7de7786bb7db5159fc8a7bfa3df72381ff16a38c) of master
branch on sourceware git
(https://sourceware.org/git/?p=binutils-gdb.git;a=tree;h=7de7786bb7db5159fc8a7bfa3df72381ff16a38c;hb=7de7786bb7db5159fc8a7bfa3df72381ff16a38c)

Thank you.

[Bug rtl-optimization/102062] powerpc suboptimal unrolling simple array sum

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102062

--- Comment #15 from Segher Boessenkool  ---
This should be fixed now, please confirm.  Thanks!

[Bug tree-optimization/102131] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102131

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org
Version|unknown |12.0
   Target Milestone|--- |12.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-08-30
Summary|wrong code at -O1 and above |[12 Regression] wrong code
   |on x86_64-linux-gnu |at -O1 and above on
   ||x86_64-linux-gnu
   Priority|P3  |P1

--- Comment #1 from Jakub Jelinek  ---
Started with r12-3136-g3673dcf6d6baeb67bb70ff03d4cb3f92beed0075

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918

--- Comment #15 from Steve Kargl  ---
On Mon, Aug 30, 2021 at 05:11:12PM +, rimvydas.jas at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
> 
> --- Comment #14 from Rimvydas (RJ)  ---
> (In reply to Steve Kargl from comment #13)
> > The -fdefault-* options change the storage association rules
> > in a way that breaks Fortran.  Places of concern include, but
> > are not limited, to COMMON, EQUIVALENCE, maybe the TRANSFER
> > intrinsic, BOZ conversion, calling external routines, etc.
> Actually the
> https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html and
> gfortran.1 manpage list this definition for -freal-*-real-* options, while:

When g95 was imported into GCC, I am the person that changed
g95's -r8 option into gfortran's -fdefault-real-8 (along with
-i8) option.  I'm also the person that made these options work
for some definition of "work", and I have always considered
these options to be broken because of what you are re-discovering.

> -fdefault-real-8
> Set the default real type to an 8 byte wide type. This option also affects
> the kind of non-double real constants like 1.0. This option promotes the
> default width of DOUBLE PRECISION and double real constants like 1.d0 to 16
> bytes if possible. If -fdefault-double-8 is given along with fdefault-real-8,
> DOUBLE PRECISION and double real constants are not promoted. Unlike
> -freal-4-real-8, fdefault-real-8 does not promote variables with explicit kind
> declarations.

The words of caution for -freal-* and family of options also
applies to the -fdefault-* options.  I suspect much of work
done on the intrinsics modules is done independently and
obliviously to these options.

Feel free to update the documentation.  It may be prudent
to add a sentence that states

   "These options are intended to be used as aids when 
porting code from one precision to another, and may
not be suitable for production use."

or similar.

> > And, no, I'm not wasting my time contriving examples to prove
> > that these options should be avoided.
> Fair enough, but these Fortran legacy features like COMMON, EQUIVALENCE, BOZ
> and calling external user routines without interface have nothing in common
> with original PR report or more trivial _gfortran_reshape_r8 example in 
> Comment
> #8

COMMON, EQUIVALENCE, and BOZ are not legacy features.
These are full fledged features of modern Fortran. 
While COMMON and EQUIVALENCE may be frowned upon with
an eye toward usings MODULEs, BOZ is quite different
and alive.  In particular, I wrote the BOZ support and
rewrote to conform to the F2018 standard.  F202x is
extending where and how BOZ can/should be handled.

The original problem is simply another manifestation of 
why these options should be avoided, if not removed from
gfortran.  In your original example, you have changed the
ABI between foo.o and bar.o, which now confuses lto.

[Bug c++/101355] incorrect `this' in destructor calls when compiling coroutines with ubsan

[iains at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101355

Iain Sandoe  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=95137
   Keywords||wrong-code
 Ever confirmed|0   |1
 CC||iains at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-08-30

--- Comment #3 from Iain Sandoe  ---
the two cases seem likely related - if not actually the same.  At present, I
was not sure if this is a coroutines bug (and have not had time to look at it
in detail).

The root cause does appear to be the same - that the sanitiser is expecting the
temp (D.9828 in your case) to be valid - but there is some path through the
code where a suspension occurs so that this is not true.

Unfortunately, I'm not familiar enough with the sanitizer code to comment on
whether the proposed fix is the right one.

[Bug middle-end/102133] New: [12 Regression] ICE in set_rtl building libgcc __muldc3 for 32-bit SPARC

[jsm28 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102133

Bug ID: 102133
   Summary: [12 Regression] ICE in set_rtl building libgcc
__muldc3 for 32-bit SPARC
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: liuhongt at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-*-*

Created attachment 51380
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51380&action=edit
preprocessed source

commit 7218c2ec365ce95f5a1012a6eb425b0a36aec6bf, "Make sure we're playing with
integral modes before call extract_integral_bit_field.", introduces the
following ICE building libgcc for 32-bit SPARC (32-bit multilib for
sparc64-linux-gnu). Compile the attached test with -m32 -O2.

during RTL pass: expand
/scratch/jmyers/glibc/many12/src/gcc/libgcc/libgcc2.c: In function '__muldc3':
/scratch/jmyers/glibc/many12/src/gcc/libgcc/libgcc2.c:1947:1: internal compiler
error: in set_rtl, at cfgexpand.c:200
 1947 | CONCAT3(__mul,MODE,3) (MTYPE a, MTYPE b, MTYPE c, MTYPE d)
  | ^~~~
0x7ccbe9 set_rtl
/scratch/jmyers/glibc/many12/src/gcc/gcc/cfgexpand.c:179
0x7cf028 set_parm_rtl(tree_node*, rtx_def*)
/scratch/jmyers/glibc/many12/src/gcc/gcc/cfgexpand.c:1401
0x98a451 assign_parm_setup_reg
/scratch/jmyers/glibc/many12/src/gcc/gcc/function.c:3401
0x98a451 assign_parms
/scratch/jmyers/glibc/many12/src/gcc/gcc/function.c:3707
0x98de2c expand_function_start(tree_node*)
/scratch/jmyers/glibc/many12/src/gcc/gcc/function.c:5163
0x7e11b9 execute
/scratch/jmyers/glibc/many12/src/gcc/gcc/cfgexpand.c:6692
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/101355] incorrect `this' in destructor calls when compiling coroutines with ubsan

[iains at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101355

--- Comment #4 from Iain Sandoe  ---
patch proposed here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578401.html

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918

--- Comment #16 from Rimvydas (RJ)  ---
(In reply to Steve Kargl from comment #15)
> I'm also the person that made these options work
> for some definition of "work", and I have always considered
> these options to be broken because of what you are re-discovering.
> The words of caution for -freal-* and family of options also
> applies to the -fdefault-* options.  I suspect much of work
> done on the intrinsics modules is done independently and
> obliviously to these options.
Statement like this implies that gfortran does *not* properly support variables
using explicit kinds like selected_real_kind(13,300) or real(kind=8) or
real(kind=16) or ISO_C_BINDING ones other than default plain REAL.  From
-ftree-dump-original dumps it is seen that even plain REAL or DOUBLE PRECISION
are assigned REAL(KIND=N) for all types, like
static real(kind=8) b[4] = {[0 ... 3]=1.0e+0};

> COMMON, EQUIVALENCE, and BOZ are not legacy features.
> These are full fledged features of modern Fortran. 
Some people still prefer to use Hollerith constants, implicit types, statement
functions, arithmetic if's, shared do terminations, fixed source form, even
PAUSE and there is nothing wrong with it.  Still, these are not related to this
PR.

> The original problem is simply another manifestation of 
> why these options should be avoided, if not removed from
> gfortran.  In your original example, you have changed the
> ABI between foo.o and bar.o, which now confuses lto.
ABI in this case can not be broken because no data is exchange between foo()
and bar(), nor libgfortran.so.5.0.0 is being recompiled.  Only thing that might
affect the runtime is:
  static integer(kind=4) options.4[7] = {2116, 4095, 0, 1, 1, 0, 31};
  _gfortran_set_options (7, &options.4[0]);
and based on
https://gcc.gnu.org/onlinedocs/gfortran/_005fgfortran_005fset_005foptions.html
these should not influence how runtime library should handle default
integer/real/logical/character types without explicit kind.

Again question is what is getting broken and what is the scope of this?  Is it
limited to LTO compilation only?  Any help to understand the actual problem
would very likely lead to a simple one line fix in the source code.

[Bug middle-end/102133] [12 Regression] ICE in set_rtl building libgcc __muldc3 for 32-bit SPARC

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102133

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug fortran/102113] parsing error in assigned goto

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102113

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,

are you going to submit your patch?

[Bug target/102125] (ARM Cortex-M3 and newer) missed optimization. memcpy not needed operations

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102125

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=91674

--- Comment #3 from Andrew Pinski  ---
I suspect PR 91674 is the same.

[Bug fortran/101349] ICE in gfc_get_descriptor_field, at fortran/trans-array.c:140

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101349

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,

are you going to submit your patch?

[Bug fortran/101327] ICE in find_array_element, at fortran/expr.c:1355

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101327

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 ---
Slightly more compact resulting code with:

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 35563a78697..dfecc3012e1 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -1337,7 +1337,9 @@ find_array_element (gfc_constructor_base base,
gfc_array_ref *ar,
   for (i = 0; i < ar->dimen; i++)
 {
   if (!gfc_reduce_init_expr (ar->as->lower[i])
- || !gfc_reduce_init_expr (ar->as->upper[i]))
+ || !gfc_reduce_init_expr (ar->as->upper[i])
+ || ar->as->upper[i]->expr_type != EXPR_CONSTANT
+ || ar->as->lower[i]->expr_type != EXPR_CONSTANT)
{
  t = false;
  cons = NULL;
@@ -1351,9 +1353,6 @@ find_array_element (gfc_constructor_base base,
gfc_array_ref *ar,
  goto depart;
}

-  gcc_assert (ar->as->upper[i]->expr_type == EXPR_CONSTANT
- && ar->as->lower[i]->expr_type == EXPR_CONSTANT);
-
   /* Check the bounds.  */
   if ((ar->as->upper[i]
   && mpz_cmp (e->value.integer,

Steve,

are you going to submit this or your version?

[Bug middle-end/102126] Wrong optimization of FP multiplication and division by 1 and -1 with -ftrapping-math when an underflow is possible

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126

--- Comment #5 from joseph at codesourcery dot com  ---
Exception traps (and thus exact underflow) are outside the scope of ISO C.  
(Some forms of alternate exception handling are described in TS 18661-5, 
which is *not* being integrated into C2x, but none of them are like 
feenableexcept; they involve lexically scoped, not dynamically scoped, 
alternate exception handling.)  Note "This specification does not require 
support for trap handlers that maintain information about the order or 
count of floating-point exceptions.", concerning a different case where 
trap handlers could observe transformations that are not otherwise 
visible.

Maybe we should split -ftrapping-math into the on-by-default flag 
concerned with the raising of exception flags, and an off-by-default flag 
concerned with actual changed-flow-of-control traps.  (That's apart from 
the question of splitting -ftrapping-math into the part concerned with 
local transformations keeping the correct set of exception flags raised by 
expressions whose results are used, and the part (largely not implemented, 
but see Marc Glisse's -ffenv-access patches from August 2020) concerned 
with treating flag raising as an actual side effect and preventing code 
movement or removal that would be valid if flag raising weren't handled as 
a side effect.)

[Bug target/102127] [12 Regression] ICE when compiling (m32) powerpc/440-mulchw-1.c since g:ff6bb9dde10ab665a35bb75527313cd9f7d52f8e

[jsm28 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127

Joseph S. Myers  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #8 from Joseph S. Myers  ---
This is probably the bug causing an ICE building GCC for soft-float powerpc
that showed up in my glibc bot.

https://sourceware.org/pipermail/libc-testresults/2021q3/008465.html

[Bug middle-end/102129] -ftrapping-math is broken or badly documented

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102129

--- Comment #2 from joseph at codesourcery dot com  ---
On Mon, 30 Aug 2021, vincent-gcc at vinc17 dot net via Gcc-bugs wrote:

> In the generated code with -O1 and above, one can see that the multiplication
> is done after g is called, even if -ftrapping-math is used (which is the
> default). This is incorrect as x * 5.0 may trap, terminating the program with 
> a
> floating-point exception, in which case g must not be executed.

It's incorrect as the function g might call fetestexcept and examine the 
floating-point exception flags raised, or feclearexcept to clear them.  
That has nothing to do with trap enablement.  Since trap enablement is 
outside the scope of ISO C, and since various processors implement aspects 
of it differently making it inherently unportable, issues that appear 
without involving enabled traps are best considered without involving such 
traps at all.

[Bug target/30336] -mtune=native is wrong when not built with gcc

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30336

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |4.5.0

--- Comment #4 from Andrew Pinski  ---
This was fixed with r0-93833 where we ignore now -march=native and/or
-mtune=native if not compiled with GCC, There were more fixes later on what
macro gets tested too.

[Bug middle-end/102126] Wrong optimization of FP multiplication and division by 1 and -1 with -ftrapping-math when an underflow is possible

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126

--- Comment #6 from joseph at codesourcery dot com  ---
Issues relating to traps being enabled are still bugs (unlike e.g. any 
issues with changing x87 rounding precision, which are definitely "don't 
do that" when it invalidates assumptions made by the compiler) - e.g. we 
have tests in the testsuite for exact underflow being handled 
appropriately by soft-fp for __float128 - but correct semantics when traps 
are enabled can't usefully be read from ISO C or any part of TS 18661, 
since trap enablement is out of scope there.

[Bug target/102107] protocol register (r12) corrupted before a tail call

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #6 from Segher Boessenkool  ---
I get (-mcpu=power10 -mabi=elfv2 -O2):

.L2:
ld 9,0(30)   # 59   [c=8 l=4]  *movdi_internal64/1
addi 1,1,112 # 124  [c=4 l=4]  *adddi3/1
.cfi_def_cfa_offset 0
li 3,0   # 63   [c=4 l=4]  *movdi_internal64/3
ld 0,16(1)   # 125  [c=8 l=4]  *movdi_internal64/1
ld 31,-8(1)  # 129  [c=8 l=4]  *movdi_internal64/1
ld 12,0(9)   # 62   [c=8 l=4]  *movdi_internal64/1
addi 9,9,8   # 60   [c=4 l=4]  *adddi3/1
std 9,0(30)  # 61   [c=4 l=4]  *movdi_internal64/0
ld 30,-16(1) # 128  [c=8 l=4]  *movdi_internal64/1
mtlr 0   # 127  [c=4 l=4]  *movdi_internal64/23
.cfi_restore 65
mtctr 12 # 103  [c=4 l=4]  *movdi_internal64/23
lwz 12,8(1)  # 126  [c=8 l=4]  *movsi_internal1/2
mtcrf 8,12   # 130  [c=4 l=4]  *mtcrfsi
.cfi_restore 72
.cfi_restore 31
.cfi_restore 30
bctr # 66   [c=4 l=4]  *sibcall_value_aixdi/1

This looks just fine.  What is wrong with your build?

[Bug fortran/101327] ICE in find_array_element, at fortran/expr.c:1355

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101327

--- Comment #3 from Steve Kargl  ---
On Mon, Aug 30, 2021 at 07:35:17PM +, anlauf at gcc dot gnu.org wrote:
> 
> Steve,
> 
> are you going to submit this or your version?
> 

I no longer have the ability to commit changes,
so I won't being submitting patches to fortran@
and gcc-patches@ for review.  I'll simply add
patches to bug reports and move on.

My current method of development:

1) git clone humble into gccx/
2) Develop a patch and test patch.
3) git diff HEAD > prXXX.diff
4) Place diff into PR.
5) Repeat 2)-4) until gccx/ tree gets messed up
6) rm -rf gccx/ and goto 1)

[Bug fortran/101349] ICE in gfc_get_descriptor_field, at fortran/trans-array.c:140

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101349

--- Comment #3 from Steve Kargl  ---
On Mon, Aug 30, 2021 at 07:31:17PM +, anlauf at gcc dot gnu.org wrote:
> 
> --- Comment #2 from anlauf at gcc dot gnu.org ---
> Steve,
> 
> are you going to submit your patch?
> 

I submitted the patch to bugzilla.  Whether
it makes it into the repository is predicated
on new volunteers stepping into gfortran world.

[Bug tree-optimization/102134] New: [12 Regression] wrong code at -O1

[zsojka at seznam dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102134

Bug ID: 102134
   Summary: [12 Regression] wrong code at -O1
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 51381
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51381&action=edit
reduced testcase

Output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c
$ ./a.out 
Aborted

$ 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-r12-3224-20210830105821-gd73c44800b5-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.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-r12-3224-20210830105821-gd73c44800b5-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210830 (experimental) (GCC)

[Bug tree-optimization/102134] [12 Regression] wrong code at -O1

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102134

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug tree-optimization/102134] [12 Regression] wrong code at -O1

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102134

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org
   Priority|P3  |P1
   Last reconfirmed||2021-08-30

--- Comment #1 from Jakub Jelinek  ---
Started with r12-3164-gb2ef23239f245871e9b35b902391f2e94a041627

[Bug fortran/101327] ICE in find_array_element, at fortran/expr.c:1355

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101327

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #3)
> I no longer have the ability to commit changes,
> so I won't being submitting patches to fortran@
> and gcc-patches@ for review.  I'll simply add
> patches to bug reports and move on.

You rarely say whether the patch regtests fine.  Would be a nice-to-have.

> My current method of development:
> 
> 1) git clone humble into gccx/
> 2) Develop a patch and test patch.
> 3) git diff HEAD > prXXX.diff
> 4) Place diff into PR.
> 5) Repeat 2)-4) until gccx/ tree gets messed up
> 6) rm -rf gccx/ and goto 1)

Probably not the most common nor most efficient workflow when using git...

Anyway, the current patch is obvious enough.  I could commit it for you.

[Bug c++/46691] Null pointer in template deduction

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46691

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:53907e20ee1fdf91163ff19b8f1dc716563e903a

commit r10-10081-g53907e20ee1fdf91163ff19b8f1dc716563e903a
Author: Paul Thomas 
Date:   Thu May 6 14:41:33 2021 +0100

Fortran: Assumed and explicit size class arrays [PR46691/99819].

2021-05-06  Paul Thomas  

gcc/fortran/ChangeLog

PR fortran/46691
PR fortran/99819
* class.c (gfc_build_class_symbol): Remove the error that
disables assumed size class arrays. Class array types that are
not deferred shape or assumed rank are given a unique name and
placed in the procedure namespace.
* trans-array.c (gfc_trans_g77_array): Obtain the data pointer
for class arrays.
(gfc_trans_dummy_array_bias): Suppress the runtime error for
extent violations in explicit shape class arrays because it
always fails.
* trans-expr.c (gfc_conv_procedure_call): Handle assumed size
class actual arguments passed to non-descriptor formal args by
using the data pointer, stored as the symbol's backend decl.

gcc/testsuite/ChangeLog

PR fortran/46691
PR fortran/99819
* gfortran.dg/class_dummy_6.f90: New test.
* gfortran.dg/class_dummy_7.f90: New test.

(cherry picked from commit a2c593009fef1564dbef2237ee71e9fd08f5361e)

[Bug fortran/99819] [9/10 Regression] ICE in gfc_defer_symbol_init, at fortran/trans-decl.c:841

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99819

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:53907e20ee1fdf91163ff19b8f1dc716563e903a

commit r10-10081-g53907e20ee1fdf91163ff19b8f1dc716563e903a
Author: Paul Thomas 
Date:   Thu May 6 14:41:33 2021 +0100

Fortran: Assumed and explicit size class arrays [PR46691/99819].

2021-05-06  Paul Thomas  

gcc/fortran/ChangeLog

PR fortran/46691
PR fortran/99819
* class.c (gfc_build_class_symbol): Remove the error that
disables assumed size class arrays. Class array types that are
not deferred shape or assumed rank are given a unique name and
placed in the procedure namespace.
* trans-array.c (gfc_trans_g77_array): Obtain the data pointer
for class arrays.
(gfc_trans_dummy_array_bias): Suppress the runtime error for
extent violations in explicit shape class arrays because it
always fails.
* trans-expr.c (gfc_conv_procedure_call): Handle assumed size
class actual arguments passed to non-descriptor formal args by
using the data pointer, stored as the symbol's backend decl.

gcc/testsuite/ChangeLog

PR fortran/46691
PR fortran/99819
* gfortran.dg/class_dummy_6.f90: New test.
* gfortran.dg/class_dummy_7.f90: New test.

(cherry picked from commit a2c593009fef1564dbef2237ee71e9fd08f5361e)

[Bug target/102127] [12 Regression] ICE when compiling (m32) powerpc/440-mulchw-1.c since g:ff6bb9dde10ab665a35bb75527313cd9f7d52f8e

[wschmidt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127

Bill Schmidt  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #9 from Bill Schmidt  ---
This should be fixed now, with commit of r12-3229.  Please reopen if any of
these failures still occur.

[Bug target/102125] (ARM Cortex-M3 and newer) missed optimization. memcpy not needed operations

[jankowski938 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102125

--- Comment #4 from Piotr  ---
mov r3, r0
ldr r0, [r0]  @ unaligned
ldr r1, [r3, #4]  @ unaligned
bx  lr

can be optimized even more 

ldr r1, [r0, #4]  @ unaligned
ldr r0, [r0]  @ unaligned
bx  lr