[Bug tree-optimization/43401] Register not cleand correctly by acessing thru pointer

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Keywords||wrong-code

--- Comment #6 from Andrew Pinski  ---
Fixed a long time ago.

[Bug libgcc/101655] canadian compile of libgcc uses native cc as the compiler instead of the target cross compiler

[bootmgr at 163 dot com via Gcc-bugs]

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

--- Comment #11 from bootmgr at 163 dot com  ---
(In reply to Andreas Schwab from comment #10)
> In a canadian cross, you don't compile the target libraries.  They are
> already built while building the cross compiler.

Isn't this a bug?
I manually reconfigured libgcc, and it can detect x86_46-w64-mingw32-{gcc,g++}.
But I did not continue to build it.
Why can't the target library be used for Canadian cross?
I have another question. Why can't libgcc,libquadmath,libvtv and libstdc++
detect the CFLAGS,CXXFLAGS or CPPFALGS environment variable when I build cross
compiler?

[Bug target/57333] Wrong detection of LZCNT instruction, -mno-lzcnt has no effect

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> Testcase for the error:
> $ echo | gcc -dM -E - -march=amdfam10 -mno-lzcnt | grep LZCNT
> #define __LZCNT__ 1
> 
> 
> Is broken again on the trunk.

Filed PR 101685 for that.


As far as the LTO issue, it might be already fixed a different way; of course
without a testcase it is hard to say why it is broken.

[Bug target/101685] [12 Regression] -march=amdfam10 -mno-lzcnt Defines __LZCNT__

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|-march=amdfam10 -mno-lzcnt  |[12 Regression]
   |Defines __LZCNT__   |-march=amdfam10 -mno-lzcnt
   ||Defines __LZCNT__
   Target Milestone|--- |12.0
 CC||mliska at suse dot cz

[Bug target/57333] Wrong detection of LZCNT instruction, -mno-lzcnt has no effect

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|NEW |UNCONFIRMED

[Bug target/101685] New: -march=amdfam10 -mno-lzcnt Defines __LZCNT__

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

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

Bug ID: 101685
   Summary: -march=amdfam10 -mno-lzcnt Defines __LZCNT__
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

r12-36 broke -march=amdfam10 -mno-lzcnt:
if (((processor_alias_table[i].flags & PTA_ABM) != 0)
&& !TARGET_EXPLICIT_ABM_P (opts))
  {
SET_TARGET_LZCNT (opts);
SET_TARGET_POPCNT (opts);
  }

Most likely also broke -mno-popcnt too.

[Bug target/57333] Wrong detection of LZCNT instruction, -mno-lzcnt has no effect

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu
   Last reconfirmed||2021-07-30
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #5 from Andrew Pinski  ---
Testcase for the error:
$ echo | gcc -dM -E - -march=amdfam10 -mno-lzcnt | grep LZCNT
#define __LZCNT__ 1


Is broken again on the trunk.

[Bug c++/101684] Different optimization levels lead to different output results (-Wuninitialized)

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

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

--- Comment #2 from Andrew Pinski  ---
Note find_olap_engine has a similar issue too.


int64_t int_value = *(int64_t*)(data);
int32_t frac_value = *(int32_t*)((char*)data + sizeof(int64_t));
Should be:
int64_t int_value;
memcpy(_value, data, sizeof(int_value));
int32_t frac_value;
memcpy(_value, (char*)data + sizeof(int64_t), sizeof(frac_value));

[Bug c++/101684] Different optimization levels lead to different output results (-Wuninitialized)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
You are violating C/C++ aliasing rules.
You access value as a uint32_t when you stored to it as a
DecimalV2Value/__int_128_t .

Use either -fno-strict-aliasing or use memcpy inside murmur_hash3_32 to do the
read via uint32_t.

So something like:

const uint8_t* blocks = (const uint8_t*)(data + nblocks * 4);

for (int i = -nblocks; i; i++) {
uint32_t k1;
memcpy (, blocks + i*sizeof(k1), k1);

[Bug c++/101684] New: Different optimization levels lead to different output results (-Wuninitialized)

[drfeng08 at gmail dot com via Gcc-bugs]

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

Bug ID: 101684
   Summary: Different optimization levels lead to different output
results (-Wuninitialized)
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drfeng08 at gmail dot com
  Target Milestone: ---

The same code compiles as expected under O0 and gets an error under O3, the
compiler prompts a Warning (uninitialized in this function [-Wunitialized]), I
double-checked the relevant variables and it is impossible to have an
uninitialized case.

Minimal reproducible case

```
#include 
#include 
#include 
#include 

static const uint32_t ONE_BILLION = 10;

static const uint32_t MURMUR3_32_SEED = 104729;

static uint32_t rotl32(uint32_t x, int8_t r) {
return (x << r) | (x >> (32 - r));
}

static uint32_t fmix32(uint32_t h) {
h ^= h >> 16;
h *= 0x85ebca6b;
h ^= h >> 13;
h *= 0xc2b2ae35;
h ^= h >> 16;
return h;
}

// modify from
https://github.com/aappleby/smhasher/blob/master/src/MurmurHash3.cpp
static uint32_t murmur_hash3_32(const void* key, int32_t len, uint32_t seed) {
const uint8_t* data = (const uint8_t*)key;
const int nblocks = len / 4;

uint32_t h1 = seed;

const uint32_t c1 = 0xcc9e2d51;
const uint32_t c2 = 0x1b873593;
const uint32_t* blocks = (const uint32_t*)(data + nblocks * 4);

for (int i = -nblocks; i; i++) {
uint32_t k1 = blocks[i];

k1 *= c1;
k1 = rotl32(k1, 15);
k1 *= c2;

h1 ^= k1;
h1 = rotl32(h1, 13);
h1 = h1 * 5 + 0xe6546b64;
}

const uint8_t* tail = (const uint8_t*)(data + nblocks * 4);
uint32_t k1 = 0;
switch (len & 3) {
case 3:
k1 ^= tail[2] << 16;
case 2:
k1 ^= tail[1] << 8;
case 1:
k1 ^= tail[0];
k1 *= c1;
k1 = rotl32(k1, 15);
k1 *= c2;
h1 ^= k1;
};

h1 ^= len;
h1 = fmix32(h1);
return h1;
}

class DecimalV2Value {
public:
DecimalV2Value() = default;
inline bool from_olap_decimal(int64_t int_value, int64_t frac_value) {
bool success = true;
bool is_negative = (int_value < 0 || frac_value < 0);
if (is_negative) {
int_value = std::abs(int_value);
frac_value = std::abs(frac_value);
}

if (frac_value > 9) {
frac_value = 9;
success = false;
}

_value = static_cast<__int128_t>(int_value) * ONE_BILLION + frac_value;
if (is_negative) _value = -_value;

return success;
}

private:
__int128_t _value;
};

struct DecimalFindOp {
uint32_t find_olap_engine(const void* data) {
DecimalV2Value value;
int64_t int_value = *(int64_t*)(data);
int32_t frac_value = *(int32_t*)((char*)data + sizeof(int64_t));
value.from_olap_decimal(int_value, frac_value);
return murmur_hash3_32((char*), sizeof(DecimalV2Value), 0);
}
};

struct decimal12_t {
int64_t integer;
int32_t fraction;
} __attribute__((packed));

int main(int argc, char* argv[]) {
decimal12_t d12;
d12.integer = atoi(argv[0]);
d12.fraction= atoi(argv[1]);
DecimalFindOp op;
std::cout << op.find_olap_engine() << std::endl;
return 0;
}
```

> /opt/compiler/gcc-10/bin/g++ case.cpp  -Wall -std=c++11 -O3 -g
```
case.cpp: In function 'int main(int, char**)':
case.cpp:35:18: warning: 'value' is used uninitialized in this function
[-Wuninitialized]
   35 | uint32_t k1 = blocks[i];
  |  ^~
case.cpp:35:18: warning: '*((void*)& value +4)' is used uninitialized in this
function [-Wuninitialized]
case.cpp:35:18: warning: '*((void*)& value +8)' is used uninitialized in this
function [-Wuninitialized]
case.cpp:35:18: warning: '*((void*)& value +12)' is used uninitialized in this
function [-Wuninitialized]
```
> ./a.out 12 12
```
2167721464
```

if I use -O1 
> /opt/compiler/gcc-10/bin/g++ case.cpp  -Wall -std=c++11  -g
> ./a.out 12 12
output:
```
4203026776
```

[Bug debug/101669] error reading variable from debug information when compiling with -O2

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

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

Jiu Fu Guo  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #8 from Jiu Fu Guo  ---
(In reply to Andrew Pinski from comment #6)
> Hmmm, maybe https://sourceware.org/bugzilla/show_bug.cgi?id=27999

Thanks, Andrew.

Great! With the latest gdb from the trunk, it is ok. 

(gdb) b sub
Breakpoint 1 at 0xa58: file /home/guojiufu/temp/gdb.f90, line 9.
(gdb) b 17
Breakpoint 2 at 0xafc: file /home/guojiufu/temp/gdb.f90, line 17.
(gdb) r
Starting program: /home/guojiufu/temp/gdb/binutils-gdb/arg1.exe

Breakpoint 1, 0x00010a58 in sub (a=..., n=10) at
/home/guojiufu/temp/gdb.f90:9
9   subroutine sub (a, n)
(gdb) c
Continuing.

Breakpoint 2, sub (a=..., n=10) at /home/guojiufu/temp/gdb.f90:17
17write (*,*) a
(gdb) p a
$1 = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
(gdb) 

So, it seems not to be an issue from GCC, and works fine on with the latest
binutils.

Thanks all!

[Bug debug/101669] error reading variable from debug information when compiling with -O2

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Jiu Fu Guo from comment #5)
> readelf --debug-dump arg1.exe |grep readelf
> readelf: Error: Invalid location list entry type 8

DW_LLE_start_length = 0x08,

Didn't make it into binutils until 2.35:
https://sourceware.org/pipermail/binutils/2020-November/114140.html


gdb support went in at
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;f=gdb/dwarf2/loc.c;h=3112ed9799124edf4d1f9c903da0d59f5a4ca102

Which did not make it until gdb 10.0.

[Bug rtl-optimization/101683] Floating point exception for double->unsigned conversion on avx512 only

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=9651
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #3 from Andrew Pinski  ---
Simple fix:
diff --git a/gcc/rtlanal.c b/gcc/rtlanal.c
index ec7a062829c..1ff701d6d4f 100644
--- a/gcc/rtlanal.c
+++ b/gcc/rtlanal.c
@@ -3261,6 +3261,7 @@ may_trap_p_1 (const_rtx x, unsigned flags)
   break;

 case FIX:
+case UNSIGNED_FIX:
   /* Conversion of floating point might trap.  */
   if (flag_trapping_math && HONOR_NANS (XEXP (x, 0)))
return 1;

This has always been a bug .

[Bug rtl-optimization/101683] Floating point exception for double->unsigned conversion on avx512 only

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-30
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
if-conversion succeeded through noce_try_cmove_arith

[Bug rtl-optimization/101683] Floating point exception for double->unsigned conversion on avx512 only

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

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

--- Comment #1 from Andrew Pinski  ---
Trapping math is turned on by default 
I wonder why ifcvt.c is doing the cmov ...

[Bug debug/101669] error reading variable from debug information when compiling with -O2

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

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

--- Comment #6 from Andrew Pinski  ---
Hmmm, maybe https://sourceware.org/bugzilla/show_bug.cgi?id=27999

[Bug target/101683] New: Floating point exception for double->unsigned conversion on avx512 only

[bartoldeman at users dot sourceforge.net via Gcc-bugs]

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

Bug ID: 101683
   Summary: Floating point exception for double->unsigned
conversion on avx512 only
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bartoldeman at users dot sourceforge.net
  Target Milestone: ---

Created attachment 51222
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51222=edit
File to reproduce

For this code:

#define _GNU_SOURCE
#include 

int main(int argc, char **argv) {
feenableexcept(FE_INVALID);
double argcm10 = argc / -0.1;
return (unsigned)(argcm10 < 0.0 ? 0 : argcm10);
}

$ gcc -O -march=skylake-avx512 fpexcept.c -lm
$ ./a.out 
Floating point exception


the instructions
vcvttsd2usi %xmm0, %eax
vxorpd  %xmm1, %xmm1, %xmm1
vucomisd%xmm0, %xmm1
movl$0, %edx
cmova   %edx, %eax
are generated just after the division, so the conversion happens before the
comparison.
"If a converted result cannot be represented in the destination format, the
floating-point invalid exception is raised, and if this exception is masked,
the integer value 2^w – 1 is returned, where w represents the number of bits in
the destination format."

so when masked, for argcm10 = -10.0 the value 2^w-1 is discarded and all is
well, since it's < 0, but not when unmasked.

I can reproduce this issue with 9.3 as well, but not with 8.4 (the generated
code is correct for 8.4). I have not tried 11.1 yet.

Note: I found this issue with the UCX library when compiled with
-march=skylake-avx512, this example is stripped down from:
https://github.com/openucx/ucx/blob/f5362f5e6f80d930b88c44c63b4d8d71cf91d214/src/ucp/core/ucp_ep.c#L2699

[Bug debug/101669] error reading variable from debug information when compiling with -O2

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

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

--- Comment #5 from Jiu Fu Guo  ---
(In reply to Andrew Pinski from comment #4)
> What version of gdb are you using?

Tried gdb8.1/8.3/9.2 on ppc64le.
In gdb, the msg "error reading variable: dwarf2_find_location_expression:"
occurs when stopping at the breakpoint 'sub' on the tip message:

Breakpoint 1, 0x00010a58 in sub (a=, n=10) at
/home/guojiufu/temp/gdb.f90:7


readelf --debug-dump arg1.exe |grep readelf
readelf: Error: Invalid location list entry type 8
readelf: Warning: Hole and overlap detection requires adjacent view lists and
loclists.


readelf -v
GNU readelf (GNU Binutils for Ubuntu) 2.34
readelf 2.30 can also get the Error/Warning msg.


gfortran -O2 -g ~/temp/gdb.f90 -gdwarf-5 -o arg1.exe

On x86 is similar, readelf2.30/gdb8.1 can reproduce the msg at my side.

Before gcc11, need -gdwarf-5 to reproduce since we default to this dwarf
version in gcc11.

[Bug tree-optimization/45243] Non-volatile variables don't need to be constantly modified at -Os

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization

[Bug tree-optimization/33535] bitpos_of_field() returns false result base of hard coded multiplication by 8

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.6.0

--- Comment #3 from Andrew Pinski  ---
Has been fixed since r0-106604.

[Bug target/31782] Invalid assembly code on initial dollar signs

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||kerrg at ccs dot neu.edu

--- Comment #13 from Andrew Pinski  ---
*** Bug 46163 has been marked as a duplicate of this bug. ***

[Bug target/46163] nested function called $ causes assembly error

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
Dup of bug 31782.

*** This bug has been marked as a duplicate of bug 31782 ***

[Bug target/31782] Invalid assembly code on initial dollar signs

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rwxr-xr-x at gmx dot de

--- Comment #12 from Andrew Pinski  ---
*** Bug 52554 has been marked as a duplicate of this bug. ***

[Bug target/52554] Variable called $1 causes invalid asm to be generated

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #9 from Andrew Pinski  ---
Dup of bug 31782.

*** This bug has been marked as a duplicate of bug 31782 ***

[Bug target/31782] Invalid assembly code on initial dollar signs

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-29
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #11 from Andrew Pinski  ---
Confirmed.

[Bug target/72867] SSE/AVX/AVX512: incorrect optimization of VMINPS/VMAXPS at compile time

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||mathias at gaunard dot com

--- Comment #8 from Andrew Pinski  ---
*** Bug 57057 has been marked as a duplicate of this bug. ***

[Bug target/57057] Bad optimization on x86 for minps and maxps

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #3 from Andrew Pinski  ---
This was fixed for GCC 6.3+ and is a dup of bug 72867.

*** This bug has been marked as a duplicate of bug 72867 ***

[Bug target/57690] bextr sometimes used instead of shr

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #2 from Andrew Pinski  ---
6.1+ produces shr:
addq$8, %rsp
.cfi_def_cfa_offset 8
shrl$2, %eax

combine dump for GCC 6.1:
Trying 8 -> 9:
Failed to match this instruction:
(set (reg:DI 91)
(zero_extract:DI (reg:SI 87 [ _3 ])
(const_int 30 [0x1e])
(const_int 2 [0x2])))

Combine dump for 5.4:
Trying 8 -> 9:
Successfully matched this instruction:
(set (reg:DI 92 [ D.1847 ])
(zero_extract:DI (subreg:DI (reg:SI 87 [ D.1846 ]) 0)
(const_int 30 [0x1e])
(const_int 2 [0x2])))
allowing combination of insns 8 and 9
original costs 4 + 1 = 5
replacement cost 4
deferring deletion of insn with uid = 8.
modifying insn i3 9: {r92:DI=zero_extract(r87:SI#0,0x1e,0x2);clobber
flags:CC;}
  REG_UNUSED flags:CC
  REG_DEAD r87:SI
deferring rescan insn with uid = 9.
starting the processing of deferred insns
rescanning insn with uid = 9.
ending the processing of deferred insns

But I think GCC 6.1+ is producing invalid RTL in combine.  And it is no longer
matching the instruction.

I think the 6.1 behavior started with r6-2022.

[Bug c/101682] gcc incorrectly rejects C2x attributes after declaration-specifiers

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Paul Eggert from comment #2)
> Clang's warnings are not a problem here, because in clang 12.0.0 (the
> current release) __has_c_attribute(nodiscard) is false, so code like this
> works:

I was testing the trunk clang git commit
ef8c6849a235e97b8b981e0f998d430fdbd7bc2a  not the release.

[Bug target/56863] cmpnltpd recognition

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Last reconfirmed|2013-04-08 00:00:00 |2021-7-29

--- Comment #3 from Andrew Pinski  ---
(insn 7 6 8 (set (reg:V2DF 87)
(lt:V2DF (reg/v:V2DF 84 [ a ])
(reg/v:V2DF 85 [ b ]))) "/app/example.c":3:20 -1
 (nil))

(insn 8 7 9 (set (reg:V2DI 86)
(subreg:V2DI (reg:V2DF 87) 0)) "/app/example.c":3:20 -1
 (nil))

(insn 9 8 10 (set (reg:V2DI 88)
(const_vector:V2DI [
(const_int -1 [0x]) repeated x2
])) "/app/example.c":3:20 -1
 (nil))

(insn 10 9 0 (set (reg:V2DI 82 [ _2 ])
(and:V2DI (not:V2DI (reg:V2DI 86))
(reg:V2DI 88))) "/app/example.c":3:20 -1
 (nil))

[Bug c/101682] gcc incorrectly rejects C2x attributes after declaration-specifiers

[eggert at gnu dot org via Gcc-bugs]

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

--- Comment #2 from Paul Eggert  ---
Clang's warnings are not a problem here, because in clang 12.0.0 (the current
release) __has_c_attribute(nodiscard) is false, so code like this works:

#ifndef __has_c_attribute
# define __has_c_attribute(x) 0
#endif
#if __has_c_attribute (nodiscard)
# define NODISCARD [[nodiscard]]
#else
# define NODISCARD
#endif
extern NODISCARD int f (void);
extern int NODISCARD g (void);
int NODISCARD h (void);
NODISCARD extern int i (void);
NODISCARD int j (void);

Although draft C2x recommends this sort of macro preprocessing and it works
with Clang 12.0.0, this code doesn't work with GCC 11.2.0 due to its
incompatibility with draft C2x.

This is more what the original code looked like, by the way; I removed the
macro preprocessing to simplify the original bug report.

[Bug c/101682] gcc incorrectly rejects C2x attributes after declaration-specifiers

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

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

--- Comment #1 from Andrew Pinski  ---
clang rejects/warnings similar to gcc:
:2:8: error: an attribute list cannot appear here
extern [[nodiscard]] int f (void);
   ^
:3:14: error: 'nodiscard' attribute cannot be applied to types
extern int [[nodiscard]] g (void);
 ^
:4:7: error: 'nodiscard' attribute cannot be applied to types
int [[nodiscard]] h (void);
  ^

[Bug target/47186] -O2 moves invariant address load INTO loop

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Andrew Pinski  ---
Looks to be fixed in 5.1+.

5.1-7.3 produces:
.L2:
callrand
addl$4, %ebx
movl%eax, -4(%ebx)
cmpl$mike+400, %ebx
jne .L2

8.1+ produces
.L2:
callrand
movl%eax, mike(,%ebx,4)
addl$1, %ebx
cmpl$100, %ebx
jne .L2

[Bug c/101682] New: gcc incorrectly rejects C2x attributes after declaration-specifiers

[eggert at gnu dot org via Gcc-bugs]

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

Bug ID: 101682
   Summary: gcc incorrectly rejects C2x attributes after
declaration-specifiers
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at gnu dot org
  Target Milestone: ---

The grammar at the start of section 6.7 of the current C2x draft (N2596) says
that attribute specifiers may appear either before or after declaration
specifiers. Unfortunately, GCC rejects attribution specifiers after declaration
specifiers. For example, for this this source code:

extern [[nodiscard]] int f (void);
extern int [[nodiscard]] g (void);
int [[nodiscard]] h (void);
[[nodiscard]] extern int i (void);
[[nodiscard]] int j (void);

the command 'gcc -S t.c' rejects the first three lines even though they conform
to the draft standard. It allows only the last two lines. The incorrect GCC
output is:

t.c:1:1: warning: ‘nodiscard’ attribute ignored [-Wattributes]
1 | extern [[nodiscard]] int f (void);
  | ^~
t.c:1:22: error: expected identifier or ‘(’ before ‘int’
1 | extern [[nodiscard]] int f (void);
  |  ^~~
t.c:2:1: warning: ‘nodiscard’ attribute ignored [-Wattributes]
2 | extern int [[nodiscard]] g (void);
  | ^~
t.c:3:1: warning: ‘nodiscard’ attribute ignored [-Wattributes]
3 | int [[nodiscard]] h (void);
  | ^~~

This is with GCC 11.2.0, which I built myself on an RHEL 8.4 x86-64 platform.

[Bug target/47133] code size opportunity for boolean expression evaluation

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

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

--- Comment #2 from Andrew Pinski  ---
5.4+ produces:
ldr r3, [r1]
cmp r3, #9
ittte   eq
ldreq   r0, [r1, #4]
clzeq   r0, r0
lsreq   r0, r0, #5
movne   r0, #0
bx  lr

[Bug rtl-optimization/47698] CMOV accessing volatile memory with read side effect

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||regehr at cs dot utah.edu

--- Comment #9 from Andrew Pinski  ---
*** Bug 35764 has been marked as a duplicate of this bug. ***

[Bug target/35764] improper load from volatile

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0
  Known to work||4.1.2, 4.7.0
  Known to fail||4.6.4
 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #5 from Andrew Pinski  ---
Fixed in GCC 4.7.0 because this is a dup of bug 47698.

*** This bug has been marked as a duplicate of bug 47698 ***

[Bug c++/82081] Tail call optimisation of noexcept function leads to exception allowed through

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rogero at howzatt dot co.uk

--- Comment #13 from Andrew Pinski  ---
*** Bug 64181 has been marked as a duplicate of this bug. ***

[Bug ipa/64181] 'noexcept' on a lambda sometimes appears to get optimised away at -O2 (or above).

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #8 from Andrew Pinski  ---
So in the end this is a dup of bug 82081.  That is  -fno-optimize-sibling-calls
is able to workaround the problem.

*** This bug has been marked as a duplicate of bug 82081 ***

[Bug ipa/64181] 'noexcept' on a lambda sometimes appears to get optimised away at -O2 (or above).

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||8.4.0

--- Comment #7 from Andrew Pinski  ---
And works in 8.4.0.

[Bug ipa/64181] 'noexcept' on a lambda sometimes appears to get optimised away at -O2 (or above).

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||9.1.0

--- Comment #6 from Andrew Pinski  ---
Actually 9.2.0 works but not 9.1.0.

[Bug ipa/64181] 'noexcept' on a lambda sometimes appears to get optimised away at -O2 (or above).

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> Seems to be fixed in GCC 10+.  It looks like GCC is handling volatile more
> correctly now.

Note I could only get the original testcase to show the issue not the others
ones.

[Bug ipa/64181] 'noexcept' on a lambda sometimes appears to get optimised away at -O2 (or above).

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||10.0

--- Comment #4 from Andrew Pinski  ---
Seems to be fixed in GCC 10+.  It looks like GCC is handling volatile more
correctly now.

[Bug ipa/64641] ICE in get_polymorphic_call_info with C-cast to (polymorphic) object-reference

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||4.8.5
  Known to fail||4.9.0, 4.9.1, 4.9.2, 4.9.3,
   ||4.9.4
 Resolution|--- |FIXED
   Keywords||ice-on-valid-code
   Target Milestone|--- |5.0
 Status|NEW |RESOLVED

--- Comment #3 from Andrew Pinski  ---
Fixed in GCC 5.  It fails for me on x86_64-linux-gnu for all of the 4.9.x
series.

[Bug middle-end/101679] triplicate warning offset outside bounds of constant string

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

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

--- Comment #2 from Martin Sebor  ---
For the code in comment #1, the first warning is issued from the front end, the
second one from the Gimplifier, and the last one just before expansion.  The
first one still has the right location.  The second one has the location of the
call because that's what's being folded.  The third one has no location because
it's being issued for a STRING_CST so the code substitutes input_location.

[Bug middle-end/101679] triplicate warning offset outside bounds of constant string

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

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

Martin Sebor  changed:

   What|Removed |Added

Summary|duplicate warning offset|triplicate warning offset
   |outside bounds of constant  |outside bounds of constant
   |string  |string

--- Comment #1 from Martin Sebor  ---
An even better example of the same problem.  It also illustrates how the
warning location gets progressively worse:

$ cat a.c && gcc -S -Wall a.c 
const char s[0] = { };

int f (void)
{
  return __builtin_strlen (s);
}
a.c: In function ‘f’:
a.c:5:28: warning: offset ‘0’ outside bounds of constant string
[-Warray-bounds]
5 |   return __builtin_strlen (s);
  |^
a.c:1:12: note: ‘s’ declared here
1 | const char s[0] = { };
  |^
a.c:5:10: warning: offset ‘0’ outside bounds of constant string
[-Warray-bounds]
5 |   return __builtin_strlen (s);
  |  ^~~~
a.c:1:12: note: ‘s’ declared here
1 | const char s[0] = { };
  |^
a.c:3:5: warning: offset ‘0’ outside bounds of constant string [-Warray-bounds]
3 | int f (void)
  | ^
a.c:1:12: note: ‘s’ declared here
1 | const char s[0] = { };
  |^

[Bug c++/67033] [c++11] template argument invalid for integral constant expression beginning with address-of expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #2)
> Confirmed.
> 
> Testcase from PR56428:

This is a different issue overall related to PMF rather than to addresses, I
filed PR 101681 for that.

(In reply to Ed Catmur from comment #1)
> template class X {};
> int i;
> X<> x1;  // OK
> X<(&(i))> x2;  // OK since C++11
> template class Y : X {};  // OK since C++11 if !b
> X x3; // OK since C++1z

GCC 6+ does the correct thing for the testcase in comment #1 so closing.

[Bug c++/101681] New: PMF comparison to nullptr is not considered a constexpr

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

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

Bug ID: 101681
   Summary: PMF comparison to nullptr is not considered a
constexpr
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 55004, 101603
  Target Milestone: ---

Take:
template  struct Z { };

struct C
{
void f();
Z<::f == nullptr> z;
};
 CUT ---
This should be accepted in C++11 or newer.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603
[Bug 101603] [meta-bug] pointer to member functions issues

[Bug c++/101603] [meta-bug] pointer to member functions issues

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-07-29

--- Comment #1 from Andrew Pinski  ---
.

[Bug c++/89781] Misleading error messages when initializing a static data member in-class

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-29
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
Confirmed, the error message definitely can be improved.

[Bug c++/86970] Rejected constexpr expression involving lambdas and inheritance, "use of this in a constant expression"

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||9.4.0
  Known to work||10.0

--- Comment #3 from Andrew Pinski  ---
Seems fixed in GCC 10+.

[Bug c++/101680] [9/10 Regression] spurious error: use of ‘this’ in a constant expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|spurious error: use of  |[9/10 Regression] spurious
   |‘this’ in a constant|error: use of ‘this’ in a
   |expression  |constant expression
  Known to work||8.5.0
   Keywords||rejects-valid
  Known to fail||10.1.0

--- Comment #1 from Andrew Pinski  ---
Seems fixed in GCC 11.
But fails in 10.3.0 and was working in GCC 8.5.0.

[Bug middle-end/168] Spurious signed/unsigned comparison warning

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #6)
> fixed on the mainline (20030614) by:
> 
> I do not think this should fixed for 3.3 since this an adittional feature.

r0-50598

[Bug c++/101680] New: spurious error: use of ‘this’ in a constant expression

[mu11 at yahoo dot com via Gcc-bugs]

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

Bug ID: 101680
   Summary: spurious error: use of ‘this’ in a constant expression
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mu11 at yahoo dot com
  Target Milestone: ---

g++ issues a spurious error for the following test case:

$ cat t.cpp
template auto f1(ARGS &&...);

template
struct F { };

template
struct K { };

template
struct N {
  using i = typename T::i;
  struct M { };
  static void S(typename F, 1>::template A<2> m) { }
  void f2() {
#ifdef BUG
f1::S, int>(this->t);
#else
f1(this->t);
#endif
  }
};

% g++ -c -std=c++17 t.cpp
% 

% g++ -c -DBUG -std=c++17 t.cpp
t.cpp: In member function ‘void N::f2()’:
t.cpp:16:14: error: use of ‘this’ in a constant expression
   16 | f1::S, int>(this->t);
  |  ^

[Bug testsuite/101517] Some testcases were lost when tree-ssa was merged

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

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

--- Comment #3 from Andrew Pinski  ---
Created attachment 51221
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51221=edit
Patch which adds them back

This is the patch which I am testing.

[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #12 from Jürgen Reuter  ---
(In reply to Iain Sandoe from comment #11)

> > 1. Update to XCode 12.5.1 (which apparently exists, but I don't know if it
> > has the fixes?)
> 
> not yet checked - but if someone has time I'd like to know ;)
>
> 
> a) was hoping for a fix [does anyone know if 12.5.1 fixes?]
> 

I just checked with XCode 12.5.1, nothing fixed yet, the problem persists.

[Bug fortran/101101] ICE in gfc_build_array_type, at fortran/trans-types.c:1391

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2021-07-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

Workaround: use

  class(t) :: x(:)

[Bug ipa/101382] function declarations with identical asm label aliasing a target function does not compile with -flto

[fparzefall at pjrcorp dot com via Gcc-bugs]

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

--- Comment #2 from Fabian Parzefall  ---
I am wondering whether LTO is wrong or the default handling when not using LTO
is wrong. As I understand it, the assembly that is generated in this case is
correct. The documentation of GNU as even states:

You may .set a symbol many times in the same assembly provided that the
values given to the symbol are constants. [1]

If I read it right, it is acceptable to even define the symbol multiple times
with different values. From a compiler perspective however in the above code
snippet, x is being defined twice, first through b's and then through c's alias
attribute. In this case, this is harmless, but gcc does not even complain if
the alias of one of them is changed to some different function with an entirely
different signature.

I don't see a technical reason, why GCC should not emit an error here when
symbols with the same asm label are defined twice within a single TU. Either
both declaration are identical, so one of them can be removed, or they differ,
which is probably undefined behavior. Please correct me, if I miss the obvious.

Of course existing code would break (including some code in glibc), so I am not
suggesting this is how this should be fixed. Maybe there could be a warning
when the same asm symbol is defined twice?


[1] https://sourceware.org/binutils/docs/as/Set.html

[Bug target/65568] ptrmem8.C:9:9: internal compiler error: in build_ptrmemfunc, at cp/typeck.c:7940

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||vladimir.kokovic at gmail dot 
com

--- Comment #3 from Andrew Pinski  ---
*** Bug 97825 has been marked as a duplicate of this bug. ***

[Bug testsuite/97825] internal compiler error: in build_ptrmemfunc, at cp/typeck.c:9199

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Target||x86_64-w64-mingw32
 Resolution|--- |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
Dup of bug 65568.

*** This bug has been marked as a duplicate of bug 65568 ***

[Bug target/65568] ptrmem8.C:9:9: internal compiler error: in build_ptrmemfunc, at cp/typeck.c:7940

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |NEW

[Bug target/65572] ptrmem5.C:7:26: internal compiler error: in gimplify_expr, at gimplify.c:8629

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||vladimir.kokovic at gmail dot 
com

--- Comment #3 from Andrew Pinski  ---
*** Bug 97824 has been marked as a duplicate of this bug. ***

[Bug testsuite/97824] internal compiler error: in gimplify_expr, at gimplify.c:14531

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
Dup of bug 65572.

*** This bug has been marked as a duplicate of bug 65572 ***

[Bug c++/65573] 13908.C:20:33: internal compiler error: in cp_build_addr_expr_1, at cp/typeck.c:5527

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||vladimir.kokovic at gmail dot 
com

--- Comment #3 from Andrew Pinski  ---
*** Bug 97826 has been marked as a duplicate of this bug. ***

[Bug testsuite/97826] internal compiler error: in cp_build_addr_expr_1, at cp/typeck.c:6453

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of bug 65573.

*** This bug has been marked as a duplicate of bug 65573 ***

[Bug libfortran/98076] Increase speed of integer I/O

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|11.3|---

--- Comment #3 from anlauf at gcc dot gnu.org ---
Not a regression, so removing target milestone.

[Bug fortran/98411] [10/11/12 Regression] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[10/11] Pointless: Array|[10/11/12 Regression]
   |larger than |Pointless: Array larger
   |‘-fmax-stack-var-size=’,|than
   |moved from stack to static  |‘-fmax-stack-var-size=’,
   |storage for main program|moved from stack to static
   |variables   |storage for main program
   ||variables

--- Comment #13 from anlauf at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #12)

Hi Tobias,

> The -frecursive flag is fine - but highly misleading, until reading the
> gfortran manual.
> I think the last sentence should be something like:
> 
> "Consider increasing the ‘-fmax-stack-var-size=’ limit (or use -frecursive,
> which implies unlimited -fmax-stack-var-size) - or change the code to use an
> ALLOCATABLE array. If the variable is never accessed concurrently, this
> warning can be ignored; in this case, the variable could also be declared
> with the SAVE attribute."

that should be easier to understand.  Do you want to take over this PR?

I still have the patch from comment#9 in my tree, fixing comment#0.
However, IIRC my debugging sessions had cases where we miss setting
an implicit save.  Unfortunately, those particular testcases are lost.

As a reminder: Fortran 2018:8.5.16(4) has:

"A variable, common block, or procedure pointer declared in the scoping unit
of a main program, module, or submodule implicitly has the SAVE attribute,
which may be confirmed by explicit specification. If a common block has the
SAVE attribute in any other kind of scoping unit, it shall have the SAVE
attribute in every scoping unit that is not of a main program, module, or
submodule."

As a minimal solution we could combine the patch in comment#9 with the
textual change from comment#12 and defer the handling of implicit save.

[Bug rtl-optimization/14319] incorrect optimization of union of structs with common initial sequences

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu.org

--- Comment #19 from Andrew Pinski  ---
*** Bug 43495 has been marked as a duplicate of this bug. ***

[Bug testsuite/43495] gcc.c-torture/execute/20000603-1.c fails with -fpic/-fPIC

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||
 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from Andrew Pinski  ---
Just going to make this as a dup of bug 14319.

*** This bug has been marked as a duplicate of bug 14319 ***

[Bug testsuite/45068] g++.dg/debug/dwarf2/nested-2.C failed on Linux/ia64

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Fixed long time ago.

[Bug testsuite/37628] gcc.c-torture/execute/pr35456.c is not generic

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-29
   Severity|normal  |enhancement
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Maybe we should add an signed_zero target and run the tests that used signed
zeros only on those targets. Though I don't think anyone will be doing this any
time soon as most targets are IEEE targets.

Confirmed.

[Bug testsuite/16230] Spurious test failures with --disable-static

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
libgcj was removed in GCC 7 so closing as fixed.

[Bug testsuite/101517] Some testcases were lost when tree-ssa was merged

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2021-07-29

--- Comment #2 from Andrew Pinski  ---
I will take care of this.

[Bug fortran/100651] [9/10/11/12 Regression] Weird memory corruption with multiple triggers

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

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

Iain Sandoe  changed:

   What|Removed |Added

Summary|Weird memory corruption |[9/10/11/12 Regression]
   |with multiple triggers  |Weird memory corruption
   ||with multiple triggers

--- Comment #6 from Iain Sandoe  ---
(In reply to Matt Thompson from comment #5)

Thanks for the additional checks.

> $ ./a.out
>  opt_string.F90 122 T
>  opt_string.F90 123   7
>  err_msg: foo bar
> 
> and NAG 7.0_7048 does:
> 
> $ ./a.out
>  opt_string.F90 122 T
>  opt_string.F90 123 7
>  err_msg: foo bar

Then, this is indeed a regression:

gcc-5.5:
 /source/test/fortran/pr100651.F90 122 T
 /source/test/fortran/pr100651.F90 123   32727
 err_msg: foo bar

gcc-6-5;
 /source/test/fortran/pr100651.F90 122 T
 /source/test/fortran/pr100651.F90 123   32767
 err_msg: foo barH\?

gcc-7.5
 /source/test/fortran/pr100651.F90 122 T
 /source/test/fortran/pr100651.F90 123   32767
 err_msg: foo barH\?

gcc8.5:
 /source/test/fortran/pr100651.F90 122 T
 /source/test/fortran/pr100651.F90 123  1569183428
t(23248,0x106ee05c0) malloc: can't allocate region
*** mach_vm_map(size=140734762573824) failed (error code=3)
t(23248,0x106ee05c0) malloc: *** set a breakpoint in malloc_error_break to
debug
Operating system error: Cannot allocate memory
Memory allocation failure in xrealloc

Error termination. Backtrace:
#0  0x106659f9d
.. etc.

[Bug tree-optimization/101641] Bogus redundant store removal

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #5 from Martin Uecker  ---
(In reply to Richard Biener from comment #3)
>
> What we know from the union read is that the dynamic type is either the
> union type (so the read can pun) or the dynamic type is the union member
> type (then the read cannot pun).  6.5/7 allows accesses using
> "an aggregate or union type that includes [a type compatible with the
> effective
> type of the object]".  Though the 'aggregate' case appears quite odd to me,
> does it really allow 'int i; struct { float f; int i; } *p =  float x =
> p->f;'?  

I do not think this is meant to work as the
read is using an lvalue of type float and
that is not covered by the rules.

I believe that the aggregate case is meant for
the case where sub objects are modified as part of
struct/union assignment (i.e. when the lvalue used
for the access is of struct/union type).

But the rules could be interpreted to allow:

int i; struct { float f; int i; } *p = 
int j = p->i;

which I think should not be allowed.

[Bug middle-end/101679] New: duplicate warning offset outside bounds of constant string

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

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

Bug ID: 101679
   Summary: duplicate warning offset outside bounds of constant
string
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Only one instance of -Warray-bounds should be reported the access below but GCC
issues two.  The warning is issued from c_strlen() with the first instance
during lowering and the second during (or just before) expansion.  The first
instance calls suppress_warning(arg, OPT_Warray_bounds) which is checked again
before issuing the second instance by calling warning_suppressed_p (arg,
OPT_Warray_bounds).  The problem is that the first time arg is an ADDR_EXPR but
VAR_DECL the second.  Stripping the ADDR_EXPR and disabling the warning for its
operand is not a solution because it would disable warnings for invalid uses of
the same operand in other statements, both in the same function or (for global
variables) in others.

$ cat a.c && gcc -S -Wall a.c 
const char s0[0] = { };

char* f (char *d)
{
  return __builtin_strcpy (d, s0);
}

a.c: In function ‘f’:
a.c:5:31: warning: offset ‘0’ outside bounds of constant string
[-Warray-bounds]
5 |   return __builtin_strcpy (d, s0);
  |   ^~
a.c:1:12: note: ‘s0’ declared here
1 | const char s0[0] = { };
  |^~
a.c:5:10: warning: offset ‘0’ outside bounds of constant string
[-Warray-bounds]
5 |   return __builtin_strcpy (d, s0);
  |  ^~~~
a.c:1:12: note: ‘s0’ declared here
1 | const char s0[0] = { };
  |^~

[Bug c/24293] Undefined behaviour not diagnosed with -fsyntax-only

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||hristo at venev dot name

--- Comment #8 from Andrew Pinski  ---
*** Bug 63878 has been marked as a duplicate of this bug. ***

[Bug c/63878] Variables of incomplete type can be defined with -fno-fat-lto-objects

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #4 from Andrew Pinski  ---
So this has been fixed since GCC 6 by PR 24293 so closing as a dup.

*** This bug has been marked as a duplicate of bug 24293 ***

[Bug c/24293] Undefined behaviour not diagnosed with -fsyntax-only

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug fortran/100651] Weird memory corruption with multiple triggers

[matthew.thompson at nasa dot gov via Gcc-bugs]

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

--- Comment #5 from Matt Thompson  ---
Iain,

The Linux system would be SUSE Linux Enterprise Server 12 SP3. The macOS system
is macOS 11.5.1.

On the Linux machine, I can confirm the error with (I only have some versions
of GCC available):

* 8.3.0
* 9.2.0
* 10.1.0
* 11.1.0

On the macOS where I just built 11.2.0, I see the same crash.

Now, with 7.4.0 and 6.5.0 (can only test on Linux), I don't get the run-time
crash. Instead, I believe it works...sort of? To wit:

$ ./a.out
 opt_string.F90 122 T
 opt_string.F90 123   10922
 err_msg: foo bar, err_msg: foo bar, err_msg: foo bar, err_msg: foo bar,
err_msg: foo bar, err_msg: foo bar, err_msg: foo bar, err_msg: foo bar,
err_msg: foo bar, err_msg: foo bar, err_msg: foo bar, err_msg: foo bar,
err_msg: foo bar, err_msg: foo bar, err_msg: foo bar, err_msg: foo bar,
err_msg: foo bar,...

That last bit goes on for a while. This isn't the intended behavior. Intel
2021.3 does:

$ ./a.out
 opt_string.F90 122 T
 opt_string.F90 123   7
 err_msg: foo bar

and NAG 7.0_7048 does:

$ ./a.out
 opt_string.F90 122 T
 opt_string.F90 123 7
 err_msg: foo bar

We are unsure why GNU is doing this...recursive-like behavior? It's not like
the routine is called in a loop!

[Bug c/60139] Imprecise column number for -pedantic on non-computable initializer element

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||edwin+bugs at etorok dot eu

--- Comment #4 from Andrew Pinski  ---
*** Bug 37187 has been marked as a duplicate of this bug. ***

[Bug c/37187] please provide a way to treat -pedantic as warning when using -Werror

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.0
 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from Andrew Pinski  ---
So this was fixed in GCC 5 because it is an exact dup of bug 60139.

*** This bug has been marked as a duplicate of bug 60139 ***

[Bug c/97882] [8/9/10/11 Regression] Segmentation Fault on improper redeclaration of function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #9 from Andrew Pinski  ---
*** Bug 89932 has been marked as a duplicate of this bug. ***

[Bug target/89932] ICE in must_pass_in_stack_var_size_or_pad, at calls.c:5824

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

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

--- Comment #4 from Andrew Pinski  ---
Actually this one has been fixed while PR 67694 has not.
THis is a dup of bug 97882.

*** This bug has been marked as a duplicate of bug 97882 ***

[Bug objc/67694] ICE on returning undefined enum in must_pass_in_stack_var_size_or_pad

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2017-08-09 00:00:00 |2021-7-29
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=97882
  Component|target  |objc
   Keywords||error-recovery

--- Comment #3 from Andrew Pinski  ---
Related to PR 97882 but this one still happens.

[Bug c/97882] [8/9/10/11 Regression] Segmentation Fault on improper redeclaration of function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dpotapov at gmail dot com

--- Comment #8 from Andrew Pinski  ---
*** Bug 92428 has been marked as a duplicate of this bug. ***

[Bug c/92428] Crash on conflicting types

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||11.0
 Status|UNCONFIRMED |RESOLVED
   Keywords||ice-on-invalid-code
 Resolution|--- |DUPLICATE
  Known to fail||4.1.2

--- Comment #3 from Andrew Pinski  ---
Fixed by the patch which fixed PR 97882.

*** This bug has been marked as a duplicate of bug 97882 ***

[Bug c/101171] [10 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:3006

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||changochen1 at gmail dot com

--- Comment #10 from Andrew Pinski  ---
*** Bug 93574 has been marked as a duplicate of this bug. ***

[Bug c/93574] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:2925

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
Dup of bug 101171.

*** This bug has been marked as a duplicate of bug 101171 ***

[Bug c/101171] [10 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:3006

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||doko at debian dot org

--- Comment #9 from Andrew Pinski  ---
*** Bug 97892 has been marked as a duplicate of this bug. ***

[Bug c/97892] [10/11/12 Regression] ICE in tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:2946

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
Dup of bug 101171.

*** This bug has been marked as a duplicate of bug 101171 ***

[Bug tree-optimization/71538] Missing removal of null pointer check

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Ever confirmed|0   |1
   Last reconfirmed||2021-07-29
 Status|UNCONFIRMED |NEW

--- Comment #5 from Andrew Pinski  ---
(In reply to sasho648 from comment #4)
> More *shocking* example will be:
> 
> struct tx { int a[6], b[6]; } *f();
> 
> void (main)() 
> {
>   int *p = f()->b;
> 
>   if(p == NULL)
>   printf("What?"); 
> }
> 

This one works with GCC 10+.

The first one is still not implemented.
The cast is removed early:
<;
So it might be hard to implement.

Confirmed

[Bug testsuite/101678] New: [12 regression] many fortran errors afterr r12-2553

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

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

Bug ID: 101678
   Summary: [12 regression] many fortran errors afterr r12-2553
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:a3b350f1799a1c0f9e2ece5b817a537fe42f0d2d, r12-2553

FAIL: gfortran.dg/ISO_Fortran_binding_1.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_1.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_1.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gfortran.dg/ISO_Fortran_binding_1.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_1.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_10.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_10.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_10.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_10.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gfortran.dg/ISO_Fortran_binding_10.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_10.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_11.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_11.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_11.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_11.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gfortran.dg/ISO_Fortran_binding_11.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_11.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_12.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_12.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_12.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_12.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gfortran.dg/ISO_Fortran_binding_12.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_12.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_15.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_15.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_15.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_15.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gfortran.dg/ISO_Fortran_binding_15.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_15.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_16.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_16.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_16.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_16.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gfortran.dg/ISO_Fortran_binding_16.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_16.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_17.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_17.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_17.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_17.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gfortran.dg/ISO_Fortran_binding_17.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_17.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_18.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_18.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_18.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_18.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gfortran.dg/ISO_Fortran_binding_18.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_18.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_3.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_3.f90   -O1  (test for excess errors)
FAIL: 

[Bug fortran/101627] List-directed read with trailing characters after quotes

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-07-29
   Priority|P3  |P4
 Ever confirmed|0   |1

--- Comment #2 from kargl at gcc dot gnu.org ---
Here a correct patch, which has been regression tested.


diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 8cc7ddbe8e2..b551f2b9843 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -1258,7 +1258,7 @@ read_character (st_parameter_dt *dtp, int length
__attribute__ ((unused)))
  done:
   c = next_char (dtp);
  done_eof:
-  if (is_separator (c) || c == EOF)
+  if (quote == '"' || quote == '\'' || is_separator (c) || c == EOF)
 {
   unget_char (dtp, c);
   eat_separator (dtp);

[Bug debug/101669] error reading variable from debug information when compiling with -O2

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

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

--- Comment #4 from Andrew Pinski  ---
What version of gdb are you using?

[Bug middle-end/101671] pr83510 fails with -Os because threader confuses -Warray-bounds

[aldyh at redhat dot com via Gcc-bugs]

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

--- Comment #2 from Aldy Hernandez  ---
Yeah, that would be great.  Thanks!

On Thu, Jul 29, 2021 at 6:05 PM msebor at gcc dot gnu.org
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101671
>
> Martin Sebor  changed:
>
>What|Removed |Added
> 
>  CC||msebor at gcc dot gnu.org
>Last reconfirmed||2021-07-29
>Keywords||diagnostic
> Summary|pr83510 fails because   |pr83510 fails with -Os
>|threader confuses   |because threader confuses
>|-Warray-bounds  |-Warray-bounds
>  Ever confirmed|0   |1
>  Status|UNCONFIRMED |NEW
>
> --- Comment #1 from Martin Sebor  ---
> Confirmed.  I've extracted the test case that fails from the bigger test.
> Rather than xfailing the whole test I think it would be better to split out
> just the failing case and/or xfail just that assertion.  Unless you expect the
> others to start failing too due to some changes you still have planned?
>
> $ cat a.c && gcc -Os -S -Wall a.c
> extern int f (void);
> extern void sink (unsigned int);
>
> unsigned int a[10];
>
> static unsigned int g (int i, int j)
> {
>   if (i == 9)
> return j;
>   else if (i == 10)
> return a[i];// no warning here
>   return 0;
> }
>
> void test_g (int j)
> {
>   for (int i = 0; i < 10; i++)
> {
>   if (f ())
> sink (g (i, j));
> }
> }
>
> static unsigned int h (int i, int j)
> {
>   switch (i)
> {
> case 9:
>   return j;
> case 10:
>   return a[i];  // { dg-bogus "-Warray-bounds" }
> }
>   return 0;
> }
>
> void test_h (int j)
> {
>   for (int i = 0; i < 10; i++)
> {
>   if (f ())
> sink (h (i, j));
> }
> }
> In function ‘h’,
> inlined from ‘test_h’ at a.c:41:2:
> a.c:31:15: warning: array subscript 10 is above array bounds of ‘unsigned
> int[10]’ [-Warray-bounds]
>31 |   return a[i];  // { dg-bogus "-Warray-bounds" }
>   |  ~^~~
> a.c: In function ‘test_h’:
> a.c:4:14: note: while referencing ‘a’
> 4 | unsigned int a[10];
>   |  ^
>
> --
> You are receiving this mail because:
> You reported the bug.
>

[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:2f6bdd51cfe15403085b69c133065ebda4af9bb9

commit r12-2600-g2f6bdd51cfe15403085b69c133065ebda4af9bb9
Author: Martin Sebor 
Date:   Thu Jul 29 10:11:18 2021 -0600

Xfail just the failing assertion and correct target.

Related to:
PR middle-end/101674 - gcc.dg/uninit-pred-9_b.c fails after jump threading
rewrite

gcc/testsuite:
PR middle-end/101674
* gcc.dg/uninit-pred-9_b.c: Xfail just the failing assertion and
correct target.

[Bug c++/101670] Internal compiler error with concepts

[joeloser93 at gmail dot com via Gcc-bugs]

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

Joe Loser  changed:

   What|Removed |Added

 CC||joeloser93 at gmail dot com

--- Comment #1 from Joe Loser  ---
Here's a simple workaround using concepts directly:

```
template  concept Complete = requires(T t) { sizeof(t); };
template  concept Incomplete = !Complete;
template  struct S {};

struct A;
S s1;

struct A {};
S s2;
```



See it live at https://gcc.godbolt.org/z/MjKoM8dP6

[Bug fortran/100651] Weird memory corruption with multiple triggers

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu,
   ||x86_64-apple-darwin
   Last reconfirmed||2021-07-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #4 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #3)
> could you please:
> 
> * identify the linux and macOS platforms affected (add to target in the BZ
> here) 
> 
> * identify if this is a regression (i.e. does 8.5 work as expected?)
>  we adjust the title to read [N,M,O Regression blah blah] if that is so.

NM.. I checked it - it fails for at least gcc5.5+ on Darwin and 8.3+ on Linux
(so not a regression - but the fortran folks probably should look at it).

(disclaimer: I didn't read the code - just tested that it failed on several
systems)

[Bug middle-end/101671] pr83510 fails with -Os because threader confuses -Warray-bounds

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   Last reconfirmed||2021-07-29
   Keywords||diagnostic
Summary|pr83510 fails because   |pr83510 fails with -Os
   |threader confuses   |because threader confuses
   |-Warray-bounds  |-Warray-bounds
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Sebor  ---
Confirmed.  I've extracted the test case that fails from the bigger test. 
Rather than xfailing the whole test I think it would be better to split out
just the failing case and/or xfail just that assertion.  Unless you expect the
others to start failing too due to some changes you still have planned?

$ cat a.c && gcc -Os -S -Wall a.c
extern int f (void);
extern void sink (unsigned int);

unsigned int a[10];

static unsigned int g (int i, int j)
{
  if (i == 9)
return j;
  else if (i == 10)
return a[i];// no warning here
  return 0;
}

void test_g (int j)
{
  for (int i = 0; i < 10; i++)
{
  if (f ())
sink (g (i, j));
}
}

static unsigned int h (int i, int j)
{
  switch (i)
{
case 9:
  return j;
case 10:
  return a[i];  // { dg-bogus "-Warray-bounds" }
}
  return 0;
}

void test_h (int j)
{
  for (int i = 0; i < 10; i++)
{
  if (f ())
sink (h (i, j));
}
}
In function ‘h’,
inlined from ‘test_h’ at a.c:41:2:
a.c:31:15: warning: array subscript 10 is above array bounds of ‘unsigned
int[10]’ [-Warray-bounds]
   31 |   return a[i];  // { dg-bogus "-Warray-bounds" }
  |  ~^~~
a.c: In function ‘test_h’:
a.c:4:14: note: while referencing ‘a’
4 | unsigned int a[10];
  |  ^