[Bug tree-optimization/96753] Missed optimization on modulo when left side value is known to be greater than right side value

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-08-24

--- Comment #1 from Marc Glisse  ---
We do this simplification when integer ranges tell us that x

[Bug tree-optimization/96758] New: strncmp miscompiles as memcmp

[gcc-bugs at vgkmb dot com]

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

Bug ID: 96758
   Summary: strncmp miscompiles as memcmp
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at vgkmb dot com
  Target Milestone: ---

Created attachment 49106
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49106=edit
strncmp test program

strncmp(x, y, n) == 0 generates the wrong code under -O2 when:
- n is a constant power of two
- x is a non-constant buffer of size > n with runtime content
- y is "c ? a : b" where
- c is a non-constant condition
- and a and b are constant strings with lengths < n

Actual code: equivalent to memcmp(x, y, n) == 0 but is incorrect since neither
string is guaranteed to be at least n characters long.

Expected code: strncmp library call or inlined equivalent.

Host/target: x86_64-pc-linux-gnu
OS: Fedora 32 Linux 5.7.16-200.fc32.x86_64

Reduced from case found in smartmontools-7.1 compiled by the distro provided
compiler gcc (GCC) 10.2.1 20200723 (Red Hat 10.2.1-1).

#include 
#include 

int main(int argc, char *argv[]) {
const char *s = argc > 0 ? "a" : "b";
char x[5];
char y[5] = "a\0a";
memcpy(x, y, sizeof(y));
printf("%d\n", !strncmp(x, s, 4));
return 0;
}

Compiled as "gcc -O2 test.c" this prints "0" but should print "1" (and does
without -O2).

I confirmed via gcc.godbolt.org that it was OK in 9.3 but broken in 10 onward:
https://gcc.godbolt.org/z/e37fsP

I reproduced locally on the same system with latest main branch at 87c753ac
configured and built with defaults.

Then I bisected from tag releases/gcc-9.3.0 on and found the first bad commit
27c14dbc6b (SVN r277076) whose title seems related:

PR tree-optimization/91996 - fold non-constant strlen relational
expressions

For the bisects I configured with --enable-languages=c --disable-multilib
--disable-bootstrap to speed up testing.

Please find attached preprocessed repro source for the case above. Expected
output is "1" (confirmed by compiling without -O2).

[Bug tree-optimization/96757] New: aarch64：ICE during GIMPLE pass: vect

[duanbo3 at huawei dot com]

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

Bug ID: 96757
   Summary: aarch64：ICE during GIMPLE pass: vect
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: duanbo3 at huawei dot com
  Target Milestone: ---

Hi, gcc-trunk ICEs when compiling the following testcase with -O3 on aarch64:
short
fun1(short i, short j)
{
  return i * j;
}

int 
fun(int a, int b, int c)
{
  int *v, z, k, m;
  short f, d;
  for (int i=0; i m;
z = f > k;
*v += fun1(z,b);
  }
}

a.c: In function ‘fun’:
a.c:12:1: error: non-trivial conversion in unary operation
   12 | fun(int a, int b, int c)
  | ^~~
vector(4) 
vector(4) 
mask_patt_29.18_65 = ~mask__2.17_64;
during GIMPLE pass: vect
dump file: a.c.163t.vect
a.c:12:1: internal compiler error: verify_gimple failed
0xcc4767 verify_gimple_in_cfg(function*, bool)
.././../gcc/tree-cfg.c:5491
0xb8af2b execute_function_todo
.././../gcc/passes.c:1992
0xb8be2b do_per_function
.././../gcc/passes.c:1640
0xb8be2b execute_todo
.././../gcc/passes.c:2046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Before vect pass, the main statements of this case will be optimized like：
_1 = d_10(D) > 3;
_2 = a_11(D) > m_12(D);
_18 = _1 > _2 ? _26 : 0;

