[Bug middle-end/93298] GCC 10.0 non-current union member access

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |INVALID

--- Comment #2 from Richard Biener  ---
I'd say it's not a dup but INVALID since you are reading the non-active union
member a.m1 after the loop which ends in activating a.m2.  GCCs type punning
via union doesn't apply because you use pointer accesses as Andrew says.  He
also
points to a related (and valid) bugreport though.

[Bug testsuite/93294] [10 Regression] Addition of -fdiagnostic-urls=never to testsuite flags broke compat.exp testing with ALT_CC_UNDER_TEST=gcc etc.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/93279] [9/10 Regression] C++ Template substitution ICE

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||8.3.0
Version|unknown |9.2.0
   Target Milestone|--- |9.3
Summary|[9 Regression] C++ Template |[9/10 Regression] C++
   |substitution ICE|Template substitution ICE
  Known to fail||10.0, 9.2.0

[Bug c/93278] huge almost empty array takes huge time to compile and produces huge object file

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-01-17
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
Please provide the compiler command-line you are using, append -v and provide
the generated output.

[Bug target/93119] [ICE] The traditional TLS support of aarch64-ilp32 target may be not perfect while enable fPIC

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
So looking further, my patch is incorrect.

The glibc sources for __tls_get_addr says it returns void* which is a 32bit
value which might or might not be zero extended.
So I need to fix this slightly different from what I did.

>These are supposed to be machine addresses, not C pointers.
Yes and no but see above, even my attached patch is wrong.  I am rewriting this
again.

[Bug tree-optimization/92980] [miss optimization]redundant load missed by fre.

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Ah, sorry I failed to see the entry from BB2 isn't fallthru.  I agree the
difference is spurious in this particular case but in general it's quite hard
to do better without excessively rotating most multi-exit loops.  Note in
the end you also have to satisfy should_duplicate_loop_header_p for each
block to duplicate.

So what is suprious here is that we do not consider

 do
   {
   }
 while (i++ < n);

to be a do-while loop but we do for

 do
   {
   }
 while (++i < n);

due to the IV update in the latch.  IMHO technically that's correct.

The loop in question does not look like a do-while loop to us because
the loop header doesn't contain "most" of the loop body.  But CFG wise
it perfectly satisfies the predicate.

I think the new FAILs are somewhat spurious and one would need to investigate
on a case-by-case basis whether they really are a regression.  Often
they are testcases for specific input IL (which you changed) rather than
a specific C testcase.

[Bug tree-optimization/57359] store motion causes wrong code for union access at -O3

[rguenther at suse dot de]

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

