[Bug tree-optimization/82217] New: ICE on valid code at -O1 and above: in visit_phi, at tree-ssa-sccvn.c:3908

[su at cs dot ucdavis.edu]

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

Bug ID: 82217
   Summary: ICE on valid code at -O1 and above: in visit_phi, at
tree-ssa-sccvn.c:3908
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This should be a very recent regression. 


$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20170915 (experimental) [trunk revision 252779] (GCC)
$
$ gcctk -O0 small.c
$ gcc-7.2.0 -O1 small.c
$
$ gcctk -O1 small.c
during GIMPLE pass: fre
small.c: In function ‘fn1’:
small.c:29:1: internal compiler error: in visit_phi, at tree-ssa-sccvn.c:3908
 }
 ^
0xe4d420 visit_phi
../../gcc-source-trunk/gcc/tree-ssa-sccvn.c:3908
0xe4d420 visit_use
../../gcc-source-trunk/gcc/tree-ssa-sccvn.c:3982
0xe4dfd3 process_scc
../../gcc-source-trunk/gcc/tree-ssa-sccvn.c:4330
0xe4dfd3 extract_and_process_scc_for_name
../../gcc-source-trunk/gcc/tree-ssa-sccvn.c:4401
0xe4dfd3 DFS
../../gcc-source-trunk/gcc/tree-ssa-sccvn.c:4451
0xe4ee33 sccvn_dom_walker::before_dom_children(basic_block_def*)
../../gcc-source-trunk/gcc/tree-ssa-sccvn.c:4900
0x1379a2a dom_walker::walk(basic_block_def*)
../../gcc-source-trunk/gcc/domwalk.c:291
0xe4fe25 run_scc_vn(vn_lookup_kind)
../../gcc-source-trunk/gcc/tree-ssa-sccvn.c:5016
0xe1ae62 execute
../../gcc-source-trunk/gcc/tree-ssa-pre.c:5157
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$


--


int a, b, c;

void fn1 ()
{ 
  while (1)
{ 
  if (c)
goto L2;
  break;
}
  if (c)
{
L1:{
int g[1];
if (b)
  goto L1;
goto L1;
  L2:
for (a = 0; a;)
  goto L1;
  }
}
}

int main ()
{ 
  fn1 ();
  return 0;
}

[Bug go/82208] exec_linux.go:197:27: error: reference to undefined name 'SYS_UNSHARE'

[mfe at live dot de]

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

--- Comment #2 from martin  ---
Created attachment 42175
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42175=edit
make log

make log

[Bug c/82216] internal compiler error: Illegal instruction

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
How are you configuring GCC?

[Bug c/82216] internal compiler error: Illegal instruction

[suhubdyd at iro dot umontreal.ca]

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

--- Comment #2 from Dendi Suhubdy  ---
1) Did you compile gcc-7.2 yourself?

Yes

2) Did you compile GMP separately from GCC?

No, I did the `./contrib/download_prerequisites`

3) Are you running GCC on a different machine than you compiled GMP?

Yes

[Bug c/82216] internal compiler error: Illegal instruction

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-09-15
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
3 things:
1) Did you compile gcc-7.2 yourself?
2) Did you compile GMP separately from GCC?
3) Are you running GCC on a different machine than you compiled GMP?

[Bug c/82216] New: internal compiler error: Illegal instruction

[suhubdyd at iro dot umontreal.ca]

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

Bug ID: 82216
   Summary: internal compiler error: Illegal instruction
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: suhubdyd at iro dot umontreal.ca
  Target Milestone: ---

(gdb) start
Temporary breakpoint 1 at 0x403cf0: file ../.././gcc/gcc-main.c, line 42.
Starting program: /u/suhubdyd/.local/bin/gcc-7.2 -D_GNU_SOURCE
-Dgpuarray_EXPORTS -I/u/suhubdyd/research/frameworks/libgpuarray/src -Wall
-Wno-unused-parameter -Werror=format-security -Wdeclaration-after-statement
-std=gnu89 -g -DDEBUG -fPIC -fvisibility=hidden -Wdeclaration-after-statement
-DGPUARRAY_BUILDING_DLL -DGPUARRAY_SHARED -o
CMakeFiles/gpuarray.dir/gpuarray_reduction.c.o -c
/u/suhubdyd/research/frameworks/libgpuarray/src/gpuarray_reduction.c

Temporary breakpoint 1, main (argc=20, argv=0x7fffb618) at
../.././gcc/gcc-main.c:42
42  ../.././gcc/gcc-main.c: No such file or directory.
(gdb) handle SIGILL stop nopass
SignalStop  Print   Pass to program Description
SIGILLYes   Yes No  Illegal instruction
(gdb) c
Continuing.
/u/suhubdyd/research/frameworks/libgpuarray/src/gpuarray_reduction.c: In
function ‘maxandargmaxSchedule’:
/u/suhubdyd/research/frameworks/libgpuarray/src/gpuarray_reduction.c:720:2:
internal compiler error: Illegal instruction
  slack[0] = slack[1] = slack[2] = 1.1;
  ^
0x9d13df crash_signal
../.././gcc/toplev.c:337
0x9433d4 real_from_string(real_value*, char const*)
../.././gcc/real.c:2107
0x943d0b real_from_string3(real_value*, char const*, format_helper)
../.././gcc/real.c:2173
0x612b33 interpret_float
../.././gcc/c-family/c-lex.c:932
0x613a17 c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
../.././gcc/c-family/c-lex.c:432
0x5b1bb0 c_lex_one_token
../.././gcc/c/c-parser.c:248
0x5bf2fa c_parser_peek_token(c_parser*)
../.././gcc/c/c-parser.c:435
0x5bf2fa c_parser_expr_no_commas
../.././gcc/c/c-parser.c:6428
0x5bf16a c_parser_expr_no_commas
../.././gcc/c/c-parser.c:6429
0x5bf16a c_parser_expr_no_commas
../.././gcc/c/c-parser.c:6429
0x5bf352 c_parser_expression
../.././gcc/c/c-parser.c:8588
0x5c0979 c_parser_expression_conv
../.././gcc/c/c-parser.c:8621
0x5c987b c_parser_statement_after_labels
../.././gcc/c/c-parser.c:5405
0x5cb4f4 c_parser_compound_statement_nostart
../.././gcc/c/c-parser.c:4919
0x5cbc0e c_parser_compound_statement
../.././gcc/c/c-parser.c:4752
0x5b7534 c_parser_declaration_or_fndef
../.././gcc/c/c-parser.c:2125
0x5d4943 c_parser_external_declaration
../.././gcc/c/c-parser.c:1468
0x5d53b9 c_parser_translation_unit
../.././gcc/c/c-parser.c:1349
0x5d53b9 c_parse_file()
../.././gcc/c/c-parser.c:18176
0x6193b3 c_common_parse_file()
../.././gcc/c-family/c-opts.c:1107
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[Inferior 1 (process 24434) exited with code 01]
(gdb) c
The program is not being run.
(gdb)

[Bug tree-optimization/79622] [6/7/8 Regression] Wrong code w/ -O2 -floop-nest-optimize

[spop at gcc dot gnu.org]

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

--- Comment #4 from Sebastian Pop  ---
Yes, that phi node looks like a reduction.  We need to handle the phi as a
write to expose the loop carried reduction variable to the dependence analysis.
I think your change goes in the right direction.  Thanks!

[Bug fortran/82215] Feature request to better support two pass compiling with gfortran

[busby1 at llnl dot gov]

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

