[Bug libstdc++/91495] std::transform_reduce with unary op is implemented in the parallel case but not the basic case

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-20
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Already fixed on trunk by r272459, it just needs to be backported to the gcc-9
branch.

[Bug libstdc++/91495] std::transform_reduce with unary op is implemented in the parallel case but not the basic case

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |9.3

[Bug ada/91492] [10 regression] Ada documentation issue starting with r274637

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c++/91493] g++ 9.2.1 crashes compiling clickhouse

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-08-20
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Please provide a testcase that can be compiled.

[Bug fortran/91497] New: -Wconversion warns when doing explicit type conversion

[manfred99 at gmx dot ch]

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

Bug ID: 91497
   Summary: -Wconversion warns when doing explicit type conversion
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manfred99 at gmx dot ch
  Target Milestone: ---

real b
  double precision a
  PARAMETER(a=3.1415927d0)

  b=REAL(a)
  b=REAL(a, kind=4)
  end

gives
a.f:5:13:

5 |   b=REAL(a)
  | 1
Warning: Change of value in conversion from 'REAL(8)' to 'REAL(4)' at (1)
[-Wconversion]
a.f:6:13:

6 |   b=REAL(a, kind=4)
  | 1
Warning: Change of value in conversion from 'REAL(8)' to 'REAL(4)' at (1)
[-Wconversion]


for current trunk (no new regression though).


gfortran should not warn about explicit type conversions with REAL(), INT()
etc.
Otherwise there is no possibility to silence this warning.

[Bug tree-optimization/91491] [9 Regression] glib2.0 build not working when built with -O2 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-08-20
   Target Milestone|--- |9.3
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The testcase needs -std=gnu89 to work.

If you compile test_run_seed() with -O1 PRE is already disabled, so you
mean that if you compile the file with -O2 but disable PRE on just
test_run_seed() the testcase works?  But Simon says it's broken when
compilng test_run_seed with -O1 ...

What is true?

There's also a debug counter treepre_insert you could use to further
track down which PRE transform is guilty.  Also try -fno-tree-tail-merge.

The only loop I see in test_run_seed is

  while (strchr (" \t\v\r\n\f", *rseed))
rseed++;

so where does it actually hang?

[Bug middle-end/91490] [9/10 Regression] bogus argument missing terminating nul warning on strlen of a flexible array member

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.3

[Bug ada/91492] [10 regression] Ada documentation issue starting with r274637

[pmderodat at gcc dot gnu.org]

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

pmderodat at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-20
 Ever confirmed|0   |1

--- Comment #2 from pmderodat at gcc dot gnu.org ---
Hello, thank you for reporting this! I somehow failed to submit the
corresponding patch (the testcase is correct). I’ll fix this right now…

[Bug target/91498] New: [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[rguenth at gcc dot gnu.org]

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

Bug ID: 91498
   Summary: [10 Regression] STV change in r274481 causes 300.twolf
regression on Haswell
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Split out from PR91154 comment#25

Biggest changes when benchmarking -mno-stv (base) against -mstv (peak):

   7.28% 37789  twolf_peak.none  twolf_peak.none   [.] ucxx2 
   4.21% 25709  twolf_base.none  twolf_base.none   [.] ucxx2
   3.72% 22584  twolf_base.none  twolf_base.none   [.] new_dbox
   2.48% 22364  twolf_peak.none  twolf_peak.none   [.] new_dbox
   1.49%  8270  twolf_base.none  twolf_base.none   [.] sub_penal
   1.12%  7576  twolf_peak.none  twolf_peak.none   [.] sub_penal
   1.36%  9314  twolf_peak.none  twolf_peak.none   [.] old_assgnto_new2
   1.11%  5257  twolf_base.none  twolf_base.none   [.] old_assgnto_new2

and in ucxx2 I see

  0.17 │   mov%eax,(%rsp)
  3.55 │   vpmins (%rsp),%xmm0,%xmm1   
   │   test   %eax,%eax
  0.22 │   vmovd  %xmm1,%r8d  
  0.80 │   cmovs  %esi,%r8d

...

Testcase:

extern int numBins;
extern int binOffst;
extern int binWidth;
extern int Trybin;
void foo (int);

void bar (int aleft, int axcenter)
{
  int a1LoBin = (((Trybin=((axcenter + aleft)-binOffst)/binWidth)<0)
 ? 0 : ((Trybin>numBins) ? numBins : Trybin));
  foo (a1LoBin);
}

where combine eliminates the reg-reg copies STV adds to split live-ranges
between GPR and SSE uses (currently one plain move and one set via
vec_merge/duplicate).

Making STV of SI/DImode chains always happen after combine (in STV2) fixes
the testcase above but regresses gcc.target/i386/minmax-6.c which ran into
a very similar issue and was reduced from a SPEC CPU 2006 regression observed.

In the end the issue is that as soon as the RA decides it needs to spill
for a dual-use pseudo it ends up going through the stack because of, as
HJ notices, the minimum cost of moves between SSE and integer units is 8:

  /* Moves between SSE and integer units are expensive.  */
  if (SSE_CLASS_P (class1) != SSE_CLASS_P (class2))

/* ??? By keeping returned value relatively high, we limit the number
   of moves between integer and SSE registers for all targets.
   Additionally, high value prevents problem with x86_modes_tieable_p(),
   where integer modes in SSE registers are not tieable
   because of missing QImode and HImode moves to, from or between
   MMX/SSE registers.  */
return MAX (8, SSE_CLASS_P (class1)
? ix86_cost->hard_register.sse_to_integer
: ix86_cost->hard_register.integer_to_sse);

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization, ra
 Target||x86_64-*-* i?86-*-*
 CC||hjl.tools at gmail dot com,
   ||uros at gcc dot gnu.org
   Target Milestone|--- |10.0

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Patch that causes gcc.target/i386/minmax-6.c to spill to the stack:
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01283.html

This makes SI/DImode chains handled by STV2 only (after combine).  We can
take it from there if we think that's what we need to do anyways.  In the
end it's STV/RA interaction, I guess if we can take combine out of the
equation it might simplify things.

[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922

[rguenth at gcc dot gnu.org]

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

--- Comment #33 from Richard Biener  ---
(In reply to Uroš Bizjak from comment #32)
> (In reply to H.J. Lu from comment #31)
> 
> > > No, IMO IRA should be "fixed" to avoid stack temporary and (based on some
> > > cost metric) use direct move for paradoxical subregs.
> > 
> > The problem is
> > 
> >   /* Moves between SSE and integer units are expensive.  */
> >   if (SSE_CLASS_P (class1) != SSE_CLASS_P (class2))
> > 
> > /* ??? By keeping returned value relatively high, we limit the number
> >of moves between integer and SSE registers for all targets.
> >Additionally, high value prevents problem with x86_modes_tieable_p(),
> >where integer modes in SSE registers are not tieable
> >because of missing QImode and HImode moves to, from or between
> >MMX/SSE registers.  */
> > return MAX (8, SSE_CLASS_P (class1)
> > ? ix86_cost->hard_register.sse_to_integer
> > : ix86_cost->hard_register.integer_to_sse);
> > 
> > The minimum cost of moves between SSE and integer units is 8.
> 
> I guess this should be reviewed. This is from reload time, nowadays we never
> actually disable sse <-> int moves, we use preferred_for_{speed,size}
> attributes. Also, at least for TARGET_MMX_WITH_SSE targets, we can change
> the penalty for MMX moves.
> 
> These sort of changes should be backed by runtime benchmark results.
> 
> Thanks for heads up, but let's take this cost issue elsewhere.

I think it's related but since we were asked to keep this PR open also for
other targets I've created PR91498 for the 300.twolf regression and this
RA/costing issue.

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #1)
> Patch that causes gcc.target/i386/minmax-6.c to spill to the stack:
> https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01283.html
> 
> This makes SI/DImode chains handled by STV2 only (after combine).  We can
> take it from there if we think that's what we need to do anyways.  In the
> end it's STV/RA interaction, I guess if we can take combine out of the
> equation it might simplify things.

Yes, this is the intended way SI/DImode STV should be used.

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Tue Aug 20 08:45:56 2019
New Revision: 274694

URL: https://gcc.gnu.org/viewcvs?rev=274694&root=gcc&view=rev
Log:
2019-08-20  Richard Biener  

PR target/91498
* config/i386/i386-features.c (general_scalar_chain::convert_op):
Use (vec_merge (vec_duplicate..)) style vector from scalar move.
(convert_scalars_to_vector): Add timode_p parameter and use it
to guard TImode-only operation.
(pass_stv::gate): Adjust so STV runs twice for TARGET_64BIT.
(pass_stv::execute): Pass down timode_p.

* gcc.target/i386/minmax-7.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/minmax-7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-features.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/91307] -flto causes binary to vary

[gccbmw at lsmod dot de]

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

--- Comment #10 from Bernhard M. Wiedemann  ---
After a full rebuild of openSUSE Tumbleweed, the GLOBAL__I_65535_ string
appears in diffs of 12 packages:
blog
libpt2
lodepng
nethogs
nodejs12
nvme-cli
python-python-crfsuite
qpid-cpp
Rivet
udp2raw-tunnel
udpspeeder
yate-bts

Of those, qpid-cpp Rivet were already unreproducible without LTO.

[Bug rtl-optimization/91347] [7/8/9/10 Regression] hppa: wrong code generated with tail call optimisation

[ebotcazou at gcc dot gnu.org]

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

--- Comment #19 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Aug 20 09:10:53 2019
New Revision: 274708

URL: https://gcc.gnu.org/viewcvs?rev=274708&root=gcc&view=rev
Log:
PR rtl-optimization/91347
* dse.c (scan_insn): Call add_wild_read for non-const/memset tail calls
before reload if HARD_FRAME_POINTER_IS_ARG_POINTER.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20190820-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dse.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/91347] [7/8/9/10 Regression] hppa: wrong code generated with tail call optimisation

[ebotcazou at gcc dot gnu.org]

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

--- Comment #20 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Aug 20 09:13:29 2019
New Revision: 274709

URL: https://gcc.gnu.org/viewcvs?rev=274709&root=gcc&view=rev
Log:
PR rtl-optimization/91347
* dse.c (scan_insn): Call add_wild_read for non-const/memset tail calls
before reload if HARD_FRAME_POINTER_IS_ARG_POINTER.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/execute/20190820-1.c
  - copied unchanged from r274708,
trunk/gcc/testsuite/gcc.c-torture/execute/20190820-1.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/dse.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/91347] [7/8/9/10 Regression] hppa: wrong code generated with tail call optimisation

[ebotcazou at gcc dot gnu.org]

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

--- Comment #21 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Aug 20 09:15:27 2019
New Revision: 274710

URL: https://gcc.gnu.org/viewcvs?rev=274710&root=gcc&view=rev
Log:
PR rtl-optimization/91347
* dse.c (scan_insn): Call add_wild_read for non-const/memset tail calls
before reload if HARD_FRAME_POINTER_IS_ARG_POINTER.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/execute/20190820-1.c
  - copied unchanged from r274709,
trunk/gcc/testsuite/gcc.c-torture/execute/20190820-1.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/dse.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/91347] [7/8/9/10 Regression] hppa: wrong code generated with tail call optimisation