--- Comment #20 from rguenther at suse dot de  ---
On Fri, 17 Jan 2020, pinskia at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
> 
> --- Comment #19 from Andrew Pinski  ---
> (In reply to Richard Biener from comment #14)
> > Testcase from PR81028
> > 
> > extern void abort();
> > 
> > typedef int A;
> > typedef float B;
> > 
> > void __attribute__((noinline,noclone))
> > foo(A *p, B *q, long unk)
> > {
> >   for (long i = 0; i < unk; ++i) {
> >   *p = 1;
> >   q[i] = 42;
> >   }
> > }
> > 
> 
> I don't see how the above function cannot be optimized to what we currently
> optimize it to?  The C/C++ aliasing rules say p and q cannot be a related
> pointer at all.
> 
> In the inplacement new case, there is another issue going on.  Locals and
> changing types was a defect report against C++ (or at least I thought I saw
> one).

This is about "placement new" or rather the middle-end memory model.
You can also simply make p/q point to different union members of the
same union where then the above is still valid with unk == 0 but we
mess it up, re-ordering the stores (basically we say the stores don't
conflict which is not correct for WAW or WAR dependences)

[Bug tree-optimization/92980] [miss optimization]redundant load missed by fre.

[wwwhhhyyy333 at gmail dot com]

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

--- Comment #11 from Hongyu Wang  ---
(In reply to rguent...@suse.de from comment #10)
> 
> It has two exits which makes it difficult
> Or impossible to make it truly do-while.
> But it's close enough and further rotating the loop doesn't make it better.

Thanks for the explanation. But the original loop without eliminating the
parser code is:

  [local count: 114863532]:
 goto ; [100.00%]

  [local count: 1014686025]:
 i.0_1 = (unsigned int) i_10;
 _2 = i.0_1 * 4;
 _3 = a_13(D) + _2;
 _4 = *_3;
 _5 = i.0_1 + 1;
 _6 = _5 * 4;
 _7 = a_13(D) + _6;
 _8 = *_7;
 if (_4 > _8)
   goto ; [5.50%]
 else
   goto ; [94.50%]

  [local count: 958878293]:
 i_15 = i_10 + 1;

  [local count: 1073741824]:
 # i_10 = PHI <0(2), i_15(4)>
 _9 = n_12(D) + -1;
 if (_9 > i_10)
   goto ; [94.50%]
 else
   goto ; [5.50%]

  [local count: 114863532]:
 # _11 = PHI <0(3), 1(5)>
 return _11;

This is considered as not a do-while loop since the latch (bb 4) is not empty,
and it is successfully rotated. I don't think there is much difference except
i_15 = i_10 + 1 which can be optimized by fre after the parser change. 

So I wonder if the original one is rotated, why the one with empty latch can't.

[Bug tree-optimization/57359] store motion causes wrong code for union access at -O3

[pinskia at gcc dot gnu.org]

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

--- Comment #19 from Andrew Pinski  ---
(In reply to Richard Biener from comment #14)
> Testcase from PR81028
> 
> extern void abort();
> 
> typedef int A;
> typedef float B;
> 
> void __attribute__((noinline,noclone))
> foo(A *p, B *q, long unk)
> {
>   for (long i = 0; i < unk; ++i) {
>   *p = 1;
>   q[i] = 42;
>   }
> }
> 

I don't see how the above function cannot be optimized to what we currently
optimize it to?  The C/C++ aliasing rules say p and q cannot be a related
pointer at all.

In the inplacement new case, there is another issue going on.  Locals and
changing types was a defect report against C++ (or at least I thought I saw
one).

[Bug middle-end/93298] GCC 10.0 non-current union member access

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
>I'm not sure whether this test program is valid

You are not accessing via the union but rather via a short or an int.

BUT it is a dup of bug 57359.

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

[Bug tree-optimization/57359] store motion causes wrong code for union access at -O3

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||msl023508 at gmail dot com

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

[Bug middle-end/93298] New: GCC 10.0 non-current union member access

[msl0000023508 at gmail dot com]

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

Bug ID: 93298
   Summary: GCC 10.0 non-current union member access
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msl023508 at gmail dot com
  Target Milestone: ---

I'm not sure whether this test program is valid, but here it is:

$ cat test-case.c 
extern int printf(const char *, ...);

union {
unsigned int m1;
unsigned short int m2;
} a;
unsigned int *const b = 
unsigned short *c = 

int main() {
int i;
for(i = 0; i < 5; i++) {
*b = 0;
(*c)++;
}
printf("%u\n", a.m1);
printf("%hu\n", a.m2);
return 0;
}
$ gcc-10-20200110 -v
Using built-in specs.
COLLECT_GCC=gcc-10-20200110
COLLECT_LTO_WRAPPER=/opt/gcc-10-20200110/bin/../lib/gcc/x86_64-unknown-freebsd11/10.0.0/lto-wrapper
Target: x86_64-unknown-freebsd11
Configured with: ../gcc-10-20200110/configure --build=x86_64-unknown-freebsd11
--prefix=/usr/local --sysconfdir=/etc --localstatedir=/var
--libexecdir='/usr/local/lib' --enable-version-specific-runtime-libs
--disable-rpath --with-system-zlib
--enable-languages=c,c++,objc,obj-c++,fortran,lto --enable-plugin
--enable-initfini-array --enable-gnu-indirect-function
--program-suffix=-10-20200110
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20200110 (experimental) (GCC) 
$ gcc-10-20200110 -Wall -Wextra -O2 test-case.c 
$ ./a.out 
0
5
$ gcc-10-20200110 -Wall -Wextra -O1 test-case.c
$ ./a.out
1
1


I has been read C90 and C99 for information of reading non-current member in an
union; it seems the value would be 'unspecified' by the C99.
While C90 says:
> if a member of a union object is accessed after a value has been stored in a 
> different member of the object, the behavior is implementation-defined.

I tried to use C90 mode to compile the program, but got same result:

$ gcc-10-20200110 -Wall -Wextra -std=c90 -O2 test-case.c
$ ./a.out
0
5
$ gcc-10-20200110 -Wall -Wextra -std=c90 -O1 test-case.c
$ ./a.out
1
1
$ gcc-10-20200110 -Wall -Wextra -std=c90 -Os test-case.c
$ ./a.out
0
5

[Bug c++/93286] [10 Regression] ICE: tree check: did not expect class ‘type’, have ‘type’ (reference_type) in convert_from_reference, at cp/cvt.c:550 since g:e0d91792eec490d1

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/93286] [10 Regression] ICE: tree check: did not expect class ‘type’, have ‘type’ (reference_type) in convert_from_reference, at cp/cvt.c:550 since g:e0d91792eec490d1

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:5194b51ed9714808d88827531e91474895b6c706

commit r10-6029-g5194b51ed9714808d88827531e91474895b6c706
Author: Jason Merrill 
Date:   Thu Jan 16 16:55:39 2020 -0500

PR c++/93286 - ICE with __is_constructible and variadic template.

Here we had been recursing in tsubst_copy_and_build if type2 was a
TREE_LIST
because that function knew how to deal with pack expansions, and tsubst
didn't.  But tsubst_copy_and_build expects to be dealing with expressions,
so we crash when trying to convert_from_reference a type.

* pt.c (tsubst) [TREE_LIST]: Handle pack expansion.
(tsubst_copy_and_build) [TRAIT_EXPR]: Always use tsubst for type2.

[Bug target/93119] [ICE] The traditional TLS support of aarch64-ilp32 target may be not perfect while enable fPIC

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> Created attachment 47663 [details]
> Patch which fixes the problem
> 
> So we need to accept P modes and not PTR modes for the aarch64_valid_symref.
> And then we need to also change the mode of the result to be always Pmode
> (DImode).
> And then we need to take the lower part of the result.
> 
> Oh also instead of checking if we are targetting ILP32, we need to check the
> type of imm and such.

I will submit this patch after a build/test but I made sure both testcases
don't fail any more.

[Bug target/93119] [ICE] The traditional TLS support of aarch64-ilp32 target may be not perfect while enable fPIC

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 47663
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47663=edit
Patch which fixes the problem

So we need to accept P modes and not PTR modes for the aarch64_valid_symref. 
And then we need to also change the mode of the result to be always Pmode
(DImode).
And then we need to take the lower part of the result.

Oh also instead of checking if we are targetting ILP32, we need to check the
type of imm and such.

[Bug c++/93297] internal compiler error: in set_constraints, at cp/constraint.cc:

[euloanty at live dot com]

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

fdlbxtqi  changed:

   What|Removed |Added

 CC||euloanty at live dot com

--- Comment #1 from fdlbxtqi  ---
Created attachment 47662
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47662=edit
preprocessed file

[Bug c++/93297] New: internal compiler error: in set_constraints, at cp/constraint.cc:

[euloanty at live dot com]

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

Bug ID: 93297
   Summary: internal compiler error: in set_constraints, at
cp/constraint.cc:
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-invalid-code, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

sha1.cc: In function ‘int main()’:
sha1.cc:7:90: internal compiler error: in set_constraints, at
cp/constraint.cc:1176
7 |  fast_io::osha
s(std::piecewise_construct,std::forward_as_tuple(),std::forward_as_tuple());
  |
 ^
0x658b55 set_constraints(tree_node*, tree_node*)
../../gcc/gcc/cp/constraint.cc:1176
0xa23457 alias_ctad_tweaks
../../gcc/gcc/cp/pt.c:28284
0xa23457 deduction_guides_for
../../gcc/gcc/cp/pt.c:28395
0xa2377b do_class_deduction
../../gcc/gcc/cp/pt.c:28500
0xa2377b do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/gcc/cp/pt.c:28629
0x9584ec cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:7463
0x9fe844 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:20768
0x9e07c2 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13629
0x9e251a cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:13061
0x9e30b7 cp_parser_statement
../../gcc/gcc/cp/parser.c:11383
0x9e4098 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11745
0x9e4178 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11699
0x9fab65 cp_parser_function_body
../../gcc/gcc/cp/parser.c:22907
0x9fab65 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:22958
0x9fde3d cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:28745
0x9fee46 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:28661
0x9fee46 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:20536
0x9e07c2 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13629
0xa091a2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:13328
0xa0991a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4723
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


on windows MinGW-w64
sha1.cc: In function 'int main()':
sha1.cc:7:90: internal compiler error: in set_constraints, at
cp/constraint.cc:1177
7 |  fast_io::osha
s(std::piecewise_construct,std::forward_as_tuple(),std::forward_as_tuple());
  |
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug analyzer/93291] 'FAIL: gcc.dg/analyzer/pattern-test-2.c' for a few configurations

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to David Malcolm from comment #1) 
> I'm not sure where the difference between the targets originates; is there a
> way to force the usage of bitwise-or here?

Try to write it this way:

bool tmp1 = p == 0B;
bool tmp2 = q == 0B
bool tmp = tmp1 | tmp2;
if (tmp)

[Bug c/92833] ice for broken C code

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #8 from Joseph S. Myers  ---
Fix committed, thanks.

[Bug c/92833] ice for broken C code

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Joseph Myers :

https://gcc.gnu.org/g:852f0ae80555238c425e33f98df5c7077694bd9f

commit r10-6026-g852f0ae80555238c425e33f98df5c7077694bd9f
Author: Kerem Kat 
Date:   Thu Jan 16 23:42:11 2020 +

Fix ICE caused by swallowing a token in c_parser_consume_token

This patch fixes ICE on invalid code, specifically files that have
conflict-marker-like signs before EOF.

PR c/92833
gcc/c/
* c-parser.c (c_parser_consume_token): Fix peeked token stack pop
to support 4 available tokens.

gcc/testsuite/
* c-c++-common/pr92833-1.c, c-c++-common/pr92833-2.c,
c-c++-common/pr92833-3.c, c-c++-common/pr92833-4.c: New tests.

[Bug lto/89358] [8 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings

[rogero at howzatt dot demon.co.uk]

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

--- Comment #23 from Roger Orr  ---
That's good to hear -- thank you very much!

[Bug c++/93280] [10 Regression] ICE: in cp_gimplify_expr, at cp /cp-gimplify.c:933 since g:08f594eb399dab06

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/93280] [10 Regression] ICE: in cp_gimplify_expr, at cp /cp-gimplify.c:933 since g:08f594eb399dab06

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:801f5b96775288e55193a66a746caab1ddd56f4a

commit r10-6024-g801f5b96775288e55193a66a746caab1ddd56f4a
Author: Jason Merrill 
Date:   Thu Jan 16 10:46:40 2020 -0500

PR c++/93280 - ICE with aggregate assignment and DMI.

I recently added an assert to cp-gimplify to catch any
TARGET_EXPR_DIRECT_INIT_P being expanded without a target object, and this
testcase found one.  We started out with a TARGET_EXPR around the
CONSTRUCTOR, which would normally mean that the member initializer would be
used to directly initialize the appropriate member of whatever object the
TARGET_EXPR ends up initializing.  But then gimplify_modify_expr_rhs
stripped the TARGET_EXPR in order to assign directly from the elements of
the CONSTRUCTOR, leaving no object for the TARGET_EXPR_DIRECT_INIT_P to
initialize.  I considered setting CONSTRUCTOR_PLACEHOLDER_BOUNDARY in that
case, which implies TARGET_EXPR_NO_ELIDE, but decided that there's no
particular reason the A initializer needs to initialize a member of a B
rather than a distinct A object, so let's only set
TARGET_EXPR_DIRECT_INIT_P
when we're using the DMI in a constructor.

* init.c (get_nsdmi): Set TARGET_EXPR_DIRECT_INIT_P here.
* typeck2.c (digest_nsdmi_init): Not here.

[Bug c++/93296] New: Compiler error when assigning array to const reference with implicit constructor call.

[benjamin at readyatdawn dot com]

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

Bug ID: 93296
   Summary: Compiler error when assigning array to const reference
with implicit constructor call.
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: benjamin at readyatdawn dot com
  Target Milestone: ---

I'm seeing this error running godbolt.org compiler explorer. I don't have gcc
installed on my PC so I have not attached a preprocessed file, but the bug is
very simple to reproduce. I see the issue with all versions of gcc available on
compiler explorer.

This is the simplest repro I ended up with:


struct Container {
Container(int (&)[3]) { }
};

int main() {
int data[3];
const Container& container = data;
return 0;
}


error: invalid initialization of reference of type 'const Container&' from
expression of type 'int*'

A few changes avoid the issue, these both work:


const Container container = data;// no reference
const Container& container { data }; // explicit construction


Compiler output with '-v':

Using built-in specs.

COLLECT_GCC=/opt/compiler-explorer/gcc-9.2.0/bin/g++

Target: x86_64-linux-gnu

Configured with: ../gcc-9.2.0/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran,ada,d
--enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto
--enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build

Thread model: posix

gcc version 9.2.0 (Compiler-Explorer-Build) 

COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' './output.s'
'-masm=intel' '-S' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'


/opt/compiler-explorer/gcc-9.2.0/bin/../libexec/gcc/x86_64-linux-gnu/9.2.0/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-9.2.0/bin/../lib/gcc/x86_64-linux-gnu/9.2.0/
-D_GNU_SOURCE  -quiet -dumpbase example.cpp -masm=intel -mtune=generic
-march=x86-64 -auxbase-strip ./output.s -g -version -fdiagnostics-color=always
-o ./output.s

GNU C++14 (Compiler-Explorer-Build) version 9.2.0 (x86_64-linux-gnu)

compiled by GNU C version 7.4.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP



GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

ignoring nonexistent directory
"/opt/compiler-explorer/gcc-9.2.0/bin/../lib/gcc/x86_64-linux-gnu/9.2.0/../../../../x86_64-linux-gnu/include"

ignoring duplicate directory
"/opt/compiler-explorer/gcc-9.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.2.0/../../../../include/c++/9.2.0"

ignoring duplicate directory
"/opt/compiler-explorer/gcc-9.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.2.0/../../../../include/c++/9.2.0/x86_64-linux-gnu"

ignoring duplicate directory
"/opt/compiler-explorer/gcc-9.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.2.0/../../../../include/c++/9.2.0/backward"

ignoring duplicate directory
"/opt/compiler-explorer/gcc-9.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.2.0/include"

ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"

ignoring duplicate directory
"/opt/compiler-explorer/gcc-9.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.2.0/include-fixed"

ignoring nonexistent directory
"/opt/compiler-explorer/gcc-9.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.2.0/../../../../x86_64-linux-gnu/include"

#include "..." search starts here:

#include <...> search starts here:


/opt/compiler-explorer/gcc-9.2.0/bin/../lib/gcc/x86_64-linux-gnu/9.2.0/../../../../include/c++/9.2.0


/opt/compiler-explorer/gcc-9.2.0/bin/../lib/gcc/x86_64-linux-gnu/9.2.0/../../../../include/c++/9.2.0/x86_64-linux-gnu


/opt/compiler-explorer/gcc-9.2.0/bin/../lib/gcc/x86_64-linux-gnu/9.2.0/../../../../include/c++/9.2.0/backward

 /opt/compiler-explorer/gcc-9.2.0/bin/../lib/gcc/x86_64-linux-gnu/9.2.0/include


/opt/compiler-explorer/gcc-9.2.0/bin/../lib/gcc/x86_64-linux-gnu/9.2.0/include-fixed

 /usr/local/include

 /opt/compiler-explorer/gcc-9.2.0/bin/../lib/gcc/../../include

 /usr/include/x86_64-linux-gnu

 /usr/include

End of search list.

GNU C++14 (Compiler-Explorer-Build) version 9.2.0 (x86_64-linux-gnu)

compiled by GNU C version 7.4.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP



GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

Compiler executable checksum: 35bcd684e0bc8b3378dcc1f162909bba

: In function 'int main()':

:7:34: error: invalid initialization of reference of type 'const
Container&' 

[Bug c++/93036] [9/10 Regression] g++.dg/cpp2a/nontype-class27.C testcase accepted in -std=c++17 mode since r276248

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Fixed by g:657fea973b00350c99de9e67bff0438d1503.

[Bug c/93239] Enhancement: allow unevaluated statement expressions at filescope

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
I'd be concerned about trouble when code processing statements tries to 
deal with context that doesn't exist outside of functions.  Consider a 
statement expression containing a function definition (does that count as 
a nested function?), statement expressions containing declarations, 
possibly with extern, possibly not (how do those interact with file-scope 
declarations?), statement expressions containing _Atomic operations (see 
the sort of issues we had in bug 65345, though that was fixed), statement 
expressions containing __local__ declarations and goto.  It would be 
necessary to go through language features systematically, especially 
declarations and language features that try to create declarations 
internally, to ensure they behave sensibly inside statement expressions at 
file scope - and to test all the same features in old-style parameter 
declarations to ensure declarations from those features don't get mixed up 
in the parameter declaration handling.

(I concur that unevaluated statement expressions *should* be allowed at 
file scope, but think such a change would need pretty extensive test 
coverage of language features that are likely to be risky in such a 
context.)

[Bug analyzer/93293] 'FAIL: gcc.dg/analyzer/dot-output.c dg-check-dot dot-output.c.state-purge.dot'

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Thanks for filing this.

I was using record-style labels, but switched to HTML-style labels when I
upgraded graphviz and my record-style labels stopped working.

Based on
  https://lists.freedesktop.org/archives/wayland-devel/2017-June/034218.html
which says:
> http://www.graphviz.org/content/i-havent-been-able-render-these-files-graphviz-226
> indicates that the error message basically means that the authors of
> graphviz consider record-style labels to be deprecated and are no
> longer fixing errors with them. This patch changes the labels to be
> in the HTML style, which seems to require duplicating style between all
> the nodes, but it's not like these files are often edited.

That link is a 404, but archive.org has:
 
https://web.archive.org/web/20170816104830/http://www.graphviz.org:80/content/i-havent-been-able-render-these-files-graphviz-226

So it seems there should probably be a minimum version of graphviz in that
DejaGnu test.

Works for me with graphviz-2.40.1-46.fc30.x86_64, FWIW.

[Bug c++/93286] [10 Regression] ICE: tree check: did not expect class ‘type’, have ‘type’ (reference_type) in convert_from_reference, at cp/cvt.c:550 since g:e0d91792eec490d1

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/93028] internal compiler error: in write_type, at cp/mangle.c:2073

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Trying to compile test.cpp from Comment 5 again, I did see an ICE:

internal compiler error: tree check: expected tree that contains ‘decl minimal’
structure, have ‘tree_list’ in lookup_type_scope_1, at cp/name-lookup.c:6492
0x1829be2 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/tree.c:10071
0x83f864 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3311
0xa02cae lookup_type_scope_1
../../gcc/cp/name-lookup.c:6492
0xa02fab lookup_type_scope(tree_node*, tag_scope)
../../gcc/cp/name-lookup.c:6535
0x93d757 lookup_and_check_tag
../../gcc/cp/decl.c:13990
0x93deff xref_tag_1
../../gcc/cp/decl.c:14104
0x93e8a8 xref_tag(tag_types, tree_node*, tag_scope, bool)
../../gcc/cp/decl.c:14226
0xa34cab cp_parser_elaborated_type_specifier
../../gcc/cp/parser.c:18583
0xa328e6 cp_parser_type_specifier
../../gcc/cp/parser.c:17450
0xa2ce49 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14120
0xa48668 cp_parser_single_declaration
../../gcc/cp/parser.c:28165
0xa477da cp_parser_template_declaration_after_parameters
../../gcc/cp/parser.c:27846
0xa484fc cp_parser_explicit_template_declaration
../../gcc/cp/parser.c:28094
0xa48556 cp_parser_template_declaration_after_export
../../gcc/cp/parser.c:28113
0xa2f573 cp_parser_template_declaration
../../gcc/cp/parser.c:15594
0xa41183 cp_parser_member_declaration
../../gcc/cp/parser.c:24332
0xa41076 cp_parser_member_specification_opt
../../gcc/cp/parser.c:24259
0xa3efdd cp_parser_class_specifier_1
../../gcc/cp/parser.c:23400
0xa3fe34 cp_parser_class_specifier
../../gcc/cp/parser.c:23662
0xa32844 cp_parser_type_specifier
../../gcc/cp/parser.c:17424
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

but that got fixed by 41d93b16cac5b348b7883e259f7880b4a0addc23

[Bug analyzer/93291] 'FAIL: gcc.dg/analyzer/pattern-test-2.c' for a few configurations

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Thanks.  The test is rather over-specified, it seems.

x86_64 gimple for test_2 is:

  _1 = p_5(D) == 0B;
  _2 = q_6(D) == 0B;
  _3 = _1 | _2;
  if (_3 != 0)
goto ; [51.12%]
  else
goto ; [48.88%]


powerpc64le gimple for test_2 has:

  if (p_2(D) == 0B)
goto ; [18.09%]
  else
goto ; [81.91%]

   [local count: 879501929]:
  if (q_3(D) == 0B)
goto ; [30.95%]
  else
goto ; [69.05%]

So on x86_64, it's done both comparisons against NULL first, and optimized the
|| into:
  _3 = _1 | _2;
whereas on powerpc64le it uses control flow to do this.

The purpose of this test is to verify that the pattern-matching detects the
underlying conditionals in the presence of that "_3 = _1 | _2;" optimization,
so maybe a gimple FE test might be appropriate here.

I'm not sure where the difference between the targets originates; is there a
way to force the usage of bitwise-or here?

[Bug tree-optimization/93292] [10 Regression] ICE (segfault) in vectorizable_comparison on powerpc64le-linux-gnu since r10-5071

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-16
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |10.0
Summary|[10 Regression] ICE |[10 Regression] ICE
   |(segfault) in   |(segfault) in
   |vectorizable_comparison on  |vectorizable_comparison on
   |powerpc64le-linux-gnu   |powerpc64le-linux-gnu since
   ||r10-5071
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with r10-5071-g02d895504cc59be06fc3f7ec0cfd4eb160561211.