--- Comment #2 from Lee Busby  ---
(In reply to kargl from comment #1)
> It sound like you are looking for Fortran 2008's SUBMODULE feature.
> See for example
> 
> https://software.intel.com/en-us/blogs/2015/07/07/doctor-fortran-in-we-all-
> live-in-a-yellow-submodule

Thank you for the comment.  I had previously read Mr. Lionel's description of
submodules, and I read it again just now.  I do think that submodules, in
principle, address many, possibly even all, the problems that I describe in my
attached report.  In practice, however, we're not going to rewrite 45,000 lines
of existing code in order to find out.

As I understand them, submodules would allow you to, by hand, put all the
interfaces into compilation units that could effectively be processed without
object code generation.  If so, those compilation units would presumably
compile quickly, like the first pass in the two pass method.  Then, presumably,
all the compilation units that *do* require object code generation can be
processed in parallel, because all their dependencies are present.

That's what the two pass approach does for us now, without any code rewriting. 
I do understand why SUBMODULE was added to the standard, and I fully support
it.  It's really not a feasible path for our project, however.  So I hope
you'll consider the feature request.  Maybe I fail to understand the issues,
but it does not seem like a huge change to the already-existing set of compiler
options and capabilities.

Thank you.

[Bug c++/82209] Compile error "X causes a section type conflict with Y" should provide more information

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
(In reply to Jeffrey Walton from comment #2)
> (In reply to Eric Gallager from comment #1)
> > Do you have a complete standalone testcase we could use to reproduce?
> 
> Thanks Eric.
> 
> We were not able to reduce it to a minimal test case. That was part of the
> pain for us.
> 

Well, even if you can't reduce it to be minimal, can you at least provide the
preprocessed source and the flags you passed to gcc when compiling? You could
also try setting a breakpoint in gdb at line 325 in varasm.c (where the message
comes from) and then see when it gets hit and post the backtrace...

[Bug target/82158] _Noreturn functions that do return clobber caller's registers on ARM32 (but not other arches)

[peter at cordes dot ca]

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

--- Comment #3 from Peter Cordes  ---
(In reply to jos...@codesourcery.com from comment #2)
> Falling off a noreturn function sounds like it could be another case to 
> insert __builtin_trap (), as we do in various cases of undefined behavior.

gcc has had a `-mabort-on-noreturn` option for ARM32 for a long time, but it's
not enabled by default.

I'm still not sure if clobbering r5 when the function really doesn't return is
a feature (which gcc should be doing for other targets) or a bug.

It clearly breaks stack unwinding of call-preserved register values with x86-64
style .eh_frame metadata; does this matter for exceptions from callees of the
noreturn function, or only for debugging?

Anyway, gcc should either produce a compile-time error, call __builtin_trap()
or abort(), or properly restore all call-preserved registers when it returns. 
There should be no set of options that lets it make bad code like this, even
with a warning.

[Bug fortran/82215] Feature request to better support two pass compiling with gfortran

[kargl at gcc dot gnu.org]

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

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 ---
It sound like you are looking for Fortran 2008's SUBMODULE feature.
See for example

https://software.intel.com/en-us/blogs/2015/07/07/doctor-fortran-in-we-all-live-in-a-yellow-submodule

[Bug c++/82209] Compile error "X causes a section type conflict with Y" should provide more information

[noloader at gmail dot com]

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

--- Comment #2 from Jeffrey Walton  ---
(In reply to Eric Gallager from comment #1)
> Do you have a complete standalone testcase we could use to reproduce?

Thanks Eric.

We were not able to reduce it to a minimal test case. That was part of the pain
for us.

We found moving the dtor out-of-line fixed the problem. We have no idea why it
fixed the problem. Also see
https://github.com/weidai11/cryptopp/commit/51752cb91aa6.

We also have no idea what caused the problem. The issue was not present going
back one week earlier to commit 67bcdaed9abb. We did not twiddle with things
like section alignments or attributes.

The one thing that changed between now and then was adding Power8 AES through
built-ins. The major commits in the series can be found at
https://github.com/weidai11/cryptopp/issues/497. But there's nothing special
about the commits; they look like AESNI and ARMv8 intrinsics.

Maybe the Power8 AES built-ins caused GCC to take slightly different code
paths, and that knocked something loose?

It would still be nice to get a better message from the compiler when the error
surfaces. We dumb-lucked into the fix. We were trying anything we could think
of.

[Bug fortran/82215] New: Feature request to better support two pass compiling with gfortran

[busby1 at llnl dot gov]

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

Bug ID: 82215
   Summary: Feature request to better support two pass compiling
with gfortran
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: busby1 at llnl dot gov
  Target Milestone: ---

Created attachment 42174
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42174=edit
LLNL-TR-738243, five page technical report, four figures (PDF)

The term *two pass* fortran compiling means that in pass1, module files are
created, and in pass2, object files are generated.  I have developed an interim
method to carry out two pass compiles with gfortran.  The attached paper shows
how using the two pass approach on a 45,000 SLOC Fortran project speeds up our
compiles by almost a factor of four.  This is a huge improvement, as our code
is undergoing heavy development, with many daily compiles.

It would be most useful if the gfortran compiler had options that could
directly support two pass compiles.  We can accomplish the goal now by
"abusing" existing options, so it is certainly feasible.  Please see footnote
#6 on the last page of the attached document for suggestions about how this
feature request might be satisfied.

Thank you.

[Bug ada/82141] [8 regression] raised RTSFIND.RE_NOT_AVAILABLE : rtsfind.adb:851 on darwin

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

Summary|[8 Regression] raised   |[8 regression] raised
   |RTSFIND.RE_NOT_AVAILABLE :  |RTSFIND.RE_NOT_AVAILABLE :
   |rtsfind.adb:851 on darwin   |rtsfind.adb:851 on darwin

--- Comment #38 from Eric Botcazou  ---
> I wonder whether the check-acats exception issues in PR81361 are related?

Yes, I think that it's a duplicate of PR ada/81361, i.e. the sem_ch7.adb change
only exposed the problem for rtsfind.adb.

[Bug ada/82141] [8 Regression] raised RTSFIND.RE_NOT_AVAILABLE : rtsfind.adb:851 on darwin

[ebotcazou at gcc dot gnu.org]

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

--- Comment #37 from Eric Botcazou  ---
Created attachment 42173
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42173=edit
Reduced testcase

To be compiled at -O2.

[Bug ada/81361] [8 regression] Broken exception handling at -O2

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
Summary|Exceptions mishandled   |[8 regression] Broken
   |(_Unwind_Resume() can't |exception handling at -O2
   |return) |

[Bug target/81647] inconsistent LTGT behavior at different optimization levels on AArch64.

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #5 from Steve Ellcey  ---
Looking at the code and the aarch64 documentation, the non-vectorized version
does the comparisons with fcmp which is defined as a "quiet compare" and only
generates an exception for signaling NANs.  The vectorized version uses fcmgt
and that is defined to raise exceptions.  I am not sure what GCC can do here
other than manually clear the exceptions that fcmgt raised (Yuk).

[Bug c++/81314] [6/7/8 Regression] Undefined reference to a function with -fopenmp

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep 14 20:18:17 2017
New Revision: 252770

URL: https://gcc.gnu.org/viewcvs?rev=252770=gcc=rev
Log:
PR c++/81314
* cp-gimplify.c (omp_var_to_track): Look through references.
(omp_cxx_notice_variable): Likewise.

* testsuite/libgomp.c++/pr81314.C: New test.

Added:
trunk/libgomp/testsuite/libgomp.c++/pr81314.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/libgomp/ChangeLog

[Bug c++/80947] [6/7/8 Regression] Different visibility for the lambda and its capture list members with -fvisibility=hidden

[vladz at scylladb dot com]

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

--- Comment #10 from Vlad Zolotarov  ---
(In reply to Jonathan Wakely from comment #9)
> It says not to attach an archive containing the things we don't want (e.g.
> sources without includes). And a .gz file is not an archive.


"Please avoid posting an archive (.tar, .shar or .zip); we generally need just
a single file to reproduce the bug (the .i/.ii/.f preprocessed file), and, by
storing it in an archive, you're just making our volunteers' jobs harder."

But if you insist I can gzip and post it. Whatever makes it easier to fix the
issue. Please, let me know if that's what you want.

[Bug ada/81361] Exceptions mishandled (_Unwind_Resume() can't return)

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
Investigating.

[Bug ada/81361] Exceptions mishandled (_Unwind_Resume() can't return)

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
As of today, once PR ada/82141 is worked around, I get:

=== acats Summary ===
# of expected passes2263
# of unexpected failures57
Native configuration is x86_64-apple-darwin14.5.0

with the same assertion failure for some of them and with unhandled exceptions
for others, so I think this will give a reduced testcase for PR ada/82141.

[Bug c++/80947] [6/7/8 Regression] Different visibility for the lambda and its capture list members with -fvisibility=hidden

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
It says not to attach an archive containing the things we don't want (e.g.
sources without includes). And a .gz file is not an archive.

[Bug jit/82174] Null name in one entry of the builtin_data array of jit-builtins.c

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Should be fixed by r252769.

[Bug jit/82174] Null name in one entry of the builtin_data array of jit-builtins.c

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Author: dmalcolm
Date: Thu Sep 14 19:30:26 2017
New Revision: 252769

URL: https://gcc.gnu.org/viewcvs?rev=252769=gcc=rev
Log:
Fix crash accessing builtins in sanitizer.def and after (PR jit/82174)

Calls to gcc_jit_context_get_builtin_function that accessed builtins
in sanitizer.def and after (or failed to match any builtin) led to
a crash accessing a NULL builtin name.

The entries with the NULL name came from these lines in sanitizer.def:

  /* This has to come before all the sanitizer builtins.  */
  DEF_BUILTIN_STUB(BEGIN_SANITIZER_BUILTINS, (const char *)0)

  [...snip...]

  /* This has to come after all the sanitizer builtins.  */
  DEF_BUILTIN_STUB(END_SANITIZER_BUILTINS, (const char *)0)

This patch updates jit-builtins.c to cope with such entries, fixing the
crash.

gcc/jit/ChangeLog:
PR jit/82174
* jit-builtins.c (matches_builtin): Ignore entries with a NULL
name.

gcc/testsuite/ChangeLog:
PR jit/82174
*
jit.dg/test-error-gcc_jit_context_get_builtin_function-unknown-builtin.c:
New test case.


Added:
   
trunk/gcc/testsuite/jit.dg/test-error-gcc_jit_context_get_builtin_function-unknown-builtin.c
Modified:
trunk/gcc/jit/ChangeLog
trunk/gcc/jit/jit-builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/68823] [6/7/8 Regression][graphite] tramp3d-v4 compiled with -floop-nest-optimize crashes

[spop at gcc dot gnu.org]

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

--- Comment #15 from Sebastian Pop  ---
> when DR_NUM_DIMENSIONS (dr1->dr) != DR_NUM_DIMENSIONS (dr2->dr) better "FAIL"?

Yes.
The patch looks good to me.

[Bug c++/80947] [6/7/8 Regression] Different visibility for the lambda and its capture list members with -fvisibility=hidden

[vladz at scylladb dot com]

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

--- Comment #8 from Vlad Zolotarov  ---
(In reply to Jonathan Wakely from comment #7)
> Wow bugzilla really does suggest that. How stupid.

And the (In reply to Jonathan Wakely from comment #6)
> (In reply to Vlad Zolotarov from comment #5)
> > (In reply to Jonathan Wakely from comment #4)
> > > (In reply to Vlad Zolotarov from comment #1)
> > > > Created attachment 41472 [details]
> > > > an ii value generated by g++-6
> > > 
> > > This is a URL not a preprocessed file.
> > 
> > The file is too big to be attached directly therefore I've attached the URL
> > that leads you to the file in question like it was recommended by Bugzilla
> > when I tried to attach the file.
> 
> Did you try compressing it? 


The "Reporting Bugs" at https://gcc.gnu.org/bugs/ explicitly says not to attach
any archives.

Even if that's still too big you can just put
> the URL in a comment, creating an attachment that contains a URL is just
> pointless indirection.

[Bug demangler/82195] Undemangleable lambda

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

  Component|c++ |demangler

--- Comment #3 from Nathan Sidwell  ---
The problem is that in a local name 'Z fn E name [disc]', 'name' could be a
(nested) function and have encoded parms.  We do not expecting that and either
barf or attach them to the wrong level of the tree.  Attaching to the wrong
level works most of the time, except when the fn is an instantiation.  And of
course, generic lambdas are such a thing and didn't prevously exist.

[Bug target/81268] [avr] Support __gcc_isr pseudo-instruction for more efficient ISR prologues

[egallager at gcc dot gnu.org]

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

--- Comment #8 from Eric Gallager  ---
(In reply to Georg-Johann Lay from comment #7)
> (In reply to Aldy Hernandez from comment #6)
> > Author: aldyh
> > Date: Wed Sep 13 16:56:35 2017
> > New Revision: 252421
> > 
> > URL: https://gcc.gnu.org/viewcvs?rev=252421=gcc=rev
> > Log:
> > gcc/
> > PR target/81754
> > PR target/81268
> > * config/avr/avr.opt (mgas-isr-prologues): New Var
> > avr_gasisr_prologues.
> > * config/avr/avr.md (gasisr, *gasisr): Use it instead of
> > TARGET_GASISR_PROLOGUES.
> > * config/avr/avr.c (avr_option_override): Same.
> > (avr_pass_pre_proep::execute): Same.
> > 
> > Modified:
> > branches/range-gen2/gcc/ChangeLog
> > branches/range-gen2/gcc/config/avr/avr.c
> > branches/range-gen2/gcc/config/avr/avr.md
> > branches/range-gen2/gcc/config/avr/avr.opt
> 
> Hi, are changes to some provate branches (presumably by merging trunk or
> some release branch into it) supposed to trigger bugzilla entries?

I was wondering this myself; might be worth sending an email to the gcc mailing
list asking about it

[Bug c++/82209] Compile error "X causes a section type conflict with Y" should provide more information

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-09-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Do you have a complete standalone testcase we could use to reproduce?

[Bug c++/80947] [6/7/8 Regression] Different visibility for the lambda and its capture list members with -fvisibility=hidden

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Wow bugzilla really does suggest that. How stupid.

[Bug c++/80947] [6/7/8 Regression] Different visibility for the lambda and its capture list members with -fvisibility=hidden

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Vlad Zolotarov from comment #5)
> (In reply to Jonathan Wakely from comment #4)
> > (In reply to Vlad Zolotarov from comment #1)
> > > Created attachment 41472 [details]
> > > an ii value generated by g++-6
> > 
> > This is a URL not a preprocessed file.
> 
> The file is too big to be attached directly therefore I've attached the URL
> that leads you to the file in question like it was recommended by Bugzilla
> when I tried to attach the file.

Did you try compressing it? Even if that's still too big you can just put the
URL in a comment, creating an attachment that contains a URL is just pointless
indirection.

[Bug c++/80947] [6/7/8 Regression] Different visibility for the lambda and its capture list members with -fvisibility=hidden

[vladz at scylladb dot com]

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

--- Comment #5 from Vlad Zolotarov  ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Vlad Zolotarov from comment #1)
> > Created attachment 41472 [details]
> > an ii value generated by g++-6
> 
> This is a URL not a preprocessed file.

The file is too big to be attached directly therefore I've attached the URL
that leads you to the file in question like it was recommended by Bugzilla when
I tried to attach the file.

> 
> Reproducer from comment 2 (thanks):
> 
> template
> class MyClass  {
> public:
> MyClass() {
> auto outer = [this]()
> {
> auto fn = [this]   { };
> };
> }
> };
> int main() { MyClass r; }

[Bug rtl-optimization/82192] [5/6/7/8 Regression] gcc produces incorrect code with -O2 and bit-field

[segher at gcc dot gnu.org]

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

--- Comment #14 from Segher Boessenkool  ---
I'll check if this patch regresses code quality on any target.  Looks
good though, thanks!

[Bug libstdc++/71187] declval() can be implemented without requiring a template instantiation

[eric.niebler at gmail dot com]

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

--- Comment #3 from Eric Niebler  ---
I suppose, but I doubt it would matter much. add_rvalue_reference is not used
nearly as frequently as declval (except in the current implementation of
declval).

[Bug target/82214] New: [AArch64] Incorrect checking of LDP/STP offsets in aarch64_print_operand

[jcw at gcc dot gnu.org]

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

Bug ID: 82214
   Summary: [AArch64] Incorrect checking of LDP/STP offsets in
aarch64_print_operand
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jcw at gcc dot gnu.org
  Target Milestone: ---

Hi,

Currently, aarch64_print_operand calls aarch64_print_operand_address
(indirectly) when used on a memory address.

For LDP/STP memory operands, the behavior is incorrect.
`aarch64_print_operand_address` checks `aarch64_classify_address` to see
whether the passed address is valid and to determine some classification
information.

However, aarch64_print_operand does not have enough information to distinguish
between a LDP/STP operand and a LDR/STR operand. This means that in the call
the aarch64_classify_address, the address is treated as a (differently sized)
LDR/STR operand. In some cases, the LDP/STP operand is not within the range for
LDR/STR and results in an ICE.

An example of this case is with a negative offset for a 8 byte wide mode (such
as a double). The offset for LDR/STR can be 12 bits unsigned adjusted, or 9
bits signed unadjusted, and the 7 bits signed adjusted of LDP/STP has a wider
range than either of those in this case.

I suggest that we add another format type to aarch64_print_operand for LDP/STP
addresses that does the correct checking for LDP/STP memory addresses.

Note that if this patch has gone in:
https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00873.html

Then it can be updated to not disallow negative offsets for double and long int
modes by changing (in aarch64_gen_adjusted_ldpstp):


/* The base offset is optimally half way between the two stp/ldp offsets. 
*/
   if (msize <= 4) 
 base_off = (off_val_1 + off_val_3) / 2;
   else
 /* However, due to issues with negative LDP/STP offset generation for
larger modes, for DF and DI modes (and any vector modes that have
since been added) we must not use negative addresses smaller than
9 signed unadjusted bits can store.  This provides the most range
in this case.  */
 base_off = off_val_1;

   /* Adjust the base so that it is aligned with the addresses but still
  optimal.  */
   if (base_off % msize != off_val_1 % msize)
 /* Fix the offset, bearing in mind we want to make it bigger not
smaller.  */
 base_off += (((base_off % msize) - (off_val_1 % msize)) + msize) % msize;
   else if (msize <= 4) 
 /* The negative range of LDP/STP is one larger than the positive range. 
*/
 base_off += msize;
to
   /* The base offset is optimally half way between the two stp/ldp offsets. 
*/
   base_off = (off_val_1 + off_val_3) / 2;

   /* Adjust the base so that it is aligned with the addresses but still
  optimal.  */
   if (base_off % msize != off_val_1 % msize)
 /* Fix the offset, bearing in mind we want to make it bigger not
smaller.  */
 base_off += (((base_off % msize) - (off_val_1 % msize)) + msize) % msize;
   else 
 /* The negative range of LDP/STP is one larger than the positive range. 
*/
 base_off += msize;


I expect this to fix test case `gcc.target/aarch64/ldp_stp_11.c`


To reproduce:

The bug is hidden on current trunk as we don't generate negative offset LDP/STP
instructions on AArch64. If the above patch is installed, it is again hidden by
the extra checks.

To reproduce, make sure my patch is installed, remove the checks from the code
as I indicated above. Then testcase `gcc.target/aarch64/ldp_stp_11` should ICE.

Jackson.

[Bug tree-optimization/81945] [8 Regression] ICE in operator[], at vec.h:749

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
Don't know transformation done by graphite.  In this case, graphite0 has an
additional function dump:
;; Function at._loopfn.1 (at._loopfn.1, funcdef_no=2, decl_uid=1951,
cgraph_uid=1, symbol_order=2)

at._loopfn.1 (void * .paral_data_param)
{
  //...
}

which is generated from the original function at?  Also the new function
contains loop and loop->orig_loop_num is copied from data LFN_LOOP_DIST_ALIAS. 
It also looks like the distributed loop is handled by graphite/parloops.  In
general I think it's okay, only waste some compilation time because transformed
loop will be removed by vectorizer.  But leaking loop->orig_loop_num
information to newly created function is wrong.

[Bug c/82186] [7/8 Regression] ICE (segfault), VLA type with inlining

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Ok (but I'm on vacation next 6 days).

[Bug rtl-optimization/82192] [5/6/7/8 Regression] gcc produces incorrect code with -O2 and bit-field

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
So like this (untested) or somewhere else?

--- gcc/combine.c.jj2017-09-14 10:04:56.0 +0200
+++ gcc/combine.c   2017-09-14 16:59:28.529783572 +0200
@@ -7444,7 +7444,14 @@ make_extraction (machine_mode mode, rtx
   if (pos_rtx && CONST_INT_P (pos_rtx))
 pos = INTVAL (pos_rtx), pos_rtx = 0;

-  if (GET_CODE (inner) == SUBREG && subreg_lowpart_p (inner))
+  if (GET_CODE (inner) == SUBREG
+  && subreg_lowpart_p (inner)
+  && (paradoxical_subreg_p (inner)
+ /* If trying or potentionally trying to extract
+bits outside of is_mode, don't look through
+non-paradoxical SUBREGs.  See PR82192.  */
+ || (pos_rtx == NULL_RTX
+ && pos + len <= GET_MODE_PRECISION (is_mode
 {
   /* If going from (subreg:SI (mem:QI ...)) to (mem:QI ...),
 consider just the QI as the memory to extract from.
@@ -7470,7 +7477,12 @@ make_extraction (machine_mode mode, rtx
   if (new_rtx != 0)
return gen_rtx_ASHIFT (mode, new_rtx, XEXP (inner, 1));
 }
-  else if (GET_CODE (inner) == TRUNCATE)
+  else if (GET_CODE (inner) == TRUNCATE
+  /* If trying or potentionally trying to extract
+ bits outside of is_mode, don't look through
+ TRUNCATE.  See PR82192.  */
+  && pos_rtx == NULL_RTX
+  && pos + len <= GET_MODE_PRECISION (is_mode))
 inner = XEXP (inner, 0);

   inner_mode = GET_MODE (inner);
--- gcc/testsuite/gcc.c-torture/execute/pr82192.c.jj2017-09-14
17:02:54.281234432 +0200
+++ gcc/testsuite/gcc.c-torture/execute/pr82192.c   2017-09-14
17:02:39.0 +0200
@@ -0,0 +1,22 @@
+/* PR rtl-optimization/82192 */
+
+unsigned long long int a = 0x95dd3d896f7422e2ULL;
+struct S { unsigned int m : 13; } b;
+
+__attribute__((noinline, noclone)) void
+foo (void)
+{
+  b.m = ((unsigned) a) >> (0x644eee9667723bf7LL
+  | a & ~0xdee27af8U) - 0x644eee9667763bd8LL;
+}
+
+int
+main ()
+{
+  if (__INT_MAX__ != 0x7fffULL)
+return 0;
+  foo ();
+  if (b.m != 0)
+__builtin_abort ();
+  return 0;
+}

[Bug rtl-optimization/82192] [5/6/7/8 Regression] gcc produces incorrect code with -O2 and bit-field

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
As far as I know this is undefined; combine should avoid making such
out-of-range patterns (unless the existing insns are already like that,
it will happily make even bigger garbage then).

[Bug libstdc++/71187] declval() can be implemented without requiring a template instantiation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
I wonder if it would make sense to use the same __declval helper for
add_rvalue_reference too. That would allow us to lose the
__add_rvalue_reference_helper class template.

[Bug c/82186] [7/8 Regression] ICE (segfault), VLA type with inlining

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Marek, can you please have a look?

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[jakub at gcc dot gnu.org]

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

Bug 82203 Summary: [5/6/7/8 regression] missing -Wmaybe-uninitialized warning 
with tree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82203

   What|Removed |Added

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

[Bug tree-optimization/18501] [5/6/7/8 Regression] Missing 'used uninitialized' warning (CCP)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||arnd at linaro dot org

--- Comment #80 from Jakub Jelinek  ---
*** Bug 82203 has been marked as a duplicate of this bug. ***

[Bug middle-end/82203] [5/6/7/8 regression] missing -Wmaybe-uninitialized warning with tree-vrp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Jakub Jelinek  ---
Dup.

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

[Bug target/81268] [avr] Support __gcc_isr pseudo-instruction for more efficient ISR prologues

[gjl at gcc dot gnu.org]

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

--- Comment #7 from Georg-Johann Lay  ---
(In reply to Aldy Hernandez from comment #6)
> Author: aldyh
> Date: Wed Sep 13 16:56:35 2017
> New Revision: 252421
> 
> URL: https://gcc.gnu.org/viewcvs?rev=252421=gcc=rev
> Log:
> gcc/
>   PR target/81754
>   PR target/81268
>   * config/avr/avr.opt (mgas-isr-prologues): New Var
>   avr_gasisr_prologues.
>   * config/avr/avr.md (gasisr, *gasisr): Use it instead of
>   TARGET_GASISR_PROLOGUES.
>   * config/avr/avr.c (avr_option_override): Same.
>   (avr_pass_pre_proep::execute): Same.
> 
> Modified:
> branches/range-gen2/gcc/ChangeLog
> branches/range-gen2/gcc/config/avr/avr.c
> branches/range-gen2/gcc/config/avr/avr.md
> branches/range-gen2/gcc/config/avr/avr.opt

Hi, are changes to some provate branches (presumably by merging trunk or some
release branch into it) supposed to trigger bugzilla entries?

[Bug sanitizer/81929] [7/8 Regression] exponential slowdown in undefined behavior sanitizer for streaming

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 42172
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42172=edit
gcc8-pr81929.patch

Untested fix.

[Bug sanitizer/81068] Sanitizer memory leak in codecvt_utf8

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-09-14
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I would doubt w/ sanitizer one can have it working:

$ clang++ pr81068.cpp -std=c++11 && ./a.out 
terminate called after throwing an instance of 'std::range_error'
  what():  wstring_convert::from_bytes
Aborted (core dumped)

$ clang++ --version
clang version 4.0.1 (tags/RELEASE_401/final 305264)

$ g++ pr81068.cpp -std=c++11 && ./a.out 
terminate called after throwing an instance of 'std::range_error'
  what():  wstring_convert::from_bytes
Aborted (core dumped)

$ g++ --version
g++ (SUSE Linux) 7.1.1 20170802 [gcc-7-branch revision 250825]

$ valgrind ./a.out 
==18712== Memcheck, a memory error detector
==18712== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==18712== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==18712== Command: ./a.out
==18712== 
terminate called after throwing an instance of 'std::range_error'
  what():  wstring_convert::from_bytes
==18712== 
==18712== Process terminating with default action of signal 6 (SIGABRT):
dumping core
==18712==at 0x5758B30: raise (raise.c:51)
==18712==by 0x575A110: abort (abort.c:79)
==18712==by 0x4ED2234: __gnu_cxx::__verbose_terminate_handler() (in
/usr/lib64/libstdc++.so.6.0.24)
==18712==by 0x4ED0025: ??? (in /usr/lib64/libstdc++.so.6.0.24)
==18712==by 0x4ED0070: std::terminate() (in /usr/lib64/libstdc++.so.6.0.24)
==18712==by 0x4ED02B2: __cxa_throw (in /usr/lib64/libstdc++.so.6.0.24)
==18712==by 0x4EF89BE: std::__throw_range_error(char const*) (in
/usr/lib64/libstdc++.so.6.0.24)
==18712==by 0x401A16:
std::__cxx11::wstring_convert, char16_t, std::allocator, std::allocator
>::from_bytes(char const*, char const*) (in
/home/marxin/Programming/testcases/a.out)
==18712==by 0x40146C: main (in /home/marxin/Programming/testcases/a.out)

Can you please verify that it's a valid code?

[Bug target/81317] builtin_vec_ld fails for powerpc with altivec

[segher at gcc dot gnu.org]

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

--- Comment #26 from Segher Boessenkool  ---
I still can't reproduce the problem, and I don't see where the null
pointer is coming from either.  Someone who can reproduce the problem
will have to do some debugging.  Sorry.

[Bug c++/82171] Cant use std::declval in concept testing map operator[]

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-14
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
(In reply to Daniel Krügler from comment #2)
> As I understand it, this wording should allow using std::declval within the
> requirement-body as you did it without causing it being considered odr-used,
> so the current behaviour looks like a bug to me.

Let's go with that.

[Bug c++/80947] [6/7/8 Regression] Different visibility for the lambda and its capture list members with -fvisibility=hidden

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic, visibility
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-14
  Known to work||5.4.0
Summary|Different visibility for|[6/7/8 Regression]
   |the lambda and its capture  |Different visibility for
   |list members with   |the lambda and its capture
   |-fvisibility=hidden |list members with
   ||-fvisibility=hidden
 Ever confirmed|0   |1
  Known to fail||6.4.0, 7.2.0, 8.0

--- Comment #4 from Jonathan Wakely  ---
(In reply to Vlad Zolotarov from comment #1)
> Created attachment 41472 [details]
> an ii value generated by g++-6

This is a URL not a preprocessed file.

Reproducer from comment 2 (thanks):

template
class MyClass  {
public:
MyClass() {
auto outer = [this]()
{
auto fn = [this]   { };
};
}
};
int main() { MyClass r; }

[Bug c++/80947] Different visibility for the lambda and its capture list members with -fvisibility=hidden

[a...@cloudius-systems.com]

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

--- Comment #3 from Avi Kivity  ---
A gentle ping, in the unlikely case that this bug was forgotten.

[Bug rtl-optimization/82192] [5/6/7/8 Regression] gcc produces incorrect code with -O2 and bit-field

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
  Component|tree-optimization   |rtl-optimization

[Bug jit/82174] Null name in one entry of the builtin_data array of jit-builtins.c

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
The entry with the NULL name comes from this line in sanitizer.def:

  /* This has to come before all the sanitizer builtins.  */
  DEF_BUILTIN_STUB(BEGIN_SANITIZER_BUILTINS, (const char *)0)

There's also this one at the end of sanitizer.def:
  /* This has to come after all the sanitizer builtins.  */
  DEF_BUILTIN_STUB(END_SANITIZER_BUILTINS, (const char *)0)

These were added in r232891 (aka ee49ca6a1c66c03e3b8ba494c78c02f0f92de050) to
fix PR lto/69254.

I'm working on a fix.

[Bug c++/81311] An std::ref argument calls copy constructor instead of template constructor in C++17 mode

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-14
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
extern "C" int puts(const char*);

struct function
{
function()
{
puts("function()");
}

template function( F )
{
puts("function(F)");
}

function( function const& )
{
puts("function(function const&)");
}
};

struct ref
{
  ref() = default;

  operator function&() const;
};

int main()
{
function f2( ref{} );
}

Compiles OK with C++14, printing "function(F)" but fails to link with C++17:

/tmp/ccB3mFFt.o: In function `main':
/tmp/ref.cc:30: undefined reference to `ref::operator function&() const'
collect2: error: ld returned 1 exit status

Presumably caused by the changes for guaranteed elision in C++17.

Interestingly if the conversion operator is defined as deleted then it compiles
OK, choosing the function(F) constructor instead.

[Bug c++/58796] throw nullptr not caught by catch(type*)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #23 from Jonathan Wakely  ---
This was fixed for GCC 7 so I'm closing it.

If you need it backported to GCC 6 please say so, as I won't bother otherwise.

[Bug c++/58796] throw nullptr not caught by catch(type*)

[redi at gcc dot gnu.org]

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

--- Comment #22 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #17)
> Not all cases work though, nullptr cannot be caught as a pointer to member
> function, and fixing that is difficult, so I'm keeping this open.

That was fixed in r238532

[Bug c++/82195] Undemangleable lambda

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
Created attachment 42171
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42171=edit
Further simplified

Further simplification removes the inner lambda.  The key problem is needing to
name objects within the scope of the instantiated generic lambda's template
function operator.  We end up using a template parameter reference, trying to
refer to that operator instantiation, but the scopes are confusing.

The Local::fn function is mangled as:
 _ZZZ3FoovENKUlT_E_clIiEEfS_EN5Local2fnEv
the backreference 'S_' is to the 'T_' component, but manually undoing that
substitution does not resolve the demangler's problem.

If we desugar the testcase, and define an explict lambda-like class, at file
scope, it's Local::fn function is mangled as:
  _ZZN6lambdaclIiEEfT_EN5Local2fnEv
The demangler can demangle that.  Manually wrapping that inside another
local-scope mangle breaks the demangler.

[Bug tree-optimization/68823] [6/7/8 Regression][graphite] tramp3d-v4 compiled with -floop-nest-optimize crashes

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #14 from Richard Biener  ---
Created attachment 42170
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42170=edit
patch

Like this.

[Bug tree-optimization/82192] [5/6/7/8 Regression] gcc produces incorrect code with -O2 and bit-field

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Jeffrey A. Law from comment #10)
> Does the oddity that shifts truncate on x86, but bit operations do not come
> into play here?

x86 doesn't define SHIFT_COUNT_TRUNCATED (though in this testcase there is no
out of bound shift count anyway) and I believe the requirement is that if it is
defined then all the shift/insv/extv and similar instructions have to have the
truncation behavior, not just some, so I think this macro isn't relevant to
this PR.  The shift count is fine, but shift count + len is or might be too big
and the question is what happens with the upper bits.

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #10 from Richard Biener  ---
[...]
>> Why does Solaris ld output warnings by default?  Does it have an
>> option to suppress them?  It doesn't seem that it considers them
>> errors?
>
> Btw, I suppose I can simply leave the names of the global UNDEFs in place.
> That'll remove that specific warning.  Still the question is why solaris
> ld segfaults and whether there is a way to supress the section warning
> by doing some magic to the entry.

It seems the ld SEGV happens because the string table associated with
the symtab is size 0 and not of type SHT_STRTAB:

Section Header[171]:  sh_name: .symtab
sh_addr:  0   sh_flags:   [ SHF_ALLOC ]
sh_size:  0x14c0  sh_type:[ SHT_SYMTAB ]
sh_offset:0x551c  sh_entsize: 0x10 (332 entries)
sh_link:  172 sh_info:325
sh_addralign: 0x4   

Section Header[172]:  sh_name: 
sh_addr:  0   sh_flags:   [ SHF_EXCLUDE ]
sh_size:  0   sh_type:[ SHT_NULL ]
sh_offset:0x69dc  sh_entsize: 0
sh_link:  0   sh_info:0

The input object has

Section Header[171]:  sh_name: .symtab
sh_addr:  0   sh_flags:   [ SHF_ALLOC ]
sh_size:  0x14c0  sh_type:[ SHT_SYMTAB ]
sh_offset:0x3e13c sh_entsize: 0x10 (332 entries)
sh_link:  172 sh_info:325
sh_addralign: 0x4   

Section Header[172]:  sh_name: .strtab
sh_addr:  0   sh_flags:   [ SHF_ALLOC ]
sh_size:  0xdb0   sh_type:[ SHT_STRTAB ]
sh_offset:0x3f5fc sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x1   

instead.

I think I can see now how this happens: initially, sections 171 and 172
are marked for dropping.  However, later on there's this section

Section Header[174]:  sh_name: .rela.gnu.debuglto_.debug_info
sh_addr:  0   sh_flags:   [ SHF_ALLOC ]
sh_size:  0xc sh_type:[ SHT_RELA ]
sh_offset:0x69dc  sh_entsize: 0xc (1 entry)
sh_link:  171 sh_info:3
sh_addralign: 0x4   

which causes section 171 to be retained, while 172 is still dropped,
leading to the inconsistency observed above.  Btw., GNU ld chokes on
that object just the same:

$ gld-2.29 -o ltoout-as.o ltoin-as.o
gld-2.29: ltoin-as.o: attempt to load strings from a non-string section (number
172)
ltoin-as.o: error adding symbols: Bad value

Rainer

[Bug tree-optimization/68823] [6/7/8 Regression][graphite] tramp3d-v4 compiled with -floop-nest-optimize crashes

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
We apply blocking on

int a[256][256];

void foo (void)
{
  int *p = [4][7];
  for (int i = 0; i < 256; ++i)
for (int j = 0; j < 256; ++j)
  a[j][i] = a[j][i] * (*(int(*)[1])p)[0];
}

but not when we use a plain indirection, then we get

[scop-detection-fail] Graphite cannot handle data-refs in stmt:
# VUSE <.MEM_20>
_2 = MEM[(int *)];

for some reason (stmt_has_simple_data_refs_p fails).  Zero subscripts I guess.
That's a weird thing to look at, even __real MEM[(int *)] would make it
one subscript (see dr_analyze_indices).

Means graphite doesn't handle non-indexed memory reads either.

So the above might be a different bug (we're supposed to reject the data-ref?).

We're also blocking

int a[256][256];

void foo (void)
{
  int *p = [0][0];
  for (int i = 0; i < 256; ++i)
for (int j = 0; j < 256; ++j)
  a[j][i] = a[j][i] * p[i];
}

can't wrap my head around whether that's valid or not.

In the end it looks like graphite doesn't handle mixed pointer / non-pointer
accesses because it relies on DR_ACCESS_FNs "matching" for all possible
may-aliases.  I suppose

  /* The access polyhedron contains the polyhedral space this data
 reference will access.

 The polyhedron contains these dimensions:

 - The alias set (a):
 Every memory access is classified in at least one alias set.

 - The subscripts (s_0, ..., s_n):
 The memory is accessed using zero or more subscript dimensions.

 - The iteration domain (variables and parameters)

means that when things are in the same alias set they may still differ
in the number of subscripts?  But in that case they always appear as
not aliasing?

That is, should we, in

static void
build_alias_set (scop_p scop)
{
  int num_vertices = scop->drs.length ();
  struct graph *g = new_graph (num_vertices);
  dr_info *dr1, *dr2;
  int i, j;
  int *all_vertices;

  FOR_EACH_VEC_ELT (scop->drs, i, dr1)
for (j = i+1; scop->drs.iterate (j, ); j++)
  if (dr_may_alias_p (dr1->dr, dr2->dr, true))
{
  add_edge (g, i, j);
  add_edge (g, j, i);

when DR_NUM_DIMENSIONS (dr1->dr) != DR_NUM_DIMENSIONS (dr2->dr) better "FAIL"?

[Bug c++/81314] [6/7/8 Regression] Undefined reference to a function with -fopenmp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 42169
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42169=edit
gcc8-pr81314.patch

Untested fix.

[Bug target/82170] gcc optimizes int range-checking poorly on x86-64

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Target|x86_64-*-*  |x86_64-*-*, powerpc*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-14
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #9 from Segher Boessenkool  ---
For range tests, one of the first things the tree optimisers do (in
003t.original) is change  (a <= x && x < b)  into  (x - a u< b - a)
(where u< is unsigned compare).  And this in as narrow a type as
possible.

This survives all the way through the gimple optimisers.  There is
no way combine can deal with this in general.

Maybe there should be a separate EXPR for range tests?

(The generated code looks relatively *good* on x86, btw ;-) )

[Bug ada/82141] [8 Regression] raised RTSFIND.RE_NOT_AVAILABLE : rtsfind.adb:851 on darwin

[simon at pushface dot org]

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

--- Comment #36 from simon at pushface dot org ---
(In reply to simon from comment #28)
> For the Darwin 15 build (+ patch to darwin.h from PR80556) was 
> configured with
> 
> --prefix=/Volumes/Miscellaneous/tmp/opt/gcc-8.0.0 
> --without-libiconv-prefix 
> --disable-libmudflap 
> --disable-libstdcxx-pch 
> --disable-libsanitizer 
> --disable-libcc1 
> --disable-libcilkrts 
> --disable-multilib 
> --disable-nls 
> --enable-languages=c,c++,ada 
> --build=x86_64-apple-darwin15
> 
> and built with make -k; these components all showed the RTSFIND 
> error:
> 
> g-exptty
> g-locfil
> s-gloloc
> g-socthi
> 
> I tried removing these from the build, to see whether the exception 
> problem showed up in simpler code, but s-gloloc is used indirectly 
> by rtsfind, so I stopped.

On second thoughts, rtsfind isn’t part of the RTS, so I eliminated the only
caller of s-globloc (s-shasto) and the build succeeded.

I then tried a tiny exception demonstrator,

with Ada.Exceptions;
with Ada.Text_IO; use Ada.Text_IO;
procedure Raiser is
   Ex : exception;
   procedure Do_It (J : Natural);
   procedure Do_It (J : Natural) is
   begin
  if J - 1 not in Natural then
 raise Ex with "underflow";
  end if;
  Do_It (J - 1);
   end Do_It;
begin
   begin
  Do_It (5);
   exception
  when E : others =>
 Put_Line (Ada.Exceptions.Exception_Information (E));
   end;
   Put_Line ("end of raiser");
end Raiser;

which worked fine with both static and dynamic binding, and with no command 
line options and with the options used to compile rtsfind (A -gnatwa 
-nostdinc -O2 -Wextra -Wall -gnatwa -g -gnatp -gnatg -gnata -mtune=core2 
-mmacosx-version-min=10.11.0 --RTS=/where/its/installed).

As an extra check, I linked with the options used to link the compiler 
gnat1 (-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall 
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -static-libstdc++ 
-static-libgcc -Wl,-no_pie): still no problems.

I then tried g-exptty; it fails, as previously observed, no matter what
the compilation flags.

[Bug c++/81314] [6/7/8 Regression] Undefined reference to a function with -fopenmp

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Testcase without STL:
// { dg-do link }

template 
struct S {
  S () { s = 0; }
  S (const S ) { s = x.s; }
  ~S () {}
  int s;
};

void
foo (S<2> )
{
  #pragma omp taskloop
  for (int i = 0; i < 100; ++i)
x.s++;
}

int
main ()
{
  S<2> s;
  #pragma omp parallel
  #pragma omp master
  foo (s);
}

[Bug target/78994] -Ofast makes aarch64 C++ benchmark slower for A53

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-14
   Assignee|unassigned at gcc dot gnu.org  |wilco at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch for bootstrapping under Xcode 9

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to Iain Sandoe from comment #11)
> (In reply to Richard Biener from comment #4)
> > The gcc-6 backport is ok (if you want to go ahead).
> 
> Is (a suitably modified) version also OK for gcc-5?
>  (I checked the posted one on Darwin and Linux and it seems OK, but I don't
> have much state on this)

Sure.

[Bug libstdc++/82212] libstdc++ makes (integer|index)_sequence available with -std=c++11, but they're C++14 features

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Markus Trippelsdorf  ---
Closing.

[Bug libstdc++/82212] libstdc++ makes (integer|index)_sequence available with -std=c++11, but they're C++14 features

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-09-14
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to DB from comment #0)
> std::integer_sequence and std::index_sequence are defined under this
> condition:
> 
> #if __cplusplus > 201103L

Erm ... wat?

[Bug c++/82213] Please warn about const rvalue reference parameters [void func(const T&&);]

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-14
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
I agree this makes sense, and IMHO it should be included in -Wall. The
exceptional cases where const X&& is used for a good reason could use -Wno-xxx
to suppress the warning.

[Bug tree-optimization/79622] [6/7/8 Regression] Wrong code w/ -O2 -floop-nest-optimize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
we fail to represent the PHI defining g5_23:

   [83.33%] [count: INV]:
  # l9_22 = PHI <0(3), l9_16(5)>
  # g5_23 = PHI <-1(3), 0(5)>
  # ivtmp_20 = PHI <5(3), ivtmp_13(5)>
  dc[l9_22] = g5_23;
  l9_16 = l9_22 + 1;
  ivtmp_13 = ivtmp_20 - 1;
  if (ivtmp_13 != 0)
goto ; [80.00%] [count: INV]
  else
goto ; [20.00%] [count: INV]

   [66.66%] [count: INV]:
  goto ; [100.00%] [count: INV]

[scheduler] original ast:
for (int c0 = 0; c0 <= 1; c0 += 1)
  for (int c1 = 0; c1 <= 4; c1 += 1)
S_4(c0, c1);

not sure if this is a case of "cross-BB-scalar-vars" but that doesn't handle
non-SSA uses.  So a similar case would be the following:

 # _1 = PHI <_2(entry), 0(latch)>

The following patch fixes this by always marking non-SCEV analyzable
PHI defs as "writes".

Index: gcc/graphite-scop-detection.c
===
--- gcc/graphite-scop-detection.c   (revision 252062)
+++ gcc/graphite-scop-detection.c   (working copy)
@@ -1744,7 +1744,9 @@ build_cross_bb_scalars_def (scop_p scop,
   gimple *use_stmt;
   imm_use_iterator imm_iter;
   FOR_EACH_IMM_USE_STMT (use_stmt, imm_iter, def)
-if (def_bb != gimple_bb (use_stmt) && !is_gimple_debug (use_stmt))
+if ((def_bb != gimple_bb (use_stmt) && !is_gimple_debug (use_stmt))
+   /* ???  PR79622.  */
+   || gimple_code (SSA_NAME_DEF_STMT (def)) == GIMPLE_PHI)
   {
writes->safe_push (def);
DEBUG_PRINT (dp << "Adding scalar write: ";

passes the graphite.exp testsuites, otherwise untested.

Sebastian?

[Bug c/80832] GCC_COLORS

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Why it should be so fine-grained?
As for caret, it is documented what it is elsewhere in the documentation (the ^
character pointing at the source location below the source line), but it
actually changed in later gcc versions (gcc 5 is going out of support RSN),
https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html#Diagnostic-Message-Formatting-Options
shows that we now have instead of caret range1 and range2 and there are many
further kinds).

[Bug rtl-optimization/80481] Unoptimal additional copy instructions

[andrew.n.senkevich at gmail dot com]

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

--- Comment #1 from Andrew Senkevich  ---
Reload phase adds insn 1817 (1)

(insn 856 855 1817 136 (set (reg:V16SI 22 xmm1 [orig:985 vect__72.36 ] [985])
(unspec:V16SI [
(mem:V16SI (plus:DI (reg/f:DI 39 r10 [orig:206 vectp.34 ]
[206])
(reg:DI 2 cx [982])) [4 MEM[base: vectp.34_259, index:
_972, offset: 0B]+0 S64 A32])
(reg:V16SI 47 xmm10 [1041])
] UNSPEC_VPERMVAR)) "./test-first.c":60 4157 {avx512f_permvarv16si}
 (nil))
(insn 1817 856 857 136 (set (reg:V16SF 23 xmm2 [orig:985 vect__72.36 ] [985])  
(1)
(reg:V16SF 22 xmm1 [orig:985 vect__72.36 ] [985])) "./test-first.c":61
1237 {movv16sf_internal}
 (nil))
(insn 857 1817 858 136 (set (reg:V16SF 23 xmm2 [orig:985 vect__72.36 ] [985])
(fma:V16SF (neg:V16SF (reg:V16SF 23 xmm2 [orig:985 vect__72.36 ]
[985]))
(mem:V16SF (plus:DI (reg/f:DI 37 r8 [orig:201 vectp.38 ] [201])
(reg:DI 1 dx [orig:557 ivtmp.110 ] [557])) [4 MEM[base:
vectp.38_249, index: ivtmp.110_977, offset: 0B]+0 S64 A512])
(reg:V16SF 28 xmm7 [orig:1034 vect_cst__243 ] [1034])))
"./test-first.c":61 1928 {*fma_fnmadd_v16sf}
 (nil))

and it lives until the end:

#(insn:TI 856 851 1817 75 (set (reg:V16SI 22 xmm1 [orig:985 vect__72.36 ]
[985])
#(unspec:V16SI [
#(mem:V16SI (plus:DI (reg/f:DI 39 r10 [orig:206 vectp.34 ]
[206])
#(reg:DI 2 cx [982])) [4 MEM[base: vectp.34_259, index:
_972, offset: 0B]+0 S64 A32])
#(reg:V16SI 47 xmm10 [1041])
#] UNSPEC_VPERMVAR)) "./test-first.c":60 4157
{avx512f_permvarv16si}
# (expr_list:REG_DEAD (reg:DI 2 cx [982])
#(nil)))
vpermd  (%r10,%rcx), %zmm10, %zmm1  # 856   avx512f_permvarv16si   
[length = 7]
#(insn:TI 1817 856 857 75 (set (reg:V16SF 23 xmm2 [orig:985 vect__72.36 ]
[985])
#(reg:V16SF 22 xmm1 [orig:985 vect__72.36 ] [985])) "./test-first.c":61
1237 {movv16sf_internal}
# (expr_list:REG_DEAD (reg:V16SF 22 xmm1 [orig:985 vect__72.36 ] [985])
#(nil)))
vmovaps %zmm1, %zmm2# 1817  movv16sf_internal/3 [length = 6]   
(1)
#(insn 857 1817 860 75 (set (reg:V16SF 23 xmm2 [orig:985 vect__72.36 ] [985])
#(fma:V16SF (neg:V16SF (reg:V16SF 23 xmm2 [orig:985 vect__72.36 ]
[985]))
#(mem:V16SF (plus:DI (reg/f:DI 37 r8 [orig:201 vectp.38 ] [201])
#(reg:DI 1 dx [orig:557 ivtmp.110 ] [557])) [4 MEM[base:
vectp.38_249, index: ivtmp.110_977, offset: 0B]+0 S64 A512])
#(reg:V16SF 28 xmm7 [orig:1034 vect_cst__243 ] [1034])))
"./test-first.c":61 1928 {*fma_fnmadd_v16sf}
# (nil))
vfnmadd132ps(%r8,%rdx), %zmm7, %zmm2# 857  
*fma_fnmadd_v16sf/1 [length = 7]

[Bug middle-end/66462] GCC isinf/isnan/... builtins cause sNaN exceptions

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #10 from Wilco  ---
(In reply to Bill Sacks from comment #9)
> I have found that, with gfortran, the following all lead to a SIGFPE if I
> compile with -ffpe-trap=invalid:
> 
> (1) ieee_value(my_nan, ieee_quiet_nan)
> 
> (2) ieee_value(my_nan, ieee_signaling_nan)
> 
> (3) ieee_is_nan called on a signaling NaN
> 
> (4) gfortran's built-in isnan called on a signaling NaN
> 
> (5) ieee_class called on a signaling NaN
> 
> (See https://github.com/NCAR/billsacks-gfortran-snan/tree/master_n01 for
> test code and more information.)
> 
> Are all of these duplicate problems to the one reported here, or are some of
> these separate issues that should be opened?

If the code does what it appears to do (just creating NaN bitpatterns and
testing them, not arithmetic) then it is likely something else as this
shouldn't cause exceptions. It's worth narrowing down to a tiny example and
find out where the exception happens in the generated assembly. Running on
other targets (which support traps) may be worthwhile to find out whether this
is a general issue or x64 specific.

[Bug other/78366] target_clones does not generate resovler function

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Liška  ---
(In reply to Martin Liška from comment #6)
> As discussed in PR81214, the behavior was changed to generate ifunc resolver
> even when a target_clone function is not directly used. Please take a look
> at r249840.

That said I'm going to close it as trunk is fixed. And changes are not subject
of backport.

[Bug c++/82213] New: Please warn about const rvalue reference parameters [void func(const T&&);]

[palves at redhat dot com]

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

Bug ID: 82213
   Summary: Please warn about const rvalue reference parameters
[void func(const T&&);]
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: palves at redhat dot com
  Target Milestone: ---

It'd be nice if GCC would warn about const rvalue reference
parameters.

AFAIK, there's no good use for such parameters, and they'll usually lead 
to a silent pessimization when you try to move from the passed in
temporary object:

 void func (const std::vector &)
 {
   // does not actually move.  silently copies instead ...
   std::vector vec2 = std::move (vec); 

   // ... because the above called the 'vector(const vector &)'
   // overload,  instead of 'vector(vector &&)'.
 }

See  for a
case just like the above.

The only good use of 'const T &&' parameters that I'm aware of
is to delete overloads, like:

  void func(const T &);
  void func(const T &&) = delete;

... so that const rvalues don't use the const T& overload.  E.g., std::ref.

So I think it'd be nice to warn about const rvalue ref parameters 
of non-deleted functions.

[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch for bootstrapping under Xcode 9

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe  ---
(In reply to Richard Biener from comment #4)
> The gcc-6 backport is ok (if you want to go ahead).

Is (a suitably modified) version also OK for gcc-5?
 (I checked the posted one on Darwin and Linux and it seems OK, but I don't
have much state on this)

[Bug target/82170] gcc optimizes int range-checking poorly on x86-64

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
To summarize IRC discussions about this, the first step should be to introduce
SEXT_EXPR (split from Prathamesh's patch, improve), then add match.pd
canonicalization of these range testing to SEXT_EXPR + EQ_EXPR/NE_EXPR or
BIT_AND_EXPR + EQ/NE, recognize those in range discovery for reassoc.
Combine probably isn't able to handle transformation of one seq to the other,
and in any case, combiner would be only one way (it simplifies/canonicalizes
the IL to something, but doesn't have easy way to try two completely different
but equivalent sequences; also, often it is more than 4 instructions).
So we should try to do something in the expansion to try both sequences and
pick the less costly.

[Bug middle-end/32911] Function __attribute__ ((idempotent))

[bugzilla at tecnocode dot co.uk]

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

--- Comment #5 from Philip Withnall  ---
Bug filed against Clang with the same request here:
https://bugs.llvm.org/show_bug.cgi?id=34600

[Bug libstdc++/82212] New: libstdc++ makes (integer|index)_sequence available with -std=c++11, but they're C++14 features

[db0451 at gmail dot com]

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

Bug ID: 82212
   Summary: libstdc++ makes (integer|index)_sequence available
with -std=c++11, but they're C++14 features
   Product: gcc
   Version: unknown
   URL: https://bugzilla.gnome.org/show_bug.cgi?id=787648
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: db0451 at gmail dot com
  Target Milestone: ---

https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/utility#L298

std::integer_sequence and std::index_sequence are defined under this condition:

#if __cplusplus > 201103L

However, these features debuted in the C++14 Standard, not in C++11.

The symbols therefore should not be available in -std=c++11 mode. When users,
for example, don't realise they only debuted in C++14, use them in -std=c++11
mode, and later compile that code using clang/libc++ in the same mode - they
suddenly get compile errors and realise their project unwittingly started
requiring C++14.

See the URL for a downstream example of this causing a problem.

[Bug ipa/81214] GCC target_clone support does not work for global functions with no references

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Liška  ---
No plan to backport, thus closing.

[Bug tree-optimization/82163] [8 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:707

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |amker at gcc dot gnu.org

--- Comment #2 from amker at gcc dot gnu.org ---
I will investigate the issue.  Thanks very much for reporting and bisect.

[Bug tree-optimization/81346] Missed constant propagation into comparison

[glisse at gcc dot gnu.org]

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

--- Comment #18 from Marc Glisse  ---
(In reply to Gergö Barany from comment #17)
> the division used to be replaced by a shift that updated the condition code
> register (again, on ARM; r250337):

(just my opinion)
At a high level (gimple), (unsigned)x+3<=6 seems like a more canonical way to
represent an interval than x/4==0. If the second one turns out to be more
efficient on some targets, it sounds like we could later turn (unsigned)x+3<=6
into x/4==0 (even if the user did not write it that way), i.e. add a new
transform at RTL time. Looks like a separate enhancement request would be
appropriate.

[Bug driver/81829] [7 Regression] /usr/bin/gcc-{ar,nm,ranlib} segfault without arguments

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Created attachment 42168
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42168=edit
Patch candidate

So I eventually decided to remove the smartness in wrappers, let's make it
simple. I've been testing that.

[Bug tree-optimization/80996] gcc.dg/vect/vect-multitypes-12.c XPASSes

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2017-09/msg00874.ht
   ||ml
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org

--- Comment #2 from Rainer Orth  ---
Fixed.

[Bug target/82170] gcc optimizes int range-checking poorly on x86-64

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
More complete testcase:
extern inline int f1 (long long n) { return -__INT_MAX__ - 1 <= n && n <=
__INT_MAX__; }
extern inline int f2 (long long n) { return n == (int) n; }
extern inline int f3 (unsigned long long n) { return n <= ~0U; }
extern inline int f4 (unsigned long long n) { return n == (unsigned int) n; }
extern inline int f5 (long long n) { return -__SHRT_MAX__ - 1 <= n && n <=
__SHRT_MAX__; }
extern inline int f6 (long long n) { return n == (short) n; }
extern inline int f7 (unsigned long long n) { return n <= (unsigned short) ~0U;
}
extern inline int f8 (unsigned long long n) { return n == (unsigned short) n; }
extern inline int f9 (long long n) { return -__SCHAR_MAX__ - 1 <= n && n <=
__SCHAR_MAX__; }
extern inline int f10 (long long n) { return n == (signed char) n; }
extern inline int f11 (unsigned long long n) { return n <= (unsigned char) ~0U;
}
extern inline int f12 (unsigned long long n) { return n == (unsigned char) n; }
extern inline int f13 (int n) { return -__SHRT_MAX__ - 1 <= n && n <=
__SHRT_MAX__; }
extern inline int f14 (int n) { return n == (short) n; }
extern inline int f15 (unsigned int n) { return n <= (unsigned short) ~0U; }
extern inline int f16 (unsigned int n) { return n == (unsigned short) n; }
extern inline int f17 (int n) { return -__SCHAR_MAX__ - 1 <= n && n <=
__SCHAR_MAX__; }
extern inline int f18 (int n) { return n == (signed char) n; }
extern inline int f19 (unsigned int n) { return n <= (unsigned char) ~0U; }
extern inline int f20 (unsigned int n) { return n == (unsigned char) n; }
extern inline int f21 (short int n) { return -__SCHAR_MAX__ - 1 <= n && n <=
__SCHAR_MAX__; }
extern inline int f22 (short int n) { return n == (signed char) n; }
extern inline int f23 (unsigned short int n) { return n <= (unsigned char) ~0U;
}
extern inline int f24 (unsigned short int n) { return n == (unsigned char) n; }
extern void foo (void);
void s1 (long long n) { if (f1 (n)) foo (); }
void s2 (long long n) { if (f2 (n)) foo (); }
void s3 (unsigned long long n) { if (f3 (n)) foo (); }
void s4 (unsigned long long n) { if (f4 (n)) foo (); }
void s5 (long long n) { if (f5 (n)) foo (); }
void s6 (long long n) { if (f6 (n)) foo (); }
void s7 (unsigned long long n) { if (f7 (n)) foo (); }
void s8 (unsigned long long n) { if (f8 (n)) foo (); }
void s9 (long long n) { if (f9 (n)) foo (); }
void s10 (long long n) { if (f10 (n)) foo (); }
void s11 (unsigned long long n) { if (f11 (n)) foo (); }
void s12 (unsigned long long n) { if (f12 (n)) foo (); }
void s13 (int n) { if (f13 (n)) foo (); }
void s14 (int n) { if (f14 (n)) foo (); }
void s15 (unsigned int n) { if (f15 (n)) foo (); }
void s16 (unsigned int n) { if (f16 (n)) foo (); }
void s17 (int n) { if (f17 (n)) foo (); }
void s18 (int n) { if (f18 (n)) foo (); }
void s19 (unsigned int n) { if (f19 (n)) foo (); }
void s20 (unsigned int n) { if (f20 (n)) foo (); }
void s21 (short int n) { if (f21 (n)) foo (); }
void s22 (short int n) { if (f22 (n)) foo (); }
void s23 (unsigned short int n) { if (f23 (n)) foo (); }
void s24 (unsigned short int n) { if (f24 (n)) foo (); }

So, this seems to be an instruction selection thing.  Comparing each pair of
functions shows that at least for instruction counts the latter is often, but
not always, shorter.

One question is if we want to canonicalize this during gimple fold (either the
n ==/!= (narrower type) n, or n + narrower_type_min_as_unsigned_wider <=/>
narrower_type_max_as_unsigned_wider to the other form if single use); if we do
and it is the former form, we'd also need to adjust the range discovery code
that reassoc uses in the range optimization.

Then there is a question how do we want to generate optimal sequence.  Do we
e.g. want to hook into the expansion (somewhere in do_store_flag and
do_compare_and_jump), check for this pattern (using TER info) and perhaps try
to expand both sequences, compute costs of both and see what is cheaper?

Hardcoding just one way I'm afraid is not going to be always a win.

Or shall the combiner be able to do something?

[Bug tree-optimization/80996] gcc.dg/vect/vect-multitypes-12.c XPASSes

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  ---
Author: ro
Date: Thu Sep 14 09:20:18 2017
New Revision: 252754

URL: https://gcc.gnu.org/viewcvs?rev=252754=gcc=rev
Log:
Don't xfail gcc.dg/vect/vect-multitypes-12.c on 32-bit SPARC (PR
tree-optimization/80996)

PR tree-optimization/80996
* gcc.dg/vect/vect-multitypes-12.c: Remove sparc*-*-* handling.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-multitypes-12.c

[Bug tree-optimization/81346] Missed constant propagation into comparison

[gergo.barany at inria dot fr]

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

--- Comment #17 from Gergö Barany  ---
Thanks for fixing this. I did notice a small thing that might be considered a
tiny regression due to the fix.

If the divisor is a small power of 2, as in the following example:

int fn1(char p1) {
  long a;
  char b;
  int c = a = 4;
  b = !(p1 / a);
  if (b)
c = 0;
  return c;
}

the division used to be replaced by a shift that updated the condition code
register (again, on ARM; r250337):

lsrsr3, r0, #2
movne   r0, #4
moveq   r0, #0
bx  lr

whereas after the fix (tested on r250342) the new folding rule takes precedence
and generates one instruction more:

add r0, r0, #3
cmp r0, #6
movhi   r0, #4
movls   r0, #0
bx  lr

I guess the rule could be updated to only apply if the divisor is not a small
power of 2, or folding a division by a power of 2 into a shift could be
prioritized.

Sorry about only pointing this out two months later! Also, let me stress that I
do not have code that depends on this transformation. This came out of research
I'm doing on missed optimization, and this was one example I found interesting.

[Bug c/82210] [5/6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
  Known to work||3.4.6
   Keywords||ABI, wrong-code
   Last reconfirmed||2017-09-14
 Ever confirmed|0   |1
Summary|Having _Alignas in a struct |[5/6/7/8 Regression] Having
   |with VLAs causes writing to |_Alignas in a struct with
   |one array to overwrite  |VLAs causes writing to one
   |another |array to overwrite another
   Target Milestone|--- |5.5
  Known to fail||4.0.0

--- Comment #1 from Richard Biener  ---
Same with __attribute__((aligned(16))).  Indeed works ok with using 15 instead
of size.

Got broken by tree-ssa somehow (3.4.6 works, 4.0.0 fails).

clang complains:

t.c:7:9: error: fields must have a constant size: 'variable length array in
  structure' extension will never be supported
  } a[size];
^

so this is a GCC extension it seems.

[Bug tree-optimization/82211] [8 Regression] ICE error: non-cold basic block 32 reachable only by paths crossing the cold partition

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/82211] New: [8 Regression] ICE error: non-cold basic block 32 reachable only by paths crossing the cold partition

[marxin at gcc dot gnu.org]

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

Bug ID: 82211
   Summary: [8 Regression] ICE error: non-cold basic block 32
reachable only by paths crossing the cold partition
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at ucw dot cz
  Target Milestone: ---

Happens on SPEC2006 on 403.gcc benchmark when one uses PGO:

i386.c: In function 'ix86_compute_frame_layout':
i386.c:4135:1: error: non-cold basic block 32 reachable only by paths crossing
the cold partition
 }
 ^
during RTL pass: bbro
i386.c:4135:1: internal compiler error: verify_flow_info failed
0x74d68c verify_flow_info()
../../gcc/cfghooks.c:259
0x763c76 checking_verify_flow_info
../../gcc/cfghooks.h:198
0x763c76 cfg_layout_finalize()
../../gcc/cfgrtl.c:4314
0x129aad9 execute
../../gcc/bb-reorder.c:2601

[Bug target/81325] -fcompare-debug failure on ppc64le

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep 14 08:07:30 2017
New Revision: 252752

URL: https://gcc.gnu.org/viewcvs?rev=252752=gcc=rev
Log:
PR target/81325
* cfgbuild.c (find_bb_boundaries): Ignore debug insns in decisions
if and where to split a bb, except for splitting before debug insn
sequences followed by non-label real insn.  Delete debug insns
in between basic blocks.

* g++.dg/cpp0x/pr81325.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr81325.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgbuild.c
trunk/gcc/testsuite/ChangeLog

[Bug c/81631] -Wcast-qual false positive for pointer to array

[gcc17 at cwde dot de]

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

--- Comment #3 from Tobias Jordan  ---
Hi,

thanks for taking a look, and thanks for your explanation. As far as I
understand it, it's somewhat intuitive that the qualifiers apply to array
elements and not the array type itself. What bugs me is that -Wcast-qual in
this case looks at the array type, not at the element type, to detect whether
qualifiers match.

My actual use case is more complicated than the first example. I'm doing some
kind of marshalling/unmarshalling:

const int (*bar(const int (*x)[6]))[6]
{
  const void * y = x;   /* (1) */
  /* y takes a journey... */
  return (const int (*)[6]) y;  /* (2) */
}

In this example, if I remove the "const" in (1), I get a warning for
"-Wdiscarded-array-qualifiers". If I make y a "const void *", I get the
"-Wcast-qual" warning in (2). In my opinion, using a "const void *" would be
the correct way to do it.

Actually, when I change the type of y to a "void*" and do an explicit cast in
(1), like in
  void * y = (void *) x;/* (1') */

I don't get any warning at all. Here, I would expect a "-Wcast-qual" warning:
before the cast, x is a pointer to an array of consts, so I couldn't modify the
pointer target. After the cast, I can, and don't get any warnings (but
undefined behaviour).

So my proposal for -Wcast-qual would be: when looking at pointer-to-array,
consider the qualifiers of the element type, not the array type, to detect
whether qualifiers match.

As a side note, clang seems to agree with me here:

$ clang -Wcast-qual -c foo.c
foo.c:3:24: warning: cast from 'int const (*)[6]' to 'void *' drops const
qualifier [-Wcast-qual]
   void * y = (void *) x;/* (1') */
   ^
1 warning generated.

[Bug c/82210] New: Having _Alignas in a struct with VLAs causes writing to one array to overwrite another

[gopalsr83 at gmail dot com]

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

Bug ID: 82210
   Summary: Having _Alignas in a struct with VLAs causes writing
to one array to overwrite another
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gopalsr83 at gmail dot com
  Target Milestone: ---

Created attachment 42167
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42167=edit
Preprocessed source that can be used to reproduce the bug

In the following program, writing elements of s.b causes overwrite of the last
few elements of s.a:

void fun(int size)
{
int i;
struct {
_Alignas(16) struct {
short aa;
} a[size];
int b[size];
} s;

for (i = 0; i < size; i++) {
s.a[i].aa = 0x1234;
}

for (i = 0; i < size; i++) {
s.b[i] = 0;
}

for (i = 0; i < size; i++) {
printf("0x%04x ", s.a[i].aa);
}

printf("\n");
}

int main ()
{
fun(15);
}

The above program produces the output:
0x1234 0x1234 0x1234 0x1234 0x1234 0x1234 0x1234 0x1234 0x 0x 0x
0x 0x 0x 0x 


I have narrowed it down to the use of VLAIS in combination with the _Alignas
specifier.

Removing _Alignas causes the program to execute correctly and produce the
output:

0x1234 0x1234 0x1234 0x1234 0x1234 0x1234 0x1234 0x1234 0x1234 0x1234 0x1234
0x1234 0x1234 0x1234 0x1234 

Command line output:
[gopal@localbuild ~]$gcc -v -save-temps -std=c11 -O0 -o test test.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c11' '-O0' '-o' 'test'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/cc1 -E -quiet -v test.c -mtune=generic
-march=x86-64 -std=c11 -O0 -fpch-preprocess -o test.i
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c11' '-O0' '-o' 'test'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/cc1 -fpreprocessed test.i -quiet
-dumpbase test.c -mtune=generic -march=x86-64 -auxbase test -O0 -std=c11
-version -o test.s
GNU C11 (GCC) version 7.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.2.0, GMP version 6.1.2, MPFR version
3.1.5-p2, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 7.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.2.0, GMP version 6.1.2, MPFR version
3.1.5-p2, 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: 7c9818d05f48c6fe376de9e4c491b54f
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c11' '-O0' '-o' 'test'
'-mtune=generic' '-march=x86-64'
 as -v --64 -o test.o test.s
GNU assembler version 2.29 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.29
COMPILER_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c11' '-O0' '-o' 'test'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/collect2 -plugin
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
-plugin-opt=-fresolution=test.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc

[Bug c++/82209] New: Compile error "X causes a section type conflict with Y" should provide more information

[noloader at gmail dot com]

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

Bug ID: 82209
   Summary: Compile error "X causes a section type conflict with
Y" should provide more information
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noloader at gmail dot com
  Target Milestone: ---

We are catching a compile error under GCC 6.10 on AIX. The error is shown
below. The diagnostic message does not appear to have enough information to
troubleshoot the issue. After 3 hours of knob turning we are still experiencing
the issue.

This error is not too common, but when it hits people seem to suffer. The
questions on Stack Overflow and around the web seem to point to a gap in the
error message. That is, the error message does not provide enough information
and most people guess at the cause of the problem.

I found one question that actually tried to troubleshoot the issue by
identifying the objects, their section and the attributes. The OP was doing
things like inspecting *.ii and *.s files, but he/she could not identify the
conflict. Also see https://stackoverflow.com/q/30005764/608639.

Telling me the objects are conflicting, the X and Y in "X causes a section type
conflict with Y", is a good start. I'd like to request the error message be
improved to include (1) the section of each conflicting object, and (2) the
attributes of the section that are contributing to the conflict.

==

In file included from bench2.cpp:9:0:
gfpcrypt.h: In function 'CryptoPP::DL_PrivateKey_GFP::~DL_PrivateKey_GFP()
[with GP = CryptoPP::DL_GroupParameters_DSA]':
gfpcrypt.h:519:13: error: CryptoPP::DL_PrivateKey_GFP::~DL_PrivateKey_GFP()
[with GP = CryptoPP::DL_GroupParameters_DSA] causes a section type conflict
with void CryptoPP::AllocatorWithCleanup::deallocate(void*,
CryptoPP::AllocatorWithCleanup::size_type) [with T = unsigned
char; bool T_Align16 = true]
 virtual ~DL_PrivateKey_GFP() {}
 ^
In file included from integer.h:20:0,
 from validate.h:8,
 from bench2.cpp:6:
secblock.h:217:7: note: 'void CryptoPP::AllocatorWithCleanup::deallocate(void*, CryptoPP::AllocatorWithCleanup::size_type) [with T = unsigned char; bool T_Align16 = true]' was
declared here
  void deallocate(void *ptr, size_type size)
   ^~
GNUmakefile:1026: recipe for target 'bench2.o' failed

[Bug go/82208] exec_linux.go:197:27: error: reference to undefined name 'SYS_UNSHARE'

[mfe at live dot de]

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

--- Comment #1 from martin  ---
I used the gcc-trunk source:
nas-02-90-38:/media/gcc-trunk# /opt/svn-1.9.7/bin/svn info
Path: .
Working Copy Root Path: /c/media/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 251751
Node Kind: directory
Schedule: normal
Last Changed Author: law
Last Changed Rev: 251751
Last Changed Date: 2017-09-05 22:20:25 -0700 (Tue, 05 Sep 2017)

Compiling gcc on the readynas duo takes up to 4-5 days.

[Bug go/82208] New: exec_linux.go:197:27: error: reference to undefined name 'SYS_UNSHARE'

[mfe at live dot de]

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

Bug ID: 82208
   Summary: exec_linux.go:197:27: error: reference to undefined
name 'SYS_UNSHARE'
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: mfe at live dot de
CC: cmang at google dot com
  Target Milestone: ---

I used:
/gcc-trunk-compiled# ../gcc-trunk/configure CC=/opt/gcc-7.1/bin/gcc
CXX=/opt/gcc-7.1/bin/g++ --enable-languages=c,c++,go --prefix=/opt/gcc-7.2.0 
--with-cpu=v7 --disable-libstdcxx-pch --disable-linux-futex
--disable-libsanitizer --enable-__cxa_atexit --with-system-zlib
--enable-clocale=gnu --enable-debug  --disable-doc --disable-libcilkrts
--disable-libitm --disable-nls

The error occurred with:
/usr/local/bin/make

The error message:
scall/libcall_uname.go ../../../gcc-trunk/libgo/go/syscall/libcall_wait4.go
../../../gcc-trunk/libgo/go/syscall/lsf_linux.go
../../../gcc-trunk/libgo/go/syscall/msan0.go
../../../gcc-trunk/libgo/go/syscall/netlink_linux.go
../../../gcc-trunk/libgo/go/syscall/setuidgid_linux.go
../../../gcc-trunk/libgo/go/syscall/sleep_select.go
../../../gcc-trunk/libgo/go/syscall/sockcmsg_linux.go
../../../gcc-trunk/libgo/go/syscall/sockcmsg_unix.go
../../../gcc-trunk/libgo/go/syscall/socket.go
../../../gcc-trunk/libgo/go/syscall/socket_linux.go
../../../gcc-trunk/libgo/go/syscall/socket_linux_type.go
../../../gcc-trunk/libgo/go/syscall/socket_posix.go
../../../gcc-trunk/libgo/go/syscall/str.go
../../../gcc-trunk/libgo/go/syscall/syscall.go
../../../gcc-trunk/libgo/go/syscall/syscall_errno.go
../../../gcc-trunk/libgo/go/syscall/syscall_linux.go
../../../gcc-trunk/libgo/go/syscall/syscall_unix.go
../../../gcc-trunk/libgo/go/syscall/timestruct.go libcalls.go sysinfo.go
syscall_arch.go epoll.go  -fPIC -o .libs/syscall.o
../../../gcc-trunk/libgo/go/syscall/exec_linux.go:197:27: error: reference to
undefined name 'SYS_UNSHARE'
   _, _, err1 = RawSyscall(SYS_UNSHARE, sys.Unshareflags, 0, 0)
   ^
../../../gcc-trunk/libgo/go/syscall/libcall_linux_utimesnano.go:17:18: error:
reference to undefined name '_AT_FDCWD'
  err = utimensat(_AT_FDCWD, path, (*[2]Timespec)(unsafe.Pointer([0])), 0)
  ^
../../../gcc-trunk/libgo/go/syscall/lsf_linux.go:14:28: error: use of undefined
type 'SockFilter'
 func LsfStmt(code, k int) *SockFilter {
^
../../../gcc-trunk/libgo/go/syscall/lsf_linux.go:14:28: error: use of undefined
type 'SockFilter'
../../../gcc-trunk/libgo/go/syscall/lsf_linux.go:74:8: error: use of undefined
type 'SockFprog'
  var p SockFprog
^
../../../gcc-trunk/libgo/go/syscall/lsf_linux.go:75:3: error: reference to
field 'Len' in object which has no fields or methods
  p.Len = uint16(len(i))
   ^
../../../gcc-trunk/libgo/go/syscall/lsf_linux.go:76:3: error: reference to
field 'Filter' in object which has no fields or methods
  p.Filter = (*SockFilter)(unsafe.Pointer([0]))
   ^
../../../gcc-trunk/libgo/go/syscall/lsf_linux.go:76:15: error: reference to
undefined name 'SockFilter'
  p.Filter = (*SockFilter)(unsafe.Pointer([0]))
   ^
../../../gcc-trunk/libgo/go/syscall/lsf_linux.go:76:14: error: expected pointer
  p.Filter = (*SockFilter)(unsafe.Pointer([0]))
  ^
../../../gcc-trunk/libgo/go/syscall/socket_linux.go:173:22: error: reference to
undefined name 'SizeofIPv6MTUInfo'
  vallen := Socklen_t(SizeofIPv6MTUInfo)
  ^
../../../gcc-trunk/libgo/go/syscall/lsf_linux.go:14:28: error: use of undefined
type 'SockFilter'
 func LsfStmt(code, k int) *SockFilter {
^
../../../gcc-trunk/libgo/go/syscall/lsf_linux.go:14:28: error: use of undefined
type 'SockFilter'
../../../gcc-trunk/libgo/go/syscall/lsf_linux.go:14:28: error: use of undefined
type 'SockFilter'
../../../gcc-trunk/libgo/go/syscall/socket_linux.go:171:50: error: use of
undefined type 'IPv6MTUInfo'
 func GetsockoptIPv6MTUInfo(fd, level, opt int) (*IPv6MTUInfo, error) {
  ^
../../../gcc-trunk/libgo/go/syscall/socket_linux.go:171:50: error: use of
undefined type 'IPv6MTUInfo'
make[4]: *** [Makefile:3213: syscall.lo] Error 1
make[4]: Leaving directory
'/c/media/gcc-trunk-compiled/sparc-unknown-linux-gnu/libgo'
make[3]: *** [Makefile:2629: all-recursive] Error 1
make[3]: Leaving directory
'/c/media/gcc-trunk-compiled/sparc-unknown-linux-gnu/libgo'

Do you need any more informations?