[ebotcazou at gcc dot gnu.org]

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

--- Comment #22 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Aug 20 09:17:04 2019
New Revision: 274711

URL: https://gcc.gnu.org/viewcvs?rev=274711&root=gcc&view=rev
Log:
PR rtl-optimization/91347
* dse.c (scan_insn): Call add_wild_read for non-const/memset tail calls
before reload if HARD_FRAME_POINTER_IS_ARG_POINTER.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/execute/20190820-1.c
  - copied unchanged from r274710,
trunk/gcc/testsuite/gcc.c-torture/execute/20190820-1.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/dse.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/91347] [7/8/9/10 Regression] hppa: wrong code generated with tail call optimisation

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #23 from Eric Botcazou  ---
Fixed on all active branches.

[Bug ada/91492] [10 regression] Ada documentation issue starting with r274637

[pmderodat at gcc dot gnu.org]

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

--- Comment #3 from pmderodat at gcc dot gnu.org ---
Author: pmderodat
Date: Tue Aug 20 09:47:44 2019
New Revision: 274714

URL: https://gcc.gnu.org/viewcvs?rev=274714&root=gcc&view=rev
Log:
[Ada] Add missing dot at the end of lang.opt doc for -fdump-scos

2019-08-20  Pierre-Marie de Rodat  

gcc/ada/

PR ada/91492
* gcc-interface/lang.opt (-fdump-scos): Add missing dot at the
end of the documentation.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/lang.opt

[Bug libstdc++/91488] [9/10 Regression] char_traits::length causes "inlining failed in call to always_inline" error with -fgnu-tm -O2 -std=c++17

[ensadc at mailnesia dot com]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #1 from ensadc at mailnesia dot com ---
It seems that the inliner does not like the `static` specifier in
`__constant_string_p`. This also triggers "inlining failed in call to
always_inline" error:

static __attribute__((always_inline)) constexpr bool
f()
{
return __builtin_is_constant_evaluated();
}

int main() {
(void)f();
}

[Bug ada/91492] [10 regression] Ada documentation issue starting with r274637

[pmderodat at gcc dot gnu.org]

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

--- Comment #4 from pmderodat at gcc dot gnu.org ---
I just commited the fix. Can you double check that the test failure is fixed?

[Bug c++/91499] New: Compile error when trying to aggregate-initialize a member array of non-movable objects with virtual functions

[l2m at ukr dot net]

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

Bug ID: 91499
   Summary: Compile error when trying to aggregate-initialize a
member array of non-movable objects with virtual
functions
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: l2m at ukr dot net
  Target Milestone: ---

Created attachment 46733
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46733&action=edit
Output of "gcc -v" and the compilation error

This bug report is based on the stackoverflow discussion that can be found
here:
https://stackoverflow.com/questions/57559634/initialization-of-an-array-of-non-moveable-objects-why-does-such-code-fail-to-c

Here's the code that fails to compile on GCC:


class Test // non-copyable and non-movable class with virtual functions
{
public:
Test() = delete;

Test(const Test&) = delete;
Test(Test&&) = delete;
Test& operator=(const Test&) = delete;
Test& operator=(Test&&) = delete;

Test(int a, int b) : a_(a), b_(b) {}
virtual ~Test() {}

int a_;
int b_;
};

//

class B
{
public:
/*(1)*/ B() : test_{{1, 2}, {3, 4}} {} // Does not compile on GCC

private:
Test test_[2];
};

// 

int main()
{
B b;
Test test[2] = {{1, 2}, {3, 4}}; // Successfully compiles
}


GCC 9.2 outputs:

: In constructor 'B::B()':
:23:35: error: use of deleted function 'Test::Test(Test&&)'
   23 | /*(1)*/ B() : test_{{1, 2}, {3, 4}} {} // Does not compile on GCC
  |   ^
:7:5: note: declared here
7 | Test(Test&&) = delete;
  | ^~~~

Other related information (the system type, the options given when GCC was
configured/built, the complete command line that triggers the bug, the compiler
output) is contained in the attached text file. Basically, this output was
taken from the https://godbolt.org/ online compiler. But all other compilers
that I've tried give the same error.
A preprocessed file (*.i*) is NOT included because I have "reduced the testcase
to a small file that doesn't include any other file" (item "ii" from Detailed
bug reporting instructions).

As explained by user L. F. on stackoverflow, this code is expected to be
compiled successfully without requiring a move constructor.

[Bug c++/91500] New: [9 REGRESSION] gcc-9 ICE on valid code

[costamagnagianfranco at yahoo dot it]

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

Bug ID: 91500
   Summary: [9 REGRESSION] gcc-9 ICE on valid code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: costamagnagianfranco at yahoo dot it
  Target Milestone: ---

Created attachment 46734
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46734&action=edit
preprocessed sources and log file

I'm attaching the log returned by the command, and the preprocessed source

uname -a
Linux 5.0.0-23-generic #24~18.04.1-Ubuntu SMP Mon Jul 29 16:12:28 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux


Its a chroot of Ubuntu devel, g++-9.2.0-1ubuntu1

building with g++-8 works.

Please let me know if I missed anything

[Bug c++/91500] [9 Regression] gcc-9 ICE on valid code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||10.0, 8.3.0
   Keywords||needs-bisection,
   ||needs-reduction
   Last reconfirmed||2019-08-20
 Ever confirmed|0   |1
Summary|[9 REGRESSION] gcc-9 ICE on |[9 Regression] gcc-9 ICE on
   |valid code  |valid code
   Target Milestone|--- |9.3
  Known to fail||9.1.0, 9.2.1

--- Comment #1 from Richard Biener  ---
Confirmed on the branch.  Trunk seems to work.  Cannot verify GCC 8 because the
preprocessed source contains __builtin_constant_evaluated calls.

[Bug c++/91500] [9 Regression] gcc-9 ICE on valid code

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
> ./cc1plus -quiet ccOfXKGA.ii -std=c++17
/clickhouse-18.16.1+ds/dbms/src/Storages/ColumnDefault.cpp: In function
‘std::string DB::toString(DB::ColumnDefaultKind)’:
/clickhouse-18.16.1+ds/dbms/src/Storages/ColumnDefault.cpp:47:117: internal
compiler error: in ocp_convert, at cp/cvt.c:766
0x933e66 ocp_convert(tree_node*, tree_node*, int, int, int)
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/cvt.c:766
0x93699c convert(tree_node*, tree_node*)
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/cvt.c:1637
0xbd0e11 check_return_expr(tree_node*, bool*)
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/typeck.c:9800
0xb57af5 finish_return_stmt(tree_node*)
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/semantics.c:894
0xa655b0 cp_parser_jump_statement
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/parser.c:12919
0xa61762 cp_parser_statement
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/parser.c:11191
0xa62697 cp_parser_statement_seq_opt
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/parser.c:11657
0xa6258b cp_parser_compound_statement
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/parser.c:11611
0xa773b5 cp_parser_function_body
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/parser.c:22662
0xa776db cp_parser_ctor_initializer_opt_and_function_body
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/parser.c:22711
0xa813b2 cp_parser_function_definition_after_declarator
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/parser.c:27812
0xa811d9 cp_parser_function_definition_from_specifiers_and_declarator
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/parser.c:27729
0xa72de2 cp_parser_init_declarator
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/parser.c:20297
0xa668c2 cp_parser_simple_declaration
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/parser.c:13551
0xa6648b cp_parser_block_declaration
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/parser.c:13367
0xa66170 cp_parser_declaration
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/parser.c:13238
0xa6626b cp_parser_toplevel_declaration
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/parser.c:13267
0xa65cc6 cp_parser_declaration_seq_opt
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/parser.c:13114
0xa70ca9 cp_parser_namespace_body
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/parser.c:19327
0xa70c53 cp_parser_namespace_definition
/space/rguenther/src/svn/gcc-9-branch/gcc/cp/parser.c:19305
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/91499] Compile error when trying to aggregate-initialize a member array of non-movable objects with user-defined destructor