[Bug target/91298] $ at the beginging causing Error: junk `(%rip)' after expression

[pskocik at gmail dot com]

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

pskocik at gmail dot com changed:

   What|Removed |Added

 CC||pskocik at gmail dot com

--- Comment #4 from pskocik at gmail dot com ---
Related https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45591 .

I've played with it and this simple patch

diff --git a/gcc/final.c b/gcc/final.c
index fefc4874b24a..ba7425afa667 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -4087,11 +4087,20 @@ output_addr_const (FILE *file, rtx x)
 case SYMBOL_REF:
   if (SYMBOL_REF_DECL (x))
assemble_external (SYMBOL_REF_DECL (x));
-#ifdef ASM_OUTPUT_SYMBOL_REF
-  ASM_OUTPUT_SYMBOL_REF (file, x);
-#else
-  assemble_name (file, XSTR (x, 0));
-#endif
+
+ {
+ bool dollar_eh = XSTR(x,0)[0] == '$';
+ if (dollar_eh) fputc('(',file);
+
+   #ifdef ASM_OUTPUT_SYMBOL_REF
+ ASM_OUTPUT_SYMBOL_REF (file, x);
+   #else
+ assemble_name (file, XSTR (x, 0));
+   #endif
+
+ if (dollar_eh) fputc(')',file);
+ }
+
   break;

 case LABEL_REF:

seems to fix it, at least for x86-64. Basically you need parentheses around
names of globals (at least those that start with `$`) when they're used as
operands.

The parentheses is what clang does.

Both clang and tinycc have no problem with this. It would be great if gcc could
catch up.

[Bug c/93239] Enhancement: allow unevaluated statement expressions at filescope

[pskocik at gmail dot com]

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

--- Comment #1 from pskocik at gmail dot com ---
Fixing this seems as simple as removing/commenting-out:

gcc/c/c-parser.c:8195 /* If we've not yet started the current function's
statement list,
gcc/c/c-parser.c:8196or we're in the parameter scope of an old-style
function
gcc/c/c-parser.c:8197declaration, statement expressions are not
allowed.  */
gcc/c/c-parser.c:8198 if (!building_stmt_list_p () ||
old_style_parameter_scope ())
gcc/c/c-parser.c:8199   {
gcc/c/c-parser.c:8200 error_at (loc, "braced-group within expression
allowed "
gcc/c/c-parser.c:8201   "only inside a function");
gcc/c/c-parser.c:8202 parser->error = true;
gcc/c/c-parser.c:8203 c_parser_skip_until_found (parser,
CPP_CLOSE_BRACE, NULL);
gcc/c/c-parser.c:8204 c_parser_skip_until_found (parser,
CPP_CLOSE_PAREN, NULL);
gcc/c/c-parser.c:8205 expr.set_error ();
gcc/c/c-parser.c:8206 break;
gcc/c/c-parser.c:8207   }

This would be both very useful, and it makes all kind of sense, because other
expression constructs (function calls, comma expressions, ...) aren't
restricted syntactically either (just semantically), which means they _can_ be
inside untaken branches of constant-forming _Generic/__builtin_choose_expr, and
I can think of no good reason why statement expressions shouldn't be allowed
there too.

[Bug c++/93295] ICE in alias_ctad_tweaks

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
commit 1a291106384cabc73da0bc0f457b1cd3a4015970
Author: Jason Merrill 
Date:   Wed Nov 27 17:05:53 2019 -0500

Implement P1814R0, CTAD for alias templates.

This patch implements C++20 class template argument deduction for alias
templates, which works by a moderately arcane transformation of the
deduction guides for the underlying class template.  When implementing it,
it seemed that I could simplify the rules in the draft a bit and get
essentially the same effect; I'll be emailing the committee to that effect
soon.

gcc/cp/
* pt.c (rewrite_tparm_list): Factor out of build_deduction_guide.
(maybe_aggr_guide): Check for copy-init here.
(alias_ctad_tweaks, deduction_guides_for): New.
(ctor_deduction_guides_for): Factor out of do_class_deduction.
(ctad_template_p): New.
* parser.c (cp_parser_simple_type_specifier): Use it.
* constraint.cc (append_constraint): New.
gcc/c-family/
* c-cppbuiltin.c (c_cpp_builtins): Update __cpp_deduction_guides.

From-SVN: r278786

[Bug c++/93295] ICE in alias_ctad_tweaks

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-16
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/93295] New: ICE in alias_ctad_tweaks

[ensadc at mailnesia dot com]

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

Bug ID: 93295
   Summary: ICE in alias_ctad_tweaks
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ensadc at mailnesia dot com
  Target Milestone: ---

https://wandbox.org/permlink/B02uUhc2QP8OChB9

template
struct A { A(int); };

template
A(T) -> A;

template
using B = A;

B a(0);


prog.cc:10:12: internal compiler error: in alias_ctad_tweaks, at cp/pt.c:28223
   10 | B a((int*)0);
  |^
0x5b9faa alias_ctad_tweaks
../../source/gcc/cp/pt.c:28223
0x5b9faa deduction_guides_for
../../source/gcc/cp/pt.c:28395
0x7048b3 do_class_deduction
../../source/gcc/cp/pt.c:28500
0x7048b3 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../source/gcc/cp/pt.c:28629
0x6693e6 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../source/gcc/cp/decl.c:7463
0x6eb461 cp_parser_init_declarator
../../source/gcc/cp/parser.c:20762
0x6ce805 cp_parser_simple_declaration
../../source/gcc/cp/parser.c:13627
0x6f3962 cp_parser_declaration
../../source/gcc/cp/parser.c:13325
0x6f4084 cp_parser_translation_unit
../../source/gcc/cp/parser.c:4723
0x6f4084 c_parse_file()
../../source/gcc/cp/parser.c:43563
0x7bb56b c_common_parse_file()
../../source/gcc/c-family/c-opts.c:1186
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


The error disappears if `A` is changed to `A`, or if `, class = int` is
removed.

[Bug libstdc++/87106] Group move and destruction of the source, where possible, for speed

[glisse at gcc dot gnu.org]

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

--- Comment #29 from Marc Glisse  ---
Note that __is_bitwise_relocatable is specialized to true for deque, so we are
not super consistent here ;-)
The original patch used is_trivially_move_constructible, IIRC I changed it to
is_trivial so the review wouldn't turn into a lengthy discussion on the
subject, but I don't think going back to is_trivially_move_constructible would
cause miscompilations (maybe warnings with -Wsystem-headers).

[Bug c/93278] huge almost empty array takes huge time to compile and produces huge object file

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
If you mean [ rather than { before HUGE, that doesn't change anything at all.
Maybe it is assembler or linker that need a lot of memory or time, but gcc
certainly doesn't.

[Bug libstdc++/87106] Group move and destruction of the source, where possible, for speed

[dan at stahlke dot org]

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

--- Comment #28 from Dan Stahlke  ---
Thank you.  That makes sense.  I had asked about it here:
https://stackoverflow.com/questions/59690019  I was directed to this thread,
and linked back to the SO thread you provided.

[Bug tree-optimization/93292] [10 Regression] ICE (segfault) in vectorizable_comparison on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Created attachment 47661
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47661=edit
gcc10-pr93292.patch

Untested fix.

[Bug c++/93285] [10 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.c:931 since g:08f594eb399dab06

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Jason Merrill  ---
dup.

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

[Bug c++/93280] [10 Regression] ICE: in cp_gimplify_expr, at cp /cp-gimplify.c:933 since g:08f594eb399dab06

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/93280] [10 Regression] ICE: in cp_gimplify_expr, at cp /cp-gimplify.c:933 since g:08f594eb399dab06

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
*** Bug 93285 has been marked as a duplicate of this bug. ***

[Bug fortran/93289] array constructor of different length: Missing diagnostic when PARAMETER is in list

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Thu, Jan 16, 2020 at 05:14:44PM +, burnus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93289
> 
> --- Comment #3 from Tobias Burnus  ---
> Okay, it is indeed a -std=gnu extension. I still regard it as bug that it
> differs, but we can now think about which one to change. Namely:

IMHO, yes, it is a bug.  I have come to believe that
anything that is an extension should emit a error/warning.
This includes defacto standard things like REAL*4, where
a new -fallow-invalid-typespec would accept REAL*4 with
a warning and -Winvalid-typespec could be used to suppress
the warning.

FOr this particular bug, you also need to look in array.c.
For example, in gfc_match_array_constructor(), gfortran
walks the constructor to check for compatible typespecs
of constructor components if a type spec is present (ie.,
[real(4) :: x, y]).  See lines 1292-1332.  The is also
the function walk_array_constructor().

[Bug target/93133] __builtin_isgreater emits trapping compare instruction

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #1)
> This happens during combine.  If whether the comparison raises exception or
> not is distinguished on aarch64 with CCFPEmode vs. CCFPmode, then guess the
> problem is when that distinction gets ignored (unless in fast-math mode) or
> when it goes away completely.

combine isn't wrong here.  Describing anything else than the result of the
comparison with different CCmodes is what is wrong.

[Bug bootstrap/64271] Minimal patches to bootstrap on NetBSD

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:98d56ea8900fdcff8f1987cf2bf499a5b7399857

commit r10-6022-g98d56ea8900fdcff8f1987cf2bf499a5b7399857
Author: Jonathan Wakely 
Date:   Fri Jan 10 16:01:19 2020 +

libstdc++: std::ctype fixes for recent versions of NetBSD

This removes support for EOL versions of NetBSD and syncs the
definitions with patches from NetBSD upstream.

The only change here that isn't from upstream is to use _CTYPE_BL for
the isblank class, which is correct but wasn't previously done either in
FSF GCC or the NetBSD packages.

2020-01-16  Kai-Uwe Eckhardt  
Matthew Bauer  
Jonathan Wakely  

PR bootstrap/64271 (partial)
* config/os/bsd/netbsd/ctype_base.h (ctype_base::mask): Change type
to unsigned short.
(ctype_base::alpha, ctype_base::digit, ctype_base::xdigit)
(ctype_base::print, ctype_base::graph, ctype_base::alnum): Sync
definitions with NetBSD upstream.
(ctype_base::blank): Use _CTYPE_BL.
* config/os/bsd/netbsd/ctype_configure_char.cc (_C_ctype_): Remove
Declaration.
(ctype::classic_table): Use _C_ctype_tab_ instead of _C_ctype_.
(ctype::do_toupper, ctype::do_tolower): Cast char
parameters to unsigned char.
* config/os/bsd/netbsd/ctype_inline.h (ctype::is): Likewise.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-16
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
This happens during tentative parsing, so no errors are reported for decltype
not being followed by ( auto ) tokens and we segfault on trying to dereference
NULL open_paren to get open_paren->location.

The following patch avoids the ICE, on this testcase then reports:
--- gcc/cp/parser.c.jj  2020-01-16 12:15:47.211552009 +0100
+++ gcc/cp/parser.c 2020-01-16 17:41:39.322353708 +0100
@@ -18237,10 +18237,15 @@ cp_parser_placeholder_type_specifier (cp
  placeholder = cp_lexer_consume_token (parser->lexer);
  open_paren = cp_parser_require (parser, CPP_OPEN_PAREN,
  RT_OPEN_PAREN);
- cp_parser_require_keyword (parser, RID_AUTO, RT_AUTO);
+ if (!open_paren)
+   return error_mark_node;
+ if (!cp_parser_require_keyword (parser, RID_AUTO, RT_AUTO))
+   return error_mark_node;
   close_paren = cp_parser_require (parser, CPP_CLOSE_PAREN,
   RT_CLOSE_PAREN,
   open_paren->location);
+ if (!close_paren)
+   return error_mark_node;
}
 }

pr92517.C:5:10: error: ‘C’ does not name a type
5 | requires C decltype
  |  ^

Is that what we want, or do we want to emit an error even during tentative
parsing, or make the whole function deal with NULL open_paren and/or
close_paren and let the caller's do something?  For open_paren it would be a
matter of open_paren ? open_paren->location : UNKNOWN_LOCATION, for close_paren
there is a single spot where we could use placeholder->location if close_paren
is NULL.

[Bug fortran/93289] array constructor of different length: Missing diagnostic when PARAMETER is in list

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
Okay, it is indeed a -std=gnu extension. I still regard it as bug that it
differs, but we can now think about which one to change. Namely:


In the always-error case (i.e. literal first):
* gfc_resolve_character_array_constructor
  …
  if (expr->ts.u.cl->length == NULL)
  …
  else if (found_length != current_length)
{
  gfc_error ("Different CHARACTER lengths (%ld/%ld) in array"
 " constructor at %L", (long) found_length,

In the other case, one has:

* gfc_resolve_character_array_constructor
  …
  if (expr->ts.u.cl->length == NULL)
  …
  else
  …
gfc_set_constant_character_len (found_length, p->expr,
has_ts ? -1 : current_length);

And in gfc_set_constant_character_len:

  if (check_len != -1 && slen != check_len
  && !(gfc_option.allow_std & GFC_STD_GNU))
gfc_error_now ("The CHARACTER elements of the array constructor "
   "at %L must have the same length (%ld/%ld)",

[Bug testsuite/93294] New: [10 Regression] Addition of -fdiagnostic-urls=never to testsuite flags broke compat.exp testing with ALT_CC_UNDER_TEST=gcc etc.

[jakub at gcc dot gnu.org]

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

Bug ID: 93294
   Summary: [10 Regression] Addition of -fdiagnostic-urls=never to
testsuite flags broke compat.exp testing with
ALT_CC_UNDER_TEST=gcc etc.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

All the compat.exp tests now FAIL if the alt compiler doesn't support this new
option.

[Bug testsuite/93294] [10 Regression] Addition of -fdiagnostic-urls=never to testsuite flags broke compat.exp testing with ALT_CC_UNDER_TEST=gcc etc.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-16
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

[Bug target/93133] __builtin_isgreater emits trapping compare instruction

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
(In reply to rsand...@gcc.gnu.org from comment #3)
> Mine.  TBH I'm not really sure why the AArch64 definition
> of REVERSE_CONDITION is there.  We can't use CCFP GT as
> a form of quiet GT (!UNLT) [...]

Of course I meant !UNLE here.

[Bug fortran/93289] array constructor of different length: Missing diagnostic when PARAMETER is in list

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
(In reply to kargl from comment #1)
> It appears to be an undocumented extension. Add -Wall to your command line.

I would rather call it a bug :-)

The truncation warning is a separate thing. For instance, it (correctly)
triggers for the following valid code:

  print *, [character(len=2) :: "ab", "hjf333"]

and it does not trigger for the invalid

  character(len=*), parameter :: str = "123"
  print *, [str, "ab"]
  end

(Obviously also not for the valid "[character(len=20) :: "ab", str]".)

[Bug target/93133] __builtin_isgreater emits trapping compare instruction

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Mine.  TBH I'm not really sure why the AArch64 definition
of REVERSE_CONDITION is there.  We can't use CCFP GT as
a form of quiet GT (!UNLT) since it still looks to the
target-independent code like a normal signalling GT,
even if we ever did code-generate it differently.
And there should be no target-specific reasons for
turning a CCFPE GT into a CCFPE UNLT.

So let's see how much breaks if we just remove the
definition. :-)

[Bug analyzer/93293] New: 'FAIL: gcc.dg/analyzer/dot-output.c dg-check-dot dot-output.c.state-purge.dot'

[tschwinge at gcc dot gnu.org]

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

Bug ID: 93293
   Summary: 'FAIL: gcc.dg/analyzer/dot-output.c dg-check-dot
dot-output.c.state-purge.dot'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

Testing 299ddc612136421f1d9865ea4f2f84f7e3791824 on x86_64-pc-linux-gnu, I see:

XFAIL: gcc.dg/analyzer/dot-output.c  (test for warnings, line 21)
PASS: gcc.dg/analyzer/dot-output.c (test for excess errors)
PASS: gcc.dg/analyzer/dot-output.c dg-check-dot dot-output.c.callgraph.dot
PASS: gcc.dg/analyzer/dot-output.c dg-check-dot dot-output.c.eg.dot
FAIL: gcc.dg/analyzer/dot-output.c dg-check-dot
dot-output.c.state-purge.dot
PASS: gcc.dg/analyzer/dot-output.c dg-check-dot dot-output.c.supergraph.dot

spawn dot -O -Tpng dot-output.c.state-purge.dot
Warning: dot-output.c.state-purge.dot:11: string ran past end of line
Error: dot-output.c.state-purge.dot:12: syntax error near line 12
context:  >>> ' <<< _5' not needed here
Warning: dot-output.c.state-purge.dot:34: string ran past end of line
Warning: dot-output.c.state-purge.dot:45: string ran past end of line
Warning: dot-output.c.state-purge.dot:68: string ran past end of line
[etc.]

  1 digraph "supergraph" {
  2   overlap=false;
  3   compound=true;
  4   subgraph "cluster_test_2" {
  5 style="dashed"; color="black"; label="test_2";
  6 subgraph cluster_node_0 {
  7   style="solid";
  8   color="black";
  9   fillcolor="lightgrey";
 10   label="sn: 0";
 11 annotation_for_node_0
[shape=none,margin=0,style=filled,fillcolor=lightblue,label="'c1_4' not needed
here
 12 '_5' not needed here
 13 
[more empty lines]
 33 
 34 "];
 35 
 36   node_0
[shape=none,margin=0,style=filled,fillcolor=lightgrey,label=];
 38 
 39 }
 40 subgraph cluster_node_1 {
 41   style="solid";
 42   color="black";
 43   fillcolor="lightgrey";
 44   label="sn: 1";
 45 annotation_for_node_1
[shape=none,margin=0,style=filled,fillcolor=lightblue,label="'c1_4' not needed
here
 46 '_5' not needed here
 47 
[more empty lines]
[etc.]

That's Ubuntu 12.10:

$ dot -V
dot - graphviz version 2.26.3 (20100126.1600)

... perhaps too old to deal with such multi-line strings -- but perhaps they
shouldn't be generated like that?

[Bug tree-optimization/93292] New: [10 Regression] ICE (segfault) in vectorizable_comparison on powerpc64le-linux-gnu

[doko at ubuntu dot com]

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

Bug ID: 93292
   Summary: [10 Regression] ICE (segfault) in
vectorizable_comparison on powerpc64le-linux-gnu
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at ubuntu dot com
  Target Milestone: ---

seen with 20200116 on powerpc64-linux-gnu


$ cat editor_profiler.ii
class a {
public:
  static int c(float p1) {
static int b;
b = p1 ? p1 + 0.5 : 0;
return b;
  }
};
int *d;
float e;
void f() {
  float g;
  for (int h; h; h++) {
d[h] += a::c(g < 0 ?: g > 5 ?: g);
a::c(e);
  }
}

$ g++ -c -O3 -fstack-protector-strong editor_profiler.ii
during GIMPLE pass: vect
editor_profiler.ii: In function ‘void f()’:
editor_profiler.ii:11:6: internal compiler error: Segmentation fault
   11 | void f() {
  |  ^
0x10a217c3 crash_signal
../../src/gcc/toplev.c:328
0x10c9c79c TYPE_VECTOR_SUBPARTS(tree_node const*)
../../src/gcc/tree.h:3836
0x10c9c79c vectorizable_comparison
../../src/gcc/tree-vect-stmts.c:10495
0x10cad147 vect_analyze_stmt(_stmt_vec_info*, bool*, _slp_tree*,
_slp_instance*, vec*)
../../src/gcc/tree-vect-stmts.c:10907
0x10cdb0ef vect_slp_analyze_node_operations
../../src/gcc/tree-vect-slp.c:2786
0x10cdb053 vect_slp_analyze_node_operations
../../src/gcc/tree-vect-slp.c:2850
0x10cdb053 vect_slp_analyze_node_operations
../../src/gcc/tree-vect-slp.c:2850
0x10cdb053 vect_slp_analyze_node_operations
../../src/gcc/tree-vect-slp.c:2850
0x10cdb053 vect_slp_analyze_node_operations
../../src/gcc/tree-vect-slp.c:2850
0x10cdf97f vect_slp_analyze_operations(vec_info*)
../../src/gcc/tree-vect-slp.c:2926
0x10ce208f vect_slp_analyze_bb_1
../../src/gcc/tree-vect-slp.c:3250
0x10ce208f vect_slp_bb_region
../../src/gcc/tree-vect-slp.c:3311
0x10ce208f vect_slp_bb(basic_block_def*)
../../src/gcc/tree-vect-slp.c:3446
0x10ce79eb try_vectorize_loop_1
../../src/gcc/tree-vectorizer.c:946
0x10ce83ff vectorize_loops()
../../src/gcc/tree-vectorizer.c:1125
0x10baec9f execute
../../src/gcc/tree-ssa-loop.c:414
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug libstdc++/91263] unordered_map and unordered_set operator== double key comparison causes exponential behavior

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Fixed on trunk. Let's keep this open and decide whether to backport it to the
release branches.

[Bug c/93278] huge almost empty array takes huge time to compile and produces huge object file

[doug at cs dot dartmouth.edu]

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

--- Comment #2 from doug mcilroy  ---
My error. I omitted half the program. The bad behavior is exhibited by
char a{HUGE] = "x";
int main(){ return 0; }

[Bug analyzer/93291] New: 'FAIL: gcc.dg/analyzer/pattern-test-2.c' for a few configurations

[tschwinge at gcc dot gnu.org]

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

Bug ID: 93291
   Summary: 'FAIL: gcc.dg/analyzer/pattern-test-2.c' for a few
configurations
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

Testing 299ddc612136421f1d9865ea4f2f84f7e3791824 on
powerpc64le-unknown-linux-gnu, I see:

PASS: gcc.dg/analyzer/pattern-test-2.c  (test for warnings, line 11)
PASS: gcc.dg/analyzer/pattern-test-2.c  (test for warnings, line 11)
FAIL: gcc.dg/analyzer/pattern-test-2.c  (test for warnings, line 21)
FAIL: gcc.dg/analyzer/pattern-test-2.c  (test for warnings, line 21)
PASS: gcc.dg/analyzer/pattern-test-2.c  (test for warnings, line 21)
PASS: gcc.dg/analyzer/pattern-test-2.c  (test for warnings, line 21)
FAIL: gcc.dg/analyzer/pattern-test-2.c (test for excess errors)

[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c: In function 'test1':
[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:11:6: warning: pattern
match on 'ptr != 0'
[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:11:6: note: (1) here
('ptr' is in state 'start')
[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:11:6: warning: pattern
match on 'ptr == 0'
[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:11:6: note: (1) here
('ptr' is in state 'start')
[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c: In function 'test_2':
[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:6: warning: pattern
match on 'p != 0'
[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:6: note: (1) here
('p' is in state 'start')
[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:6: warning: pattern
match on 'p == 0'
[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:6: note: (1) here
('p' is in state 'start')
[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:17: warning:
pattern match on 'q == 0'
[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:6: note: (1)
following 'false' branch (when 'p' is non-NULL)...
[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:17: note: (2) ...to
here
[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:17: note: (3) here
('q' is in state 'start')
[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:17: warning:
pattern match on 'q != 0'
[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:6: note: (1)
following 'false' branch (when 'p' is non-NULL)...
[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:17: note: (2) ...to
here
[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:17: note: (3) here
('q' is in state 'start')

Excess errors:
[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:6: warning: pattern
match on 'p == 0'
[...]/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:17: warning:
pattern match on 'q == 0'

Per , this happens for a few configurations:
powerpc64le-unknown-linux-gnu, pru-unknown-elf, moxie-unknown-elf,
m68k-unknown-linux-gnu, powerpc-ibm-aix7.2.0.0.

[Bug target/40838] gcc shouldn't assume that the stack is aligned

[mahatma at eu dot by]

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

--- Comment #99 from Dzianis Kahanovich  ---
PPS About some hidden thinks/things. In pure theory. "*cost-model=cheap" can
reduce SSE usage, -mstackrealign - can increase function prolog/epilog
overhead. In my case - x7-Z8700 CPU have 2 FPU cores for 4 CPU cores
(silvermont-1 have even less FPUs), so solution looks sure better then
"-mstackrealign". But on some other CPUs something may be else and need to be
tested about performance.

[Bug analyzer/93288] ICE in supergraph.cc:180

[pmatos at gcc dot gnu.org]

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

--- Comment #2 from pmatos at gcc dot gnu.org ---
(In reply to David Malcolm from comment #1)
> Note that C++ is out-of-scope for the analyzer for GCC 10.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x01cb37ed in supergraph::supergraph (this=0x7fffcda0,
> logger=0x0)
> at ../../src/gcc/analyzer/supergraph.cc:180
> 180   = ENTRY_BLOCK_PTR_FOR_FN (edge->callee->get_fun ());
> Missing separate debuginfos, use: dnf debuginfo-install
> gmp-6.1.2-10.fc30.x86_64 libmpc-1.1.0-3.fc30.x86_64
> libzstd-1.4.2-1.fc30.x86_64 mpfr-3.1.6-4.fc30.x86_64
> 
> (gdb) p edge->callee
> $1 = 
> 
> (gdb) p edge->callee->get_fun()->cfg
> $4 = (control_flow_graph *) 0x0
> 
> So it's a segfault reading through a NULL cfg pointer.

Ah - sorry. I was not aware of that. :)
I will test it on C only for now then. Thanks. Feel free to close this if you
wish.

[Bug target/40838] gcc shouldn't assume that the stack is aligned

[mahatma at eu dot by]

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

--- Comment #98 from Dzianis Kahanovich  ---
fix: "I not try to rebuild 32bit "world" without ANY workaround" - on modern
gcc (now all under 9.2). Previous experiments was times & versions ago, so many
other new factors/fixes can solve most issues.

[Bug c++/93285] [10 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.c:931 since g:08f594eb399dab06

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/40838] gcc shouldn't assume that the stack is aligned

[mahatma at eu dot by]

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

--- Comment #97 from Dzianis Kahanovich  ---
No. Looking into gcc/opts.c - "-O3 optimizations" section - line:
{ OPT_LEVELS_3_PLUS, OPT_fvect_cost_model_, NULL, VECT_COST_MODEL_DYNAMIC },

- so, for -O3 it's "dynamic". Then, RTFM, "cheap" more cares about aligning.
But anymore, I not try to rebuild 32bit "world" without ANY workaround, so all
still dirty ;)

PS For some options configuration behaviour still non-linear, so queryng "gcc
-Q ..." still unsafe to check some defaults...

(In reply to Viktor Ostashevskyi from comment #96)
> Honestly, I don't see how your compiler flags could help. cost-model=cheap
> is default, data-alignment doesn't change incoming stack alignment.
> 
> ср, 15 січ. 2020, 14:31 користувач mahatma at eu dot by <
> gcc-bugzi...@gcc.gnu.org> пише:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
> >
> > --- Comment #95 from Dzianis Kahanovich  ---
> > Just FYI. Novadays, on my Thinkpad tablet with Atom (32 bit userspace
> > Gentoo),
> > I globally replace patch/-mstackrealign to "-fvect-cost-model=cheap
> > -fsimd-cost-model=cheap -malign-data=cacheline" and all works fine for -O3
> > +.
> > (This is dirty example, as cacheline for some old SSE CPUs are different,
> > etc).
> >
> > --
> > You are receiving this mail because:
> > You are on the CC list for the bug.

[Bug rtl-optimization/93264] [10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-16
 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
It tries to redirect a crossing jump from cold to hot partition to a new bb
that is in cold partition.
cfg_layout_redirect_edge_and_branch has code to handle this case, but only if
the 
branch is simplejump:
4429  if (e->flags & EDGE_CROSSING
4430  && BB_PARTITION (e->src) == BB_PARTITION (dest)
4431  && simplejump_p (BB_END (src)))
4432{
4433  if (dump_file)
4434fprintf (dump_file,
4435 "Removing crossing jump while redirecting edge form %i
to %i\n",
4436 e->src->index, dest->index);
4437  delete_insn (BB_END (src));
4438  remove_barriers_from_footer (src);
4439  e->flags |= EDGE_FALLTHRU;
4440}
which is not the case here:
(insn 577 350 578 27 (set (reg:DI 309)
(high:DI (label_ref:DI 220))) "pr71550.c":19:20 -1
 (insn_list:REG_LABEL_OPERAND 220 (nil)))
(insn 578 577 579 27 (set (reg:DI 308)
(lo_sum:DI (reg:DI 309)
(label_ref:DI 220))) "pr71550.c":19:20 -1
 (insn_list:REG_LABEL_OPERAND 220 (expr_list:REG_EQUAL (label_ref:DI 220)
(nil
(jump_insn/j 579 578 220 27 (set (pc)
(reg:DI 308)) "pr71550.c":19:20 -1
 (nil)
 -> 220)
The generic code really doesn't know what it should remove to replace it with
the fallthru edge.
So, I'd say something in the caller or a few callers up should have punted on
it before, but no idea what.

[Bug analyzer/93290] analyzer ICE on isnan()

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-16
 Ever confirmed|0   |1

[Bug fortran/93289] array constructor of different length: Missing diagnostic when PARAMETER is in list

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #0)
> print *, [str, "ab", "hjf333"] ! Accepted, why?
> print *, [str, str2]   ! Accepted, why?
> end

It appears to be an undocumented extension.  Add -Wall to your command line.

% gfcx -Wall -c a.f90
a.f90:2:20:

2 | print *, [str, "ab", "hjf333"] ! Accepted, why?
  |1
Warning: CHARACTER expression at (1) is being truncated (6/3)
[-Wcharacter-truncation]
a.f90:3:14:

3 | print *, [str, str2]   ! Accepted, why?
  |  1
Warning: CHARACTER expression at (1) is being truncated (4/3)
[-Wcharacter-truncation]

[Bug rtl-optimization/93272] LRA: EH reg allocated to hold local variable

[krebbel at gcc dot gnu.org]

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

--- Comment #2 from Andreas Krebbel  ---
This problem to some degree is specific to IBM Z since our EH regs are
call-saved registers. For targets using call-clobbered EH regs such a
collisions usually cannot happen. Perhaps it can be provoked with
-fnon-call-exceptions.

[Bug libstdc++/91263] unordered_map and unordered_set operator== double key comparison causes exponential behavior

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r10-6005-gd916538965ea260c6bcdb1d46581f6d572017ce8
Author: Fran�ois Dumont 
Date:   Thu Jan 16 08:34:21 2020 +

libstdc++: Improve unordered containers == operator (PR 91263)

Avoid comparing elements with operator== multiple times by replacing
uses of find and equal_range with equivalent inlined code that uses
operator== instead of the container's equality comparison predicate.
This is valid because the standard requires that operator== is a
refinement of the equality predicate.

Also replace the _S_is_permutation function with std::is_permutation,
which wasn't yet implemented when this code was first written.

PR libstdc++/91263
* include/bits/hashtable.h (_Hashtable<>): Make _Equality<> friend.
* include/bits/hashtable_policy.h: Include .
(_Equality_base): Remove.
(_Equality<>::_M_equal): Review implementation. Use
std::is_permutation.
* testsuite/23_containers/unordered_multiset/operators/1.cc
(Hash, Equal, test02, test03): New.
* testsuite/23_containers/unordered_set/operators/1.cc
(Hash, Equal, test02, test03): New.

[Bug analyzer/93290] New: analyzer ICE on isnan()

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 93290
   Summary: analyzer ICE on isnan()
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

As reported on IRC, this code ICEs the analyzer:

#include 
int main(void) {
float foo = 42.;
if (isnan(foo)) {
return 1;
} return 0;
}

during IPA pass: analyzer
foo.c: In function 'main':
foo.c:4:8: internal compiler error: in eval_condition_without_cm, at
analyzer/region-model.cc:5197
4 | if (isnan(foo)) {
  |^
0x632ab1 region_model::eval_condition_without_cm(svalue_id, tree_code,
svalue_id) const
../../gcc-2588197/gcc/analyzer/region-model.cc:5197
0xe2e729 region_model::eval_condition(svalue_id, tree_code, svalue_id) const
../../gcc-2588197/gcc/analyzer/region-model.cc:5161
0xe2e729 region_model::add_constraint(tree_node*, tree_code, tree_node*,
region_model_context*)
../../gcc-2588197/gcc/analyzer/region-model.cc:5270
0xe20492 program_state::on_edge(exploded_graph&, exploded_node const&,
superedge const*, state_change*)
../../gcc-2588197/gcc/analyzer/program-state.cc:727
0xe0f549 exploded_node::on_edge(exploded_graph&, superedge const*,
program_point*, program_state*, state_change*) const
../../gcc-2588197/gcc/analyzer/engine.cc:1075
0xe16297 exploded_graph::process_node(exploded_node*)
../../gcc-2588197/gcc/analyzer/engine.cc:2500
0xe16822 exploded_graph::process_worklist()
../../gcc-2588197/gcc/analyzer/engine.cc:2253
0xe16e69 impl_run_checkers(logger*)
../../gcc-2588197/gcc/analyzer/engine.cc:3570
0xe178d3 run_checkers()
../../gcc-2588197/gcc/analyzer/engine.cc:3624
0xe0de58 execute
../../gcc-2588197/gcc/analyzer/analyzer-pass.cc:84
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Confirmed with ab7c7b46c35ed1be68d4c020a2f20ee96f68b64b.

It's due to unhandled case op == UNORDERED_EXPR in
region_model::eval_condition_without_cm

[Bug fortran/93289] New: array constructor of different length: Missing diagnostic when PARAMETER is in list

[burnus at gcc dot gnu.org]

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

Bug ID: 93289
   Summary: array constructor of different length: Missing
diagnostic when PARAMETER is in list
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: accepts-invalid, diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

The following code has different string lengths in the array constructor.
If only string literals are used, an error is printed. But if the first
argument is a PARAMETER, seemingly no checking is done.

character(len=*), parameter ::  str = "abj", str2 = "1234"
print *, ["ab", "hjf333", str] ! Error: Different CHARACTER lengths (2/6) in
array...
print *, ["ab", str2]  ! Error -> OK
print *, [str, "ab", "hjf333"] ! Accepted, why?
print *, [str, str2]   ! Accepted, why?
end

[Bug c++/93286] [10 Regression] ICE: tree check: did not expect class ‘type’, have ‘type’ (reference_type) in convert_from_reference, at cp/cvt.c:550 since g:e0d91792eec490d1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Indeed, with those options started to ICE with
r8-742-gb42cc3ca244ea57d5112638a73e7f83c58202a84 when __is_constructible has
been implemented.

[Bug analyzer/93288] ICE in supergraph.cc:180

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Note that C++ is out-of-scope for the analyzer for GCC 10.

Program received signal SIGSEGV, Segmentation fault.
0x01cb37ed in supergraph::supergraph (this=0x7fffcda0, logger=0x0)
at ../../src/gcc/analyzer/supergraph.cc:180
180 = ENTRY_BLOCK_PTR_FOR_FN (edge->callee->get_fun ());
Missing separate debuginfos, use: dnf debuginfo-install
gmp-6.1.2-10.fc30.x86_64 libmpc-1.1.0-3.fc30.x86_64 libzstd-1.4.2-1.fc30.x86_64
mpfr-3.1.6-4.fc30.x86_64

(gdb) p edge->callee
$1 = 

(gdb) p edge->callee->get_fun()->cfg
$4 = (control_flow_graph *) 0x0

So it's a segfault reading through a NULL cfg pointer.

[Bug tree-optimization/93231] [10 Regression] ICEs since r280132

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #8 from Wilco  ---
Fixed.

[Bug c++/93286] [10 Regression] ICE: tree check: did not expect class ‘type’, have ‘type’ (reference_type) in convert_from_reference, at cp/cvt.c:550 since g:e0d91792eec490d1

[edlinger at gcc dot gnu.org]

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

--- Comment #1 from Bernd Edlinger  ---
with the following command it started already earlier:

gcc -Wshadow-compatible-local -fmax-errors=1 -std=c++17 -c effect.ii

[Bug c/93287] _Static_assert creates spurious -Wdeclaration-after-statement warnings

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Markus F.X.J. Oberhumer from comment #5)
> Still this is not nice from a usability perspective - why did the standard
> make this a declaration instead of a statement?

I said why, to allow it to be at the toplevel and not inside a function without
changing the grammar that much.

[Bug analyzer/93288] New: ICE in supergraph.cc:180

[pmatos at gcc dot gnu.org]

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

Bug ID: 93288
   Summary: ICE in supergraph.cc:180
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: pmatos at gcc dot gnu.org
  Target Milestone: ---

Great work with the analyzer! :)

I am running it on WebKit and I find a few issues. At the moment they all seem
to point to supergraph.cc:180. Here's a reduced example with todays
(16.01.2020) GCC:

$ /home/pmatos/installs/gcc-20200116/bin/g++ -v   
Using built-in specs.
COLLECT_GCC=/home/pmatos/installs/gcc-20200116/bin/g++
COLLECT_LTO_WRAPPER=/home/pmatos/installs/gcc-20200116/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/pmatos/installs/gcc-20200116
--enable-languages=c,c++,lto --disable-docs --disable-multilib --disable-nls
--disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200116 (experimental) (GCC)

Test case:

struct a {
  a();
};
class {
  a b;
} c;

$ /home/pmatos/installs/gcc-20200116/bin/g++ -std=gnu++17 -fanalyzer -c
AllIsoHeaps.ii
during IPA pass: analyzer
AllIsoHeaps.ii:6:4: internal compiler error: Segmentation fault
6 | } c;
  |^
0x105fbdf crash_signal
../../gcc/gcc/toplev.c:328
0x140d341 supergraph::supergraph(logger*)
../../gcc/gcc/analyzer/supergraph.cc:180
0x13d768f impl_run_checkers(logger*)
../../gcc/gcc/analyzer/engine.cc:3520
0x13d8d73 run_checkers()
../../gcc/gcc/analyzer/engine.cc:3624
0x13cdb28 execute
../../gcc/gcc/analyzer/analyzer-pass.cc:84
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c/93287] _Static_assert creates spurious -Wdeclaration-after-statement warnings

[markus at oberhumer dot com]

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

--- Comment #5 from Markus F.X.J. Oberhumer  ---
I see, many thanks for the clarification.

Still this is not nice from a usability perspective - why did the standard make
this a declaration instead of a statement?

Well, will revert back to using homegrown COMPILE_TIME_ASSERT macros...

[Bug tree-optimization/92429] [10 Regression] ICE in vect_transform_stmt, at tree-vect-stmts.c:10918

[avieira at gcc dot gnu.org]

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from avieira at gcc dot gnu.org ---
I believe this is fixed, closing.

[Bug c/93287] _Static_assert creates spurious -Wdeclaration-after-statement warnings

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
_Static_assert is a declaration in the C standard to allow it to be at the
toplevel too.

Also this fails as expected (on both GCC and Clang):
int f(void)
{
  if (1)
_Static_assert (1);
}

 CUT 
so yes _Static_assert is a declaration.

I would say it is a bug in clang rather than gcc here.
clang documentation is really really lacking here too:
https://clang.llvm.org/docs/DiagnosticsReference.html#wdeclaration-after-statement

:)

GCC is much better:
https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html#index-Wdeclaration-after-statement
-Wdeclaration-after-statement (C and Objective-C only)
Warn when a declaration is found after a statement in a block. This construct,
known from C++, was introduced with ISO C99 and is by default allowed in GCC.
It is not supported by ISO C90. See Mixed Declarations[1].

[1]
https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Mixed-Declarations.html#Mixed-Declarations

[Bug c/93278] huge almost empty array takes huge time to compile and produces huge object file

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Can't reproduce with current trunk (7.x is unsupported, but can't reproduce
with that either):
char a[HUGE] = "x";
./cc1 -fmem-report -O2 -DHUGE=100 pr93278.c
...
 TOTAL  :   0.01  0.00  0.01   
   1383 kB
Assembly is then:
.type   a, @object
.size   a, 100
a:
.string "x"
.zero   98

[Bug lto/93166] [10 Regression] ICE in get_info_about_necessary_edges, at ipa-cp.c:4137 since r278893

[fxue at gcc dot gnu.org]

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

--- Comment #3 from fxue at gcc dot gnu.org ---
(In reply to Martin Jambor from comment #2)
> I have analyzed this ICE and came to the conclusion that the assert is
> wrong for polymorphic context lattices - e.g. in the reported case we
> always pass the same class to first parameter, which in the recursive
> call then serves as a basis to ancestor JF for the second parameter.
> 
> When propagating polymorphic contexts within SCCs we allow creating
> new values because for any sane input their number will be limited by
> class hierarchy (and potential insane input limited by
> param_ipa_cp_value_list_size).  I think that is OK too.
> 
> So we can either simply remove the assert or make it active only for
> tree lattices.  At the moment I'd prefer the former, but Feng, if this
> assert proved valuable in development the recursive function
> versioning patch, I'll be happy to keep it.  What do you think?

Sorry for late response due to trip. I'll check it.

[Bug c/93287] _Static_assert creates spurious -Wdeclaration-after-statement warnings

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Markus F.X.J. Oberhumer from comment #2)
> This is somewhat unexpected, and I do not get any warnings when using clang:
> 
> $ clang-9 -Wdeclaration-after-statement test.c

But clang might be wrong ...

[Bug c/93287] _Static_assert creates spurious -Wdeclaration-after-statement warnings

[markus at oberhumer dot com]

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

--- Comment #2 from Markus F.X.J. Oberhumer  ---
This is somewhat unexpected, and I do not get any warnings when using clang:

$ clang-9 -Wdeclaration-after-statement test.c

[Bug c/93287] _Static_assert creates spurious -Wdeclaration-after-statement warnings

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
_Static_assert is considered a declaration IIRC.

[Bug c/93287] New: _Static_assert creates spurious -Wdeclaration-after-statement warnings

[markus at oberhumer dot com]

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

Bug ID: 93287
   Summary: _Static_assert creates spurious
-Wdeclaration-after-statement warnings
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markus at oberhumer dot com
  Target Milestone: ---

gcc 9 under Fedora 31: gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)

The small program below creates spurious warnings:

$ gcc -Wdeclaration-after-statement test.c

test.c: In function ‘main’:
test.c:4:5: warning: ISO C90 forbids mixed declarations and code
[-Wdeclaration-after-statement]
4 | _Static_assert(1 == 1, "error");
  | ^~


$ cat test.c

int main() {
int r;
r = 0;
_Static_assert(1 == 1, "error");
return r;
}

[Bug rtl-optimization/92176] LRA problem with reloads for subreg operands

[krebbel at gcc dot gnu.org]

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

--- Comment #11 from Andreas Krebbel  ---
(In reply to CVS Commits from comment #10)
> The master branch has been updated by Andreas Krebbel :
> 
> https://gcc.gnu.org/g:3b5757ea87ad2274b841340335bf7536204e615b
> 
> commit r10-5996-g3b5757ea87ad2274b841340335bf7536204e615b
> Author: Andreas Krebbel 
> Date:   Thu Jan 16 10:41:44 2020 +0100
> 
> Work around array out of bounds warning in mkdeps
> 
> This suppresses an array out of bounds warning in mkdeps.c as proposed
> by Martin Sebor in the bugzilla.
> 
> array subscript 2 is outside array bounds of ‘const char [2]’
> 
> Since this warning does occur during bootstrap it currently breaks
> werror builds on IBM Z.
> 
> The problem can be reproduced also on x86_64 by changing the inlining
> threshold using: --param max-inline-insns-auto=80
> 
> Bootstrapped and regression tested on x86_64 and IBM Z.
> 
> libcpp/ChangeLog:
> 
> 2020-01-16  Andreas Krebbel  
> 
>   PR tree-optimization/92176
>   * mkdeps.c (deps_add_default_target): Avoid calling apply_vpath to
>   suppress an array out of bounds warning.

PR number was wrong in the commit - sorry.

[Bug bootstrap/93282] [10 Regression] build failure introduced with the git conversion

[doko at debian dot org]

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

Matthias Klose  changed:

   What|Removed |Added

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

--- Comment #2 from Matthias Klose  ---
my bad, pebcak.

[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE

[markeggleston at gcc dot gnu.org]

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

--- Comment #10 from markeggleston at gcc dot gnu.org ---
This is relevant:

https://gcc.gnu.org/ml/fortran/2017-12/msg00082.html

since the non_recursive keyword is not yet recognised by gfortran, I think it
SHOULD be postponed.

[Bug target/40838] gcc shouldn't assume that the stack is aligned

[ostash at ostash dot kiev.ua]

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

--- Comment #96 from Viktor Ostashevskyi  ---
Honestly, I don't see how your compiler flags could help. cost-model=cheap
is default, data-alignment doesn't change incoming stack alignment.

ср, 15 січ. 2020, 14:31 користувач mahatma at eu dot by <
gcc-bugzi...@gcc.gnu.org> пише:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
>
> --- Comment #95 from Dzianis Kahanovich  ---
> Just FYI. Novadays, on my Thinkpad tablet with Atom (32 bit userspace
> Gentoo),
> I globally replace patch/-mstackrealign to "-fvect-cost-model=cheap
> -fsimd-cost-model=cheap -malign-data=cacheline" and all works fine for -O3
> +.
> (This is dirty example, as cacheline for some old SSE CPUs are different,
> etc).
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE

[markeggleston at gcc dot gnu.org]

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

--- Comment #9 from markeggleston at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #7)
> (In reply to Tobias Burnus from comment #5)
> > Side remark: The Fortran 2018 introduction states:
> > 
> > "the RECURSIVE keyword is advisory only. The NON_RECURSIVE keyword specifies
> > that a procedure is not recursive."
> 
> That's a Fortran 2018 change, see also PR 91413 …
> 
> I am not quite sure what implications this have for -fno-automatic
> -frecursive etc. As those are vendor extensions, it probably just means that
> one just needs to update the documentation.

So for Fortran 2018 the default for a procedure should be recursive and prior
to Fortran 2018 it should should not.

The default standard is GNU which includes everything up Fortran 2018 plus
extensions. When this is used I expect that no thought has been made regarding
the standard so simply implementing the above would break existing programs.

Should this issue be postponed to the stage 1?

[Bug tree-optimization/92429] [10 Regression] ICE in vect_transform_stmt, at tree-vect-stmts.c:10918

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Andre Simoes Dias Vieira
:

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

commit r10-5997-gf7dff7699fd70d3b8c3e637818e18c86f93ccfec
Author: Andre Vieira 
Date:   Thu Jan 16 10:28:02 2020 +

PR tree-optimization/92429 do not fold when updating epilogue statements

This patch addresses the problem reported in PR92429.  When creating an
epilogue for vectorization we have to replace the SSA_NAMEs in the
PATTERN_DEF_SEQs and RELATED_STMTs of the epilogue's loop_vec_infos. When
doing
this we were using simplify_replace_tree which always folds the
replacement.
This may lead to a different tree-node than the one which was analyzed in
vect_loop_analyze.  In turn the new tree-node may require a different
vectorization than the one we had prepared for which caused the ICE in
question.

gcc/ChangeLog:
2020-01-16  Andre Vieira  

PR tree-optimization/92429
* tree-ssa-loop-niter.h (simplify_replace_tree): Add parameter.
* tree-ssa-loop-niter.c (simplify_replace_tree): Add parameter to
control folding.
* tree-vect-loop.c (update_epilogue_vinfo): Do not fold when replacing
tree.

gcc/testsuite/ChangeLog:
2020-01-16  Andre Vieira  

PR tree-optimization/92429
* gcc.dg/vect/pr92429.c: New test.

[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE

[markeggleston at gcc dot gnu.org]

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

--- Comment #8 from markeggleston at gcc dot gnu.org ---
The change to:

if (ns->save_all || (!flag_automatic && !recursive))

Now allows the second example program to produce:

 Hello   1
 Hello   2
 Hello   3
 Hello   4
 Hello   5

instead of:

 Hello   1
 Hello   32766
STOP 1

I'll add the second program as a test case.

[Bug fortran/91413] [F2018]: Procedures are recursive by default; switching from stack to static allocation is not safe

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #6 from Tobias Burnus  ---
Currently, direct recursive use is still not permitted:

Error: Function ‘faculty’ at (1) cannot be called recursively, as it is not
RECURSIVE

This has to be turned into "Error: Fortran 2018: ... without RECURSIVE".

We also have to think about how to handle the -f(no-)automatic -frecursive etc.
with this change. – As "SAVE" is also allowed in recursive functions, we just
need to ensure that the old semantic stays the same and write a few more words
to the documentation.

Regarding -fmax-stack-var-size=n and -fstack-arrays, one also needs to should
point out the implications regarding recursive use, possibly the effect of an
explicit RECURSIVE and Fortran >= 2018.

Regarding the stack to static handling: I think we currently also print the
message if the user has explicitly given "NON_RECURSIVE" as the flag is
currently binary (recursive - true/false) but it should keep track of
(nonspecified, recursive, non_recursive).

[Bug c++/93286] [10 Regression] ICE: tree check: did not expect class ‘type’, have ‘type’ (reference_type) in convert_from_reference, at cp/cvt.c:550 since g:e0d91792eec490d1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-16
  Known to work||9.2.0
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

[Bug c++/93286] New: [10 Regression] ICE: tree check: did not expect class ‘type’, have ‘type’ (reference_type) in convert_from_reference, at cp/cvt.c:550 since g:e0d91792eec490d1

[marxin at gcc dot gnu.org]

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

Bug ID: 93286
   Summary: [10 Regression] ICE: tree check: did not expect class
‘type’, have ‘type’ (reference_type) in
convert_from_reference, at cp/cvt.c:550 since
g:e0d91792eec490d1
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: edlinger at gcc dot gnu.org
  Target Milestone: ---

I see the following ICE:

$ cat effect.ii
template  using __bool_constant = struct A;
template 
struct B : __bool_constant<__is_constructible(int, _Args...)> {};
template  using enable_if_t = int;
template  bool is_constructible_v = B<_Args...>::value;
class C {
  template >>
  C(_Tp &&);
};
using Effect_t = C;
void fn1(Effect_t effect) {
  [](int ) {};
}

$ g++ -fmax-errors=1 -std=c++17 effect.ii -c
effect.ii: In instantiation of ‘struct B’:
effect.ii:5:35:   required from ‘bool is_constructible_v’
effect.ii:7:50:   required by substitution of ‘template
C::C(_Tp&&) [with _Tp = int&&;  = ]’
effect.ii:12:17:   required from here
effect.ii:3:28: internal compiler error: tree check: did not expect class
‘type’, have ‘type’ (reference_type) in convert_from_reference, at cp/cvt.c:550
3 | struct B : __bool_constant<__is_constructible(int, _Args...)> {};
  |^
0x18ae642 tree_not_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.c:9784
0x9cbb02 non_type_check(tree_node*, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.h:3457
0xa5747b convert_from_reference(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/cvt.c:550
0xc59671 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:19865
0xc5b1cd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:20164
0xc53012 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18515
0xc2f384 tsubst_template_arg(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:12069
0xc3306e tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:13136
0xc4125f tsubst(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:15388
0xc3f305 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:14988
0xc2d32c instantiate_class_template_1
/home/marxin/Programming/gcc/gcc/cp/pt.c:11639
0xc2f2da instantiate_class_template(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:12051
0xcf9f6b complete_type(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/typeck.c:137
0xc9717f lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
/home/marxin/Programming/gcc/gcc/cp/search.c:1129
0xb7b010 lookup_qualified_name(tree_node*, tree_node*, int, bool, bool)
/home/marxin/Programming/gcc/gcc/cp/name-lookup.c:6009
0xc435cb tsubst_qualified_id
/home/marxin/Programming/gcc/gcc/cp/pt.c:15980
0xc55c14 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:19184
0xc53012 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18515
0xc43a3e tsubst_init
/home/marxin/Programming/gcc/gcc/cp/pt.c:16067
0xc6de81 regenerate_decl_from_template
/home/marxin/Programming/gcc/gcc/cp/pt.c:24819
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/92176] LRA problem with reloads for subreg operands

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Andreas Krebbel :

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

commit r10-5996-g3b5757ea87ad2274b841340335bf7536204e615b
Author: Andreas Krebbel 
Date:   Thu Jan 16 10:41:44 2020 +0100

Work around array out of bounds warning in mkdeps

This suppresses an array out of bounds warning in mkdeps.c as proposed
by Martin Sebor in the bugzilla.

array subscript 2 is outside array bounds of ‘const char [2]’

Since this warning does occur during bootstrap it currently breaks
werror builds on IBM Z.

The problem can be reproduced also on x86_64 by changing the inlining
threshold using: --param max-inline-insns-auto=80

Bootstrapped and regression tested on x86_64 and IBM Z.

libcpp/ChangeLog:

2020-01-16  Andreas Krebbel  

PR tree-optimization/92176
* mkdeps.c (deps_add_default_target): Avoid calling apply_vpath to
suppress an array out of bounds warning.

[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #7 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #5)
> Side remark: The Fortran 2018 introduction states:
> 
> "the RECURSIVE keyword is advisory only. The NON_RECURSIVE keyword specifies
> that a procedure is not recursive."

That's a Fortran 2018 change, see also PR 91413 …

I am not quite sure what implications this have for -fno-automatic -frecursive
etc. As those are vendor extensions, it probably just means that one just needs
to update the documentation.

[Bug libstdc++/87106] Group move and destruction of the source, where possible, for speed

[redi at gcc dot gnu.org]

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

--- Comment #27 from Jonathan Wakely  ---
>   if constexpr (!is_trivial_v)
> if (is_default_constructible_v<_Tp> && (__OPTIMIZE__+0))

That would need to be 'if constexpr'

I'll stop now.

[Bug libstdc++/87106] Group move and destruction of the source, where possible, for speed

[redi at gcc dot gnu.org]

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

--- Comment #26 from Jonathan Wakely  ---
Or maybe that should be:

  template
struct __is_bitwise_relocatable
: is_trivially_copyable<_Tp> { };

...

  if constexpr (!is_trivial_v)
if (is_default_constructible_v<_Tp> && (__OPTIMIZE__+0))
  std::__uninitialized_default_novalue_n(result, result + count);
else
  {
// can't do bitwise relocation today
...
  }