[Bug c/93631] internal compiler error: in gimple_ca ll_arg, at gimple.h:3258

[changochen1 at gmail dot com]

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

--- Comment #1 from Yongheng Chen  ---
POC:
---
int f2 ( int x [ strcmp ( ) ] , int b ) { return c - b ;
 }
 int ( * f1 ( int a , enum E2 { E = -2 , F , G , H }
 b ) ) ( int c , int b ) { if ( a != b ) return f2 ;
 return 0 ;
 }
 int main ( ) { int ( * ( * p ) ( int a , int b ) ) ( int c , int d ) = f1 ;
 return ( * ( * p ) ( 0 , 2 ) ) ( 2 , 2 ) ;
 }
---

[Bug c/93631] New: internal compiler error: in gimple_ca ll_arg, at gimple.h:3258

[changochen1 at gmail dot com]

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

Bug ID: 93631
   Summary: internal compiler error: in gimple_ca ll_arg, at
gimple.h:3258
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: changochen1 at gmail dot com
  Target Milestone: ---

POC:
---
---

Run command:
---
gcc -o poc poc.c
---

Gcc version:
---
gcc (GCC) 10.0.1 20200208 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
---

Stack dump:
---
internal compiler error: in gimple_ca
ll_arg, at gimple.h:3258
1 | int f2 ( int x [ strcmp ( ) ] , int b ) { return c - b ;
  | ^~
0x696d12 gimple_call_arg
../../gcc/gimple.h:3258
0x69ae3a gimple_call_arg
../../gcc/tree.h:3799
0x69ae3a gimple_call_arg
../../gcc/gimple.h:3266
0x69ae3a gimple_fold_builtin_string_compare
../../gcc/gimple-fold.c:2382
0xafbc7d gimple_fold_builtin
../../gcc/gimple-fold.c:3966
0xafbc7d gimple_fold_call
../../gcc/gimple-fold.c:4481
0xafd2f3 fold_stmt_1
../../gcc/gimple-fold.c:5152
0x169fc97 lower_stmt
../../gcc/gimple-low.c:388
0x169f7f2 lower_sequence
../../gcc/gimple-low.c:217
0x169f7f2 lower_gimple_bind
../../gcc/gimple-low.c:474
0x16a08f9 lower_function_body
../../gcc/gimple-low.c:110
0x16a08f9 execute
../../gcc/gimple-low.c:195
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
---

[Bug c++/93630] Multi-dimensional array initialization converts empty raw strings to NULL

[rodrigorivascosta at gmail dot com]

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

--- Comment #4 from Rodrigo Rivas  ---
Reproduced with 9.1 and 9.2 here:

https://godbolt.org/z/ZeEsuc

Trunk seems immune, though. Maybe it is already fixed there?

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

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

--- Comment #140 from Peter Bisroev  ---
(In reply to EML from comment #138)
> I think you need the patch from comment 63 as well

Hi EML, I apologize, was meant to respond to you directly but put everything in
one response under comment#139 to keep everything together.

Thanks!

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

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

--- Comment #139 from Peter Bisroev  ---
(In reply to dave.anglin from comment #137)
> You need to at least apply patch from comment#72.  This fixes regression
> from 4.7.x.  You should also
> consider the last patch set from The Written Word.  It was stated that it's
> possible to get a full bootstrap
> with it although there are issues.

(In reply to dave.anglin from comment #138)
> I think you need the patch from comment 63 as well

Thank you for the suggestions Dave. I have applied patch from comment#72 and
the behavior did not change. With default make command:
  gmake -j8 bootstrap \
STAGE1_CFLAGS="-D_XOPEN_SOURCE_EXTENDED" \
STAGE1_CXXFLAGS="-D_XOPEN_SOURCE_EXTENDED"

I get PCREL21B errors during linking as were shown previously. When using -Os
with STAGE1_CFLAGS and STAGE1_CXXFLAGS I get internal compiler error as
described in my comment#135.

I also took a look at the last patch set in attachment 46623 from The Written
Word in comment#94 as you have suggested. It actually contains the patches that
you have already mentioned:
- the patch from comment#72 in r214747-regression.patch
- the patch from comment#63 in PR60465-regression.patch

So I applied this entire patch set and with default make command as above, I
get exactly the same thing as before, PCREL21B errors during linking of stage1.
If I compile stage 1 with -Os or -O2 I get internal compiler error as described
above. However my ICEs seem to happen at a different stage of compilation than
what has been reported already.

It is essentially this command:
  /home/pbisroev/src/build/./gcc/xgcc \
-B/home/pbisroev/src/build/./gcc/ \
-xc -nostdinc /dev/null -S -o /dev/null \
-fself-test=/home/pbisroev/src/gcc-8.3.0/gcc/testsuite/selftests 

Which eventually calls cc1 that ICEs:
  /home/pbisroev/src/build/./gcc/cc1 -quiet -nostdinc -v \
-iprefix /home/pbisroev/src/build/gcc/../lib/gcc/ia64-hp-hpux11.31/8.3.0/ \
-isystem /home/pbisroev/src/build/./gcc/include \
-isystem /home/pbisroev/src/build/./gcc/include-fixed \
/dev/null -quiet -dumpbase null -auxbase-strip /dev/null \
-version \
-fself-test=/home/pbisroev/src/gcc-8.3.0/gcc/testsuite/selftests \
-o /dev/null

I am not sure how these selftests work yet but will take a look into them to
see if we can reproduce a reliable minimal test case. However this is what I
see in GDB for now:

(gdb) r
Starting program: /home/pbisroev/src/build/./gcc/cc1 -quiet -nostdinc -iprefix
/home/pbisroev/src/build/gcc/../lib/gcc/ia64-hp-hpux11.31/8.3.0/ -isystem
/home/pbisroev/src/build/./gcc/include -isystem
/home/pbisroev/src/build/./gcc/include-fixed /dev/null -quiet -dumpbase null
-auxbase-strip /dev/null -version
-fself-test=/home/pbisroev/src/gcc-8.3.0/gcc/testsuite/selftests
GNU C17 (GCC) version 8.3.0 (ia64-hp-hpux11.31)
compiled by GNU C version 4.7.4, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C17 (GCC) version 8.3.0 (ia64-hp-hpux11.31)
compiled by GNU C version 4.7.4, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 6ad5ed57899a8ef4c993d4479438

Program received signal SIGSEGV, Segmentation fault
  si_code: 1 - SEGV_MAPERR - Address not mapped to object.
0x79e7a40 in  ()
(gdb) bt
#0  0x79e7a40 in  ()
warning: Attempting to unwind past bad PC 0x79e7a40 
#1  0x6c81c20 in
vector_builder::try_npatterns(unsigned
int)+0x2a0 ()
#2  0x6c821d0 in vector_builder::finalize()
   +0x390 ()
#3  0x59e9b70:0 in tree_vector_builder::build()+0x30 ()
#4  0x5a69240:0 in  ()
#5  0x5a8b6b0:0 in selftest::tree_c_tests()+0x7b0 ()
#6  0x642a510:0 in selftest::run_tests()+0x190 ()
#7  0x52e68e0:0 in toplev::run_self_tests()+0x60 ()
#8  0x52e8760:0 in toplev::main(int,char**)+0x1be0 ()
#9  0x64d4eb0:0 in main+0x70 ()
(gdb)


Thanks!
--peter

[Bug c++/93630] Multi-dimensional array initialization converts empty raw strings to NULL

[rodrigorivascosta at gmail dot com]

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

--- Comment #3 from Rodrigo Rivas  ---
(In reply to Jakub Jelinek from comment #1)
> Can't reproduce, neither with 9.x, nor trunk, nor various revisions in
> between, different optimization levels etc.  I get '' in all places where it
> should be.
> What exact g++ version are you using, what exact target, what exact g++
> options?

I'm using an up-to-date x64 ArchLinux:
* `g++ --version` reports 9.2.0 (packaged as gcc-9.2.0-4) [1]
* `ld --version` reports 2.33.1 (packaged as binutils-2.33.1-2)

I'm using just `g++ test.cpp`, that will be the x86_64-unknown-linux-gnu
target. I tried also with different optimizations: -O0 -O1, -O2, -O3, -Os,
-Ofast... all the same results.

I've also tried with `-m32`, no changes. I happen to have installed
mingw-w64-gcc version 9.1.0, and running the EXE with Wine, and it also
reproduces the issue.

Doing what Andrew Pinski suggests, adding `-no-pie` changes nothing either.

To discard a weird binutils, I've run the compiler with `g++ -O0 --no-pie
test.cpp -S` and it gives:

.file   "test.cpp"
.text
.section.rodata
.LC0:
.string "AA"
.LC1:
.string "AB"
.LC2:
.string "BA"
.LC3:
.string ""
.LC4:
.string "XX"
.align 32
.type   _ZL5group, @object
.size   _ZL5group, 72
_ZL5group:
.quad   .LC0
.quad   .LC1
.zero   8
.quad   .LC2
.zero   16
.quad   .LC3
.quad   .LC3
.quad   .LC4
...

Even in the assembly, you can see how the NULL pointers creep into the array.

Adding the option `-x c` to the above command to force C produces instead:

.file   "test.cpp"
.text
.globl  group
.section.rodata
.LC0:
.string "AA"
.LC1:
.string "AB"
.LC2:
.string ""
.LC3:
.string "BA"
.LC4:
.string "XX"
.align 32
.type   group, @object
.size   group, 72
group:
.quad   .LC0
.quad   .LC1
.quad   .LC2
.quad   .LC3
.quad   .LC2
.quad   .LC2
.quad   .LC2
.quad   .LC2
.quad   .LC4
...


1: Details at:
https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/gcc
It looks like there are no distro-specific C++ patches, only a few for D.

[Bug c++/93630] Multi-dimensional array initialization converts empty raw strings to NULL

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Can you try -no-pie also?

Also what version of the linker (binutils) you are using?
since the string constants will be in a mergable section, they will be merged
together and used only location.  I wonder if binutils is not messing up ...

[Bug c++/93630] Multi-dimensional array initialization converts empty raw strings to NULL

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-02-07
 Ever confirmed|0   |1

[Bug c++/93630] Multi-dimensional array initialization converts empty raw strings to NULL

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Can't reproduce, neither with 9.x, nor trunk, nor various revisions in between,
different optimization levels etc.  I get '' in all places where it should be.
What exact g++ version are you using, what exact target, what exact g++
options?

[Bug testsuite/93619] aarch64 target testsuite is so broken with -mcpu=*

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Most likely aarch64.exp should do what mips.exp did back in 2008 with
g:c05854ec7da5f0e343c2387b0ca46bd55741f73e .

[Bug target/92518] [10 regression] ppc rounding tests fail after r278207

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Target|powerpc64-linux-gnu |powerpc64*-linux-gnu
 Status|RESOLVED|REOPENED
 CC||segher at gcc dot gnu.org
   Host|powerpc64-linux-gnu |powerpc64*-linux-gnu
 Resolution|DUPLICATE   |---
  Build|powerpc64-linux-gnu |powerpc64*-linux-gnu

--- Comment #4 from seurer at gcc dot gnu.org ---
The fix for pr92529 does not fix these.

What changed is some of the instructions generated.  For example, in
gcc.target/powerpc/ppc-round.c

round_double_uint:
.LFB2:
.cfi_startproc
fctiwuz 1,1
addi 9,1,-16
stfiwx 1,0,9
ori 2,2,0
lfiwzx 1,0,9
fcfid 1,1
blr

became

round_double_uint:
.LFB5:
.cfi_startproc
fctiwz 1,1
addi 9,1,-16
stfiwx 1,0,9
ori 2,2,0
lfiwax 1,0,9
fcfid 1,1
blr

They both apparently work (albeit aren't close to optimal).  So I think the
solution here is to update the expected instruction counts and maybe make a
TODO somewhere to see if the generated code could be made better.

[Bug c++/92947] Parenthesized aggregate initialization doesn't work with the library types it's supposed to work with

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Fixed.

[Bug c++/92947] Parenthesized aggregate initialization doesn't work with the library types it's supposed to work with

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

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

commit r10-6519-gac6eaa55a5199196ea0a25763114ce05333a14d3
Author: Marek Polacek 
Date:   Fri Feb 7 14:44:25 2020 -0500

c++: Fix paren init of aggregates in unevaluated context [PR92947]

When I implemented C++20 parenthesized initialization of aggregates
I introduced this bogus cp_unevaluated_operand check, thus disabling
this feature in unevaluated context.  Oop.

Removing the check turned up another bug: I wasn't checking the
return value of digest_init.  So when constructible_expr called
build_new_method_call_1 to see if we can construct one type from
another, it got back a bogus INIT_EXPR that looked something like
*(struct T &) 1 = <<< error >>>.  But that isn't the error_mark_node,
so constructible_expr thought we had been successful in creating the
ctor call, and it gave the wrong answer.  Covered by paren-init17.C.

PR c++/92947 - Paren init of aggregates in unevaluated context.
* call.c (build_new_method_call_1): Don't check
cp_unevaluated_operand.  Check the return value of digest_init.

* g++.dg/cpp2a/paren-init21.C: New test.

[Bug c++/93630] New: Multi-dimensional array initialization converts empty raw strings to NULL

[rodrigorivascosta at gmail dot com]

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

Bug ID: 93630
   Summary: Multi-dimensional array initialization converts empty
raw strings to NULL
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rodrigorivascosta at gmail dot com
  Target Milestone: ---

Hello!

Consider the following C++ code:

```
#include 

struct Data
{
const char *text;
};

const struct Data group[3][3] = 
{
{
{"AA"}, 
{"AB"}, 
{""}, 
},
{
{"BA"}, 
{""}, 
{""}, 
},
{
{""}, 
{""}, 
{"XX"}, 
},
};

int main()
{
for (int i = 0; i < 3; ++i)
for (int j = 0; j < 3; ++j)
{
printf("'%s'\n", group[i][j].text);
}
return 0;
}
```

I'd expect to print the strings as they are in the code. Instead it prints:
'AA'
'AB'
'(null)'
'BA'
'(null)'
'(null)'
''
''
'XX'

That is, the trailing empty strings of each subarray are compiled as if they
were NULL.

Compiling it as C instead does print the expected output, as does with clang++-

[Bug c++/92947] Parenthesized aggregate initialization doesn't work with the library types it's supposed to work with

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch, rejects-valid

--- Comment #5 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00461.html

[Bug c++/93629] A completely non-sensical requires-clause is accepted

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Seems to have been fixed yesterday.

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

[Bug c++/92517] [10 Regression] ICE on incorrect syntax involving requires and decltype

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #5 from Jonathan Wakely  ---
*** Bug 93629 has been marked as a duplicate of this bug. ***

[Bug c++/93629] New: A completely non-sensical requires-clause is accepted

[ville.voutilainen at gmail dot com]

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

Bug ID: 93629
   Summary: A completely non-sensical requires-clause is accepted
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

Test:

template 
void f() requires b && true && && && && && && &&  






false {}

Compiles fine. Trying to call the function is diagnosed, though:
error: use of function 'void f() requires  

Perhaps we should be a tad stricter at parse time?

[Bug c++/92654] [8/9 Regression] internal compiler error: in lookup_template_class_1

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] |[8/9 Regression] internal
   |internal compiler error: in |compiler error: in
   |lookup_template_class_1 |lookup_template_class_1

--- Comment #11 from Jason Merrill  ---
Fixed for GCC 10 so far.

[Bug libstdc++/93628] New: ranges::equal_to doesn't work for types convertible to function pointers

[redi at gcc dot gnu.org]

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

Bug ID: 93628
   Summary: ranges::equal_to doesn't work for types convertible to
function pointers
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

using F = void();
static_assert(std::equality_comparable_with);

struct S {
  constexpr operator F*() const { return nullptr; }
};

void operator!=(S const&, S const&) {}

// concept not satisfied because operator!= returns void
static_assert(!std::equality_comparable_with);

// but S can be compared using == via conversion to F*
static_assert(S{} == S{});

// so these should be valid:
static_assert(std::ranges::equal_to{}(S{}, S{}));
static_assert(!std::ranges::not_equal_to{}(S{}, S{}));


The problem is that our implementation of BUILTIN-PTR-CMP(T, ==, U) checks for
conversion to void*, which isn't possible for function pointers. There's no
type that all function pointers are implicitly convertible.

This might not be implementable without a new built-in.

[Bug c++/92654] [8/9/10 Regression] internal compiler error: in lookup_template_class_1

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:1e042b396e2a84e3ee17bc52def1bf241cb7d248

commit r10-6517-g1e042b396e2a84e3ee17bc52def1bf241cb7d248
Author: Jason Merrill 
Date:   Fri Feb 7 10:31:30 2020 -0500

c++: Fix use of local in constexpr if.

extract_local_specs wasn't finding the mention of 'an' as a template
argument because we weren't walking into template arguments.  So here I
changed cp_walk_subtrees to do so--only walking into template arguments in
the spelling of the type or expression, not any hidden behind typedefs. 
The
change to use typedef_variant_p avoids looking through typedefs spelled
with
'typedef' as well as those spelled with 'using'.  And then I removed some
now-redundant code for walking into template arguments in a couple of
walk_tree callbacks.

PR c++/92654
* tree.c (cp_walk_subtrees): Walk into type template arguments.
* cp-tree.h (TYPE_TEMPLATE_INFO_MAYBE_ALIAS): Use typedef_variant_p
instead of TYPE_ALIAS_P.
* pt.c (push_template_decl_real): Likewise.
(find_parameter_packs_r): Likewise.  Remove dead code.
* error.c (find_typenames_r): Remove dead code.

[Bug demangler/92797] cplus_demangle() produces huge amount of output (on trunk)

[ibuclaw at gcc dot gnu.org]

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

--- Comment #7 from ibuclaw at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #6)
> (In reply to ibuclaw from comment #4)
> > At what point does the D demangler kick in?  It should only attempt to parse
> > symbols that begin with '_D'.
> 
> Huh? D mangles symbols also starting with _Z.  Why do you think D uses _D?

https://dlang.org/spec/abi.html#name_mangling

Maybe we're talking about two different things, and I got cc'd in incorrectly.

[Bug middle-end/323] optimized code gives strange floating point results

[joseph at codesourcery dot com]

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

--- Comment #217 from joseph at codesourcery dot com  ---
On Fri, 7 Feb 2020, vincent-gcc at vinc17 dot net wrote:

> According to https://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#bug_status
> the possible status are UNCONFIRMED, CONFIRMED and IN_PROGRESS. I think that
> the correct one is CONFIRMED.

That's generic Bugzilla documentation that's not relevant to the custom 
GCC configuration of bug states, which is documented at 
 (we also have NEW and ASSIGNED 
not CONFIRMED and IN_PROGRESS).  SUSPENDED is accurate for a bug that is 
explicitly known to be hard and not being worked on, for reasons other 
than waiting for further information from the submitter.  It's completely 
correct for this bug, which should be left as SUSPENDED unless someone 
decides to work on it and so changes it to ASSIGNED with themselves as 
assignee.

[Bug c/82318] -fexcess-precision=standard has no effect on a libm function call

[bugdal at aerifal dot cx]

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

--- Comment #7 from Rich Felker  ---
I'll inquire about it. Note that F.6 already requires this for C functions; the
loophole is just that the implementation itself does not inherently have to
consist of C functions.

If it's determined that C won't require the library functions not bound to IEEE
operations to return values representable in their nominal type, then GCC needs
to be aware of whether the target libc can be expected to do so, and if not, it
needs to, as a special case, assume there might be excess precision in the
return value, so that (double)retval==retval can't be assumed to be true in the
optimizer.

Note that such an option would be nice to have anyway, for arbitrary functions,
since it's necessary for being able to call code that was compiled with
-fexcess-precision=fast from code that can't accept the
non-conforming/optimizer-unsafe behavior and safely use the return value. It
should probably be an attribute, with a flag to set the global default. For
example, __attribute__((__returns_excess_precision__)).

[Bug demangler/92797] cplus_demangle() produces huge amount of output (on trunk)

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to ibuclaw from comment #4)
> At what point does the D demangler kick in?  It should only attempt to parse
> symbols that begin with '_D'.

Huh? D mangles symbols also starting with _Z.  Why do you think D uses _D?

[Bug demangler/92797] cplus_demangle() produces huge amount of output (on trunk)

[tim.ruehsen at gmx dot de]

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

--- Comment #5 from Tim Ruehsen  ---
(In reply to ibuclaw from comment #4)
> At what point does the D demangler kick in?  It should only attempt to parse
> symbols that begin with '_D'.

There is a reproducer attached. See my initial comment on how to use it.

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

[joseph at codesourcery dot com]

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

--- Comment #10 from joseph at codesourcery dot com  ---
This has nothing to do with 84717.  The present bug is simply invalid; GCC 
is acting as specified in the C standard for excess precision.  84717 is 
arguably a legitimate issue about lack of documentation for an extension 
(albeit an extension taken from an old TR).

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[elowe at elowe dot com]

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

--- Comment #138 from EML  ---
I think you need the patch from comment 63 as well

[Bug middle-end/323] optimized code gives strange floating point results

[manu at gcc dot gnu.org]

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

--- Comment #216 from Manuel López-Ibáñez  ---
(In reply to Vincent Lefèvre from comment #215)
> According to https://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#bug_status
> the possible status are UNCONFIRMED, CONFIRMED and IN_PROGRESS. I think that
> the correct one is CONFIRMED.

Those are not the main policies. They are here:
https://gcc.gnu.org/bugs/management.html

fields.html needs to be updated some day to match the actual fields used by GCC
(there is no CONFIRMED status, there is NEW) and the above policies.

This is one of those bugs that it is so broad, controversial and noisy that
almost no active developer is going to look at it. Bugs don't get fixed because
they are NEW. There are 6979 NEW bug reports right now and many of them will
never get fixed (1300 of them are more than 10 years old).

My humble suggestion for those interested in floating-point issues in GCC would
be to create self-contained specific bugs with minimised reproducible
testcases, a clear analysis of what GCC is doing wrong, what GCC should be
doing instead, and suggestions on how it could be fixed. If the bug just says
some variation of "optimized code gives strange floating point results", it
will end up here and probably nobody will ever look at it.

For Rich's specific bug report, the relevant discussion is in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323#c127 and the expected fix is
known: Implement -fexcess-precision=standard for C++ as it was done for C.
Perhaps it would be useful to create a new PR that blocks this one that
analyses what needs to be done towards that specific goal, collects testcases,
etc. The main issue is not that this PR is not in the developers' radar. All
GCC developers working on the C/C++ FEs and optimizers are aware of the
infamous PR323 and of the solution suggested in comment 127.

The issue is simply that no one working on the C++ FE has the time or
motivation to implement -fexcess-precision=standard. If you are interested in
that, just study this email:
https://gcc.gnu.org/ml/gcc-patches/2008-11/msg00105.html and do for C++ the
same steps that Joseph did C.

[Bug c/82318] -fexcess-precision=standard has no effect on a libm function call

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
Do you have any reference to a proposal to that effect?  The current 
wording in N2454 regarding this says "IEC 60559 requires operations with 
specified operand and result formats.  Therefore, math functions that are 
bound to IEC 60559 operations (see table above) must remove any extra 
range and precision from arguments or results." - and glibc already 
implements that (on 32-bit x86, don't know the state for m68k) for the 
limited subset of library functions that are bound to such operatons, as 
well as dealing with the cases where excess range may be involved, as 
previously noted.  But most functions are not bound to an IEEE operation 
and so are not covered by that requirement.

[Bug d/91666] _builtin function no work with GDC

[ibuclaw at gcc dot gnu.org]

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ibuclaw at gcc dot gnu.org

--- Comment #1 from ibuclaw at gcc dot gnu.org ---
Either the function signature on MinGW-W64 is untranslatable into valid D, or
the gcc.builtins module is not imported in any of the code paths that are
enabled by MinGW.

It's most likely to be the latter.

[Bug middle-end/93627] New: inconsistencies between sprintf and strcpy overflow warnings

[msebor at gcc dot gnu.org]

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

Bug ID: 93627
   Summary: inconsistencies between sprintf and strcpy overflow
warnings
   Product: gcc
   Version: 10.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: ---

-Wformat-overflow diagnoses sprintf calls that might overflow the destination
based solely on the size of the array where the string argument to a %s
directive is stored, as in f() below.  (-Wformat-truncation then diagnoses the
possible truncation of the argument.)

But -Wstringop-overflow doesn't diagnose the equivalent potential overflow in
calls to strcpy (and -Wstringop-truncation likewise doesn't diagnose the
truncation in calls to strncpy -- its interpretation of truncation is different
from -Wformat-truncation: a missing nul rather than cutting off the trailing
part of the source string).

This is inconsistent and probably not terribly helpful to users, especially
when they're dealing with a warning for code that's in reality safe (but GCC
doesn't see it).

$ cat z.c && gcc -O2 -S -Wall -Wextra -Wpedantic z.c
char a[8], b[16];

void f (void)
{
  __builtin_sprintf (a, "%s", b);// -Wformat-overflow
}

void fn (void)
{
  __builtin_snprintf (a, sizeof a, "%s", b); // -Wformat-truncation
}


void g (void)
{
  __builtin_strcpy (a, b);   // missing warning
}

void gn (void)
{
  __builtin_strncpy (a, b, sizeof a - 1);// no warning (?)
  a[sizeof a - 1] = 0;
}
z.c: In function ‘f’:
z.c:5:26: warning: ‘%s’ directive writing up to 15 bytes into a region of size
8 [-Wformat-overflow=]
5 |   __builtin_sprintf (a, "%s", b);// -Wformat-overflow
  |  ^~   ~
z.c:5:3: note: ‘__builtin_sprintf’ output between 1 and 16 bytes into a
destination of size 8
5 |   __builtin_sprintf (a, "%s", b);// -Wformat-overflow
  |   ^~
z.c: In function ‘fn’:
z.c:10:37: warning: ‘%s’ directive output may be truncated writing up to 15
bytes into a region of size 8 [-Wformat-truncation=]
   10 |   __builtin_snprintf (a, sizeof a, "%s", b); // -Wformat-truncation
  | ^~   ~
z.c:10:3: note: ‘__builtin_snprintf’ output between 1 and 16 bytes into a
destination of size 8
   10 |   __builtin_snprintf (a, sizeof a, "%s", b); // -Wformat-truncation
  |   ^

[Bug demangler/92797] cplus_demangle() produces huge amount of output (on trunk)

[ibuclaw at gcc dot gnu.org]

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

--- Comment #4 from ibuclaw at gcc dot gnu.org ---
At what point does the D demangler kick in?  It should only attempt to parse
symbols that begin with '_D'.

[Bug target/93588] Vectorized load followed by FMA pessimizes on Haswell from version 8.1

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
It is because load/store costs of vector registers for register allocator
are too low.  This patch fixes it:

diff --git a/gcc/config/i386/x86-tune-costs.h
b/gcc/config/i386/x86-tune-costs.h
index c73917e5a62..54b9dad932c 100644
--- a/gcc/config/i386/x86-tune-costs.h
+++ b/gcc/config/i386/x86-tune-costs.h
@@ -2574,9 +2574,9 @@ struct processor_costs core_cost = {
   {6, 6},  /* cost of storing MMX registers
   in SImode and DImode */
   2, 2, 4, /* cost of moving XMM,YMM,ZMM register
*/
-  {6, 6, 6, 6, 12},/* cost of loading SSE registers
+  {6, 6, 6, 10, 20},   /* cost of loading SSE registers
   in 32,64,128,256 and 512-bit */
-  {6, 6, 6, 6, 12},/* cost of storing SSE registers
+  {6, 6, 6, 12, 24},   /* cost of storing SSE registers
   in 32,64,128,256 and 512-bit */
   6, 6,/* SSE->integer and
integer->SSE moves */
   /* End of register allocator costs.  */

[Bug c++/93625] inline specifier in a friend function declaration

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This was changed for C++11 by
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#281 and is a DR
against C++03 as well.

[Bug c++/93625] inline specifier in a friend function declaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-07
 Ever confirmed|0   |1

[Bug fortran/93599] [9/10 regression] Bug in fortran asynchronous I/O wait function

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-07
 Ever confirmed|0   |1

--- Comment #2 from Thomas Koenig  ---
valgrind --tool=helgrind yields

==17870== Thread #1: lock order "0x5BB51F8 before 0x5BB5300" violated
==17870== 
==17870== Observed (incorrect) order is: acquisition of lock at 0x5BB5300
==17870==at 0x4C357CB: pthread_cond_wait_WRK (hg_intercepts.c:1209)
==17870==by 0x4C368D0: pthread_cond_wait@* (hg_intercepts.c:1230)
==17870==by 0x4169D9: __gthread_cond_wait (gthr-default.h:865)
==17870==by 0x4169D9: _gfortrani_async_wait (async.c:467)
==17870==by 0x404B20: _gfortran_st_rewind (file_pos.c:440)
==17870==by 0x402974: MAIN__ (in /home/ig25/Krempel/Rewind/a.out)
==17870==by 0x402A79: main (in /home/ig25/Krempel/Rewind/a.out)
==17870== 
==17870==  followed by a later acquisition of lock at 0x5BB51F8
==17870==at 0x4C329CC: mutex_lock_WRK (hg_intercepts.c:909)
==17870==by 0x4C368A4: pthread_mutex_lock (hg_intercepts.c:925)
==17870==by 0x4169AC: __gthread_mutex_lock (gthr-default.h:749)
==17870==by 0x4169AC: _gfortrani_async_wait (async.c:467)
==17870==by 0x404B20: _gfortran_st_rewind (file_pos.c:440)
==17870==by 0x402974: MAIN__ (in /home/ig25/Krempel/Rewind/a.out)
==17870==by 0x402A79: main (in /home/ig25/Krempel/Rewind/a.out)
==17870== 
==17870== Required order was established by acquisition of lock at 0x5BB51F8
==17870==at 0x4C329CC: mutex_lock_WRK (hg_intercepts.c:909)
==17870==by 0x4C368A4: pthread_mutex_lock (hg_intercepts.c:925)
==17870==by 0x41651F: __gthread_mutex_lock (gthr-default.h:749)
==17870==by 0x41651F: _gfortrani_enqueue_data_transfer_init (async.c:369)
==17870==by 0x40B87C: data_transfer_init (transfer.c:3246)
==17870==by 0x402828: MAIN__ (in /home/ig25/Krempel/Rewind/a.out)
==17870==by 0x402A79: main (in /home/ig25/Krempel/Rewind/a.out)
==17870== 
==17870==  followed by a later acquisition of lock at 0x5BB5300
==17870==at 0x4C329CC: mutex_lock_WRK (hg_intercepts.c:909)
==17870==by 0x4C368A4: pthread_mutex_lock (hg_intercepts.c:925)
==17870==by 0x41654E: __gthread_mutex_lock (gthr-default.h:749)
==17870==by 0x41654E: _gfortrani_enqueue_data_transfer_init (async.c:376)
==17870==by 0x40B87C: data_transfer_init (transfer.c:3246)
==17870==by 0x402828: MAIN__ (in /home/ig25/Krempel/Rewind/a.out)
==17870==by 0x402A79: main (in /home/ig25/Krempel/Rewind/a.out)
==17870== 
==17870==  Lock at 0x5BB51F8 was first observed
==17870==at 0x4C3680D: pthread_mutex_init (hg_intercepts.c:787)
==17870==by 0x415FB3: __gthread_mutex_init_function (gthr-default.h:733)
==17870==by 0x415FB3: _gfortrani_init_async_unit (async.c:247)
==17870==by 0x4054FE: _gfortrani_new_unit (open.c:666)
==17870==by 0x405CEC: already_open (open.c:720)
==17870==by 0x405CEC: _gfortran_st_open (open.c:897)
==17870==by 0x4027DA: MAIN__ (in /home/ig25/Krempel/Rewind/a.out)
==17870==by 0x402A79: main (in /home/ig25/Krempel/Rewind/a.out)
==17870==  Address 0x5bb51f8 is 40 bytes inside a block of size 456 alloc'd
==17870==at 0x4C2F831: malloc (vg_replace_malloc.c:309)
==17870==by 0x418304: _gfortrani_xmalloc (memory.c:38)
==17870==by 0x415F4E: _gfortrani_init_async_unit (async.c:243)
==17870==by 0x4054FE: _gfortrani_new_unit (open.c:666)
==17870==by 0x405CEC: already_open (open.c:720)
==17870==by 0x405CEC: _gfortran_st_open (open.c:897)
==17870==by 0x4027DA: MAIN__ (in /home/ig25/Krempel/Rewind/a.out)
==17870==by 0x402A79: main (in /home/ig25/Krempel/Rewind/a.out)
==17870==  Block was alloc'd by thread #1
==17870== 

So, I think we can confirm this.

[Bug middle-end/323] optimized code gives strange floating point results

[vincent-gcc at vinc17 dot net]

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

--- Comment #215 from Vincent Lefèvre  ---
According to https://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#bug_status
the possible status are UNCONFIRMED, CONFIRMED and IN_PROGRESS. I think that
the correct one is CONFIRMED.

[Bug c++/71755] friend function may not be defined inside a class using a qualified name but GCC allows that

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Properly rejected since r10-1269-g32833537fcfcc320c8a149641b12d49d23e94609

[Bug c++/79314] friend function with qualified name definition

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Properly rejected since r10-1269-g32833537fcfcc320c8a149641b12d49d23e94609

[Bug tree-optimization/93516] [10 regression] ICE in verify_sra_access_forest, at tree-sra.c:2342 since r10-6322

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  ---
So the problems seems to be that get_ref_base_an_extent returns
different sizes for expressions of the same type - specifically a
RECORD_TYPE with padding -  when one is a standalone VAR_DECL and the
other a field within another VAR_DECL.

This leads to SRA tripping over with the following input, where struct
h contains nothing but field of type struct e.

  struct h D.2475;
  struct h l;
  struct c k;
  struct e D.2392;
  ...
  D.2475 = MEM[(const struct h &)];
  l = D.2475;
  ...
   :
  b::i (_11, l.D.2346);

so the l.D.2346 reference is reported to have 96 bits its access is
propagated to D.2475 and then in turn to D.2392, always as a struct h
96 bit access.  But D.2392 itself also has type struct h, and so we
end up with one struct h access within another, the former having 128
bits and the latter only 96, and both having the same expr - an expr
which get_ref_base_an_extent in the verifier thinks should be bigger.

Since no scalar types are involved, all of this has no impact on
codegen.  Therefore I am tempted to simply relax the assert to only
check max_size for register types.  Perhaps we should also check that
we never create access of the same or compatible type as the parent
access when propagating across assignments because that is the only
case in which we end up with this confusing expr.  Or perhaps both.

[Bug c/89288] ICE with __builtin_has_attribute in tree_code_size

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
The ICE is gone in both GCC 10 and 9 thanks to r270326.

[Bug c++/93625] New: inline specifier in a friend function declaration

[the1987.6 at gmail dot com]

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

Bug ID: 93625
   Summary: inline specifier in a friend function declaration
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: the1987.6 at gmail dot com
  Target Milestone: ---

In the latest working draft N4849, 

9.2.7 The inline specifier

"If the inline specifier is used in a friend function declaration, that
declaration shall be a definition or the function shall have previously been
declared inline."

But no error has been occurred by the following code.

---

struct X{
 friend inline void f();
};

void f(){}

---

The declaration of f as inline, is not a definition.
Also there is not a previous declaration as inline.

This seems like a compiler bug.

By the way, there is the rule in N1638(published April 11, 2004).

[Bug gcov-profile/93626] New: [GCOV] incorrect coverage when compiled with option '-fsanitize=undefined' for typedef struct

[yangyibiao at hust dot edu.cn]

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

Bug ID: 93626
   Summary: [GCOV] incorrect coverage when compiled with option
'-fsanitize=undefined' for typedef struct
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at hust dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcov -v
gcov (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or 
FITNESS FOR A PARTICULAR PURPOSE.


$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.2.0 (GCC) 


$ cat small.c
void main()
{  
  int t = 2;
  typedef struct
  {
char v[t];
  } B;
  B b;
  for (int i = 0; i < 2; i++)
b.v[i] = 0;
}

$ gcc --coverage -O0 -fsanitize=undefined small.c; ./a.out; gcov small.c; cat
small.c.gcov
File 'small.c'
Lines executed:100.00% of 9
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
1:1:void main()
1:2:{  
1:3:  int t = 2;
1:4:  typedef struct
-:5:  {
3:6:char v[t];
-:7:  } B;
1:8:  B b;
3:9:  for (int i = 0; i < 2; i++)
2:   10:b.v[i] = 0;
1:   11:}

Line #6 is wrongly marked as executed three times. When compiled without option
'-fsanitize=undefined', the coverage report is correct.

[Bug fortran/70070] ICE on initializing character data beyond min/max bound

[kargl at gcc dot gnu.org]

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

--- Comment #12 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #11)
> A generator might be helpful for validations :
> 

Thanks.  AFAICT, the patch I submitted yesterday
rejects the generated codes, because

>   if ( kvar == 1 ) then
>  write (1, fmt) '   data (c(i:i), i=1,', j, ') /', j, '*"c"/'
>   else
>  write (1, fmt) '   data (c(i:i), i=', j, ',', i, ') /', i-j+1,
> '*"c"/'

c(i:i) is no now correctly identified as invalid in a DATA statement.

gfortran has always handled implied-do loops poorly.

[Bug target/93622] bool register arguments are underspecified on x86_64

[maxim.yegorushkin at gmail dot com]

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

--- Comment #4 from Maxim Egorushkin  ---
I guess you are right, since clang compiles

bool f(int a, int b) { return a == b; }

into

f(int, int):
cmp edi, esi
seteal
ret

Where sete does't change the 7 high bytes of rax, which creates a false
dependency on the previous value of rax and could reduce performance in some
conditions. A `xor eax, eax` before that `cmp` would fix that.

May be if the ABI required bool to be either 0 or 1 that would allow for
slightly more efficient code, but I don't have numbers to support this claim.

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[bugdal at aerifal dot cx]

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

--- Comment #12 from Rich Felker  ---
Note that -fexcess-precision=standard is not available in C++ mode to fix this.

However, -ffloat-store should also ensure consistency to the optimizer
(necessary to prevent this bug, and other variants of it, from happening) at
the expense of some extreme performance and code size costs and making the
floating point results even more semantically incorrect (double-rounding all
over the place, mismatching FLT_EVAL_METHOD==2) and -ffloat-store is available
in C++ mode. Despite all these nasty effects, it may be a suitable workaround,
and at least it avoids letting the optimizer prove 0==1, thereby effectively
treating any affected code as if it contained UB.

Note that in code written to be excess-precision-aware, making use of float_t
and double_t for intermediate operands and only using float and double for
in-memory storage, -ffloat-store should yield behavior equivalent to
-fexcess-precision=standard.

[Bug rtl-optimization/93561] [bounds checking] memory overflow for spill_for

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #4 from Jeffrey A. Law  ---
Fixed by Vlad's patch on the trunk.

[Bug middle-end/323] optimized code gives strange floating point results

[bugdal at aerifal dot cx]

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

--- Comment #214 from Rich Felker  ---
I'm not particular in terms of the path it takes as long as this gets back to a
status where it's on the radar for fixing.

[Bug c++/92947] Parenthesized aggregate initialization doesn't work with the library types it's supposed to work with

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Sorry, looking into this again.  A problem I see with my fix is that with it
this assert fails:

struct A { };
struct B { };
static_assert (!__is_trivially_constructible(A, B), "");

i.e. we say __is_trivially_constructible(A, B) is true.  That still incorrect
even in C++20, right?

[Bug c++/93618] [10 Regression] : unknown array size in delete when using C++20 standard

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-07
 CC||jason at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org,
   ||redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Jakub Jelinek  ---
This boils down to:
template 
struct C {
  C () noexcept = default;
  ~C () noexcept = default;
  C (const C&) = delete;
  C& operator= (const C&) = delete;
  C& operator=(const C&) volatile = delete;
  constexpr C (T *x) noexcept : p(x) { }
  T *p = nullptr;
};

class A {
  struct B {
int c;
C d[];
  };
  void foo (int f) { B s; s.c = f; }
  B e;
};

which is rejected since GCC 6 e.g. in -std=c++17 mode, starting with
r6-6747-g05dd97db3c29364ea3fc8fc2a658586a9469db79
.  What is important is that = nullptr NSDMI (in the std::atomic case inside of
__atomic_base template).

On the libstdc++-v3 side, this changed with
r10-5914-ge4379a931d140a71b36eaecceace319837fda321

Given the flexible array member we are outside of the standard territory, so
the question is if we want to support that and if yes, what we want to do in
that case.

[Bug c++/92517] [10 Regression] ICE on incorrect syntax involving requires and decltype

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
With
struct S {
  unsigned int s1:1;
  unsigned int s2:1;
  unsigned int s3:1;
  unsigned int s4:1;
  unsigned int s5:4;
  unsigned char s6;
  unsigned short s7;
  unsigned short s8;
};
struct T {
  int t1;
  int t2;
};

static inline int
bar (struct S *x)
{
  if (x->s4)
return ((struct T *)(x + 1))->t1 + ((struct T *)(x + 1))->t2;
  else
return 0;
}

int
foo (int x, int y)
{
  struct S s;
  s.s6 = x;
  s.s7 = y & 0x1FFF;
  s.s4 = 0;
  return bar ();
}

static inline int
qux (struct S *x)
{
  int s4 = x->s4;
  if (s4)
return ((struct T *)(x + 1))->t1 + ((struct T *)(x + 1))->t2;
  else
return 0;
}

int
baz (int x, int y)
{
  struct S s;
  s.s6 = x;
  s.s7 = y & 0x1FFF;
  s.s4 = 0;
  return qux ();
}

we don't actually warn about the baz/qux case, the difference is just
separating in the source the bitfield load from comparison, so the premature
fold "optimization" doesn't trigger anymore.  And with -fno-tree-sra that s.s4
= 0; _10 = s.s4; is optimized during FRE1 value numbering.
The BIT_FIELD_REF also prevents SRA... :(
Anyway, it is clear why BIT_FIELD_REF  vn can't work in this case, the
other bits are uninitialized, or e.g. could be non-constant etc.
My thoughts were that we could just special-case BIT_FIELD_REF  & C,
either just where C is power of two and thus we extract a single bit and
handle that as visit_reference_op_load of BIT_FIELD_REF with that single bit,
so in this case BIT_FIELD_REF , or perhaps iteratively, trying to
capture the bits one by one.
This still doesn't work, as vn_reference_lookup_3 punts on anything
non-byte-ish:
  /* 3) Assignment from a constant.  We can use folds native encode/interpret
 routines to extract the assigned bits.  */
  else if (known_eq (ref->size, maxsize)
   && is_gimple_reg_type (vr->type)
   && !contains_storage_order_barrier_p (vr->operands)
   && gimple_assign_single_p (def_stmt)
   && CHAR_BIT == 8 && BITS_PER_UNIT == 8
   /* native_encode and native_decode operate on arrays of bytes
  and so fundamentally need a compile-time size and offset.  */
   && maxsize.is_constant ()
   && maxsizei % BITS_PER_UNIT == 0<= This
fails, maxsizei is 1
   && offset.is_constant ()
   && offseti % BITS_PER_UNIT == 0 <= This
would fail too, offseti is 3
   && (is_gimple_min_invariant (gimple_assign_rhs1 (def_stmt))
   || (TREE_CODE (gimple_assign_rhs1 (def_stmt)) == SSA_NAME
   && is_gimple_min_invariant (SSA_VAL (gimple_assign_rhs1
(def_stmt))
...
  if (base2
  && !reverse
  && !storage_order_barrier_p (lhs)
  && known_eq (maxsize2, size2)
  && multiple_p (size2, BITS_PER_UNIT) <= This
would fail too, size2 would be 1
  && multiple_p (offset2, BITS_PER_UNIT)   <= This
would fail too, offset2 would be 3
  && adjust_offsets_for_equal_base_address (base, ,
base2, )
  && offset.is_constant ()
  && offset2.is_constant ()
  && size2.is_constant ())
So, even if we don't want to handle all the bitfield vs. bitfield details for
now, could we perhaps special case the non-BITS_PER_UNITish offsets/sizes if
offseti == offset2i && maxsizei == size2i and perhaps don't use
native_encode/interpret in that case, but just handle INTEGER_CST and
fold_convert it to the right type?
These bitfields really ought to be integral types...

[Bug target/93622] bool register arguments are underspecified on x86_64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
It is not binary compatible.
See e.g.
https://bugs.llvm.org/buglist.cgi?quicksearch=12207%2C19909%2C42439%2C44228 for
details.

[Bug c++/92517] [10 Regression] ICE on incorrect syntax involving requires and decltype

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:82aee6dd61e2a5b4e4b124f896c8403169688f41

commit r10-6506-g82aee6dd61e2a5b4e4b124f896c8403169688f41
Author: Jason Merrill 
Date:   Thu Feb 6 16:14:19 2020 -0500

c++: Fix ICE on nonsense requires-clause.

Here we were swallowing all the syntax errors by parsing tentatively, and
returning error_mark_node without ever actually giving an error.  Fixed by
using save_tokens/rollback_tokens instead.

PR c++/92517
* parser.c (cp_parser_constraint_primary_expression): Do the main
parse non-tentatively.

[Bug target/93622] bool register arguments are underspecified on x86_64

[maxim.yegorushkin at gmail dot com]

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

--- Comment #2 from Maxim Egorushkin  ---
(In reply to Jakub Jelinek from comment #1)
> clang doesn't follow the psABI.

How can it possibly do so while staying binary compatible?

[Bug fortran/93624] New: Memory leak with allocatable

[Jiri.Furst at fs dot cvut.cz]

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

Bug ID: 93624
   Summary: Memory leak with allocatable
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Jiri.Furst at fs dot cvut.cz
  Target Milestone: ---

Created attachment 47796
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47796=edit
Source code of the test

The attached code compiles fine with gfortran 7.5.0, 8.3.1, and 9.2.1. However,
when checking with valgrind, the run_test2() produces a memory leak. Other test
cases are OK. It seems to be similar to bug #47637.

The valgrind shows:

==10301== Memcheck, a memory error detector
==10301== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==10301== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==10301== Command: ./a.out
==10301== 
==10301== 
==10301== HEAP SUMMARY:
==10301== in use at exit: 40 bytes in 1 blocks
==10301==   total heap usage: 33 allocs, 32 frees, 13,994 bytes allocated
==10301== 
==10301== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==10301==at 0x4C2E2DF: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10301==by 0x401207: create_a.3927 (test_alloc.f90:16)
==10301==by 0x400EE9: run_test2.3923 (test_alloc.f90:28)
==10301==by 0x400BE5: MAIN__ (test_alloc.f90:9)
==10301==by 0x4012F4: main (test_alloc.f90:10)
==10301== 
==10301== LEAK SUMMARY:
==10301==definitely lost: 40 bytes in 1 blocks
==10301==indirectly lost: 0 bytes in 0 blocks
==10301==  possibly lost: 0 bytes in 0 blocks
==10301==still reachable: 0 bytes in 0 blocks
==10301== suppressed: 0 bytes in 0 blocks
==10301== 
==10301== For lists of detected and suppressed errors, rerun with: -s
==10301== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

[Bug target/93622] bool register arguments are underspecified on x86_64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
clang doesn't follow the psABI.

[Bug gcov-profile/93623] New: No need to dump gcdas when forking

[cdenizet at mozilla dot com]

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

Bug ID: 93623
   Summary: No need to dump gcdas when forking
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cdenizet at mozilla dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

In order to have accurate counters, gcdas are dumped before a fork and counters
are reset.
I think the dump is pretty useless: we could just reset the counters in the
child process.
Let say a counter is N before the fork, then fork and this counter is set to 0
in the child process.
In the parent process, the counter is incremented by P and in the child process
it's incremented by C.
When dump is ran at exit, parent process will dump N+P for the given counter
and the child process will dump 0+C, so when the gcdas are merged the resulting
counter will be N+P+C: so it's correct.
So the dump is useless and is time consuming. In firefox we've a lot of
processes and a lot of gcdas, so the dump adds a lot of overhead.
I think it makes sense to dump/reset in the case of exec** functions since the
process is replaced by a new process and so the counters are definitly lost.

[Bug target/93622] New: bool register arguments are underspecified on x86_64

[maxim.yegorushkin at gmail dot com]

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

Bug ID: 93622
   Summary: bool register arguments are underspecified on x86_64
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maxim.yegorushkin at gmail dot com
  Target Milestone: ---

bool register arguments are underspecified on x86_64

The following code:

#include 

struct A {
int32_t a;
uint32_t b : 1;
uint32_t c : 31;

constexpr A(int a, int c, bool b)
: a(a), b(b), c(c)
{}
};

A f(int a, int c, bool b) {
return {a, c, b};
}

With g++ trunk and `-O3 -march=skylake -std=gnu++17` compiles to:

f(int, int, bool):
add esi, esi
movzx   edx, dl <--- zero out top 7 bytes of rdx
or  esi, edx
sal rsi, 32
mov eax, edi
or  rax, rsi
ret

Whereas clang-9 with the same flags generates:

f(int, int, bool):
lea ecx, [rdx + 2*rsi] <--- rdx is either 0 or 1.
shl rcx, 32
mov eax, edi
or  rax, rcx
ret

Why does g++ assume that a `bool` argument in a 64-bit register (rdx here) has
its top 7 bytes filled with indeterminate values, whereas clang assumes that
the register is exactly 0 or 1, please?

[Bug target/88521] GCC from r266355 miscompiles x265 for mingw-w64 target

[hjl.tools at gmail dot com]

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

Bug 85667 Summary: ms_abi rules aren't followed when returning and passing 
short structs with float and double values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85667

   What|Removed |Added

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

[Bug target/85667] ms_abi rules aren't followed when returning and passing short structs with float and double values

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #15 from H.J. Lu  ---
Fixed for GCC 10 and GCC 9.3.

[Bug tree-optimization/91954] [10 Regression] gcc.dg/vect/pr66142.c should not need early inlining to be vectorized since r10-3311-gff6686d2e5f797d6

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
GIMPLE testcase:

struct A { float x, y; };
struct B { struct A t; };

float __GIMPLE (ssa,startwith("fre"))
foo (float a, int i)
{
  struct B D_2220[32];
  float *_23;
  float _27;
  float _28;
  float _31;

  __BB(2):
  D_2220[i_14(D)].t.x = 1.0e+0f;
  D_2220[i_14(D)].t.y = a_11(D);
  _23 = _2220[i_14(D)];
  _27 = __MEM  ((float *)_23);
  _28 = __MEM  ((float *)_23 + _Literal (float *) 4);
  _31 = _27 + _28;
  return _31;
}

note the issue isn't only ref matching but alias disambiguation of
the second store against the first load.  For first load we don't
have an access path (VN has but it's representation is not the same
the alias oracle uses...).  Need to embrace a canonical decomposed
form in ao_ref maybe.

[Bug middle-end/93519] [8/9 Regression] bogus -Wrestrict for strcpy(d, s) call guarded by d != s

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Guenther :

https://gcc.gnu.org/g:3c7a03bc360c3511fae3747a71e579e9fd0824f9

commit r10-6505-g3c7a03bc360c3511fae3747a71e579e9fd0824f9
Author: Richard Biener 
Date:   Fri Feb 7 12:56:18 2020 +0100

middle-end/93519 - avoid folding stmts in obviously unreachable code

The inliner folds stmts delayed, the following arranges things so
to not fold stmts that are obviously not reachable to avoid warnings
from those code regions.

2020-02-07  Richard Biener  

PR middle-end/93519
* tree-inline.c (fold_marked_statements): Do a PRE walk,
skipping unreachable regions.
(optimize_inline_calls): Skip folding stmts when we didn't
inline.

* gcc.dg/Wrestrict-21.c: New testcase.

[Bug middle-end/93519] [8/9 Regression] bogus -Wrestrict for strcpy(d, s) call guarded by d != s

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.0
Summary|[8/9/10 Regression] bogus   |[8/9 Regression] bogus
   |-Wrestrict for strcpy(d, s) |-Wrestrict for strcpy(d, s)
   |call guarded by d != s  |call guarded by d != s

--- Comment #3 from Richard Biener  ---
Fixed on trunk sofar.

[Bug target/85667] ms_abi rules aren't followed when returning and passing short structs with float and double values

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-9 branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:850c38f5f4158a157fa792ca0b20a5a17a3ff642

commit r9-8204-g850c38f5f4158a157fa792ca0b20a5a17a3ff642
Author: H.J. Lu 
Date:   Fri Feb 7 03:50:40 2020 -0800

x86-64: Pass aggregates with only float/double in GPRs for MS_ABI

MS_ABI requires passing aggregates with only float/double in integer
registers as shown in the output from MSVC v19.10 at:

https://godbolt.org/z/2NPygd

This patch fixed:

FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54
-Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable
-Wno-uninitialized -O0 -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54
-Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable
-Wno-uninitialized -O2 -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55
-Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable
-Wno-uninitialized -O0 -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55
-Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable
-Wno-uninitialized -O2 -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56
-Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable
-Wno-uninitialized -O0 -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56
-Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable
-Wno-uninitialized -O2 -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test

in libffi testsuite.

gcc/

Backport from mainline
PR target/85667
* config/i386/i386.c (function_arg_ms_64): Add a type argument.
Don't return aggregates with only SFmode and DFmode in SSE
register.
(ix86_function_arg): Pass type to function_arg_ms_64.

gcc/testsuite/

Backport from mainline
PR target/85667
* gcc.target/i386/pr85667-10.c: New test.
* gcc.target/i386/pr85667-7.c: Likewise.
* gcc.target/i386/pr85667-8.c: Likewise.
* gcc.target/i386/pr85667-9.c: Likewise.

(cherry picked from commit ea5ca698dca15dc86b823661ac357a30b49dd0f6)

[Bug target/85667] ms_abi rules aren't followed when returning and passing short structs with float and double values

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-6503-gea5ca698dca15dc86b823661ac357a30b49dd0f6
Author: H.J. Lu 
Date:   Fri Feb 7 03:37:46 2020 -0800

x86-64: Pass aggregates with only float/double in GPRs for MS_ABI

MS_ABI requires passing aggregates with only float/double in integer
registers as shown in the output from MSVC v19.10 at:

https://godbolt.org/z/2NPygd

This patch fixed:

FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54
-Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable
-Wno-uninitialized -O0 -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54
-Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable
-Wno-uninitialized -O2 -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55
-Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable
-Wno-uninitialized -O0 -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55
-Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable
-Wno-uninitialized -O2 -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56
-Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable
-Wno-uninitialized -O0 -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56
-Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable
-Wno-uninitialized -O2 -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test

in libffi testsuite.

gcc/

PR target/85667
* config/i386/i386.c (function_arg_ms_64): Add a type argument.
Don't return aggregates with only SFmode and DFmode in SSE
register.
(ix86_function_arg): Pass arg.type to function_arg_ms_64.

gcc/testsuite/

PR target/85667
* gcc.target/i386/pr85667-10.c: New test.
* gcc.target/i386/pr85667-7.c: Likewise.
* gcc.target/i386/pr85667-8.c: Likewise.
* gcc.target/i386/pr85667-9.c: Likewise.

[Bug fortran/93423] [8/9/10 Regression] ICE on invalid with argument list for module procedure

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.4

[Bug c++/93314] [8/9/10 Regression] Invalid use of non-static data member causes ICE in gimplify_expr

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid
   Target Milestone|--- |8.4

[Bug middle-end/92096] [10 Regression] segmentation fault in 'example_labels' building gcc trunk on cygwin

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||GC
 Target||x86_64-pc-cygwin
  Component|c   |middle-end
   Target Milestone|--- |10.0

[Bug c++/92556] [10 Regression] ICE if using dependent name inside lambda expression in simple-requirement since r10-3735-gcb57504a55015891

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c++/91966] [8/9/10 Regression] pack expansion for Cartesian product breaks if certain indirections are involved since r6-1487-g1a4cd2cd7e7266b0

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |8.4

[Bug c++/91993] [8/9/10 Regression] Spurious -Wconversion warning with -fsanitize=undefined since r6-4886-gcda0a029f45d20f4

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |8.4

[Bug tree-optimization/91954] [10 Regression] gcc.dg/vect/pr66142.c should not need early inlining to be vectorized since r10-3311-gff6686d2e5f797d6

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug tree-optimization/91954] [10 Regression] gcc.dg/vect/pr66142.c should not need early inlining to be vectorized since r10-3311-gff6686d2e5f797d6

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
IPA SRA splits the struct B parameter:

Evaluating analysis results for bar/0
  Will split parameter 0
- component at byte offset 0, size 4
- component at byte offset 4, size 4
- component at byte offset 8, size 4
- component at byte offset 12, size 4

which is passed as

  D.2220[_14].t.x = 1.0e+0;
  D.2220[_14].t.y = u_11;
  D.2220[_14].w.x = x_16;
  D.2220[_14].w.y = y_18;
  _23 = [_14];
  _24 = bar (_23);

producing

bar.isra (const float ISRA.5, const float ISRA.6, const float ISRA.7, const
float ISRA.8)

the inlining of this then ends up as

  _23 = [_14];
  _27 = MEM[(float *)_23];
  _28 = MEM[(float *)_23 + 4B];
  _29 = MEM[(float *)_23 + 8B];
  _30 = MEM[(float *)_23 + 12B];

where formerly forwprop ended up combining the [_14] into the
four dereferences with the nice acccess paths which it cannot do from
the above:

  D.2220[_20].t.x = 1.0e+0;
  D.2220[_20].t.y = u_13;
  D.2220[_20].w.x = x_22;
  D.2220[_20].w.y = y_24;
  _30 = MEM  [(const struct B *)][_20].t.x;
  _34 = MEM  [(const struct B *)][_20].t.y;
  _35 = MEM  [(const struct B *)][_20].w.x;
  _36 = _30 * _35;
  _37 = MEM  [(const struct B *)][_20].w.y;

so instead we get

  D.2220[_14].t.x = 1.0e+0;
  D.2220[_14].t.y = u_11;
  D.2220[_14].w.x = x_16;
  D.2220[_14].w.y = y_18;
  _23 = [_14];
  _27 = MEM[(float *)_23];
  _28 = MEM[(float *)_23 + 4B];
  _29 = MEM[(float *)_23 + 8B];
  _30 = MEM[(float *)_23 + 12B];

which we are not able to elide (which is of course kind-of lame).

IIRC we have a duplicate report for this somewhere assigned to me (for the VN
side).  VN already can do some tricks but it doesn't handle offsetted
MEM_REFs there (vn_reference_maybe_forwprop_address) and it doesn't somehow
work for the not offseted one either.

[Bug c++/93618] [10 Regression] : unknown array size in delete when using C++20 standard

[laurent.stacul at gmail dot com]

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

--- Comment #3 from Laurent Stacul  ---
Created attachment 47795
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47795=edit
preprocessed sources

[Bug c++/93618] [10 Regression] : unknown array size in delete when using C++20 standard

[laurent.stacul at gmail dot com]

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

--- Comment #2 from Laurent Stacul  ---
Ok. To ease your work I wrote this small reproducer:

#include 

class A {
struct State {
int flag;
std::atomic next_[];
};
void state(int f) {
State s;
s.flag = f;
}
State state_;
};

$ >g++ -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers
-std=gnu++2a -c reproducer.cpp

I attach the preprocessed source.

Regards,
Stac

[Bug c++/91759] [8/9/10 Regression] g++ accepts ill-formed deduction guides in wrong scope since r7-6608-ga56c0ac08242269b

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |8.4

[Bug c++/91212] [8/9/10 Regression] const ignored for ctor arguments within return since r8-2493-g4ce8c5dea53d8073

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |8.4

[Bug middle-end/91146] [9/10 Regression] -Werror=array-bounds if compile with -fsanitize=address

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.3

[Bug target/89972] [8/9/10 Regression] ICE with overaligned arguments

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.4

[Bug ipa/93621] [10 Regression] ICE in redirect_call_stmt_to_callee, at cgraph.c:1443 since r10-5567

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|[10 Regression] ICE in  |[10 Regression] ICE in
   |redirect_call_stmt_to_calle |redirect_call_stmt_to_calle
   |e, at cgraph.c:1443 |e, at cgraph.c:1443 since
   ||r10-5567

--- Comment #2 from Jakub Jelinek  ---
Started to ICE with r10-5567-g44fca83228acc96c19c51e52b5c0448e09329170

[Bug c++/93314] [8/9/10 Regression] Invalid use of non-static data member causes ICE in gimplify_expr

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
Related to c++/84939

[Bug other/91085] fixincludes breaks

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Current glibc uses
#ifdef __has_include
# if __has_include ("linux/stat.h")
#  include "linux/stat.h"
#  ifdef STATX_TYPE
#   define __statx_timestamp_defined 1
#   define __statx_defined 1
#  endif
# endif
#endif
instead, is that also broken by fixincludes?

[Bug target/89972] [8/9/10 Regression] ICE with overaligned arguments

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |SUSPENDED
  Component|middle-end  |target
   Target Milestone|8.4 |---
Summary|[8/9/10 Regression] ICE in  |[8/9/10 Regression] ICE
   |expand_call, at |with overaligned arguments
   |calls.c:4229|

--- Comment #8 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #7)
> I suppose we need to find out the answer first -> WAITING.

Actually suspend is the correct way to mark things as waiting on external
response that is not the user (e.g ABI folks or the standards committee).

[Bug target/93611] [10 Regression] ICE in extract_constrain_insn_cached, at recog.c:2207 since r10-6451-gb7b3378f91c0641f

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed.

[Bug debug/93122] ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1668

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug debug/93122] ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1668

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r10-6502-gc006911de91ca9e23d7d2df069499c768d215eac
Author: Jakub Jelinek 
Date:   Fri Feb 7 11:09:03 2020 +0100

powerpc: Fix -fstack-clash-protection -mprefixed-addr ICE [PR93122]

As mentioned in the PR, the following testcase ICEs because rs, while valid
add_operand is not valid add_cint_operand and so gen_add3_insn fails,
because it doesn't meet the expander predicates.

Here is what I meant as the alternative, i.e. don't check any predicates,
just gen_add3_insn, if that fails, force rs into register and retry.
And, add REG_FRAME_RELATED_EXPR note always when we haven't emitted a
single
insn that has rtl exactly matching what we'd add the REG_FRAME_RELATED_EXPR
with (in that case, dwarf2cfi.c is able to figure it out by itself, no need
to waste compile time memory).

2020-02-07  Jakub Jelinek  

PR target/93122
* config/rs6000/rs6000-logue.c
(rs6000_emit_probe_stack_range_stack_clash): Always use gen_add3_insn,
if it fails, move rs into end_addr and retry.  Add
REG_FRAME_RELATED_EXPR note whenever it returns more than one insn or
the insn pattern doesn't describe well what exactly happens to
dwarf2cfi.c.

* gcc.target/powerpc/pr93122.c: New test.

[Bug target/93615] [10 Regression] unwind.h on arm can't be compiled with -std=c11

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed.

[Bug c++/89404] [8/9 Regression] ICE in build_value_init_noctor, at cp/init.c:467

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] ICE in  |[8/9 Regression] ICE in
   |build_value_init_noctor, at |build_value_init_noctor, at
   |cp/init.c:467   |cp/init.c:467

--- Comment #4 from Paolo Carlini  ---
Already fixed in trunk.

[Bug c++/89404] [8/9/10 Regression] ICE in build_value_init_noctor, at cp/init.c:467

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Paolo Carlini :

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

commit r10-6501-gc58e6cc32c4e36032701e3bc5caa136a35231b5d
Author: Paolo Carlini 
Date:   Fri Feb 7 11:05:30 2020 +0100

Add testcase of PR c++/89404, already fixed in trunk.

PR c++/89404
* g++.dg/ext/vla21.C: New.

[Bug target/93615] [10 Regression] unwind.h on arm can't be compiled with -std=c11

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:811a475ea3fcc55ee4aea7c81171891ef19dfc25

commit r10-6500-g811a475ea3fcc55ee4aea7c81171891ef19dfc25
Author: Jakub Jelinek 
Date:   Fri Feb 7 11:01:14 2020 +0100

arm: Fix up arm installed unwind.h for use in pedantic modes [PR93615]

As the following testcase shows, unwind.h on ARM can't be (starting with
GCC
10) compiled with -std=c* modes, only -std=gnu* modes.
The problem is it uses asm keyword, which isn't a keyword in those modes
(system headers vs. non-system ones don't make a difference here).
glibc and other installed headers use __asm or __asm__ keywords instead
that
work fine in both standard and gnu modes.

While there, as it is an installed header, I think it is also wrong to
completely ignore any identifier namespace rules.
The generic unwind.h defines just _Unwind* namespace identifiers plus
_sleb128_t/_uleb128_t (but e.g. unlike libstdc++/glibc headers doesn't
uglify operand names), the ARM unwind.h is much worse here.  I've just
changed the gnu_Unwind_Find_got function at least not be in user identifier
namespace, but perhaps it would be good to go further and rename e.g.
or e.g.
  typedef _Unwind_Reason_Code (*personality_routine) (_Unwind_State,
  _Unwind_Control_Block *, _Unwind_Context *);
in unwind-arm-common.h.

2020-02-07  Jakub Jelinek  

PR target/93615
* config/arm/unwind-arm.h (gnu_Unwind_Find_got): Rename to ...
(_Unwind_gnu_Find_got): ... this.  Use __asm instead of asm.  Remove
trailing :s in asm.  Formatting fixes.
(_Unwind_decode_typeinfo_ptr): Adjust caller.

* gcc.dg/pr93615.c: New test.

[Bug fortran/70070] ICE on initializing character data beyond min/max bound

[gs...@t-online.de]

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

--- Comment #11 from G. Steinmetz  ---

A generator might be helpful for validations :


$ cat generator_char_data.f90
program generator_char_data
   implicit none
   character(*), parameter :: fmt = '(*(a,i0))'
   integer :: i, j, nfile

!- variant with longer span and steps
!  integer, parameter :: n = 10**7
!  integer, parameter :: nstep = n/100
!  integer, parameter :: m = 10**7
!  integer, parameter :: mstep = m/100

   integer, parameter :: n = 100
   integer, parameter :: nstep = 1
   integer, parameter :: m = 1000
   integer, parameter :: mstep = 10

   print *, 'n, nstep :', n, nstep
   print *, 'm, mstep :', m, mstep
   nfile = 0
   do i = 1, n, nstep
  do j = i+1, i+m, mstep
 call test_variant (0, 1)
 call test_variant (1, 1)
  end do
  do j = 0, -m, -mstep
 call test_variant (0, 2)
 call test_variant (1, 2)
  end do
   end do
   print *, 'generated files :', nfile

contains

   subroutine test_open
  character(16) :: chfile
  nfile = nfile + 1
  write (chfile, fmt) 'z', nfile, '.f90'
  open (1, file=chfile)
   end
   subroutine test_close
  close (1)
   end
   subroutine test_variant (kdef, kvar)
  integer, intent(in) :: kdef, kvar
  call test_open
  write (1, fmt) 'program p'
  if ( kdef == 1 ) then
 write (1, fmt) '   integer :: i'
  end if
  write (1, fmt) '   character(', i, ') :: c'
  if ( kvar == 1 ) then
 write (1, fmt) '   data (c(i:i), i=1,', j, ') /', j, '*"c"/'
  else
 write (1, fmt) '   data (c(i:i), i=', j, ',', i, ') /', i-j+1, '*"c"/'
  end if
  write (1, fmt) 'end'
  call test_close
   end
end



Run it :

  gfortran generator_char_data.f90
  ./a.out

  for i in z*.f*; do
 timeout 2.0 gfortran -c $i
  done > list 2>&1

  grep 'internal compiler' list

[Bug c++/93595] [c++20] Substitution failure of "auto = []{}" in template parameter list in nested template context

[bastien.penavayre at epitech dot eu]

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

--- Comment #1 from bastien penavayre  ---
Note that this error only occurs with functions/methods

template
struct ok
{
   template
   using type = int;

   template
   struct otype {};
};

int main()
{
   ok<0>::type<> t; //ok
   ok<0>::otype<> v; //ok
}

https://godbolt.org/z/ouo4n7

[Bug target/93594] Missed optimization with _mm256_set/setr_m128i intrinsics

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r10-6499-gf82617f229b336d856c18313339b14657e05c129
Author: Jakub Jelinek 
Date:   Fri Feb 7 09:28:39 2020 +0100

i386: Better patch to improve avx* vector concatenation [PR93594]

After thinking some more on this, we can do better; rather than having to
add a new prereload splitter pattern to catch all other cases where it
might
be beneficial to fold first part of an UNSPEC_CAST back to the unspec
operand, this patch reverts the *.md changes I've made yesterday and
instead
tweaks the patterns, so that simplify-rtx.c can optimize those on its own.
Instead of the whole SET_SRC being an UNSPEC through which simplify-rtx.c
obviously can't optimize anything, this represents those patterns through a
VEC_CONCAT (or two nested ones for the 128-bit -> 512-bit casts) with the
operand as the low part of it and UNSPEC representing just the high part of
it (the undefined, to be ignored, bits).  While richi suggested using
already in GIMPLE for those using a SSA_NAME default definition (i.e.
clearly uninitialized use), I'd say that uninit pass would warn about
those,
but more importantly, in RTL it would probably force zero initialization of
that or use or an uninitialized pseudo, all of which is hard to match in an
pattern, so I think an UNSPEC is better for that.

2020-02-07  Jakub Jelinek  

PR target/93594
* config/i386/predicates.md (avx_identity_operand): Remove.
* config/i386/sse.md (*avx_vec_concat_1): Remove.
(avx__,
avx512f__256): Change patterns to
a VEC_CONCAT of the operand and UNSPEC_CAST.
(avx512f__): Change pattern to
a VEC_CONCAT of VEC_CONCAT of the operand and UNSPEC_CAST with
UNSPEC_CAST.

[Bug target/93611] [10 Regression] ICE in extract_constrain_insn_cached, at recog.c:2207 since r10-6451-gb7b3378f91c0641f

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r10-6498-ge7bec5d5edeaab404931bf599821c6c2a3023b47
Author: Jakub Jelinek 
Date:   Fri Feb 7 09:26:54 2020 +0100

i386: Fix splitters that call extract_insn_cached [PR93611]

The following testcase ICEs.  The generated split_insns starts
with recog_data.insn = NULL and then tries to put various operands into
recog_data.operand array and checks various splitter conditions.
The problem is that some atom related tuning splitters indirectly call
extract_insn_cached on the insn they are used in.  This can change
recog_data.operand, but most likely it will just keep it as is, but
sets recog_data.insn to the current instruction.  If that splitter doesn't
match, we continue trying some other split conditions and modify
recog_data.operand array again.  If even that doesn't find any usable
splitter, we punt, but at that point recog_data.insn says that recog_data
is valid for that particular instruction, even when recog_data.operand
array
can be anything.
The safest thing would be to copy whole recog_data to a temporary object
before doing the calls that can call extract_insn_cached and restore it
afterwards, but it would be also very costly, recog_data has 1280 bytes.
So, this patch just makes sure to clear recog_data.insn if it has changed
during the extract_insn_cached call, which means if we extract_insn_cached
later, we'll extract it properly, while if we call it say from some other
context than splitter conditions, the insn is already cached, we don't
reset
the cache.

2020-02-07  Jakub Jelinek  

PR target/93611
* config/i386/i386.c (ix86_lea_outperforms): Make sure to clear
recog_data.insn if distance_non_agu_define changed it.

* gcc.target/i386/pr93611.c: New test.