[l2m at ukr dot net]

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

--- Comment #1 from Taras  ---
(In reply to Taras from comment #0)
> 
> Here's the code that fails to compile on GCC:
> 
> class Test // non-copyable and non-movable class with virtual functions
> {

upd.:

The destructor isn't necessarily required to be virtual in this example -- the
same error occurs without the "virtual" keyword, as long as Test's destructor
has a user-defined body:
  ~Test() {}
^ does NOT compile as well

but:
  ~Test() = default; // or if there's no explicitly mentioned destructor at all
^ compiles successfully

however:
  virtual ~Test() = default;
^ does NOT compile

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
Following patch

--cut here--
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 49ab50ea41bf..11c75be113e0 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -18601,9 +18601,9 @@ ix86_register_move_cost (machine_mode mode, reg_class_t
class1_i,
where integer modes in SSE registers are not tieable
because of missing QImode and HImode moves to, from or between
MMX/SSE registers.  */
-return MAX (8, SSE_CLASS_P (class1)
-   ? ix86_cost->hard_register.sse_to_integer
-   : ix86_cost->hard_register.integer_to_sse);
+return (SSE_CLASS_P (class1)
+   ? ix86_cost->hard_register.sse_to_integer
+   : ix86_cost->hard_register.integer_to_sse);

   if (MAYBE_FLOAT_CLASS_P (class1))
 return ix86_cost->hard_register.fp_move;
--cut here--

fixes the regression.

(BTW: QI/HImodes are not "missing" at all. We can use %k modifier to move
QImode and HImode values using MOVD instruction between register sets.)

[Bug tree-optimization/91482] __builtin_assume_aligned should not break write combining

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
So the easiest thing is to move the last forwprop pass across phiopt and after
fold_builtins.  Another possibility would be to get rid of the redundant
second __builtin_assume_aligned as soon as we discover that (in CCP).

Testing the latter.

[Bug sanitizer/91455] [10 Regression] Revision r274426 breaks bootstrap on darwin

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #3 from Iain Sandoe  ---
fixed by r 274538

[Bug tree-optimization/37242] missed FRE opportunity because of signedness of addition

[rguenth at gcc dot gnu.org]

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

--- Comment #28 from Richard Biener  ---
Author: rguenth
Date: Tue Aug 20 12:02:56 2019
New Revision: 274746

URL: https://gcc.gnu.org/viewcvs?rev=274746&root=gcc&view=rev
Log:
2019-08-20  Richard Biener  

PR tree-optimization/37242
* tree-ssa-sccvn.c (visit_nary_op): Also CSE (T)(a + b)
to (T)a + (T)b if we know that a + b does not overflow.

* gcc.dg/tree-ssa/ssa-fre-80.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-80.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/22586] GVN-PRE could do strength reduction

[rguenth at gcc dot gnu.org]

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

Bug 37242 Summary: missed FRE opportunity because of signedness of addition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37242

   What|Removed |Added

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

[Bug tree-optimization/37242] missed FRE opportunity because of signedness of addition

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||10.0
 Resolution|--- |FIXED

--- Comment #27 from Richard Biener  ---
Fixed on trunk.

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #4)
> Following patch

HJ, can you please put the patch through some benchmarks? (I have no access to
SPEC).

[Bug tree-optimization/91491] [9 Regression] glib2.0 build not working when built with -O2 on x86_64-linux-gnu

[smcv at debian dot org]

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

Simon McVittie  changed:

   What|Removed |Added

 CC||smcv at debian dot org

--- Comment #2 from Simon McVittie  ---
> where does it actually hang?

The GLib tests don't hang. The smallest reproducer we have is unfortunately
still really complicated.

The test-case that hangs is to install precompiled test binaries from the
Clutter graphics library, from the
https://packages.debian.org/unstable/clutter-1.0-tests Debian package, and run
one of those (actor-offscreen-redirect is known to be affected but is not the
only one), with the GLib library under test placed in the LD_LIBRARY_PATH.

The test runs a GLib event loop (a poll-based event loop similar to
libevent/libuv/any other general-purpose event loop library), and expects a
callback attached to the Clutter graphics library's rendering path to call
g_main_loop_quit(), which "wakes up" the main loop by writing to a pipe-to-self
or eventfd, then broadcasting on a condition variable.

In the cases where the test fails, the failure mode is that the callback that
should have run g_main_loop_quit() is never reached. I think this may be
something to do with the "paint clock" in Clutter that aims to draw animated
window contents once per 60Hz screen refresh, but I don't know Clutter well
enough to know what, specifically, should happen but does not.

At the moment I have no idea why changing the optimizations that are applied to
test_run_seed() (which is part of GLib's unit test framework, and computes a
predictable seed for random numbers generated during a unit test) would have an
effect on the Clutter graphics library's X11 rendering, or on whether the event
loop terminates.

GLib's own test suite still passes, even in the builds that break the Clutter
test - so the event loop isn't *completely* broken.

> But Simon says it's broken when
> compilng test_run_seed with -O1 ...

Sorry, where did I say that? I don't think that's the case.

Summary of my findings, where "good" means the Clutter test passes, and "bad"
means the failure mode described above:

* all of GLib with gcc-8 -O2: good
* all of GLib with gcc-9 -O2: bad
* all of GLib with gcc-9 -O1: good
* all of GLib with gcc-9 -O2, except gtestutils.c with -O1: good
* all of GLib with gcc-9 -O2, except test_run_seed() reduced to -O1
  via an __attribute__: good
* all of GLib with gcc-9 -O2, except test_run_seed() with
  __attribute__((optimize("no-tree-pre"))): good

> so you
> mean that if you compile the file with -O2 but disable PRE on just
> test_run_seed() the testcase works?

Yes. This was enough to get the "good" result:
https://salsa.debian.org/gnome-team/glib/blob/debian/2.60.6-2/debian/patches/debian/Disable-an-optimization-when-building-with-gcc-9.patch

[Bug c++/91500] [9 Regression] gcc-9 ICE on valid code

[rafaeldtinoco at ubuntu dot com]

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

Rafael David Tinoco  changed:

   What|Removed |Added

 CC||rafaeldtinoco at ubuntu dot com

--- Comment #3 from Rafael David Tinoco  ---
Related:

https://github.com/yandex/ClickHouse/issues/6560
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91493

[Bug ada/91492] [10 regression] Ada documentation issue starting with r274637

[seurer at gcc dot gnu.org]

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

--- Comment #5 from seurer at gcc dot gnu.org ---
It looks like all is well now:

New passes:
FAIL: compiler driver --help=ada option(s): "^ +-.*[^:.]\$" absent from output:
"  -fdump-scos Dump Source Coverage Obligations"

[Bug tree-optimization/91491] [9 Regression] glib2.0 build not working when built with -O2 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Eh, "interesting".  Thanks for the clarifications.

I suppose you did things like running under valgrind or compiling with
-fsanitize=address.  The most obvious thing I expect from -fno-tree-pre
is stack layout changes which then smells like some bogus stack smashing
going on.  Can you try building gtestutils.c with
-O2 -fno-optimize-sibling-calls?

[Bug lto/91307] -flto causes binary to vary

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Tue Aug 20 13:14:59 2019
New Revision: 274748

URL: https://gcc.gnu.org/viewcvs?rev=274748&root=gcc&view=rev
Log:
2019-08-20  Richard Biener  

PR lto/91307
* ipa.c (cgraph_build_static_cdtor_1): Use names not recognizable
by collect2 when targetm.have_ctors_dtors which avoids dragging
in temporary filenames from LTO input objects.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa.c

[Bug c++/91500] [9 Regression] gcc-9 ICE on valid code

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
I bet this is 90393 which was just fixed by r274550 on trunk and r274597 on
gcc-9-branch.  gcc8 is not affected.

Verified both trunk and gcc 9.

[Bug target/90834] Header and startup objects not found on macOS 10.15

[iains at gcc dot gnu.org]

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

--- Comment #13 from Iain Sandoe  ---
The /usr/local/include thing needs to be handled carefully

"bare" clang (at least up to 9.x) behaves as per GCC, and prepends a given
--sysroot= to the usr/local paths too.

This is correct; imagine that you want to do a cross-compile to a different
Darwin version, so you do ...

... gcc --sysroot=/path/to/darwinXX/SDK -mmacosx-version-min=XX foo.c ... 

you *do not* want that compile line to look in /usr/local/include - since that
directory might have nothing to do with darwinXX (imagine different APIs).

So, if we wanted to do something "automatic" it would have to be predicated on:
1) That there was no --with-sysroot= given at configure time
2) That this is not a cross-compiler
3) That there is no --sysroot= on the invocation line
4) That target = host at invocation time