At the beginning of vectorization analysis，function
vect_recog_mask_conversion_pattern processed the gimple  _18 = _1 > _2 ? _15 :
0,and produce such results:
patt_17 = _1 > _2
patt_3 = patt_17 ? _15 : 0
However, it didn't consider the situation that  _1, _2's vectype is different, 
So vectorization analysis failed with most of vector mode when examining the
statement patt_17 = _1 > _2. 
Due to  aarch64  support vectorizing with multiple vector sizes
(https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=74166aabeb7f) , in some special 
mode, like V4HImode  for this case, _1 = d_10(D) > 3 and _2 = a_11(D) > m_12(D)
had same nunits but different vectype, which make vectorization analysis
succeeded.

After that,the statement patt_29 = _1 > _2 was transformed like: 
mask_patt_29.21_72 = ~mask__2.20_71；
mask_patt_29.21_73 = mask__1.19_68 & mask_patt_29.21_72;
the vectype of mask__2.20_71  is vector(4)  ，the vectype of
mask_patt_29.21_72 is vector(4)  , which leading to the ICE.

I have prepared the following patch to fix this problem, this patch added the
identification and handling for this situation in
vect_recog_mask_conversion_pattern. With that _18 = _1 > _2 ? _15 : 0 will be
transformed to such statements:
patt_3 = () _2;
patt_17 = _1 > patt_3;
patt_20 = patt_17 ? _26 : 0;
Bootstrap and tested on both aarch64 and x86 Linux platform, no new regression
witnessed.

diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
index 03d50ec5c90..cfd6bfdede8 100644
--- a/gcc/tree-vect-patterns.c
+++ b/gcc/tree-vect-patterns.c
@@ -4395,6 +4395,40 @@ vect_recog_mask_conversion_pattern (vec_info *vinfo,
{
  tmp = vect_recog_temp_ssa_var (TREE_TYPE (rhs1), NULL);
  pattern_stmt = gimple_build_assign (tmp, rhs1);
+ tree rhs1_op0 = TREE_OPERAND (rhs1, 0);
+ tree rhs1_op1 = TREE_OPERAND (rhs1, 1);
+ if (rhs1_op0 && rhs1_op1
+ && (TREE_CODE (TREE_TYPE (rhs1_op0)) == BOOLEAN_TYPE)
+ && (TREE_CODE (TREE_TYPE (rhs1_op1)) == BOOLEAN_TYPE))
+   {
+ tree rhs1_op0_type = integer_type_for_mask (rhs1_op0, vinfo);
+ tree rhs1_op1_type = integer_type_for_mask (rhs1_op1, vinfo);
+ enum tree_code rhs1_code = gimple_assign_rhs_code (pattern_stmt);
+ if (rhs1_op0_type && rhs1_op1_type
+ && (!(TYPE_PRECISION (rhs1_op0_type)
+   == TYPE_PRECISION (rhs1_op1_type
+   {
+ if (TYPE_PRECISION (rhs1_op0_type)
+ < TYPE_PRECISION (rhs1_op1_type))
+   {
+ vectype2
+   = get_mask_type_for_scalar_type (vinfo, rhs1_op0_type);
+ if (vectype2)
+   rhs1_op1 = build_mask_conversion (vinfo, rhs1_op1,
+ vectype2,
stmt_vinfo);
+   }
+ else
+   {
+ vectype2
+   = get_mask_type_for_scalar_type (vinfo, rhs1_op1_type);
+ if (vectype2)
+   rhs1_op0 = build_mask_conversion (vinfo, rhs1_op0,
+ vectype2,
stmt_vinfo);
+   }
+ pattern_stmt = gimple_build_assign (tmp, rhs1_code,
+  

[Bug rtl-optimization/96756] [AArch64] Missed FPSR description on saturating instruction patterns

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Don't put volatile  on __read_neon_cumulative_sat  because it does NOT mean
what you think it means.  It means __read_neon_cumulative_sat  is noreturn.

Also this is expected really as GCC does NOT model vqadd_u32/fpsr.

Maybe the following is better:
static int __read_neon_cumulative_sat (uint32x2_t t) {
_ARM_FPSCR _afpscr_for_qc;
asm volatile ("mrs %0,fpsr" : "=r" (_afpscr_for_qc) : "v"(t));
return _afpscr_for_qc.b.QC;
}

  res = vqadd_u32 (op0, op1);
  if (__read_neon_cumulative_sat (res) != 1)
abort ();

[Bug rtl-optimization/96756] New: [AArch64] Missed FPSR description on saturating instruction patterns

[xiezhiheng at huawei dot com]

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

Bug ID: 96756
   Summary: [AArch64] Missed FPSR description on saturating
instruction patterns
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xiezhiheng at huawei dot com
  Target Milestone: ---
Target: aarch64

Test case:

#include 
#include 

typedef union {
  struct {
int _xxx:24;
unsigned int FZ:1;
unsigned int DN:1;
unsigned int AHP:1;
unsigned int QC:1;
int V:1;
int C:1;
int Z:1;
int N:1;
  } b;
  unsigned int word;
} _ARM_FPSCR;

static volatile int __read_neon_cumulative_sat (void) {
_ARM_FPSCR _afpscr_for_qc;
asm volatile ("mrs %0,fpsr" : "=r" (_afpscr_for_qc));
return _afpscr_for_qc.b.QC;
}

int main()
{
  uint32x2_t op0, op1, res;

  op0 = vdup_n_u32 ((uint32_t)0xfff0);
  op1 = vdup_n_u32 ((uint32_t)0x20);

  _ARM_FPSCR _afpscr_for_qc;
  asm volatile ("mrs %0,fpsr" : "=r" (_afpscr_for_qc));
  _afpscr_for_qc.b.QC = (0);
  asm volatile ("msr fpsr,%0" :  : "r" (_afpscr_for_qc));

  res = vqadd_u32 (op0, op1);
  if (__read_neon_cumulative_sat () != 1)
abort ();

  return 0;
}

Command line (GCC version 11.0): aarch64-linux-gnu-gcc test.c -O0 -o test
$ ./test
Run successfully

Command line (GCC version 11.0): aarch64-linux-gnu-gcc test.c -O2 -o test
$ ./test
Aborted (core dumped)

The test case has different results under -O0 and -O2.
In RTL phase insn
  (insn 11 10 12 2 (set (reg:V2SI 97)
(us_plus:V2SI (reg:V2SI 98)
(reg:V2SI 99))) {aarch64_uqaddv2si}
 (nil))
would be eliminated because saturating instruction patterns have no side
effect of set the FPSR register and this insn is treated as dead insn.

Reference mails:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552367.html

[Bug target/93372] cris performance regressions due to de-cc0 work

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Hans-Peter Nilsson :

https://gcc.gnu.org/g:0e6c51de8ec47bf5f0dfaabfd1898c722d0485b4

commit r11-2814-g0e6c51de8ec47bf5f0dfaabfd1898c722d0485b4
Author: Hans-Peter Nilsson 
Date:   Mon Aug 24 03:15:21 2020 +0200

reorg.c (fill_slots_from_thread): Improve for TARGET_FLAGS_REGNUM

This handles TARGET_FLAGS_REGNUM clobbering insns as delay-slot
fillers using a method similar to that in commit 33c2207d3fda,
where care was taken for fill_simple_delay_slots to allow such
insns when scanning for delay-slot fillers *backwards* (before
the insn).

A TARGET_FLAGS_REGNUM target is typically a former cc0 target.
For cc0 targets, insns don't mention clobbering cc0, so the
clobbers are mentioned in the "resources" only as a special
entity and only for compare-insns and branches, where the cc0
value matters.

In contrast, with TARGET_FLAGS_REGNUM, most insns clobber it and
the register liveness detection in reorg.c / resource.c treats
that as a blocker (for other insns mentioning it, i.e. most)
when looking for delay-slot-filling candidates.  This means that
when comparing core and performance for a delay-slot cc0 target
before and after the de-cc0 conversion, the inability to fill a
delay slot after conversion manifests as a regression.  This was
one such case, for CRIS, with random_bitstring in
gcc.c-torture/execute/arith-rand-ll.c as well as the target
libgcc division function.

After this, all known performance regressions compared to cc0
are fixed.

gcc:
PR target/93372
* reorg.c (fill_slots_from_thread): Allow trial insns that clobber
TARGET_FLAGS_REGNUM as delay-slot fillers.

gcc/testsuite:
PR target/93372
* gcc.target/cris/pr93372-47.c: New test.

[Bug c++/96720] ICE with* after include

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2020-08-23

--- Comment #2 from Andrew Pinski  ---
Can you attach the preprocessed source as it seems all.hpp comes from boost?

[Bug tree-optimization/96754] Failure to optimize strcpy+strlen to memcpy when strlen is done after strcpy

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug rtl-optimization/96755] New: ICE in final_scan_insn_1, at final.c:3073 with -O3 -march=skylake-avx512

[vsevolod.livinskij at frtk dot ru]

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

Bug ID: 96755
   Summary: ICE in final_scan_insn_1, at final.c:3073 with -O3
-march=skylake-avx512
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

>$ g++ -O3 -march=skylake-avx512 -c func.cpp
func.cpp: In function ‘void test(short unsigned int, unsigned char, long long
int)’:
func.cpp:13:1: error: could not split insn
   13 | }
  | ^
(insn 644 21 817 50 (set (reg:DI 70 k2 [orig:83 D.4406 ] [83])
(zero_extend:DI (not:SI (reg:SI 70 k2 [orig:505 b ] [505]
"func.cpp":10:18 622 {*one_cmplsi2_1_zext}
 (nil))
during RTL pass: final
func.cpp:13:1: internal compiler error: in final_scan_insn_1, at final.c:3073
0x7cf5e7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/gcc/rtl-error.c:108
0x75b978 final_scan_insn_1
/gcc/final.c:3073
0xd9b5cf final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/gcc/final.c:3152
0xd9b8c7 final_1
/gcc/final.c:2020
0xd9c298 rest_of_handle_final
/gcc/final.c:4658
0xd9c298 execute
/gcc/final.c:4736


Reproducer:
extern long var_22;
extern int arr_3[];
extern int arr_4[][20][9];
short a;
void test(unsigned short b, unsigned char e, long long g) {
  for (long c = 0; c < 20ULL; c = g)
for (short d = 0; d < 9; d++)
  for (char f = e; f < 8; f += 4) {
arr_3[f] = 0;
var_22 = ~(unsigned)b;
arr_4[c][d][f] = a;
  }
}

gcc version 11.0.0 20200823 (87c753ac241f25d222d46ba1ac66ceba89d6a200)

[Bug tree-optimization/96754] New: Failure to optimize strcpy+strlen to memcpy when strlen is done after strcpy

[gabravier at gmail dot com]

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

Bug ID: 96754
   Summary: Failure to optimize strcpy+strlen to memcpy when
strlen is done after strcpy
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

size_t f1(char *a, const char *b)
{
strcpy(a, b);
return strlen(b);
}

size_t f2(char *a, const char *b)
{
size_t sz = strlen(b);
memcpy(a, b, sz + 1);
return sz;
}

f1 can be optimized to f2. Using this intermediary form :

size_t f(char *a, const char *b)
{
size_t tmp = strlen(b);
strcpy(a, b);
return tmp;
}

Results in the optimization being done properly, but it would be nice if it was
doable even if the `strlen` wasn't done prior to the `strcpy`.

[Bug c/96747] -Wshadow accepts included extern variable shadowing

[matous-dev at criptext dot com]

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

--- Comment #2 from Martin Matous  ---
Other compiler's behavior does makes more sense, but yeah, personal opinion. In
case the patch ends up not being reverted the docs at
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wshadow should
probably be clarified about what kind of shadowing is silently ignored.

[Bug tree-optimization/96753] Missed optimization [x86-64] on modulo when left side value is known to be greater than right side value

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement
  Component|c   |tree-optimization

[Bug c/96753] New: Missed optimization [x86-64] on modulo when left side value is known to be greater than right side value

[goldstein.w.n at gmail dot com]

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

Bug ID: 96753
   Summary: Missed optimization [x86-64] on modulo when left side
value is known to be greater than right side value
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goldstein.w.n at gmail dot com
  Target Milestone: ---

uint64_t
do_mod(uint64_t x, uint64_t y) {
if(x >= y) {
__builtin_unreachable();
}
return x % y;
}

With -O3 compiles to

do_mod(unsigned long, unsigned long):
movq%rdi, %rax
xorl%edx, %edx
divq%rsi
movq%rdx, %rax
ret

given that x is known to be less than y this could be return x;

Godbolt link: https://gcc.godbolt.org/z/sfhr96

[Bug tree-optimization/96748] ICE in get_default_value, at tree-ssa-ccp.c:311

[manuel.lauss at googlemail dot com]

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

Manuel Lauss  changed:

   What|Removed |Added

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

--- Comment #3 from Manuel Lauss  ---
I can no longer reproduce it with a fresh checkout of 10.2 branch.
Closing as invalid.

[Bug lto/96752] -fwhopr feature - is it available in gcc 9.2.0

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
> But I can't use standard LTO because my project contains C and CPP files 
> which is compiled with different configuration flags.

That should not matter in new enough GCCs as GCC record the options per
function these days.

whopr mode is default in GCC 9.x and above and you don't need a special option
to enable it.

[Bug target/96744] [11 Regression] FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c execution test

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:87c753ac241f25d222d46ba1ac66ceba89d6a200

commit r11-2812-g87c753ac241f25d222d46ba1ac66ceba89d6a200
Author: H.J. Lu 
Date:   Fri Aug 21 09:42:49 2020 -0700

x86: Add target("general-regs-only") function attribute

gcc/

PR target/96744
* config/i386/i386-options.c (IX86_ATTR_IX86_YES): New.
(IX86_ATTR_IX86_NO): Likewise.
(ix86_opt_type): Add ix86_opt_ix86_yes and ix86_opt_ix86_no.
(ix86_valid_target_attribute_inner_p): Handle general-regs-only,
ix86_opt_ix86_yes and ix86_opt_ix86_no.
(ix86_option_override_internal): Check opts->x_ix86_target_flags
instead of opts->x_ix86_target_flags.
* doc/extend.texi: Document target("general-regs-only") function
attribute.

gcc/testsuite/

PR target/96744
* gcc.target/i386/pr96744-1.c: New test.
* gcc.target/i386/pr96744-2.c: Likewise.
* gcc.target/i386/pr96744-3a.c: Likewise.
* gcc.target/i386/pr96744-3b.c: Likewise.
* gcc.target/i386/pr96744-4.c: Likewise.
* gcc.target/i386/pr96744-5.c: Likewise.
* gcc.target/i386/pr96744-6.c: Likewise.
* gcc.target/i386/pr96744-7.c: Likewise.
* gcc.target/i386/pr96744-8a.c: Likewise.
* gcc.target/i386/pr96744-8b.c: Likewise.
* gcc.target/i386/pr96744-9.c: Likewise.

[Bug fortran/92959] ICE in gfc_conv_associated, at fortran/trans-intrinsic.c:8634

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #4 from Paul Thomas  ---
This was fixed on 2020-03-01. Commit
r10-6952-g7067f8c814088c1d02e40adf79a80f5ec53dbdde

I didn't have the hang of the git ChangeLog scheme at the time.

Paul

[Bug fortran/92785] expressions passed as real arguments to a dummy polymorphic argument fail with indexing error

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r11-2811-gdbc724d6d2073c7f2d1ea4497b4f9714c9b7ec3c
Author: Paul Thomas 
Date:   Sun Aug 23 15:48:36 2020 +0100

Changed to STOP 1 in unlimited_polymorphic_31.f03.

2020-08-23  Paul Thomas  

gcc/testsuite/
PR fortran/92785
* gfortran.dg/unlimited_polymorphic_31.f03: Change to stop 1.

[Bug fortran/96737] ICE when compiling module and submodule in same file with debug (-g)

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #6 from Paul Thomas  ---
(In reply to CVS Commits from comment #5)
> The master branch has been updated by Paul Thomas :
> 
> https://gcc.gnu.org/g:967454a212c7693577a1911e637c3f9f3edc7ccf
> 
> commit r11-2810-g967454a212c7693577a1911e637c3f9f3edc7ccf
> Author: Paul Thomas 
> Date:   Sun Aug 23 15:37:21 2020 +0100
> 
> Adding option -g to pr96737.f90.
> 
> 2020-08-23  Paul Thomas  
> 
> gcc/testsuite/
> PR fortran/96737
> * gfortran.dg/pr96737.f90: Add option -g.

Duuh! I forgot the -g too!

Closing.

Paul

[Bug fortran/96737] ICE when compiling module and submodule in same file with debug (-g)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:967454a212c7693577a1911e637c3f9f3edc7ccf

commit r11-2810-g967454a212c7693577a1911e637c3f9f3edc7ccf
Author: Paul Thomas 
Date:   Sun Aug 23 15:37:21 2020 +0100

Adding option -g to pr96737.f90.

2020-08-23  Paul Thomas  

gcc/testsuite/
PR fortran/96737
* gfortran.dg/pr96737.f90: Add option -g.

[Bug fortran/96737] ICE when compiling module and submodule in same file with debug (-g)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r11-2809-gc4565031c8dc6b5289e36553e5cd937a91825953
Author: Paul Thomas 
Date:   Sun Aug 23 15:34:27 2020 +0100

This patch fixes PR96737. See the explanatory comment in the testcase.

2020-08-23  Paul Thomas  

gcc/fortran
PR fortran/96737
* trans-types.c (gfc_get_derived_type): Derived types that are
used in submodules are not compatible with TYPE_CANONICAL from
any of the global namespaces.

gcc/testsuite/
PR fortran/96737
* gfortran.dg/pr96737.f90: New test.

[Bug c/96747] -Wshadow accepts included extern variable shadowing

[harald at gigawatt dot nl]

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

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #1 from Harald van Dijk  ---
This happens because environ is declared in a system header. The C frontend
warns when both declarations are not in a system header. The C++ frontend warns
when the second declaration is not in a system header.

Intuitively, the C++ frontend's behaviour makes more sense to me, but that is
just my personal opinion.

The C frontend's behaviour was changed intentionally, see
, but -Wshadow
has since been enhanced so that it no longer warns about object declarations
shadowing functions. If that later enhancement already covers all of the cases
that that initial system headers patch was meant to suppress warnings for,
perhaps the initial patch can be reverted now?

[Bug fortran/96737] ICE when compiling module and submodule in same file with debug (-g)

[vehre at gcc dot gnu.org]

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

--- Comment #3 from Andre Vehreschild  ---
Sorry, I was in a hurry to post the pr. You're right one needs to specify '-g'
to see the issue.

[Bug lto/96752] -fwhopr feature - is it available in gcc 9.2.0

[djuki.car.kv at gmail dot com]

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

--- Comment #1 from Djuki Bascarevic  ---
Created attachment 49105
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49105=edit
WHOPR diagram

[Bug lto/96752] New: -fwhopr feature - is it available in gcc 9.2.0

[djuki.car.kv at gmail dot com]

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

Bug ID: 96752
   Summary: -fwhopr feature - is it available in gcc 9.2.0
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: djuki.car.kv at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49104
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49104=edit
Patch for LTO during building gcc in MinGW

Dear GCC team,

I was very curious to explore Link-Time-Optimization in a GCC and I though it
can improve my project. I found that during linking I also need to provide the
same option which I have used during compiling. And it makes sense. But I can't
use standard LTO because my project contains C and CPP files which is compiled
with different configuration flags. So Linker complains every time when I try
to build my project. After that I found that instead of LTO, I can use Whole
Program  Optimization (-fwhopr). From my point of view, it will really solve my
problem, because the compiler will do all optimization during compiling and at
the end it will just link object files. Please look at the image which I found
in the GCC documentation.

But when I tried to compile just simple project with flag -fwhopr, the compiler
complained that -fwhopr is unknown option for its. Is this feature still part
of GCC? Maybe I didn't build my compiler well. The configuration which I have
used is:

$SRCDIR/configure --host=$host --build=$build --prefix=$prefix --target=$target
--disable-nls --enable-multilib --with-multilib-list=lp64,ilp32
--enable-languages=c,c++ --disable-decimal-float --with-sysroot=$prefix
--without-headers --disable-shared --disable-threads --enable-lto
--enable-plugin --disable-libmudflap --disable-libssp --disable-libgomp
--disable-libffi --disable-libstdcxx-pch --disable-win32-registry
'--with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-newlib --with-gcc --with-gnu-as --with-gnu-ld --with-gmp=$prefixlocal
--with-mpfr=$prefixlocal --with-mpc=$prefixlocal --with-isl=$prefixlocal
--with-zstd=$prefixlocal

But before configuration, you will need to apply the patch, which you can find
in attachment. This is only if you want to build it in Windows 10 using  MinGW
9.2.0. On Linux Debian 10, I think everything is working as expected. I have
tried to build gcc for aarch64, but I think for all other targets it is the
same.

Also, you have noticed I use ld.bfd instead ld.gold. Generally LTO is related
to the gold linker, but I found information that BFD linker also supports LTO.
I had some issues when I tried to use gold linker. I was able to compile my
project, but it didn't work. I didn't have a time to investigate more in it,
but I saw memory sections look different although I used the same linker
script. For this reason, I have tried to use BFD linker for LTO. 

Thanks for considering this message and I hope you will have some solution for
Whole Program Optimization option. Please let me know if I can assist any
further.

With best regards,
M.Eng. Filip Bascarevic

[Bug libstdc++/96751] New: overwriting libstdc++ for a default target during building libraries for armv5te/mthumb-interwork

[djuki.car.kv at gmail dot com]

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

Bug ID: 96751
   Summary: overwriting libstdc++ for a default target during
building libraries for armv5te/mthumb-interwork
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: djuki.car.kv at gmail dot com
  Target Milestone: ---

Created attachment 49103
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49103=edit
GCC configuration patch to reduce arm targets

Dear GCC team,

I noticed that during building multilib for armv5te/mthumb-interwork, libstdc++
and libsup++ are generated in a folder for a default target (arm_none_eabi/lib)
instead of arm_none_eabi/lib/armv5te/le/interwork. I think just this part of
the log file will be sufficient for describing a bug:


/bin/sh /build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/../mkinstalldirs
/build/arm-none-eabi_9.2.0/cross-gcc/arm-none-eabi/arm-none-eabi/include/c++/9.2.0/./pstl
for file in
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/algorithm_fwd.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/algorithm_impl.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/execution_defs.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/execution_impl.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/glue_algorithm_defs.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/glue_algorithm_impl.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/glue_execution_defs.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/glue_memory_defs.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/glue_memory_impl.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/glue_numeric_defs.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/glue_numeric_impl.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/memory_impl.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/numeric_fwd.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/numeric_impl.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/parallel_backend.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/parallel_backend_tbb.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/parallel_backend_utils.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/parallel_impl.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/pstl_config.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/unseq_backend_simd.h
/build/arm-none-eabi_9.2.0/gcc-9.2.0/libstdc++-v3/include/pstl/utils.h; do \
  /bin/install -c -m 644 ${file}
/build/arm-none-eabi_9.2.0/cross-gcc/arm-none-eabi/arm-none-eabi/include/c++/9.2.0/./pstl;
done
make[8]: Leaving directory
'/build/arm-none-eabi_9.2.0/arm-none-eabi/gcc/arm-none-eabi/v5te/le/interwork/libstdc++-v3/include'
make[7]: Leaving directory
'/build/arm-none-eabi_9.2.0/arm-none-eabi/gcc/arm-none-eabi/v5te/le/interwork/libstdc++-v3/include'
Making install in libsupc++
make[7]: Entering directory
'/build/arm-none-eabi_9.2.0/arm-none-eabi/gcc/arm-none-eabi/v5te/le/interwork/libstdc++-v3/libsupc++'
make[8]: Entering directory
'/build/arm-none-eabi_9.2.0/arm-none-eabi/gcc/arm-none-eabi/v5te/le/interwork/libstdc++-v3/libsupc++'
 /bin/mkdir -p
'/build/arm-none-eabi_9.2.0/cross-gcc/arm-none-eabi/arm-none-eabi/lib'
 /bin/sh ../libtool   --mode=install /bin/install -c   libsupc++.la
'/build/arm-none-eabi_9.2.0/cross-gcc/arm-none-eabi/arm-none-eabi/lib'
libtool: install: /bin/install -c .libs/libsupc++.lai
/build/arm-none-eabi_9.2.0/cross-gcc/arm-none-eabi/arm-none-eabi/lib/libsupc++.la
libtool: install: /bin/install -c .libs/libsupc++.a
/build/arm-none-eabi_9.2.0/cross-gcc/arm-none-eabi/arm-none-eabi/lib/libsupc++.a
libtool: install: chmod 644
/build/arm-none-eabi_9.2.0/cross-gcc/arm-none-eabi/arm-none-eabi/lib/libsupc++.a
libtool: install:
/build/arm-none-eabi_9.2.0/cross-gcc/arm-none-eabi/arm-none-eabi/bin/ranlib
/build/arm-none-eabi_9.2.0/cross-gcc/arm-none-eabi/arm-none-eabi/lib/libsupc++.a
--
Libraries have been installed in:
   /build/arm-none-eabi_9.2.0/cross-gcc/arm-none-eabi/arm-none-eabi/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_RUN_PATH' environment variable
 during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.

[Bug d/96153] d: struct literals have non-deterministic hash values

[ibuclaw at gdcproject dot org]

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

--- Comment #6 from Iain Buclaw  ---
The distinction between x86_64 passing and SPARC64 failing seems to be whether
the struct returns in memory, or via registers.  If via registers, alignment
holes that were filled are ignored by the caller (values are copied away from
the returned struct, so holes will not be carried over to the destination).

By that measure then, all initialization of any struct type that doesn't
satisfy identity_compare_p will require pre-filling with zeros.  There are
still some cases where this does not happen, such as in this testcase:
toHash(checked(12));

[Bug c++/96750] New: 10-12% performance decrease in benchmark going from GCC8 to GCC9/GCC10

[mattreecebentley at gmail dot com]

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

Bug ID: 96750
   Summary: 10-12% performance decrease in benchmark going from
GCC8 to GCC9/GCC10
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mattreecebentley at gmail dot com
  Target Milestone: ---

Created attachment 49102
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49102=edit
Compiler output

Have recently been working on a new version of the plf::colony container
(plflib.org) and found GCC9 was giving ~10% worse performance on average in a
given benchmark than GCC8. Further investigation found GCC10 was just as bad.

The effect is repeatable across architectures - I've tested on xubuntu, windows
running nuwen mingw, and on Core2 and Haswell CPUs, with and without
-march=native specified.

Compiler flags are: -O2;-march=native;-std=c++17

Code presented is with an absolute minimum use-case - other benchmarks have not
shown such strong performance differences - including both simpler and more
complex tests.
So I cannot reduce further, please do not ask me to do so.

The benchmark in question inserts into a container initially then iterates over
container elements repeatedly, randomly erasing and/or inserting new elements.

Compilers/environments used:
Xubuntu 20: GCC8.4, GCC9.3, GCC10.0.1
Windows 7: Nuwen mingw GCC8.2, nuwen mingw GCC9.2

The attached code output is from the Xubuntu environment.

Any questions let me know. I will help where I can, but my knowledge of
assembly is limited.

Information on code components:
Nanotimer is a ~nanosecond-precision sub-timeslice cross-platform timer.
Colony is a bucket-array-like unordered sequence container.

The attached zip contains the build logs and compiler preprocessed outputs for
GCC 8.4, 9.3 and 10.0.1

Thanks-
Mat

[Bug c++/96749] [coroutines] unexpected 'warning: statement has no effect [-Wunused-value]'

[bazhenov.dn at gmail dot com]

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

--- Comment #1 from Dmitry Bazhenov  ---
Created attachment 49101
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49101=edit
statement-has-no-effect.cpp

Code snippet revealing the problem.