While one could do something at configure time to choose between "/" and
"Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" based on build=host=target
and what the build system has installed, that's guaranteed to fail if the built
compiler is moved to a system with different configuration.

So, we keep coming back to needing something at invocation time - and that
something needs to be efficient (i.e. not a process launch)

[Bug lto/91307] -flto causes binary to vary

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||10.0
 Resolution|--- |FIXED

--- Comment #12 from Richard Biener  ---
Fixed for trunk.

[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #34 from Rainer Orth  ---
Some of the new testcases FAIL on 32-bit x86:

+FAIL: gcc.target/i386/minmax-4.c scan-assembler-times pmaxsd 1
+FAIL: gcc.target/i386/minmax-4.c scan-assembler-times pmaxud 1
+FAIL: gcc.target/i386/minmax-4.c scan-assembler-times pminsd 1
+FAIL: gcc.target/i386/minmax-4.c scan-assembler-times pminud 1
+FAIL: gcc.target/i386/minmax-5.c scan-assembler-times vpmaxsd 1
+FAIL: gcc.target/i386/minmax-5.c scan-assembler-times vpmaxud 1
+FAIL: gcc.target/i386/minmax-5.c scan-assembler-times vpminsd 1
+FAIL: gcc.target/i386/minmax-5.c scan-assembler-times vpminud 1
+FAIL: gcc.target/i386/minmax-6.c scan-assembler pmaxsd

This group is only seen on i386-pc-solaris2.11 while ...

+FAIL: gcc.target/i386/pr91154.c scan-assembler-not cmov
+FAIL: gcc.target/i386/pr91154.c scan-assembler-times paddd 2
+FAIL: gcc.target/i386/pr91154.c scan-assembler-times pmaxsd 2

... for this one there are also couple of gcc-testresults reports on
x86_64-pc-linux-gnu.

[Bug ada/91492] [10 regression] Ada documentation issue starting with r274637

[pmderodat at gcc dot gnu.org]

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

pmderodat at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from pmderodat at gcc dot gnu.org ---
Great, thanks! Sorry for the inconvenience…

[Bug c++/91501] New: Stack Optimization bug on function and lambda return

[baptiste.cartier at ertosgener dot com]

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

Bug ID: 91501
   Summary: Stack Optimization bug on function and lambda return
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baptiste.cartier at ertosgener dot com
  Target Milestone: ---

Created attachment 46735
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46735&action=edit
Preprocessed test file

When calling a function or a lambda to create function arguments, the stack is
not reused properly.

This bug was discovered using the 8-2019-q3-update of ARM GCC, but it appears
it also exists in GCC.

Discussion about this bug can be found here (for the ARM version of GCC) :
https://community.arm.com/developer/tools-software/tools/f/arm-compilers-forum/13366/arm-gcc-lambda-optimization/159463#159463

Link to online compiler test case : https://godbolt.org/z/hx2cEU

Attached is the preprocessed test case.

The problem with the following example code is :

wrapper2LAMBDA uses 32 bytes more of stack than wrapper1LAMBDA (ie the size of
the structure), but it should not, the stack should be reused for further
structures.


struct TestStruct
{
uint32_t field1;
uint32_t field2;
uint32_t field3;
uint32_t field4;

uint32_t field11;
uint32_t field21;
uint32_t field31;
uint32_t field41;
} ;

struct TestStruct initStructure(uint32_t f1, uint32_t f2, uint32_t f3,
uint32_t f4,uint32_t f11, uint32_t f21, uint32_t f31, uint32_t f41)
{
struct TestStruct myStruct;
myStruct.field1 = f1;
myStruct.field2 = f2;
myStruct.field3 = f3;
myStruct.field4 = f4;

myStruct.field11 = f11;
myStruct.field21 = f21;
myStruct.field31 = f31;
myStruct.field41 = f41;

return myStruct;
}

#define MACROLAMBDA(f1,f2,f3,f4,f5,f6,f7,f8) \
[&]() -> struct TestStruct { struct TestStruct ${}; \
$.field1 = f1; \
$.field2 = f2; \
$.field3 = f3; \
$.field4 = f4; \
$.field11 = f5; \
$.field21 = f6; \
$.field31 = f7; \
$.field41 = f8; \
return $; \
}()

void __attribute__((noinline)) doStuff(struct TestStruct myStruct)
{
printf("f1 = %d, f2 = %d, f3 = %d, f4 = %d, f1 = %d, f2 = %d, f3 = %d,
f4 = %d", myStruct.field1, myStruct.field2, myStruct.field3,
myStruct.field4,myStruct.field11, myStruct.field21, myStruct.field31,
myStruct.field41);
}

void __attribute__((noinline)) wrapper2LAMBDA(void)
{
doStuff(MACROLAMBDA(1,2,3,4,5,6,7,8));
doStuff(MACROLAMBDA(11,22,33,44,55,66,77,88));
}

void __attribute__((noinline)) wrapper1LAMBDA(void)
{
doStuff(MACROLAMBDA(1,2,3,4,5,6,7,8));
}

---

The assembly generated for both functions are :

--
_Z14wrapper2LAMBDAv:
movabs  rax, 8589934593
sub rsp, 72
mov QWORD PTR [rsp], rax
movabs  rax, 17179869187
mov QWORD PTR [rsp+8], rax
movabs  rax, 25769803781
mov QWORD PTR [rsp+16], rax
movabs  rax, 34359738375
mov QWORD PTR [rsp+24], rax
pushQWORD PTR [rsp+24]
pushQWORD PTR [rsp+24]
pushQWORD PTR [rsp+24]
pushQWORD PTR [rsp+24]
call_Z7doStuff10TestStruct
movabs  rax, 94489280523
mov QWORD PTR [rsp+64], rax
movabs  rax, 188978561057
mov QWORD PTR [rsp+72], rax
movabs  rax, 283467841591
mov QWORD PTR [rsp+80], rax
movabs  rax, 377957122125
mov QWORD PTR [rsp+88], rax
add rsp, 32
pushQWORD PTR [rsp+56]
pushQWORD PTR [rsp+56]
pushQWORD PTR [rsp+56]
pushQWORD PTR [rsp+56]
call_Z7doStuff10TestStruct
add rsp, 104
ret
_Z14wrapper1LAMBDAv:
movabs  rax, 8589934593
sub rsp, 40
mov QWORD PTR [rsp], rax
movabs  rax, 17179869187
mov QWORD PTR [rsp+8], rax
movabs  rax, 25769803781
mov QWORD PTR [rsp+16], rax
movabs  rax, 34359738375
mov QWORD PTR [rsp+24], rax
pushQWORD PTR [rsp+24]
pushQWORD PTR [rsp+24]
pushQWORD PTR [rsp+24]
pushQWORD PTR [rsp+24]
call_Z7doStuff10TestStruct
add rsp, 72
ret
--

"sub rsp, 72 " for wrapper2LAMBDA and "sub rsp, 40" for wrapper1LAMBDA
is what makes me believe stack is not reused, or that there is some dead stack.

The same behavior happen with ARM ASM

"subsp, sp, #80" for wrapper2LAMBDA and "subsp, sp, #52" for
wrapper1LAMBDA.

This also happ

[Bug libgomp/91473] Test case libgomp.fortran/appendix-a/a.28.5.f90 is invalid

[seurer at gcc dot gnu.org]

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

--- Comment #8 from seurer at gcc dot gnu.org ---
So for 481.wrf in cpu2006 add this to the config:

FPORTABILITY = -std=legacy

Add the same for 178.galgel, 187.facerec, and 191.fma3d in cpu2000.

For 200.sixtrack and 301.apsi in cpu2000 for some reason I had to use

PORTABILITY = -std=legacy

[Bug tree-optimization/21485] [7/8/9/10 Regression] missed load PRE, PRE makes i?87/8/9/10 suck

[egallager at gcc dot gnu.org]

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

--- Comment #67 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #49)
> PR 37242 is also needed from what I remember reading the IR.

That's fixed now.

[Bug c++/91493] g++ 9.2.1 crashes compiling clickhouse

[rafaeldtinoco at ubuntu dot com]

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

--- Comment #2 from Rafael David Tinoco  ---
Related:

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

Possibly a duplicate.

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Uroš Bizjak from comment #4)
> > Following patch
> 
> HJ, can you please put the patch through some benchmarks? (I have no access
> to SPEC).

Sure. We will measure it.  Thanks.

[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532

[sje at gcc dot gnu.org]

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

--- Comment #17 from Steve Ellcey  ---
The bug I was seeing on aarch64 turns out to be PR 91404.  It has now been
fixed.  I don't know if that patch will also fix the original bug seen on
Darwin or not.

[Bug pch/90306] ICE when using precompiled headers with -MD and -fpch-deps

[gcc at scarsita dot it]

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

Luca Bonissi  changed:

   What|Removed |Added

 CC||gcc at scarsita dot it

--- Comment #4 from Luca Bonissi  ---
Similar behavior when compiling openjdk 1.8 with gcc 9.1 or 9.2 (tried on
x86_64, armv5te, armv7hl, aarch64):

CACHE_COMPRESS=1  CCACHE_SLOPPINESS=time_macros /usr/bin/ccache /usr/bin/g++
-DLINUX -D_GNU_SOURCE -DAMD64 -DPRODUCT -I. -I/root/tmp/jdk-build
/openjdk-boot/hotspot/src/share/vm/prims
-I/root/tmp/jdk-build/openjdk-boot/hotspot/src/share/vm
-I/root/tmp/jdk-build/openjdk-boot/hotspot/sr
c/share/vm/precompiled
-I/root/tmp/jdk-build/openjdk-boot/hotspot/src/cpu/x86/vm
-I/root/tmp/jdk-build/openjdk-boot/hotspot/src/os_cpu/linux_x
86/vm -I/root/tmp/jdk-build/openjdk-boot/hotspot/src/os/linux/vm
-I/root/tmp/jdk-build/openjdk-boot/hotspot/src/os/posix/vm -I../generated -DH
OTSPOT_RELEASE_VERSION="\"25.222-b10\"" -DHOTSPOT_BUILD_TARGET="\"product\""
-DHOTSPOT_BUILD_USER="\"root\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHO
TSPOT_VM_DISTRO="\"OpenJDK\"" -DDERIVATIVE_ID="\"IcedTea 3.13.0\""
-DDISTRIBUTION_ID="\"Custom build (Tue Aug 20 15:45:08 CEST 2019)\""  -DTAR
GET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64
-DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPI
LER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT
-fcheck-new -fvisibility=hidden -m64  -pipe -fno-strict-aliasing
 -g -fno-omit-frame-pointer -O3  -DVM_LITTLE_ENDIAN -D_LP64=1  -Wpointer-arith
-Wsign-compare -Wundef -Wunused-function -Wunused-value -Wretur
n-type   -fstack-protector -g -O2 -fno-delete-null-pointer-checks
-fno-lifetime-dse -std=gnu++98  -c -MMD -MP -MF ../generated/dependencies/ac
cessFlags.o.d -fpch-deps -o accessFlags.o
/root/tmp/jdk-build/openjdk-boot/hotspot/src/share/vm/utilities/accessFlags.cpp
/root/tmp/jdk-build/openjdk-boot/hotspot/src/share/vm/precompiled/precompiled.hpp:1:
internal compiler error: Segmentation fault
1 | /*
  |
0xb83cef crash_signal
../../gcc-9.2.0/gcc/toplev.c:326
0x13c23fd apply_vpath
../../gcc-9.2.0/libcpp/mkdeps.c:127
0x13c285d deps_add_dep(deps*, char const*)
../../gcc-9.2.0/libcpp/mkdeps.c:258
0x13c2e8d deps_restore(deps*, _IO_FILE*, char const*)
../../gcc-9.2.0/libcpp/mkdeps.c:432
0x13c3f3c cpp_read_state(cpp_reader*, char const*, _IO_FILE*, save_macro_data*)
../../gcc-9.2.0/libcpp/pch.c:859
0x78eacb c_common_read_pch(cpp_reader*, char const*, int, char const*)
../../gcc-9.2.0/gcc/c-family/c-pch.c:365
0x13b469f should_stack_file
../../gcc-9.2.0/libcpp/files.c:814
0x13b469f _cpp_stack_file
../../gcc-9.2.0/libcpp/files.c:900
0x13abc4b do_include_common
../../gcc-9.2.0/libcpp/directives.c:846
0x13ac760 _cpp_handle_directive
../../gcc-9.2.0/libcpp/directives.c:541
0x13bae54 _cpp_lex_token
../../gcc-9.2.0/libcpp/lex.c:2609
0x13c1c37 cpp_get_token_1
../../gcc-9.2.0/libcpp/macro.c:2703
0x787c7e c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
../../gcc-9.2.0/gcc/c-family/c-lex.c:405
0x69ba3e cp_lexer_get_preprocessor_token
../../gcc-9.2.0/gcc/cp/parser.c:790
0x6d3437 cp_parser_initial_pragma
../../gcc-9.2.0/gcc/cp/parser.c:40747
0x6d3437 cp_lexer_new_main
../../gcc-9.2.0/gcc/cp/parser.c:644
0x6d3437 cp_parser_new
../../gcc-9.2.0/gcc/cp/parser.c:3936
0x6d3437 c_parse_file()
../../gcc-9.2.0/gcc/cp/parser.c:41188
0x78e1db c_common_parse_file()
../../gcc-9.2.0/gcc/c-family/c-opts.c:1160

Always reproducible with ccache >= 3.3.2; all works fine with ccache <= 3.2.9
or without ccache.

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5
 CC||kargl at gcc dot gnu.org
   Severity|normal  |enhancement

--- Comment #1 from kargl at gcc dot gnu.org ---
Unfortunately, -Wconversion has a problem with false positives.
You can, of course, avoid the problem by not using the option.

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
Our SPEC CPU 2017 failed with

 39 util.c:205:1: error: invalid rtl sharing found in the insn
 40   205 | }
 41   | ^
 42 (insn 29 28 3 2 (set (subreg:V2DI (reg:DI 91) 0)
 43 (vec_concat:V2DI (mem/c:DI (plus:DI (reg/f:DI 19 frame)
 44 (const_int -8 [0xfff8])) [0  S8 A64])
 45 (const_int 0 [0]))) "util.c":134:1 -1
 46  (nil))
 47 util.c:205:1: error: shared rtx
 48 (mem/c:DI (plus:DI (reg/f:DI 19 frame)
 49 (const_int -8 [0xfff8])) [0  S8 A64])
 50 during RTL pass: stv

We have an invalid shared rtx.

[Bug libstdc++/91480] Nonconforming definitions of standard library feature-test macros

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to frankhb1989 from comment #0)
> Also, in , `__cpp_lib_allocator_traits_is_always_equal` is
> wrongly spelled as `__cpp_lib_allocator_is_always_equal`.

This is incorrect. We *also* define __cpp_lib_allocator_traits_is_always_equal,
in the appropriate places. So we have an extra, non-standard macro. We don't
spell the standard one wrong.

The allocator_is_always_equal spelling was present in
http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4440.html#recs.cpp17 and
in
http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0096r0.html#detail.cpp17
but gone in
http://open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0096r1.html#recs.cpp17

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[manfred99 at gmx dot ch]

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

Manfred Schwarb  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #2 from Manfred Schwarb  ---
Of course. But not being able to silence such warnings renders
this option rather useless, IMO.
I would have expected that explicit castings would have been
special-cased in some way... 

And the manual talks explicitely about implicit conversion:
 -Wconversion
   Warn about implicit conversions ...

[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|9.2 |9.3

[Bug target/90606] Replace mfence with faster xchg for std::memory_order_seq_cst.

[nruslan_devel at yahoo dot com]

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

Ruslan Nikolaev  changed:

   What|Removed |Added

 CC||nruslan_devel at yahoo dot com

--- Comment #1 from Ruslan Nikolaev  ---
Yes, mfence is twice as slower on my machine as well. Btw, clang generates xchg
for the same code.

[Bug c/91502] New: suboptimal atomic_fetch_sub and atomic_fetch_add

[nruslan_devel at yahoo dot com]

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

Bug ID: 91502
   Summary: suboptimal atomic_fetch_sub and atomic_fetch_add
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nruslan_devel at yahoo dot com
  Target Milestone: ---

I have not specified the gcc version; it seems like it applies to any version.

I have noticed that if I write code:

#include 

int func(_Atomic(int) *a)
{
return (atomic_fetch_sub(a, 1) - 1 == 0);
}

gcc generates optimized code (gcc -O2):
func:
.LFB0:
.cfi_startproc
xorl%eax, %eax
lock subl   $1, (%rdi)
sete%al
ret

But when I change the condition to <= 0, it does not work. Correct me if I am
wrong, but, I think, it should still be able to use sub:

#include 

int func(_Atomic(int) *a)
{
return (atomic_fetch_sub(a, 1) - 1 <= 0);

}

func:
.LFB0:
.cfi_startproc
movl$-1, %eax
lock xaddl  %eax, (%rdi)
cmpl$1, %eax
setle   %al
movzbl  %al, %eax
ret

Seems like the same problem exists for atomic_fetch_add as well.

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Tue, Aug 20, 2019 at 04:12:47PM +, manfred99 at gmx dot ch wrote:
> 
> --- Comment #2 from Manfred Schwarb  ---
> Of course. But not being able to silence such warnings renders
> this option rather useless, IMO.

Yep.  At the top of my Makefile.inc file, which all of my
Makefiles pull in to set defaults, I have

.ifdef EBUG
CFLAGS+= -g -O
FFLAGS+= -g -pipe -O -fmax-errors=1 -Werror -Wall -fcheck=all
FFLAGS+= -ffpe-trap=invalid
.else
CFLAGS = -O2 -pipe -Wall -march=native -mtune=native
FFLAGS += -O2 -pipe -march=native -mtune=native
FFLAGS += -funroll-loops --param max-unroll-times=4
FFLAGS += -ftree-vectorize -Wall
.endif

# gfortran is too noisy
FFLAGS += -Wno-maybe-uninitialized -Wno-conversion -Wno-integer-division

These options produce too many false positives.

> I would have expected that explicit castings would have been
> special-cased in some way... 
> 
> And the manual talks explicitely about implicit conversion:
>  -Wconversion
>Warn about implicit conversions ...

Improvements to the documentation are encouraged.

[Bug lto/91478] FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  ---
See PR lto/83452:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83452

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #8 from Rainer Orth  ---
The new testcase FAILs on both i386-pc-solaris2.11 and x86_64-pc-linux-gnu with
-m32:

+FAIL: gcc.target/i386/minmax-7.c scan-assembler pminsd

[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922

[ro at gcc dot gnu.org]

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

--- Comment #35 from Rainer Orth  ---
Between 20190819 (r274678) and 20190820 (r274749), a new failure was
introduced:

+FAIL: gcc.target/i386/minmax-6.c scan-assembler-not rsp

Seen on both i386-pc-solaris2.11 with -m64 and x86_64-pc-linux-gnu (oldest
report
for r274708).

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Tue, Aug 20, 2019 at 03:28:29PM +, kargl at gcc dot gnu.org wrote:
> 
> --- Comment #1 from kargl at gcc dot gnu.org ---
> Unfortunately, -Wconversion has a problem with false positives.
> You can, of course, avoid the problem by not using the option.
> 

This diff will silence warnings for explicit conversion
using REAL() and INT() for the -Wconversion option.  It
does not silence warnings for -Wconversion-extra.

Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c  (revision 274676)
+++ gcc/fortran/simplify.c  (working copy)
@@ -3572,6 +3572,7 @@ static gfc_expr *
 simplify_intconv (gfc_expr *e, int kind, const char *name)
 {
   gfc_expr *result = NULL;
+  int tmp;

   /* Convert BOZ to integer, and return without range checking.  */
   if (e->ts.type == BT_BOZ)
@@ -3585,7 +3586,12 @@ simplify_intconv (gfc_expr *e, int kind, const char *n
   if (e->expr_type != EXPR_CONSTANT)
 return NULL;

+  /* For explicit conversion, turn off -Wconversion warning.  Leave the 
+ warning if -Wconversion-extra is used.  */
+  tmp = warn_conversion;
+  warn_conversion = 0;
   result = gfc_convert_constant (e, BT_INTEGER, kind);
+  warn_conversion = tmp;
   if (result == &gfc_bad_expr)
 return &gfc_bad_expr;

@@ -6467,7 +6473,7 @@ gfc_expr *
 gfc_simplify_real (gfc_expr *e, gfc_expr *k)
 {
   gfc_expr *result = NULL;
-  int kind;
+  int kind, tmp;

   /* Convert BOZ to real, and return without range checking.  */
   if (e->ts.type == BT_BOZ)
@@ -6495,7 +6501,12 @@ gfc_simplify_real (gfc_expr *e, gfc_expr *k)
   if (e->expr_type != EXPR_CONSTANT)
 return NULL;

+  /* For explicit conversion, turn off -Wconversion warning.  Leave the 
+ warning if -Wconversion-extra is used.  */
+  tmp = warn_conversion;
+  warn_conversion = 0;
   result = gfc_convert_constant (e, BT_REAL, kind);
+  warn_conversion = tmp;
   if (result == &gfc_bad_expr)
 return &gfc_bad_expr;

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #9 from Arseny Solokha  ---
(In reply to H.J. Lu from comment #7)
> Our SPEC CPU 2017 failed with
> 
>  39 util.c:205:1: error: invalid rtl sharing found in the insn
>  40   205 | }
>  41   | ^
>  42 (insn 29 28 3 2 (set (subreg:V2DI (reg:DI 91) 0)
>  43 (vec_concat:V2DI (mem/c:DI (plus:DI (reg/f:DI 19 frame)
>  44 (const_int -8 [0xfff8])) [0  S8 A64])
>  45 (const_int 0 [0]))) "util.c":134:1 -1
>  46  (nil))
>  47 util.c:205:1: error: shared rtx
>  48 (mem/c:DI (plus:DI (reg/f:DI 19 frame)
>  49 (const_int -8 [0xfff8])) [0  S8 A64])
>  50 during RTL pass: stv
> 
> We have an invalid shared rtx.

And the testcase is as simple as:

int
ff (int jn)
{
  return jn > 0 ? jn : 0;
}

% x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20190818 -march=nano-3000 -Os -c
f9272pqv.c
f9272pqv.c: In function 'ff':
f9272pqv.c:5:1: error: invalid rtl sharing found in the insn
5 | }
  | ^
(insn 18 17 3 2 (set (subreg:V4SI (reg:SI 87) 0)
(vec_merge:V4SI (vec_duplicate:V4SI (mem/c:SI (plus:DI (reg/f:DI 19
frame)
(const_int -4 [0xfffc])) [0  S4 A32]))
(const_vector:V4SI [
(const_int 0 [0]) repeated x4
])
(const_int 1 [0x1]))) "f9272pqv.c":3:1 -1
 (nil))
f9272pqv.c:5:1: error: shared rtx
(mem/c:SI (plus:DI (reg/f:DI 19 frame)
(const_int -4 [0xfffc])) [0  S4 A32])
during RTL pass: stv
f9272pqv.c:5:1: internal compiler error: internal consistency failure
0x9f3eca verify_rtx_sharing
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/emit-rtl.c:2927
0x9f3dba verify_rtx_sharing
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/emit-rtl.c:2942
0x9f3dba verify_rtx_sharing
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/emit-rtl.c:2942
0x9f3dba verify_rtx_sharing
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/emit-rtl.c:2942
0x9f4178 verify_insn_sharing
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/emit-rtl.c:3013
0x9f79ed verify_rtl_sharing()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/emit-rtl.c:3036
0xc7a8f3 execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/passes.c:2004
0xc7b536 execute_todo
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/passes.c:2037

[Bug rtl-optimization/91503] New: ICE ira-build.i:17:1: error: shared rtx

[skpgkp2 at gmail dot com]

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

Bug ID: 91503
   Summary: ICE ira-build.i:17:1: error: shared rtx
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skpgkp2 at gmail dot com
CC: crazylht at gmail dot com, hjl.tools at gmail dot com
  Target Milestone: ---

ICE when compile with gcc option "-O3  -mtune-ctrl=^inter_unit_moves_to_vec
-msse4.1"

$cat ira-build.i
typedef struct a *b;
struct a {
  b c}
;
d
  ;
e( f,  g) {
  int h, i;
  b j;
  i = g + 1;
  for (j = f; j ;
   j = j->c) 
h = e( 1);
if (h > i)
  i = h;
  return i;
}
static k() {
  d = e();
}
l() {
  k();
}


$gcc -S  -O3  -mtune-ctrl="^inter_unit_moves_to_vec"  ira-build.i  -msse4.1 -w
ira-build.i: In function \u2018l\u2019:
ira-build.i:23:1: error: invalid rtl sharing found in the insn
   23 | }
  | ^
(insn 57 56 15 4 (set (subreg:V4SI (reg:SI 96) 0)
(vec_merge:V4SI (vec_duplicate:V4SI (mem/c:SI (plus:DI (reg/f:DI 19
frame)
(const_int -4 [0xfffc])) [0  S4 A32]))
(const_vector:V4SI [
(const_int 0 [0]) repeated x4
])
(const_int 1 [0x1]))) "ira-build.i":13:9 -1
 (nil))
ira-build.i:23:1: error: shared rtx
(mem/c:SI (plus:DI (reg/f:DI 19 frame)
(const_int -4 [0xfffc])) [0  S4 A32])
during RTL pass: stv
ira-build.i:23:1: internal compiler error: internal consistency failure
0xa21114 verify_rtx_sharing
/local/gccwork/gcc_trunk/gcc/gcc/emit-rtl.c:2927
0xa20feb verify_rtx_sharing
/local/gccwork/gcc_trunk/gcc/gcc/emit-rtl.c:2942
0xa20feb verify_rtx_sharing
/local/gccwork/gcc_trunk/gcc/gcc/emit-rtl.c:2942
0xa20feb verify_rtx_sharing
/local/gccwork/gcc_trunk/gcc/gcc/emit-rtl.c:2942
0xa2143f verify_insn_sharing
/local/gccwork/gcc_trunk/gcc/gcc/emit-rtl.c:3013
0xa24d67 verify_rtl_sharing()
/local/gccwork/gcc_trunk/gcc/gcc/emit-rtl.c:3036
0xcb2ae9 execute_function_todo
/local/gccwork/gcc_trunk/gcc/gcc/passes.c:2004
0xcb382e execute_todo
/local/gccwork/gcc_trunk/gcc/gcc/passes.c:2037
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/91502] suboptimal atomic_fetch_sub and atomic_fetch_add

[nruslan_devel at yahoo dot com]

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

--- Comment #1 from Ruslan Nikolaev  ---
btw, the same problem for

#include 

int func(_Atomic(long) *a)
{
return (atomic_fetch_sub(a, 1) <= 0);
}

In the previous case clang/llvm was just like gcc, i.e., unable to optimize; in
this case clang/llvm was able to produce better code, but gcc still cannot.

[Bug tree-optimization/91491] [9 Regression] glib2.0 build not working when built with -O2 on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Richard Biener from comment #3)
> Eh, "interesting".  Thanks for the clarifications.
> 
> I suppose you did things like running under valgrind or compiling with
> -fsanitize=address.  The most obvious thing I expect from -fno-tree-pre
> is stack layout changes which then smells like some bogus stack smashing
> going on.  Can you try building gtestutils.c with
> -O2 -fno-optimize-sibling-calls?

That or there is some other undefined behavior.  Try also -fno-strict-aliasing.

[Bug fortran/91426] Different colors for errors with multiple locations

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
(In reply to David Malcolm from comment #4)

> The patch I've just attached ought to do this (though it's just a crude
> prototype - it only works for the gfc_error_opt case).
> 
> With that caveat, how does the output look?

Looks _very_ good to me.

[Bug ada/91417] [10 regression] acats c761003 fails for powerpc targets

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #1 from Iain Sandoe  ---
somewhere between 274397 and 274624 this was fixed.

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
(In reply to Steve Kargl from comment #4)

> This diff will silence warnings for explicit conversion
> using REAL() and INT() for the -Wconversion option.  It
> does not silence warnings for -Wconversion-extra.

This approcach looks very good.  It might make sense to also extend it
to -Wconversion-extra.

Do you plan to commit?  If you do, this patch is OK (we can discuss
-Wconversion-extra later).

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Tue, Aug 20, 2019 at 06:58:27PM +, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
> 
> --- Comment #5 from Thomas Koenig  ---
> (In reply to Steve Kargl from comment #4)
> 
> > This diff will silence warnings for explicit conversion
> > using REAL() and INT() for the -Wconversion option.  It
> > does not silence warnings for -Wconversion-extra.
> 
> This approcach looks very good.  It might make sense to also extend it
> to -Wconversion-extra.
> 
> Do you plan to commit?  If you do, this patch is OK (we can discuss
> -Wconversion-extra later).
> 

I wasn't going to commit until others had a chance to 
weigh in.  In particular, I wasn't sure what to do
with -Wconversion-extra as I haven't looked at the
manual to see what "extra" implies.

[Bug tree-optimization/91504] New: Inlining misses some logical operation folding

[rth at gcc dot gnu.org]

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

Bug ID: 91504
   Summary: Inlining misses some logical operation folding
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rth at gcc dot gnu.org
  Target Milestone: ---

In the following test case,

static inline unsigned deposit32(unsigned value, int start, int length,
 unsigned fieldval)
{
unsigned mask = (~0U >> (32 - length)) << start;
return (value & ~mask) | ((fieldval << start) & mask);
}

unsigned foo(unsigned value)
{
   return deposit32(value, 10, 1, 1);
}

unsigned bar(unsigned value)
{
int start = 10;
int length = 1;
unsigned fieldval = 1;
unsigned mask = (~0U >> (32 - length)) << start;
return (value & ~mask) | ((fieldval << start) & mask);
}

One would expect FOO and BAR to compile to the same code, since
the latter is the trivial inlining of the former, but that does
not happen.

gcc -O2 -S z.c gives

foo:
mvn w1, w0
and w1, w1, 1024
eor w0, w1, w0
ret

bar:
orr w0, w0, 1024
ret

The problem appears independent of target, as it isvisible on
both x86 and aarch64 targets.

[Bug c++/91505] New: [10 Regression] ICE in DECL_FUNCTION_CODE, at tree.h:3896

[asolokha at gmx dot com]

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

Bug ID: 91505
   Summary: [10 Regression] ICE in DECL_FUNCTION_CODE, at
tree.h:3896
   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: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

g++-10.0.0-alpha20190818 snapshot (r274625) ICEs when compiling
gcc/testsuite/gcc.target/i386/crc32-4.c w/ -msse4 or -mavx*:

% x86_64-unknown-linux-gnu-g++-10.0.0-alpha20190818 -mavx2 -c
gcc/testsuite/gcc.target/i386/crc32-4.c
gcc/testsuite/gcc.target/i386/crc32-4.c:6:29: internal compiler error: in
DECL_FUNCTION_CODE, at tree.h:3896
6 | unsigned long long y);
  | ^
0x685466 DECL_FUNCTION_CODE(tree_node const*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/tree.h:3896
0x685466 copy_attributes_to_builtin(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/attribs.c:1528
0x918ed9 duplicate_decls(tree_node*, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/cp/decl.c:2570
0x9890b7 do_pushdecl
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/cp/name-lookup.c:3029
0x9890b7 pushdecl(tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/cp/name-lookup.c:3157
0x9261b6 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/cp/decl.c:5292
0x9c6ac9 cp_parser_init_declarator
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/cp/parser.c:20391
0x9a9831 cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/cp/parser.c:13555
0x9cd9e2 cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/cp/parser.c:13252
0x9ce079 cp_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/cp/parser.c:4709
0x9ce079 c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/cp/parser.c:41805
0xad6c4c c_common_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/c-family/c-opts.c:1164

[Bug lto/91478] FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #5 from John David Anglin  ---
Previously, we had in pr41893-1.o.debug.temp.o:
 w gnu_lto_v1
 w gnu_lto_v1
 w gnu_lto_v1
 w gnu_lto_v1
 W pr41893_1.c.ebbf0839

Now we have:
 w
 w
 w
 W pr41893_1.c.ebbf0839

The gnu_lto_v1 symbol was resolved by libgcc.a hack.

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[manfred99 at gmx dot ch]

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

--- Comment #7 from Manfred Schwarb  ---
Hopefully this rings some bells: The warnings happen
only for parameters:

  real b
  double precision a,c,d
  PARAMETER(a=3.1415927d0)

  DATA c /3.1415927d0/
  d=3.1415927d0

  b=REAL(a)
  b=REAL(a, kind=4)
  b=REAL(c)
  b=REAL(d)
  end


a.f:8:13:

8 |   b=REAL(a)
  | 1
Warning: Change of value in conversion from 'REAL(8)' to 'REAL(4)' at (1)
[-Wconversion]
a.f:9:13:

9 |   b=REAL(a, kind=4)
  | 1
Warning: Change of value in conversion from 'REAL(8)' to 'REAL(4)' at (1)
[-Wconversion]


Thanks for your efforts!

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl  ---
On Tue, Aug 20, 2019 at 07:50:06PM +, manfred99 at gmx dot ch wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
> 
> --- Comment #7 from Manfred Schwarb  ---
> Hopefully this rings some bells: The warnings happen
> only for parameters:

Yeah. I know.  See the diff I posted.

[Bug c++/91505] [10 Regression] ICE in DECL_FUNCTION_CODE, at tree.h:3896

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-20
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

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

[Bug fortran/91426] Different colors for errors with multiple locations

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

  Attachment #46732|0   |1
is obsolete||

--- Comment #6 from David Malcolm  ---
Created attachment 46736
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46736&action=edit
Updated version of patch

This version of the patch hopefully covers all of the various
diagnostic-emitting functions in gcc/fortran/error.c

Caveats:
- not yet bootstrapped/regrtested
- patch is against an very old tree (r267518)

[Bug libstdc++/91495] std::transform_reduce with unary op is implemented in the parallel case but not the basic case

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Tue Aug 20 21:03:11 2019
New Revision: 274754

URL: https://gcc.gnu.org/viewcvs?rev=274754&root=gcc&view=rev
Log:
Implement new serial algorithms from Parallelism TS (P0024R2)

These new (non-parallel) algorithms were added to C++17 along with the
parallel algorithms, but were missing from libstdc++.

Backported for PR libstdc++/91495, replacing the use of
std::__size_to_integer which is not present on the branch.

Backport from mainline
2019-06-19  Jonathan Wakely  

* include/std/numeric (reduce(Iter, Iter, T, BinOp)): Fix value
category used in invocable check.
(reduce(Iter, Iter, T)): Pass initial value as rvalue.
* testsuite/26_numerics/reduce/2.cc: New test.

Backport from mainline
2019-06-18  Jonathan Wakely  

* include/bits/algorithmfwd.h: Change title of doc group.
* include/bits/stl_algo.h (for_each_n): Add new C++17 algorithm from
P0024R2.
* include/bits/stl_numeric.h: Define doc group and add algos to it.
* include/std/numeric (__is_random_access_iter): New internal trait.
(reduce, transform_reduce, exclusive_scan, inclusive_scan)
(transform_exclusive_scan, transform_inclusive_scan): Likewise.
* testsuite/25_algorithms/for_each/for_each_n.cc: New test.
* testsuite/26_numerics/exclusive_scan/1.cc: New test.
* testsuite/26_numerics/inclusive_scan/1.cc: New test.
* testsuite/26_numerics/reduce/1.cc: New test.
* testsuite/26_numerics/transform_exclusive_scan/1.cc: New test.
* testsuite/26_numerics/transform_inclusive_scan/1.cc: New test.
* testsuite/26_numerics/transform_reduce/1.cc: New test.
* testsuite/util/testsuite_iterators.h (test_container::size()): New
member function.

Added:
   
branches/gcc-9-branch/libstdc++-v3/testsuite/25_algorithms/for_each/for_each_n.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/exclusive_scan/
   
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/exclusive_scan/1.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/inclusive_scan/
   
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/inclusive_scan/1.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/reduce/
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/reduce/1.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/reduce/2.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/transform_exclusive_scan/
   
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/transform_exclusive_scan/1.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/transform_inclusive_scan/
   
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/transform_inclusive_scan/1.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/transform_reduce/
   
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/transform_reduce/1.cc
Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/include/bits/algorithmfwd.h
branches/gcc-9-branch/libstdc++-v3/include/bits/stl_algo.h
branches/gcc-9-branch/libstdc++-v3/include/bits/stl_numeric.h
branches/gcc-9-branch/libstdc++-v3/include/std/numeric
branches/gcc-9-branch/libstdc++-v3/testsuite/util/testsuite_iterators.h

[Bug tree-optimization/91491] [9 Regression] glib2.0 build not working when built with -O2 on x86_64-linux-gnu

[smcv at debian dot org]

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

--- Comment #5 from Simon McVittie  ---
> I suppose you did things like running under valgrind or compiling with
-fsanitize=address.

I wasn't able to reproduce the bug earlier on, in a build with
-fsanitize=address, but this was probably because I was focusing on GLib and
not Clutter. valgrind reveals that the (already compiled) Clutter test (not the
part we were recompiling) wasn't fully initializing a struct on the stack.

> The most obvious thing I expect from -fno-tree-pre
> is stack layout changes which then smells like some bogus stack smashing
> going on.

Enabling or disabling the optimization resulted in the uninitialized part of
the struct (apparently reliably) containing a zero or nonzero value. If it's
nonzero, the rest of the test is effectively skipped, so it has no opportunity
to hang.

It's entirely possible that the test in question has never worked correctly -
when I initialize the struct to all-zeroes (which appears to have been the
intention), it reliably hangs.

So I think this can be closed as not your bug. Sorry for the noise.

[Bug libstdc++/91371] std::bind and bind_front don't work with function with call convention

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Tue Aug 20 21:21:15 2019
New Revision: 274756

URL: https://gcc.gnu.org/viewcvs?rev=274756&root=gcc&view=rev
Log:
PR libstdc++/91371 make std::is_function handle other calling conventions

The x86 attributes such as ms_abi, stdcall, fastcall etc. alter the
function type, which means that functions with one of those attributes
do not match any of the partial specializations of std::is_function.

Rather than duplicating the list for every calling convention, use a
much simpler definition of std::is_function.

Also redefine __is_referenceable to not rely on partial specializations
for each type of referenceable function.

PR libstdc++/91371
* include/std/type_traits (is_function): Simplify definition. Remove
partial specializations for function types.
(__is_referenceable): Simplify definition.
* testsuite/20_util/bind/91371.cc: New test.
* testsuite/20_util/is_function/91371.cc: New test.
* testsuite/20_util/is_function/value.cc: Check more pointer types.
* testsuite/20_util/is_member_function_pointer/91371.cc: New test.
* testsuite/20_util/is_object/91371.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/20_util/bind/91371.cc
trunk/libstdc++-v3/testsuite/20_util/is_function/91371.cc
trunk/libstdc++-v3/testsuite/20_util/is_member_function_pointer/91371.cc
trunk/libstdc++-v3/testsuite/20_util/is_object/91371.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/type_traits
trunk/libstdc++-v3/testsuite/20_util/is_function/value.cc

[Bug libstdc++/91495] std::transform_reduce with unary op is implemented in the parallel case but not the basic case

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed for 9.3

[Bug c++/91505] [10 Regression] ICE in DECL_FUNCTION_CODE, at tree.h:3896

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Started with r274404.

[Bug c++/91476] [9/10 Regression] const reference variables sharing the same name in two anonymous namespaces cause a multiple definition error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||jason at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
Started to fail with r268252:

PR c++/89001 - mangling of reference temporaries

It used to be the case that the mangled name of a reference temporary
didn't
need to be standardized, because all access would be through the reference.
But now constant expressions can look through references and so different
translation units need to agree on the address of a temporary in the
initializer of a reference with vague linkage.

* cp-tree.h (struct saved_scope): Add ref_temp_count.
(current_ref_temp_count): New macro.
* mangle.c (mangle_ref_init_variable): Use it.
* typeck2.c (store_init_value): Clear it.
* call.c (make_temporary_var_for_ref_to_temp): Copy public and
comdat.

[Bug c++/91505] [10 Regression] ICE in DECL_FUNCTION_CODE, at tree.h:3896

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
This should fix it:
diff --git a/gcc/attribs.c b/gcc/attribs.c
index b89be5834de..90055a612b9 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -1525,7 +1525,15 @@ duplicate_one_attribute (tree *attrs, tree attr, const
char *name)
 void
 copy_attributes_to_builtin (tree decl)
 {
-  tree b = builtin_decl_explicit (DECL_FUNCTION_CODE (decl));
+  int fcode;
+  if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
+fcode = DECL_FUNCTION_CODE (decl);
+  else if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_MD)
+fcode = DECL_MD_FUNCTION_CODE (decl);
+  else
+fcode = DECL_FE_FUNCTION_CODE (decl);
+
+  tree b = builtin_decl_explicit (static_cast(fcode));
   if (b)
 duplicate_one_attribute (&DECL_ATTRIBUTES (b),
 DECL_ATTRIBUTES (decl), "omp declare simd");

[Bug middle-end/90676] default GIMPLE dumps lack information

[msebor at gcc dot gnu.org]

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

--- Comment #11 from Martin Sebor  ---
Author: msebor
Date: Wed Aug 21 02:18:41 2019
New Revision: 274764

URL: https://gcc.gnu.org/viewcvs?rev=274764&root=gcc&view=rev
Log:
PR testsuite/91458

gcc/testsuite/ChangeLog:
* g++.dg/tree-ssa/ssa-dse-1.C: Use the same search pattern
unconditionally (correcting r272199, PR middle-end/90676).
* gcc.dg/tree-prof/stringop-2.c: Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/ssa-dse-1.C
trunk/gcc/testsuite/gcc.dg/tree-prof/stringop-2.c

[Bug testsuite/91458] FAIL: g++.dg/tree-ssa/pr19807.C -std=gnu++98 scan-tree-dump-times optimized "&MEM\\\\[\\\\(void .\\\\)&a \\\\+ 8B\\\\]" 3

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Wed Aug 21 02:18:41 2019
New Revision: 274764

URL: https://gcc.gnu.org/viewcvs?rev=274764&root=gcc&view=rev
Log:
PR testsuite/91458

gcc/testsuite/ChangeLog:
* g++.dg/tree-ssa/ssa-dse-1.C: Use the same search pattern
unconditionally (correcting r272199, PR middle-end/90676).
* gcc.dg/tree-prof/stringop-2.c: Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/ssa-dse-1.C
trunk/gcc/testsuite/gcc.dg/tree-prof/stringop-2.c

[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output

[noloader at gmail dot com]

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

--- Comment #3 from Jeffrey Walton  ---
Lloyd's finding can be confirmed on GCC135. For example,

gcc135:~$ /opt/at12.0/bin/gcc -O3 -mcpu=power9 -m64 darn.c -o darn
gcc135:~$ ./darn
9FBE0B8B6E861BD6
9FBE0B8B6E861BD6
9FBE0B8B6E861BD6
9FBE0B8B6E861BD6
...

I can't find a header with a declaration, though:

gcc135:~$ grep -IR builtin_darn /opt/at12.0/ 2>/dev/null
gcc135:~$ grep -IR builtin_darn /lib 2>/dev/null
gcc135:~$

Does someone know where the header is located?

[Bug c++/91505] [10 Regression] ICE in DECL_FUNCTION_CODE, at tree.h:3896

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
>This should fix it:

Except it is wrong.
builtin_decl_explicit should be only used with BUILT_IN_NORMAL class.

[Bug c++/91506] New: Incorrectly issued error: parameter may not have variably modified type

[abbeyj+gcc at gmail dot com]

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

Bug ID: 91506
   Summary: Incorrectly issued error: parameter may not have
variably modified type
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abbeyj+gcc at gmail dot com
  Target Milestone: ---

Compiling:

double test(int *arr, int x) {
double ret(double(arr[x]) + 1);
return ret;
}

produces:

: In function 'double test(int*, int)':
:2:23: error: parameter may not have variably modified type 'double
[x]'
2 | double ret(double(arr[x]) + 1);
  |   ^~~


It looks like this could be a Most Vexing Parse situation but clang, ICC and
MSVC accept it.  GCC accepts this similar code which doesn't seem like it
should be treated differently from the above:

double test(int *arr, int x) {
int y = x;
double ret(double(arr[y]) + 1);
return ret;
}


Compiling with -std=c++03 changes things so GCC accepts the testcase. 
Compiling with -Wvla gets you an additional warning:

:2:23: warning: variable length array 'arr' is used [-Wvla]
2 | double ret(double(arr[x]) + 1);
  |   ^~~


This makes it seem like GCC is parsing this as a function declaration.  But
after the error is issued GCC ends up treating `ret` as having type `double`,
not as a function; changing the code to something like `return ret.foo();`
produces an error saying `... 'ret', which is of non-class type 'double'`.

Testing on godbolt.org shows that this is reproducible all the way back to
4.6.4 (if using `-std=c++0x`).  Version 4.5.3 does not exhibit the problem.

Possibly related to bug 41786 ?