[Bug testsuite/82997] [8 regression] gcc.dg/cpp/sysmac1.c and gcc.dg/cpp/macsyntx.c fail starting with r254707

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 17 07:42:28 2017
New Revision: 254857

URL: https://gcc.gnu.org/viewcvs?rev=254857=gcc=rev
Log:
PR testsuite/82997
* gcc.dg/cpp/macsyntx.c (var1, rest): Don't expect
"requires at least one" warning.
* gcc.dg/cpp/sysmac1.c (foo): Likewise.
* gcc.dg/cpp/macsyntx2.c: New test.
* gcc.dg/cpp/sysmac3.c: New test.
* gcc.dg/cpp/sysmac3.h: New file.

Added:
trunk/gcc/testsuite/gcc.dg/cpp/macsyntx2.c
trunk/gcc/testsuite/gcc.dg/cpp/sysmac3.c
trunk/gcc/testsuite/gcc.dg/cpp/sysmac3.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/cpp/macsyntx.c
trunk/gcc/testsuite/gcc.dg/cpp/sysmac1.c

[Bug c++/83028] New: Incorrect -Wsequence-point warning in correct C++17 code with new evaluation order rules

[ixsci at yandex dot ru]

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

Bug ID: 83028
   Summary: Incorrect -Wsequence-point warning in correct C++17
code with new evaluation order rules
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ixsci at yandex dot ru
  Target Milestone: ---

Compiling the following code:

#include 

using namespace std;

int main()
{
int i = 0;
cout << i++ << " " << i++ << "\n";
};

with the latest gcc (compiled on wandbox.org) and -std=c++1z gives the
following warning:
operation on 'i' may be undefined [-Wsequence-point]
 cout << i++ << " " << i++ << "\n";

But there should be no warnings since both modifications are sequenced and the
result is well defined.

[Bug libstdc++/66689] comp_ellint_3 and ellint_3 return garbage values

[3dw4rd at verizon dot net]

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

--- Comment #5 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
in other news I've switched to boost to test this.

[Bug libstdc++/66689] comp_ellint_3 and ellint_3 return garbage values

[3dw4rd at verizon dot net]

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

--- Comment #4 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
My last comment is nuts.  I was thrown by the fact that GSL, against which I've
been testing, and the Carlson papers that form the basis if the implementation
use the +nu convention.  I must change this.  This is a huge bug.

[Bug middle-end/78809] Inline strcmp with small constant strings

[law at gcc dot gnu.org]

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

--- Comment #21 from Jeffrey A. Law  ---
Author: law
Date: Fri Nov 17 05:32:05 2017
New Revision: 254856

URL: https://gcc.gnu.org/viewcvs?rev=254856=gcc=rev
Log:
2017-11-15  Qing Zhao 

PR middle-end/78809
* gimple-fold.c (gimple_fold_builtin_string_compare): Add handling
of replacing call to strncmp with corresponding call to strcmp when
meeting conditions.

PR middle-end/78809
* gcc.dg/strcmpopt_1.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/strcmpopt_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog

[Bug ada/83027] New: Hang when attaching a SIGINT handler

[porton at narod dot ru]

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

Bug ID: 83027
   Summary: Hang when attaching a SIGINT handler
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: porton at narod dot ru
  Target Milestone: ---

Created attachment 42630
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42630=edit
The source reprising the bug

Extract attached bug.zip into an empty directory.

Run

make compile
./obj/simple_test

The command simple_test hangs.

The most wonderful thing is that if I do not compile it (as "make compile" 
does) as an .a library imported when linking simple_test, but put all source 
into a single directory and run "gnatmake simple_test", then the error does 
not happen (but Program_Error is raised as it should be accordingly the docs,
because pragma Unreserve_All_Interrupts is not in effect in this example code).

Another weird thing that it happens with SIGINT but not with SIGTERM nor with
SIGCHLD.

The bug also does not happen if I remove "with Ada.Text_IO;".

GCC 7.2.0.

[Bug fortran/25829] [F03] Asynchronous IO support

[jvdelisle at gcc dot gnu.org]

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

--- Comment #33 from Jerry DeLisle  ---
(In reply to Janne Blomqvist from comment #32)
> Interestingly, Linux 4.14 contains a way to avoid a context switch to a
> threadpool in case the data is already in the page cache:
> https://kernelnewbies.org/Linux_4.14#head-
> 8c8861fbded3e87631ab06bcd511f5f0d8bfa220
> 
> Might be an interesting optimization sometime in the future..

It is interesting that I was reading this very webpage myself today looking at
4.14 feature. I am pretty sure we can hand off the I/O to the OS. I am not so
sure how one checks the status of the operaton. This is what wait should do,
wait for completion.

[Bug libfortran/78549] [8 Regression] Very slow formatted internal file output

[jvdelisle at gcc dot gnu.org]

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

--- Comment #23 from Jerry DeLisle  ---
Well, instrumenting a little bit I see that delete_root is getting called many
many many times. So, every call to newunit_alloc is assigning a new unit number
which is getting added to the treap and never reused in anyway.

The result of this is that at the end of the program when any units left on the
treap are deleted, we loop through over one million deletes.

So I now have a better idea of what we need to do.

[Bug fortran/83021] [7 Regression] gfortran segfault

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> > Could you please provide the file(s) needed to generate 
> > local_field_module.mod?
>
> I suspect the source code in question is the same as ...

This file is not enough to generate local_field_module.mod.

You have to provide a self contained reproducer otherwise the PR will be closed
as INVALID.

[Bug tree-optimization/82950] possible strlen optimization for memcmp/strcmp of arrays

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
An even simpler test case:

void g (void)
{
  const char a[] = "abc";
  const char b[] = "abcd";
  if (!__builtin_strcmp (a, b))
__builtin_abort ();
}

See also bug 78809.

[Bug fortran/82996] ICE and segfault with derived type finalization

[neil.n.carlson at gmail dot com]

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

--- Comment #8 from neil.n.carlson at gmail dot com ---
> If I remove 'elemental' for 'subroutine foo_destroy', the segfault is gone.

In that case the final procedure doesn't match the array component and wouldn't
be called.  I suspect that is why the segfault is gone.

[Bug fortran/83021] [7 Regression] gfortran segfault

[zbeekman at gmail dot com]

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

Zaak  changed:

   What|Removed |Added

 CC||zbeekman at gmail dot com

--- Comment #2 from Zaak  ---
I suspect the source code in question is the same as
https://github.com/sourceryinstitute/OpenCoarrays/blob/8eab16936fb958746575f5c9580ba521320e0444/src/tests/integration/pde_solvers/coarrayBurgers/local_field.F90

[Bug fortran/82996] ICE and segfault with derived type finalization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Blocks||37336

--- Comment #7 from Dominique d'Humieres  ---
> I think Dominique swapped 2 and 3.

Indeed!

If I compile the tests in comment 0 or 1 with '-fsanitize=address,undefined', I
get at run time an error of the kind:

pr82996.f90:17: runtime error: member access within misaligned address
0x1000e3e7620c for type 'struct foo', which requires 8 byte alignment
0x1000e47d2bec: note: pointer points here
ASAN:DEADLYSIGNAL
=
==3427==ERROR: AddressSanitizer: SEGV on unknown address 0x12001c8fa57d (pc
0x00010796507b bp 0x7ffee84cd9c0 sp 0x7ffee84cd150 T0)
#0 0x10796507a in wrap_write.part.20
(/opt/gcc/gcc7wr/lib/libasan.4.dylib+0x2507a)
#1 0x109224d2e in __sanitizer::IsAccessibleMemoryRange(unsigned long,
unsigned long) (/opt/gcc/gcc7wr/lib/libubsan.0.dylib+0x17d2e)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/opt/gcc/gcc7wr/lib/libasan.4.dylib+0x2507a)
in wrap_write.part.20
==3427==ABORTING

Program received signal SIGABRT: Process abort signal.


If I remove 'elemental' for 'subroutine foo_destroy', the segfault is gone.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug 37336] [F03] Finish derived-type finalization

[Bug tree-optimization/83026] missing strlen optimization for strcmp of unequal strings

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82950

--- Comment #1 from Martin Sebor  ---
See also pr82950 for a related enhancement.

[Bug tree-optimization/83026] New: missing strlen optimization for strcmp of unequal strings

[msebor at gcc dot gnu.org]

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

Bug ID: 83026
   Summary: missing strlen optimization for strcmp of unequal
strings
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Here's another strcmp optimization opportunity.  When strlen() determines that
two strings are of unequal length it's safe to assume they do not compare
equal.  Therefore, in the function below, the conditional with the the strcmp()
call can be folded into false.

$ cat c.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout c.c
void g (const char *a, const char *b)
{
  if (__builtin_strlen (a) == __builtin_strlen (b))
return;

  if (!__builtin_strcmp (a, b))
__builtin_abort ();
}

;; Function g (g, funcdef_no=0, decl_uid=1892, cgraph_uid=0, symbol_order=0)

g (const char * a, const char * b)
{
  long unsigned int _1;
  long unsigned int _2;
  int _3;

   [local count: 1]:
  _1 = __builtin_strlen (a_5(D));
  _2 = __builtin_strlen (b_6(D));
  if (_1 == _2)
goto ; [20.97%]
  else
goto ; [79.03%]

   [local count: 7903]:
  _3 = __builtin_strcmp (a_5(D), b_6(D));
  if (_3 == 0)
goto ; [0.04%]
  else
goto ; [99.96%]

   [count: 0]:
  __builtin_abort ();

   [local count: 9997]:
  return;

}

[Bug driver/83016] gnat1: warning: command line option ‘-nostdinc++’ is valid for C++/ObjC++ but not for Ada

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
Created attachment 42629
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42629=edit
Tentative fix

The patch makes sure g++ is only used to link and not to compile Ada stuff.

[Bug driver/83016] gnat1: warning: command line option ‘-nostdinc++’ is valid for C++/ObjC++ but not for Ada

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/53805] combine_comparisons changes trapping behavior

[glisse at gcc dot gnu.org]

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

--- Comment #11 from Marc Glisse  ---
(In reply to Richard Biener from comment #3)
> > I am happy to relabel this bug (or file a new one if you prefer) as a missed
> > optimization.
> 
> I'd say open a new one.

For reference, that's PR 53806.

[Bug libstdc++/82366] std::regex constructor called from shared library throws std::bad_cast

[spamdrop at fodvo dot org]

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

--- Comment #5 from spamdrop at fodvo dot org ---
Taking Johnathan's recommendation on Sept 29, I rebuilt the entire app, all
libaries etc using -D_GLIBCXX_USE_CXX11_ABI=0

Carefully isolating the libs and LD_LIBRARY_PATH.  Using ABI=0, the program
runs fine.  When I repeat the exact same steps without the ABI=0 define, the
program throws the std::bad_cast error.

[Bug libstdc++/83025] xfstream::open with char* gets caught on C++17 path overload.

[3dw4rd at verizon dot net]

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

--- Comment #1 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
Created attachment 42628
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42628=edit
patch...

enable_if with is_class_v.

[Bug libstdc++/83025] New: xfstream::open with char* gets caught on C++17 path overload.

[3dw4rd at verizon dot net]

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

Bug ID: 83025
   Summary: xfstream::open with char* gets caught on C++17 path
overload.
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 3dw4rd at verizon dot net
  Target Milestone: ---

Created attachment 42627
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42627=edit
Example showing error.  Compile with -std=c++17

char* filename = "test.txt"

std::ofstream unit;
unit.open(filename);

when compiled with C++17 gives:

/home/ed/bin/include/c++/8.0.0/fstream: In instantiation of ‘decltype
((void)(((std::basic_ofstream<_CharT,
_Traits>*)this)->std::basic_ofstream<_CharT, _Traits>::_M_filebuf.open(__s,
__mode))) std::basic_ofstream<_CharT, _Traits>::open(const _Path&,
std::ios_base::openmode) [with _Path = char*; _CharT = char; _Traits =
std::char_traits; decltype ((void)(((std::basic_ofstream<_CharT,
_Traits>*)this)->std::basic_ofstream<_CharT, _Traits>::_M_filebuf.open(__s,
__mode))) = void; std::ios_base::openmode = std::_Ios_Openmode]’:
err.cpp:18:27:   required from here
/home/ed/bin/include/c++/8.0.0/fstream:895:13: error: request for member
‘c_str’ in ‘__s’, which is of non-class type ‘char* const’
  { open(__s.c_str(), __mode); }

[Bug c++/79092] template: type ignored if value already instantiated

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed for GCC 8.

[Bug middle-end/83022] malloc & memset -> calloc is not always an optimization

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
Yes, this is a measurable degradation in going from gcc 4.9 -> 5.0 with myrocks
DB.  Apparently 25% more queries/sec with gcc 4.9 (I think it's from a
benchmark).  Profiling (by others) has fingered this optimization.

I am in the process of implementing a check to see if the only condition
between the malloc and memset is 'ptr != 0'.

I noticed the crazy default probabilities during investigating this.  I think
that's really a second-order problem.

[Bug fortran/83012] [8 Regression] Simply contiguous pointer function not recognized as contiguous

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Created attachment 42626
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42626=edit
patch that appears to work

This seems to work, let's see if it survives regression testing.

[Bug fortran/82996] ICE and segfault with derived type finalization

[ondrej.certik at gmail dot com]

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

Ondřej Čertík  changed:

   What|Removed |Added

 CC||ondrej.certik at gmail dot com

--- Comment #6 from Ondřej Čertík  ---
The finalizers are the most serious problem with gfortran for us. Every other
bug we can workaround one way or another it seems, but the finalizers are very
hard to workaround, one essentially has to comment them out, not just in our
code, but also in all dependencies, and even then that introduces memory leaks.

What exactly is the problem? Is this a bug in the gfortran frontend, or
something more fundamental? Is this a relatively simple fix for somebody who
understands the internals, or would this require a significant time investment
and redesign of the code?

[Bug c++/83024] ICE in build_address, at cp/typeck.c:5623

[guille at berkeley dot edu]

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

--- Comment #1 from Guille  ---
I have tested the unsimplified version of this code, and it ICEs on every
version *after* gcc-8-20170827.

[Bug c++/83024] New: ICE in build_address, at cp/typeck.c:5623

[guille at berkeley dot edu]

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

Bug ID: 83024
   Summary: ICE in build_address, at cp/typeck.c:5623
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guille at berkeley dot edu
  Target Milestone: ---

The following short code ICEs on

$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 8.0.0 20171112 (experimental) (GCC)

Code that triggers ICE follows:
---
#include 

template  struct __optional: std::optional
{
__optional()= default;
__optional(T&& t)   : std::optional (std::move(t)) {}
operator bool () const { return (bool)(const std::optional&)*this; }   
// <- omit this line and it compiles fine
};

struct A : __optional
{
static __optional parse(auto& q)
{
return A{};
}
};

int main()
{
int q;
auto p = A::parse(q);
return 0;
}

ICE message follows:
-
$ c++ -fconcepts -std=c++1z tt.c -o tt
tt.c: In static member function ‘static __optional A::parse(auto:1&)’:
tt.c:14:12: internal compiler error: in build_address, at cp/typeck.c:5623
   return A{};
^
0x931657 build_address(tree_node*)
../../gcc/cp/typeck.c:5623
0x6fe147 add_function_candidate
../../gcc/cp/call.c:2166
0x6ffa87 add_candidates
../../gcc/cp/call.c:5522
0x6fab4e add_candidates
../../gcc/cp/call.c:5433
0x6fab4e build_user_type_conversion_1
../../gcc/cp/call.c:3849
0x6fc4f9 implicit_conversion
../../gcc/cp/call.c:1897
0x6f80a0 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc/cp/call.c:10559
0x94a905 check_return_expr(tree_node*, bool*)
../../gcc/cp/typeck.c:9218
0x8ee65e finish_return_stmt(tree_node*)
../../gcc/cp/semantics.c:893
0x843bd5 cp_parser_jump_statement
../../gcc/cp/parser.c:12483
0x843bd5 cp_parser_statement
../../gcc/cp/parser.c:10897
0x844b30 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11348
0x844c07 cp_parser_compound_statement
../../gcc/cp/parser.c:11302
0x85e2b1 cp_parser_function_body
../../gcc/cp/parser.c:21837
0x85e2b1 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:21874
0x860ea6 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:26765
0x8620fc cp_parser_late_parsing_for_member
../../gcc/cp/parser.c:27645
0x851c59 cp_parser_class_specifier_1
../../gcc/cp/parser.c:22728
0x853221 cp_parser_class_specifier
../../gcc/cp/parser.c:22754
0x853221 cp_parser_type_specifier
../../gcc/cp/parser.c:16818
Please submit a full bug report,

[Bug fortran/25829] [F03] Asynchronous IO support

[jb at gcc dot gnu.org]

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

--- Comment #32 from Janne Blomqvist  ---
Interestingly, Linux 4.14 contains a way to avoid a context switch to a
threadpool in case the data is already in the page cache:
https://kernelnewbies.org/Linux_4.14#head-8c8861fbded3e87631ab06bcd511f5f0d8bfa220

Might be an interesting optimization sometime in the future..

[Bug middle-end/83022] malloc & memset -> calloc is not always an optimization

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
I am pretty sure this was discussed when the patch was reviewed. IIRC the
original patch was specifically pattern-matching if(p!=0) (with p the result of
malloc) as the only acceptable condition between malloc and memset for this
transformation, but the move to the strlen pass made that inconvenient and it
was decided that always doing the transformation was ok (I hope I am not
rewriting history). If there is a way to check the probability of reaching the
call to memset from the call to malloc (preferably conditional to the fact that
malloc returned something != 0), that could be checked before generating
calloc, but that may not be easy... (compare the local count of the 2 BBs?
That's 1 and 3300 here, but I see you have already filed PR 83023 to
improve it)

Did you actually hit a measurable slowdown in a real application?

[Bug other/53742] bad assembler output when compiling with LTO and PGO

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #11 from Eric Gallager  ---
(In reply to Martin Liška from comment #10)
> Is the issue still valid?

No response since you asked so I'm guessing not.

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[egallager at gcc dot gnu.org]

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

Bug 48724 Summary: Lto build of mozilla dies at lto-wrapper: error trying to 
exec 'make -j1': execvp: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48724

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

[Bug lto/48724] Lto build of mozilla dies at lto-wrapper: error trying to exec 'make -j1': execvp: No such file or directory

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #9 from Eric Gallager  ---
(In reply to Jan Hubicka from comment #8)
> This no longer happens with recent Firefox builds, but I think it was rather
> fixed at Firefox buildsystem...

That sounds like WORKSFORME then.

[Bug ipa/60243] IPA is slow on large cgraph tree

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #15 from Eric Gallager  ---
(In reply to Jan Hubicka from comment #14)
> Author: hubicka
> Date: Fri Mar 28 19:50:28 2014
> New Revision: 208916
> 
> URL: http://gcc.gnu.org/viewcvs?rev=208916=gcc=rev
> Log:
>   PR ipa/60243
>   * ipa-inline.c (want_inline_small_function_p): Short circuit large
>   functions; reorganize to make cheap checks first.
>   (inline_small_functions): Do not estimate growth when dumping;
>   it is expensive.
>   * ipa-inline.h (inline_summary): Add min_size.
>   (growth_likely_positive): New function.
>   * ipa-inline-analysis.c (dump_inline_summary): Add min_size.
>   (set_cond_stmt_execution_predicate): Cleanup.
>   (estimate_edge_size_and_time): Compute min_size.
>   (estimate_calls_size_and_time): Likewise.
>   (estimate_node_size_and_time): Likewise.
>   (inline_update_overall_summary): Update min_size.
>   (do_estimate_edge_time): Likewise.
>   (do_estimate_edge_size): Update.
>   (do_estimate_edge_hints): Update.
>   (growth_likely_positive): New function.
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/ipa-inline-analysis.c
> trunk/gcc/ipa-inline.c
> trunk/gcc/ipa-inline.h

Did this fix it?

[Bug target/82748] ICE with __builtin_fabsq and __float128 in copy_to_mode_reg, at explow.c:612

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Author: meissner
Date: Thu Nov 16 20:29:52 2017
New Revision: 254846

URL: https://gcc.gnu.org/viewcvs?rev=254846=gcc=rev
Log:
[gcc]
2017-11-16  Michael Meissner  

Back port from trunk
2017-11-16  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_expand_builtin): Do not do the
switch statement mapping KF built-ins to TF built-ins if we don't
have the proper ISA 3.0 assembler support.

Back port from trunk
2017-11-14  Michael Meissner  

* config/rs6000/rs6000-c.c (is_float128_p): New helper function.
(rs6000_builtin_type_compatible): Treat _Float128 and long double
as being compatible if -mabi=ieeelongdouble.
* config/rs6000/rs6000-builtin.def (BU_FLOAT128_HW_1): New macros
to setup float128 built-ins with hardware support.
(BU_FLOAT128_HW_2): Likewise.
(BU_FLOAT128_HW_3): Likewise.
(BU_FLOAT128_HW_VSX_1): Likewise.
(BU_FLOAT128_HW_VSX_2): Likewise.
(scalar_extract_expq): Change float128 built-in functions to
accommodate having both KFmode and TFmode functions.  Use the
KFmode variant as the default.
(scalar_extract_sigq): Likewise.
(scalar_test_neg_qp): Likewise.
(scalar_insert_exp_q): Likewise.
(scalar_insert_exp_qp): Likewise.
(scalar_test_data_class_qp): Likewise.
(sqrtf128_round_to_odd): Delete processing the round to odd
built-in functions as special built-in functions, and define them
as float128 built-ins.  Use the KFmode variant as the default.
(truncf128_round_to_odd): Likewise.
(addf128_round_to_odd): Likewise.
(subf128_round_to_odd): Likewise.
(mulf128_round_to_odd): Likewise.
(divf128_round_to_odd): Likewise.
(fmaf128_round_to_odd): Likewise.
* config/rs6000/rs6000.c (rs6000_expand_binop_builtin): Add
support for KFmode and TFmode xststdcqp calls.
(rs6000_expand_builtin): If long double is IEEE 128-bit floating
point, switch the built-in handlers for the get/set float128
exponent, get float128 mantissa, float128 test built-ins, and the
float128 round to odd built-in functions.  Eliminate creating the
float128 round to odd built-in functions as special built-ins.
(rs6000_init_builtins): Eliminate special creation of the float128
round to odd built-in functions.
* config/rs6000/vsx.md (xsxexpqp_): Change float128 built-in
function insns to support both TFmode and KFmode variants.
(xsxsigqp_): Likewise.
(xsiexpqpf_): Likewise.
(xsiexpqp_): Likewise.
(xststdcqp_): Likewise.
(xststdcnegqp_): Likewise.
(xststdcqp_): Likewise.

Back port from trunk
2017-11-06  Michael Meissner  

PR target/82748
* config/rs6000/rs6000-builtin.def (BU_FLOAT128_1): Delete
float128 helper macros, which are no longer used after deleting
the old 'q' built-in functions, and moving the round to odd
built-in functions to being special built-in functions.
(BU_FLOAT128_2): Likewise.
(BU_FLOAT128_1_HW): Likewise.
(BU_FLOAT128_2_HW): Likewise.
(BU_FLOAT128_3_HW): Likewise.
(FABSQ): Delete old 'q' built-in functions.
(COPYSIGNQ): Likewise.
(SQRTF128_ODD): Move round to odd built-in functions to be
special built-in functions, so that we can handle
-mabi=ieeelongdouble.
(TRUNCF128_ODD): Likewise.
(ADDF128_ODD): Likewise.
(SUBF128_ODD): Likewise.
(MULF128_ODD): Likewise.
(DIVF128_ODD): Likewise.
(FMAF128_ODD): Likewise.
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Map old 'q'
built-in names to 'f128'.
* config/rs6000/rs6000.c (rs6000_fold_builtin): Remove folding the
old 'q' built-in functions, as the machine independent code for
'f128' built-in functions handles this.
(rs6000_expand_builtin): Add expansion for float128 round to odd
functions, keying off on -mabi=ieeelongdouble of whether to use
the KFmode or TFmode variant.
(rs6000_init_builtins): Initialize the _Float128 round to odd
built-in functions.
* doc/extend.texi (PowerPC Built-in Functions): Document the old
_Float128 'q' built-in functions are now mapped into the new
'f128' built-in functions.


[gcc/testsuite]
2017-11-16  Michael Meissner  

Back port from trunk
2017-11-16  Michael Meissner  

* gcc.target/powerpc/bfp/bfp.exp: Look for *.c files, not *.c*
files to prevent ~ files from getting 

[Bug target/79845] rs6000: make code in rs6000.c more i18n-friendly

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Author: meissner
Date: Thu Nov 16 20:29:52 2017
New Revision: 254846

URL: https://gcc.gnu.org/viewcvs?rev=254846=gcc=rev
Log:
[gcc]
2017-11-16  Michael Meissner  

Back port from trunk
2017-11-16  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_expand_builtin): Do not do the
switch statement mapping KF built-ins to TF built-ins if we don't
have the proper ISA 3.0 assembler support.

Back port from trunk
2017-11-14  Michael Meissner  

* config/rs6000/rs6000-c.c (is_float128_p): New helper function.
(rs6000_builtin_type_compatible): Treat _Float128 and long double
as being compatible if -mabi=ieeelongdouble.
* config/rs6000/rs6000-builtin.def (BU_FLOAT128_HW_1): New macros
to setup float128 built-ins with hardware support.
(BU_FLOAT128_HW_2): Likewise.
(BU_FLOAT128_HW_3): Likewise.
(BU_FLOAT128_HW_VSX_1): Likewise.
(BU_FLOAT128_HW_VSX_2): Likewise.
(scalar_extract_expq): Change float128 built-in functions to
accommodate having both KFmode and TFmode functions.  Use the
KFmode variant as the default.
(scalar_extract_sigq): Likewise.
(scalar_test_neg_qp): Likewise.
(scalar_insert_exp_q): Likewise.
(scalar_insert_exp_qp): Likewise.
(scalar_test_data_class_qp): Likewise.
(sqrtf128_round_to_odd): Delete processing the round to odd
built-in functions as special built-in functions, and define them
as float128 built-ins.  Use the KFmode variant as the default.
(truncf128_round_to_odd): Likewise.
(addf128_round_to_odd): Likewise.
(subf128_round_to_odd): Likewise.
(mulf128_round_to_odd): Likewise.
(divf128_round_to_odd): Likewise.
(fmaf128_round_to_odd): Likewise.
* config/rs6000/rs6000.c (rs6000_expand_binop_builtin): Add
support for KFmode and TFmode xststdcqp calls.
(rs6000_expand_builtin): If long double is IEEE 128-bit floating
point, switch the built-in handlers for the get/set float128
exponent, get float128 mantissa, float128 test built-ins, and the
float128 round to odd built-in functions.  Eliminate creating the
float128 round to odd built-in functions as special built-ins.
(rs6000_init_builtins): Eliminate special creation of the float128
round to odd built-in functions.
* config/rs6000/vsx.md (xsxexpqp_): Change float128 built-in
function insns to support both TFmode and KFmode variants.
(xsxsigqp_): Likewise.
(xsiexpqpf_): Likewise.
(xsiexpqp_): Likewise.
(xststdcqp_): Likewise.
(xststdcnegqp_): Likewise.
(xststdcqp_): Likewise.

Back port from trunk
2017-11-06  Michael Meissner  

PR target/82748
* config/rs6000/rs6000-builtin.def (BU_FLOAT128_1): Delete
float128 helper macros, which are no longer used after deleting
the old 'q' built-in functions, and moving the round to odd
built-in functions to being special built-in functions.
(BU_FLOAT128_2): Likewise.
(BU_FLOAT128_1_HW): Likewise.
(BU_FLOAT128_2_HW): Likewise.
(BU_FLOAT128_3_HW): Likewise.
(FABSQ): Delete old 'q' built-in functions.
(COPYSIGNQ): Likewise.
(SQRTF128_ODD): Move round to odd built-in functions to be
special built-in functions, so that we can handle
-mabi=ieeelongdouble.
(TRUNCF128_ODD): Likewise.
(ADDF128_ODD): Likewise.
(SUBF128_ODD): Likewise.
(MULF128_ODD): Likewise.
(DIVF128_ODD): Likewise.
(FMAF128_ODD): Likewise.
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Map old 'q'
built-in names to 'f128'.
* config/rs6000/rs6000.c (rs6000_fold_builtin): Remove folding the
old 'q' built-in functions, as the machine independent code for
'f128' built-in functions handles this.
(rs6000_expand_builtin): Add expansion for float128 round to odd
functions, keying off on -mabi=ieeelongdouble of whether to use
the KFmode or TFmode variant.
(rs6000_init_builtins): Initialize the _Float128 round to odd
built-in functions.
* doc/extend.texi (PowerPC Built-in Functions): Document the old
_Float128 'q' built-in functions are now mapped into the new
'f128' built-in functions.


[gcc/testsuite]
2017-11-16  Michael Meissner  

Back port from trunk
2017-11-16  Michael Meissner  

* gcc.target/powerpc/bfp/bfp.exp: Look for *.c files, not *.c*
files to prevent ~ files from getting 

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
Author: tkoenig
Date: Thu Nov 16 20:24:00 2017
New Revision: 254845

URL: https://gcc.gnu.org/viewcvs?rev=254845=gcc=rev
Log:
2017-11-16  Thomas Koenig  

PR bootstrap/82856
* doc/install.texi: Document incompatibility of Perl >=5.6.26
with the required version of automake 1.11.6.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/install.texi

[Bug tree-optimization/82946] member pointer defeats strlen optimization involving a string literal

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
(In reply to rguent...@suse.de from comment #5)
> This means you can very well replace memcpy with strcpy if you know
> there's a '\0' in and only in the right place.

Sure, except when dealing with a string literal we know that the source is a
string literal and not a pointer representation disguised as a sequence of
bytes.  The optimization I'm referring to is specifically for string literals:

  unsigned g (struct A *a)
  {
strcpy (a->d, "123");   // here we have a literal, not the representation
of a pointer 
return strlen (a->d);   // a->d must be a valid pointer
  }

> We certainly have to treat literal pointers encoded in any form
> conservatively.  I don't see how they are against any standard.  There's
> other clearly "valid" optimizations missing in GCC that look more
> important to implement.

The C and C++ standards are clear as to what are valid pointer values and how
they can come about.  Copying the representation from an arbitrary constant of
an incompatible type into a pointer object is certainly not one of them.  I.e.,
this:

  const char a[] = "123";
  char *p;
  memcpy (, a, sizeof p);
  strlen (p);

is undefined, but this is of course valid:

  const char a[4] = "123";
  char *p;
  char *q = a;
  memcpy (, , sizeof p);
  strlen (p);

because it just copies the representation of what's known to be a valid pointer
value into another pointer object of a compatible type.

The point is that the bytes of no string literal can also be a valid pointer
value, even if it happens to have the same representation as one, and this can
be exploited to allow the optimization above.  It will not invalidate any
correct programs.  It would be not only invalid but downright silly for a
program to represent valid addresses as string literals.  Embedded programs of
course do hardcode pointer values, but not in string literals: they hardcode
them as integers, e.g.,

  void *my_register = (void*)0x123;

but never like so:

  char my_register[] = "123";

[Bug c++/79092] template: type ignored if value already instantiated

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Thu Nov 16 20:13:48 2017
New Revision: 254843

URL: https://gcc.gnu.org/viewcvs?rev=254843=gcc=rev
Log:
PR c++/79092 - non-type args of different types are different

* tree.c (cp_tree_equal): Check the type of constants.
* pt.c (unify) [TEMPLATE_PARM_INDEX]: Handle UNIFY_ALLOW_INTEGER
when comparing to previously deduced argument.
(maybe_convert_nontype_argument): New.
(convert_nontype_argument): Call it.
(tsubst_copy_and_build): Handle partial instantiation of
IMPLICIT_CONV_EXPR.
(unify): Ignore type when deducing from array bound.
(dependent_type_p_r): Handle DEFERRED_NOEXCEPT.
(value_dependent_expression_p): Any type-dependent expression is
value-dependent.  Handle IMPLICIT_CONV_EXPR.
* cp-tree.h (IMPLICIT_CONV_EXPR_NONTYPE_ARG): New.
* mangle.c (write_template_arg): Strip IMPLICIT_CONV_EXPR.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/nontype-auto12.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/mangle.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/tree.c

[Bug driver/83016] gnat1: warning: command line option ‘-nostdinc++’ is valid for C++/ObjC++ but not for Ada

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

   Severity|normal  |minor

[Bug target/62011] False Data Dependency in popcnt instruction

[andrew.n.senkevich at gmail dot com]

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

Andrew Senkevich  changed:

   What|Removed |Added

 CC||andrew.n.senkevich at gmail 
dot co
   ||m

--- Comment #17 from Andrew Senkevich  ---
(In reply to Travis Downs from comment #16)
> Also, this is fixed for Skylake for tzcnt and lzcnt but not popcnt.

How to confirm it? As I see it is fixed for popcnt. Could you show some
reproducer?

[Bug middle-end/83023] New: branch probabilities pessimize malloc

[nathan at gcc dot gnu.org]

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

Bug ID: 83023
   Summary: branch probabilities pessimize malloc
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42625
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42625=edit
exemplar

on x86_64 compiled with -O2 -fdump-tree-all, the ma.cc.046t.profile_estimate
contains:
  r_5 = malloc (s_3(D));
  if (r_5 != 0B)
goto ; [53.47%]
  else
goto ; [46.53%]

That's a pretty inaccurate guess at the behaviour of malloc!

[Bug fortran/83021] [7 Regression] gfortran segfault

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-11-16
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Could you please provide the file(s) needed to generate local_field_module.mod?

Revision r254377 for the 7 branch is OK.

[Bug fortran/83017] DO CONCURRENT not parallelizing

[dominiq at lps dot ens.fr]

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

--- Comment #12 from Dominique d'Humieres  ---
> Please use -fopt-info-loop to verify the loop is parallelized. You have
> to use -floop-parallelize-all as well due to the cost model issue. 

If I use the commented loop I get with/without the patch

% gfc -Ofast -ftree-parallelize-loops=4 -fopt-info-loop pr83017_db.f90
pr83017_db.f90:28:0: note: loop with 5 iterations completely unrolled (header
execution count 379)
pr83017_db.f90:26:0: note: loop with 5 iterations completely unrolled (header
execution count 1515)
pr83017_db.f90:38:0: note: loop with 5 iterations completely unrolled (header
execution count 1515)
pr83017_db.f90:18:0: note: loop with 4 iterations completely unrolled (header
execution count 379)
pr83017_db.f90:15:0: note: loop with 5 iterations completely unrolled (header
execution count 379)
pr83017_db.f90:47:0: note: parallelizing inner loop 6
pr83017_db.f90:24:0: note: basic block vectorized
pr83017_db.f90:47:0: note: basic block vectorized
% time ./a.out
 PI   2.98875999
 PI   3.14159274
4.027u 0.015s 0:01.02 395.0%0+0k 0+0io 7pf+0w

i.e., a loop is parallelized, and with -floop-parallelize-all

% gfc -Ofast -ftree-parallelize-loops=4 -floop-parallelize-all -fopt-info-loop
pr83017_db.f90
pr83017_db.f90:28:0: note: loop with 5 iterations completely unrolled (header
execution count 379)
pr83017_db.f90:26:0: note: loop with 5 iterations completely unrolled (header
execution count 1515)
pr83017_db.f90:38:0: note: loop with 5 iterations completely unrolled (header
execution count 1515)
pr83017_db.f90:18:0: note: loop with 4 iterations completely unrolled (header
execution count 379)
pr83017_db.f90:15:0: note: loop with 5 iterations completely unrolled (header
execution count 379)
pr83017_db.f90:26:0: note: parallelizing outer loop 3
pr83017_db.f90:24:0: note: basic block vectorized
% time ./a.out 
 PI   2.98876095
 PI   3.14159274
4.152u 0.011s 0:04.16 100.0%0+0k 0+0io 0pf+0w

i.e., the report says the loop is parallelized, but this is not reflected at
run time (for the original test as well).

[Bug c++/82781] [6/7/8 Regression] Vector extension operators return wrong result in constexpr

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug middle-end/83022] New: malloc & memset -> calloc is not always an optimization

[nathan at gcc dot gnu.org]

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

Bug ID: 83022
   Summary: malloc & memset -> calloc is not always an
optimization
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42623
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42623=edit
exemplar

We like to optimize malloc followed by memset into a calloc call.  Even when
the memset is conditional.  That's well formed, but pessimizes, and noticeable
when the size is large and we do unnecessary clearing.

The attached example, compiled on x86_64 with -O results in:
_Z1mmb:
movl$1, %esi
jmp calloc

But, it causes a noticeable performance regression, as 'c' is false
sufficiently often and 's' is large sufficiently often.

[Bug web/78315] "Changes" don't explain what "LRA" is

[egallager at gcc dot gnu.org]

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

--- Comment #2 from Eric Gallager  ---
The "Changes" page for gcc-7 at least says now that LRA is "(a new local
register allocator)"; is that enough?

[Bug fortran/83021] New: [7 Regression] gfortran segfault

[doko at gcc dot gnu.org]

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

Bug ID: 83021
   Summary: [7 Regression] gfortran segfault
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42622
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42622=edit
test case

[forwarded from https://bugs.debian.org/881918]

seen building open-coarrays with the gcc-7-branch 20171115, not seen on the
branch 20171001

$ gfortran global_field.f90 -fcoarray=lib
global_field.f90:126:0:

 lhs%values(:) = rhs%state()

internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.

Program received signal SIGSEGV, Segmentation fault.
0x0067a16f in gfc_walk_array_ref(gfc_ss*, gfc_expr*, gfc_ref*) ()
(gdb) bt
#0  0x0067a16f in gfc_walk_array_ref(gfc_ss*, gfc_expr*, gfc_ref*) ()
#1  0x0067cf7a in gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) ()
#2  0x006a6572 in ?? ()
#3  0x006b9814 in gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ()
#4  0x006a0895 in ?? ()
#5  0x00696a3b in gfc_apply_interface_mapping(gfc_interface_mapping*,
gfc_se*, gfc_expr*) ()
#6  0x0066ee45 in
gfc_set_loop_bounds_from_array_spec(gfc_interface_mapping*, gfc_se*,
gfc_array_spec*) ()
#7  0x0069f37e in gfc_conv_procedure_call(gfc_se*, gfc_symbol*,
gfc_actual_arglist*, gfc_expr*, vec*) ()
#8  0x006a087d in ?? ()
#9  0x0067c239 in ?? ()
#10 0x0067cdf6 in gfc_conv_loop_setup(gfc_loopinfo*, locus*) ()
#11 0x006a32e0 in ?? ()
#12 0x00668b10 in ?? ()
#13 0x0068de98 in gfc_generate_function_code(gfc_namespace*) ()
#14 0x0066c86a in gfc_generate_module_code(gfc_namespace*) ()
#15 0x0062229c in gfc_parse_file() ()
#16 0x00665630 in ?? ()
#17 0x00a7ac6f in ?? ()
#18 0x0059923a in toplev::main(int, char**) ()
#19 0x0059b5eb in main ()

[Bug c++/82781] [6/7/8 Regression] Vector extension operators return wrong result in constexpr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
I'll have a look.

[Bug debug/83010] [AARCH64] DW_AT_location is not emitted for thread local variable

[qiyao at gcc dot gnu.org]

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

--- Comment #3 from Yao Qi  ---
(In reply to Jakub Jelinek from comment #2)
> From quick look, it seems gas/ld just doesn't have corresponding support, so
> that would need to be written first.  There is R_AARCH64_TLS_DTPREL64
> relocation, wonder if that might do the job if gas has some way to emit that
> relocation.

Yes, beside gcc, something is needed in ld too.  Clang emits DW_AT_location for
TLS variable, but ld failed to link,

$ ./clang+llvm-5.0.0-aarch64-linux-gnu/bin/clang   -g 4.c -o 4.exe
/usr/bin/ld: /tmp/4-767da1.o(.debug_info+0x37): R_AARCH64_ABS64 used with TLS
symbol a_thread_local

but gold is ok,

$ ./clang+llvm-5.0.0-aarch64-linux-gnu/bin/clang -fuse-ld=gold  -g 4.c -o 4.exe

 <1><2a>: Abbrev Number: 2 (DW_TAG_variable)
<2b>   DW_AT_name: (indirect string, offset: 0x3e): a_thread_local
<2f>   DW_AT_type: <0x40>
<33>   DW_AT_external: 1
<33>   DW_AT_decl_file   : 1
<34>   DW_AT_decl_line   : 2
<35>   DW_AT_location: 10 byte block: e 0 0 0 0 0 0 0 0 e0 
(DW_OP_const8u: 0 0; DW_OP_GNU_push_tls_address or DW_OP_HP_unknown)

[Bug c++/82799] [8 Regression] -Wunused-but-set-variable false positive

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Started with r253266.

[Bug fortran/82904] [7/8 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:261

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug tree-optimization/82977] [8 Regression] AddressSanitizer: heap-use-after-free in strlen_optimize_stmt .././../gcc/tree-ssa-strlen.c:2971

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
The regression is fixed, the other issues still need work.

[Bug fortran/83012] [8 Regression] Simply contiguous pointer function not recognized as contiguous

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 63441 Summary: incorrect "array subscript is below/above array bounds" 
diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63441

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

[Bug middle-end/63441] incorrect "array subscript is below/above array bounds" diagnostic

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||5.4.0, 6.4.0, 7.1.0, 8.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=63477
 Resolution|--- |WORKSFORME

--- Comment #3 from Martin Sebor  ---
Just like with pr63477, I cannot reproduce the warning with this test case in
GCC 8.0 anymore (despite what I said in comment #2), or 7-branch, or 6-branch,
or even 5-branch.  Just like in pr63477, bisection also points to r220157 (gcc
5.0.0) as the fix.  So I'll assume that what I saw in comment #2 was some
transient fluke and resolve this as worksforsome (based on comment #1 and #2
saying it would make sense to diagnose this).

[Bug debug/83010] [AARCH64] DW_AT_location is not emitted for thread local variable

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
>From quick look, it seems gas/ld just doesn't have corresponding support, so
that would need to be written first.  There is R_AARCH64_TLS_DTPREL64
relocation, wonder if that might do the job if gas has some way to emit that
relocation.

[Bug fortran/83017] DO CONCURRENT not parallelizing

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On November 16, 2017 5:42:02 PM GMT+01:00, "dominiq at lps dot ens.fr"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017
>
>--- Comment #10 from Dominique d'Humieres 
>---
>> Created attachment 42621 [details]
>> updated patch
>
>AFAICT the patch does not fix the problem:
>
>without the patch
>
> PI   2.98876095
> PI   3.14159274
>4.742u 0.015s 0:04.77 99.5% 0+0k 0+0io 36pf+0w
>
>with the patch
>
> PI   2.98876095
> PI   3.14159274
>4.782u 0.012s 0:04.80 99.7% 0+0k 0+0io 0pf+0w

Please use - fopt-info-loop to verify the loop is parallelized. You have to use
- floop-parallelize-all as well due to the cost model issue. 

It might be we employ the same cost model at runtime.

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 63477 Summary: [6/7/8 Regression] Bogus warning with -O3 -Warray-bounds: 
array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63477

   What|Removed |Added

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

[Bug middle-end/63477] [6/7/8 Regression] Bogus warning with -O3 -Warray-bounds: array subscript is above array bounds

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Thu Nov 16 16:48:36 2017
New Revision: 254833

URL: https://gcc.gnu.org/viewcvs?rev=254833=gcc=rev
Log:
PR middle-end/63477 - Bogus warning with -O3 -Warray-bounds: array subscript
is above array bounds

gcc/testsuite/ChangeLog:

PR middle-end/63477
* gcc.dg/pr63477.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr63477.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/63477] [6/7/8 Regression] Bogus warning with -O3 -Warray-bounds: array subscript is above array bounds

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||8.0
 Resolution|--- |FIXED
  Known to fail|8.0 |

--- Comment #3 from Martin Sebor  ---
Strangely, I cannot reproduce this warning anymore with GCC 8.  Bisection
points to r220157 (gcc 5.0.0) as the revision that fixed it.  I've added the
test case to the test suite in r254833 and with that I'm resolving this bug as
fixed.  Please reopen it if the problem reappears.

[Bug fortran/83017] DO CONCURRENT not parallelizing

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
> Created attachment 42621 [details]
> updated patch

AFAICT the patch does not fix the problem:

without the patch

 PI   2.98876095
 PI   3.14159274
4.742u 0.015s 0:04.77 99.5% 0+0k 0+0io 36pf+0w

with the patch

 PI   2.98876095
 PI   3.14159274
4.782u 0.012s 0:04.80 99.7% 0+0k 0+0io 0pf+0w

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 59124 Summary: [6 Regression] Wrong warnings "array subscript is above 
array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124

   What|Removed |Added

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

[Bug tree-optimization/59124] [6 Regression] Wrong warnings "array subscript is above array bounds"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED
  Known to fail||8.0

--- Comment #47 from Martin Sebor  ---
None of the test cases here except for the one in comment #41 triggers
-Warray-bounds with GCC 8.0.  According to comments #42 and #43 the warning for
the test case in comment #41 is a true positive.  I'll go ahead and resolve
this as fixed.

I suggest to open a separate bug for any new/outstanding issues in this area to
make it easier to track each separately.

[Bug debug/83010] [AARCH64] DW_AT_location is not emitted for thread local variable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jgreenhalgh at gcc dot gnu.org,
   ||ktkachov at gcc dot gnu.org,
   ||rearnsha at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
That is because the aarch64 backend doesn't define
TARGET_ASM_OUTPUT_DWARF_DTPREL hook.
Either the assembler lacks the corresponding support, or just the backend
doesn't define it even if it could.

[Bug tree-optimization/82588] missing -Warray-bounds on a excessively large index

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to work||8.0
   Target Milestone|--- |8.0
  Known to fail||5.4.0, 6.4.0, 7.2.0

[Bug c/68325] missing -Warray-bounds on a negative subscript into a flexible array member

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||8.0
 Resolution|--- |FIXED
   Target Milestone|--- |8.0
  Known to fail||5.4.0, 6.4.0, 7.2.0

--- Comment #2 from Martin Sebor  ---
Fixed in r254830.  GCC now issues the warnings below for the test case in
comment #0:

z.c: In function ‘foo’:
z.c:7:16: warning: array subscript -2147483647 is below array bounds of
‘int[99]’ [-Warray-bounds]
 return s.a [-__INT_MAX__];
^~
z.c: In function ‘bar’:
z.c:12:17: warning: array subscript -2147483647 is below array bounds of
‘int[99]’ [-Warray-bounds]
 return p->a [-__INT_MAX__];
~^~

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 82588 Summary: missing -Warray-bounds on a excessively large index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82588

   What|Removed |Added

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

[Bug tree-optimization/82588] missing -Warray-bounds on a excessively large index

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82455
 Resolution|--- |FIXED

--- Comment #5 from Martin Sebor  ---
The -Warrray-bounds part of the issue has been fixed in r254830.  GCC now
issues the warnings below for the test case in comment #0:

a.c: In function ‘f1’:
a.c:17:11: warning: array subscript 4611686018427387904 is above array bounds
of ‘int[]’ [-Warray-bounds]
   return a[__SIZE_MAX__ / sizeof (int) + 1];   // missing -Warray-bounds
  ~^
a.c: In function ‘f2’:
a.c:22:14: warning: array subscript 9223372036854775807 is above array bounds
of ‘char[]’ [-Warray-bounds]
   return a->a[__SIZE_MAX__ / 2];   // missing -Warray-bounds
  ^~

The out-of-bounds offset is still not diagnosed.  It's the subject of a
separate bug (pr82455).

[Bug tree-optimization/82583] missing -Warray-bounds on out-of-bounds inner indices

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed in r254830.  GCC now issues the warnings below for the test case in
comment #0:

a.c: In function ‘f’:
a.c:6:12: warning: array subscript 4 is above array bounds of ‘int[4]’
[-Warray-bounds]
   p->a[1].a[4] = 1;
   ~^~~
a.c: In function ‘g’:
a.c:11:7: warning: array subscript 2 is above array bounds of ‘struct A[2]’
[-Warray-bounds]
   p->a[2].a[3] = 1;
   ^~~

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 82583 Summary: missing -Warray-bounds on out-of-bounds inner indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82583

   What|Removed |Added

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

[Bug tree-optimization/82588] missing -Warray-bounds on a excessively large index

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Thu Nov 16 16:12:36 2017
New Revision: 254830

URL: https://gcc.gnu.org/viewcvs?rev=254830=gcc=rev
Log:
PR tree-optimization/82588 - missing -Warray-bounds on a excessively large
index
PR tree-optimization/82583 - missing -Warray-bounds on out-of-bounds inner
indic

gcc/ChangeLog:

PR tree-optimization/82588
PR tree-optimization/82583
* tree-vrp.c (check_array_ref): Handle flexible array members,
string literals, and inner indices.
(search_for_addr_array): Add detail to diagnostics.

gcc/testsuite/ChangeLog:

PR tree-optimization/82588
PR tree-optimization/82583
* c-c++-common/Warray-bounds.c: New test.
* gcc.dg/Warray-bounds-11.c: Adjust.
* gcc.dg/Warray-bounds-22.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/Warray-bounds.c
trunk/gcc/testsuite/gcc.dg/Warray-bounds-22.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Warray-bounds-11.c
trunk/gcc/tree-vrp.c

[Bug tree-optimization/82583] missing -Warray-bounds on out-of-bounds inner indices

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu Nov 16 16:12:36 2017
New Revision: 254830

URL: https://gcc.gnu.org/viewcvs?rev=254830=gcc=rev
Log:
PR tree-optimization/82588 - missing -Warray-bounds on a excessively large
index
PR tree-optimization/82583 - missing -Warray-bounds on out-of-bounds inner
indic

gcc/ChangeLog:

PR tree-optimization/82588
PR tree-optimization/82583
* tree-vrp.c (check_array_ref): Handle flexible array members,
string literals, and inner indices.
(search_for_addr_array): Add detail to diagnostics.

gcc/testsuite/ChangeLog:

PR tree-optimization/82588
PR tree-optimization/82583
* c-c++-common/Warray-bounds.c: New test.
* gcc.dg/Warray-bounds-11.c: Adjust.
* gcc.dg/Warray-bounds-22.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/Warray-bounds.c
trunk/gcc/testsuite/gcc.dg/Warray-bounds-22.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Warray-bounds-11.c
trunk/gcc/tree-vrp.c

[Bug fortran/69455] [6/7/8 Regression] [F08] Assembler error(s) when using intrinsic modules in two BLOCK

[drikosev at gmail dot com]

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

Ev Drikos  changed:

   What|Removed |Added

 CC||drikosev at gmail dot com

--- Comment #12 from Ev Drikos  ---
Is there any chance to see this patch?

Thanks,
Ev. Drikos

[Bug c++/83020] New: ('17) Class template constructor call skipped with no error when substitution fails in default argument

[oremanj at mit dot edu]

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

Bug ID: 83020
   Summary: ('17) Class template constructor call skipped with no
error when substitution fails in default argument
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oremanj at mit dot edu
  Target Milestone: ---

The below C++ program is ill-formed, but gcc 7.1 and 7.2 accept it in C++17
mode, and emit code that simply doesn't call the constructor of Whoops at all.
This is reproducible if the constructor is defined out-of-line as well; there's
no reference to Whoops in the generated assembly. In C++14 mode or with gcc
6.3, the error is correctly diagnosed.


$ cat t.cc
struct NoDefault {
int val = 1234;
NoDefault(int v) : val(v) {}
};
template 
struct Whoops {
const char *str;
T obj;
Whoops(const char *s, T v = T()) : str(s), obj(v) {}
};
const char *test() {
return Whoops("hi").str;
}


$ g++-7 -O3 -std=c++17 -Wall -c t.cc && objdump -d t.o

t.o: file format elf64-x86-64

Disassembly of section .text:

 <_Z4testv>:
   0:   31 c0   xor%eax,%eax
   2:   c3  retq   


$ g++-7 -O0 -std=c++17 -Wall -c t.cc && objdump -d t.o

t.o: file format elf64-x86-64

Disassembly of section .text:

 <_Z4testv>:
   0:   55  push   %rbp
   1:   48 89 e5mov%rsp,%rbp
   4:   5d  pop%rbp
   5:   c3  retq   


$ g++-7 -v
Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
7.2.0-12+hrtdeb8u1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=gcc4-compatible --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --disable-initfini-array
Thread model: posix
gcc version 7.2.1 20171025 (Debian 7.2.0-12)

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #18 from Eric Botcazou  ---
> all-gnattools: configure-gnattools
> @: $(MAKE); $(unstage)
> @r=`${PWD_COMMAND}`; export r; \
> s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
> $(HOST_EXPORTS)  \
> (cd $(HOST_SUBDIR)/gnattools && \
>   $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS)
> $(STAGE1_FLAGS_TO_PASS)  \
> $(TARGET-gnattools))
> 
> so it builds for the host.  But when bootstrapping we want to build it
> similar to if it were a target library, that is, with the just built GCC.

Yes, that's what happens, i.e. the CXX passed to gnattools is CXX_FOR_TARGET.

> So,
> 
> host_modules= { module= gnattools; };
> 
> is technically not correct.  Not sure how it works during bootstrap, I'd have
> expected that the host compiler is used as well (gnattools is not 
> bootstrapped).

This would simply break, because the gnattools really need to be bootstrapped
as they generally cannot be built by the host compiler.  Quite puzzling indeed.

[Bug rtl-optimization/80818] LRA clobbers live hard reg clobbered during rematerialization

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #8 from Andreas Krebbel  ---
Hi Vladimir. What do you think about the additional patch?

[Bug c++/83018] To support creation of header-only C++ libraries with SIMD optimization and dynamic dispatch, allow all x86 intrinsics regardless of target instruction set

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-* i?86-*-*
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Richard Biener  ---
You need to guard affected code portions with #pragma GCC target ("avx2") for
example.

[Bug middle-end/83019] [8 Regression] Compiler dumps predictions with -nan%

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
Summary|Compiler dumps predictions  |[8 Regression] Compiler
   |with -nan%  |dumps predictions with
   ||-nan%

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener  ---
(In reply to Eric Botcazou from comment #16)
> This also breaks 'make all-gnattools' in a bootstrap build:
> 
> g++ -std=gnu++98 -static-libstdc++ -static-libgcc -I- -I../rts -I.
> -I/home/eric/svn/gcc/gcc/ada -static-libstdc++ -static-libgcc  -DIN_GCC  -g
> -O2 -W -Wall -o ../../gnatmake b_gnatm.o a-except.o ali.o ali-util.o
> aspects.o s-casuti.o alloc.o atree.o binderr.o butil.o casing.o csets.o
> debug.o elists.o einfo.o errout.o erroutc.o errutil.o err_vars.o fmap.o
> fname.o fname-uf.o fname-sf.o gnatmake.o gnatvsn.o hostparm.o interfac.o
> i-c.o i-cstrin.o krunch.o lib.o make.o makeusg.o make_util.o namet.o
> nlists.o opt.o osint.o osint-m.o output.o restrict.o rident.o s-exctab.o
> s-secsta.o s-stalib.o s-stoele.o scans.o scng.o sdefault.o sfn_scan.o
> s-purexc.o s-htable.o scil_ll.o sem_aux.o sinfo.o sinput.o sinput-c.o
> snames.o stand.o stringt.o styleg.o stylesw.o system.o validsw.o switch.o
> switch-m.o table.o targparm.o tempdir.o tree_io.o types.o uintp.o uname.o
> urealp.o usage.o widechar.o  ../link.o ../targext.o ../../ggc-none.o
> ../../libcommon-target.a ../../libcommon.a ../../../libcpp/libcpp.a
> ../rts/libgnat.a   ../../../libbacktrace/.libs/libbacktrace.a
> ../../../libiberty/libiberty.a   -no-pie -ldl
> g++: error: unrecognized command line option ‘-no-pie’
> ../gcc-interface/Makefile:2221: recipe for target '../../gnatmake' failed
> make[2]: *** [../../gnatmake] Error 1
> make[2]: Leaving directory '/home/eric/build/gcc/native/gcc/ada/tools'
> Makefile:188: recipe for target 'gnattools-native' failed
> make[1]: *** [gnattools-native] Error 2
> make[1]: Leaving directory '/home/eric/build/gcc/native/gnattools'
> Makefile:13917: recipe for target 'all-gnattools' failed
> make: *** [all-gnattools] Error 2
> 
> During the bootstrap, CXX is set to /home/eric/build/gcc/native/./gcc/xg++
> -B/home/eric/build/gcc/native/./gcc/ so this still works.

Hmm, all-gnattools does

all-gnattools: configure-gnattools
@: $(MAKE); $(unstage)
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
$(HOST_EXPORTS)  \
(cd $(HOST_SUBDIR)/gnattools && \
  $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS)
$(STAGE1_FLAGS_TO_PASS)  \
$(TARGET-gnattools))

so it builds for the host.  But when bootstrapping we want to build it
similar to if it were a target library, that is, with the just built GCC.
So,

host_modules= { module= gnattools; };

is technically not correct.  Not sure how it works during bootstrap, I'd have
expected that the host compiler is used as well (gnattools is not
bootstrapped).

[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #24 from Nathan Sidwell  ---
Fixed r254823.

[Bug c++/82836] [8 Regression] ICE on valid code

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
Fixed r254823.

[Bug c++/82836] [8 Regression] ICE on valid code

[nathan at gcc dot gnu.org]

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

--- Comment #1 from Nathan Sidwell  ---
Author: nathan
Date: Thu Nov 16 14:54:54 2017
New Revision: 254823

URL: https://gcc.gnu.org/viewcvs?rev=254823=gcc=rev
Log:
[PATCH] New lang hook

https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01340.html
PR c++/82836
PR c++/82737
* tree.h (COPY_DECL_RTL): Rename parms for clarity.
(SET_DECL_ASSEMBLER_NAME): Forward to
overwrite_decl_assembler_name.
(COPY_DECL_ASSEMBLER_NAME): Rename parms for clarity.
(overwrite_decl_assembler_name): Declare.
* tree.c (overwrite_decl_assembler_name): New.
* langhooks-def.h (lhd_overwrite_decl_assembler_name): Declare.
(LANG_HOOKS_OVERWRITE_DECL_ASSEMBLER_NAME): Provide default.
(LANG_HOOKS_INITIALIZER): Add it.
* langhooks.h (struct lang_hooks): Add overwrite_decl_assembler_name.
* langhooks.c (lhd_set_decl_assembler_name): Use
SET_DECL_ASSEMBLER_NAME.
(lhd_overwrite_decl_assembler_name): Default implementation.

PR c++/82836
PR c++/82737
* cp-objcp-common.h (LANG_HOOKS_OVERWRITE_DECL_ASSEMBLER_NAME):
Override.
* cp-tree.h (overwrite_mangling): Declare.
* decl2.c (struct mangled_decl_hash): Entries are deletable.
(overwrite_mangling): New.

PR c++/82836
PR c++/82737
* g++.dg/pr82836.C: New.


Added:
trunk/gcc/testsuite/g++.dg/pr82836.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-objcp-common.h
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl2.c
trunk/gcc/langhooks-def.h
trunk/gcc/langhooks.c
trunk/gcc/langhooks.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)

[nathan at gcc dot gnu.org]

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

--- Comment #23 from Nathan Sidwell  ---
Author: nathan
Date: Thu Nov 16 14:54:54 2017
New Revision: 254823

URL: https://gcc.gnu.org/viewcvs?rev=254823=gcc=rev
Log:
[PATCH] New lang hook

https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01340.html
PR c++/82836
PR c++/82737
* tree.h (COPY_DECL_RTL): Rename parms for clarity.
(SET_DECL_ASSEMBLER_NAME): Forward to
overwrite_decl_assembler_name.
(COPY_DECL_ASSEMBLER_NAME): Rename parms for clarity.
(overwrite_decl_assembler_name): Declare.
* tree.c (overwrite_decl_assembler_name): New.
* langhooks-def.h (lhd_overwrite_decl_assembler_name): Declare.
(LANG_HOOKS_OVERWRITE_DECL_ASSEMBLER_NAME): Provide default.
(LANG_HOOKS_INITIALIZER): Add it.
* langhooks.h (struct lang_hooks): Add overwrite_decl_assembler_name.
* langhooks.c (lhd_set_decl_assembler_name): Use
SET_DECL_ASSEMBLER_NAME.
(lhd_overwrite_decl_assembler_name): Default implementation.

PR c++/82836
PR c++/82737
* cp-objcp-common.h (LANG_HOOKS_OVERWRITE_DECL_ASSEMBLER_NAME):
Override.
* cp-tree.h (overwrite_mangling): Declare.
* decl2.c (struct mangled_decl_hash): Entries are deletable.
(overwrite_mangling): New.

PR c++/82836
PR c++/82737
* g++.dg/pr82836.C: New.


Added:
trunk/gcc/testsuite/g++.dg/pr82836.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-objcp-common.h
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl2.c
trunk/gcc/langhooks-def.h
trunk/gcc/langhooks.c
trunk/gcc/langhooks.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug driver/83016] gnat1: warning: command line option ‘-nostdinc++’ is valid for C++/ObjC++ but not for Ada

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-16
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Botcazou  ---
Known old problem, gnatlink is invoked with:

/home/eric/build/gcc/native/gcc/ada/tools/gnatclean.ali
../../gnatlink -v gnatcmd -o ../../gnat \
--GCC="/home/eric/build/gcc/native/./gcc/xg++
-B/home/eric/build/gcc/native/./gcc/ -nostdinc++ -nostdinc++
-I/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/include/x86_64-suse-linux
-I/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/include
-I/home/eric/svn/gcc/libstdc++-v3/libsupc++
-I/home/eric/svn/gcc/libstdc++-v3/include/backward
-I/home/eric/svn/gcc/libstdc++-v3/testsuite/util
-L/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/src
-L/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/src/.libs
-L/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/libsupc++/.libs
-B/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/src/.libs
-B/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/libsupc++/.libs
-B/home/eric/install/gcc/x86_64-suse-linux/bin/
-B/home/eric/install/gcc/x86_64-suse-linux/lib/ -isystem
/home/eric/install/gcc/x86_64-suse-linux/include -isystem
/home/eric/install/gcc/x86_64-suse-linux/sys-include-static-libstdc++
-static-libgcc -I- -I../rts -I. -I/home/eric/svn/gcc/gcc/ada -static-libstdc++
-static-libgcc " ../link.o ../targext.o ../../ggc-none.o
../../libcommon-target.a ../../libcommon.a ../../../libcpp/libcpp.a
../rts/libgnat.a   ../../../libbacktrace/.libs/libbacktrace.a
../../../libiberty/libiberty.a   -no-pie

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #16 from Eric Botcazou  ---
This also breaks 'make all-gnattools' in a bootstrap build:

g++ -std=gnu++98 -static-libstdc++ -static-libgcc -I- -I../rts -I.
-I/home/eric/svn/gcc/gcc/ada -static-libstdc++ -static-libgcc  -DIN_GCC  -g -O2
-W -Wall -o ../../gnatmake b_gnatm.o a-except.o ali.o ali-util.o aspects.o
s-casuti.o alloc.o atree.o binderr.o butil.o casing.o csets.o debug.o elists.o
einfo.o errout.o erroutc.o errutil.o err_vars.o fmap.o fname.o fname-uf.o
fname-sf.o gnatmake.o gnatvsn.o hostparm.o interfac.o i-c.o i-cstrin.o krunch.o
lib.o make.o makeusg.o make_util.o namet.o nlists.o opt.o osint.o osint-m.o
output.o restrict.o rident.o s-exctab.o s-secsta.o s-stalib.o s-stoele.o
scans.o scng.o sdefault.o sfn_scan.o s-purexc.o s-htable.o scil_ll.o sem_aux.o
sinfo.o sinput.o sinput-c.o snames.o stand.o stringt.o styleg.o stylesw.o
system.o validsw.o switch.o switch-m.o table.o targparm.o tempdir.o tree_io.o
types.o uintp.o uname.o urealp.o usage.o widechar.o  ../link.o ../targext.o
../../ggc-none.o ../../libcommon-target.a ../../libcommon.a
../../../libcpp/libcpp.a ../rts/libgnat.a  
../../../libbacktrace/.libs/libbacktrace.a ../../../libiberty/libiberty.a  
-no-pie -ldl
g++: error: unrecognized command line option ‘-no-pie’
../gcc-interface/Makefile:2221: recipe for target '../../gnatmake' failed
make[2]: *** [../../gnatmake] Error 1
make[2]: Leaving directory '/home/eric/build/gcc/native/gcc/ada/tools'
Makefile:188: recipe for target 'gnattools-native' failed
make[1]: *** [gnattools-native] Error 2
make[1]: Leaving directory '/home/eric/build/gcc/native/gnattools'
Makefile:13917: recipe for target 'all-gnattools' failed
make: *** [all-gnattools] Error 2

During the bootstrap, CXX is set to /home/eric/build/gcc/native/./gcc/xg++
-B/home/eric/build/gcc/native/./gcc/ so this still works.

[Bug middle-end/83019] Compiler dumps predictions with -nan%

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Uroš Bizjak  ---
Adding CC.

[Bug middle-end/83019] New: Compiler dumps predictions with -nan%

[ubizjak at gmail dot com]

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

Bug ID: 83019
   Summary: Compiler dumps predictions with -nan%
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Recent patch caused some dumps to dump -nam%.

One example is gcc.dg/graphite/interchange-12.c, which generates:

./cc1 -O2 -ffast-math -floop-nest-optimize -fdump-tree-graphite-all
interchange-12.c

interchange-12.c.150t.graphite:

...
Predictions for bb 29
  first match heuristics: 99.0%  exec 0 (estimated locally) hit 0 (estimated
locally) (-nan%)
  combined heuristics: 99.0%  exec 0 (estimated locally) hit 0 (estimated
locally) (-nan%)
  loop iterations heuristics of edge 29->28: 1.0%  exec 0 (estimated locally)
hit 0 (estimated locally) (-nan%)
Predictions for bb 30
1 edges in bb 30 predicted to even probabilities
Predictions for bb 28
  first match heuristics: 99.0%  exec 0 (estimated locally) hit 0 (estimated
locally) (-nan%)
  combined heuristics: 99.0%  exec 0 (estimated locally) hit 0 (estimated
locally) (-nan%)
  loop iterations heuristics of edge 28->22: 1.0%  exec 0 (estimated locally)
hit 0 (estimated locally) (-nan%)
...

The above dump was generated with x86_64-linux-gnu host. This is problematic
with hosts (e.g. alpha) that require -mieee when dealing with NaNs, resulting
in several ICEs [1].

The cause is the division 0/0 in:

Program received signal SIGFPE, Arithmetic exception.
0x0001207a4ee4 in dump_prediction (file=0x121665bf0, predictor=, probability=, bb=0x299df48, reason=, 
ep_edge=) at
/space/homedirs/uros/gcc-svn/trunk/gcc/predict.c:750
750   fprintf (file, " (%.1f%%)", e->count ().to_gcov_type() *
100.0
(gdb) bt
#0  0x0001207a4ee4 in dump_prediction (file=0x121665bf0,
predictor=, probability=, bb=0x299df48, 
reason=, ep_edge=) at
/space/homedirs/uros/gcc-svn/trunk/gcc/predict.c:750
#1  0x0001207af424 in combine_predictions_for_bb (bb=0x299df48,
dry_run=) at /space/homedirs/uros/gcc-svn/trunk/gcc/predict.c:1
270
#2  0x0001207b23d0 in tree_estimate_probability (dry_run=)
at /space/homedirs/uros/gcc-svn/trunk/gcc/predict.c:2819
#3  0x000120f6bf24 in graphite_transform_loops () at
/space/homedirs/uros/gcc-svn/trunk/gcc/graphite.c:425
#4  0x000120f6d374 in graphite_transforms (fun=0x12120fc31) at
/space/homedirs/uros/gcc-svn/trunk/gcc/graphite.c:447
#5  (anonymous namespace)::pass_graphite_transforms::execute (this=0x121665bf0,
fun=0x12120fc31) at /space/homedirs/uros/gcc-svn/trunk/gcc/graphite.c:
524
#6  0x00012078b038 in execute_one_pass (pass=0x1214fe7c0) at
/space/homedirs/uros/gcc-svn/trunk/gcc/passes.c:2497
#7  0x00012078bc08 in execute_pass_list_1 (pass=0x1214fe7c0) at
/space/homedirs/uros/gcc-svn/trunk/gcc/passes.c:2586
#8  0x00012078bc24 in execute_pass_list_1 (pass=0x1214fe760) at
/space/homedirs/uros/gcc-svn/trunk/gcc/passes.c:2587
#9  0x00012078bc24 in execute_pass_list_1 (pass=0x1214fe400) at
/space/homedirs/uros/gcc-svn/trunk/gcc/passes.c:2587
#10 0x00012078bc24 in execute_pass_list_1 (pass=0x1214fd070) at
/space/homedirs/uros/gcc-svn/trunk/gcc/passes.c:2587
#11 0x00012078bca4 in execute_pass_list (fn=,
pass=0x12120fc31) at /space/homedirs/uros/gcc-svn/trunk/gcc/passes.c:2597
#12 0x000120363804 in cgraph_node::expand (this=0x29c8000) at
/space/homedirs/uros/gcc-svn/trunk/gcc/cgraphunit.c:2139
#13 0x0001203652a0 in expand_all_functions () at
/space/homedirs/uros/gcc-svn/trunk/gcc/cgraphunit.c:2275
#14 symbol_table::compile (this=) at
/space/homedirs/uros/gcc-svn/trunk/gcc/cgraphunit.c:2623
#15 0x00012036874c in compile (this=0x28a4000) at
/space/homedirs/uros/gcc-svn/trunk/gcc/cgraphunit.c:2682
#16 symbol_table::finalize_compilation_unit (this=0x28a4000) at
/space/homedirs/uros/gcc-svn/trunk/gcc/cgraphunit.c:2716
#17 0x0001208a695c in compile_file () at
/space/homedirs/uros/gcc-svn/trunk/gcc/toplev.c:480
#18 0x00012013ae90 in do_compile () at
/space/homedirs/uros/gcc-svn/trunk/gcc/toplev.c:2060
#19 toplev::main (this=0x11fdff040, argc=, argv=)
at /space/homedirs/uros/gcc-svn/trunk/gcc/toplev.c:2195
#20 0x00012013cf60 in main (argc=, argv=0x11fdff168) at
/space/homedirs/uros/gcc-svn/trunk/gcc/main.c:39
(gdb) list
745   bb->count.dump (file);
746   if (e)
747 {
748   fprintf (file, " hit ");
749   e->count ().dump (file);
750   fprintf (file, " (%.1f%%)", e->count ().to_gcov_type() *
100.0
751/ bb->count.to_gcov_type ());
752 }
753 }
754

[1] https://gcc.gnu.org/ml/gcc-testresults/2017-11/msg01330.html

[Bug c++/83018] New: To support creation of header-only C++ libraries with SIMD optimization and dynamic dispatch, allow all intrinsics regardless of target architecture

[kerukuro at gmail dot com]

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

Bug ID: 83018
   Summary: To support creation of header-only C++ libraries with
SIMD optimization and dynamic dispatch, allow all
intrinsics regardless of target architecture
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kerukuro at gmail dot com
  Target Milestone: ---

Visual C++ already does this. Using Visual C++, I can use e.g. AVX2 intrinsics
in a program compiled with SSE2 target architecture and dispatch to that code
path dynamically if CPU supports AVX2. GCC requires compiling separate object
files to achieve that, which is not possible for header-only libraries.

[Bug fortran/83017] DO CONCURRENT not parallelizing

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug fortran/83017] DO CONCURRENT not parallelizing

[rguenth at gcc dot gnu.org]

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

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

Otherwise untested patch.  Note ivdep is mapped to safelen which isn't useful
for parallelization given safelen perserves forward dependences.

[Bug fortran/83017] DO CONCURRENT not parallelizing

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
If I "fix" GCC to consider the loop you annotate parallel:

do concurrent (i = 1:nsplit)
pi(i) = sum(compute( low(i), high(i) ))
end do

then we arrive at computing 4 iterations of that loop and with 2 threads
and MIN_PER_THREAD 100 (arbitrary define) we run into

  if (!flag_loop_parallelize_all
  && !oacc_kernels_p
  && ((estimated != -1
   && estimated <= (HOST_WIDE_INT) n_threads * MIN_PER_THREAD)
  /* Do not bother with loops in cold areas.  */
  || optimize_loop_nest_for_size_p (loop)))
continue;

(estimated is 4).  With -floop-parallelize-all I then get:

> ./f951 -quiet t.f90 -Ofast -ftree-parallelize-loops=2 
> -fdump-tree-parloops-details -floop-parallelize-all -fopt-info-loop
t.f90:28:0: note: loop with 5 iterations completely unrolled (header execution
count 375)
t.f90:26:0: note: loop with 5 iterations completely unrolled (header execution
count 1500)
t.f90:38:0: note: loop with 5 iterations completely unrolled (header execution
count 1500)
t.f90:18:0: note: loop with 4 iterations completely unrolled (header execution
count 375)
t.f90:15:0: note: loop with 5 iterations completely unrolled (header execution
count 375)
t.f90:26:0: note: parallelizing outer loop 3
t.f90:24:0: note: basic block vectorized
t.f90:41:0: note: basic block vectorized
t.f90:41:0: note: basic block vectorized

yay.

[Bug fortran/83017] DO CONCURRENT not parallelizing

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On November 16, 2017 2:22:50 PM GMT+01:00, cfztol at hotmail dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017
>
>--- Comment #5 from Christian Felter  ---
>Okay, sounds like there is hope. By the way, the problem also exists
>without a
>function call. Declaring
>
> real, dimension(nsplit) :: tmp
>
>and replacing the loop with
>
> do concurrent (i = 1:nsplit)
>
> tmp = 0
> do j = low(i), high(i)
> k = mod( j, nsplit ) + 1
> tmp(k) = tmp(k) + (-1)**(j+1) / real( 2*j-1 )
> end do
> pi(i) = sum(tmp)
>
> end do
>
>also inhibits parallelization.

What does do concurrent guarantee?

[Bug c++/83000] Constraints for union-templates do not work

[ensadc at mailnesia dot com]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #1 from ensadc at mailnesia dot com ---
Possible duplicate of issue 67217

[Bug c++/83003] Using the detection idiom and void_t causes an error

[ensadc at mailnesia dot com]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #3 from ensadc at mailnesia dot com ---
There doesn't even need to be a specialization of Zod.

template  class, class = void>
struct dtect1  { enum { value = 0 }; };

template  class TT>
struct dtect1 { enum { value = 1 }; };

template  struct Zod { };
template  using Zod_t = typename Zod::type;

static_assert(!dtect1::value, "");

Zod_t z2; // !!

[Bug fortran/83017] DO CONCURRENT not parallelizing

[cfztol at hotmail dot com]

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

--- Comment #5 from Christian Felter  ---
Okay, sounds like there is hope. By the way, the problem also exists without a
function call. Declaring

 real, dimension(nsplit) :: tmp

and replacing the loop with

 do concurrent (i = 1:nsplit)

 tmp = 0
 do j = low(i), high(i)
 k = mod( j, nsplit ) + 1
 tmp(k) = tmp(k) + (-1)**(j+1) / real( 2*j-1 )
 end do
 pi(i) = sum(tmp)

 end do

also inhibits parallelization.

[Bug sanitizer/83014] ICE in pretty-print with -fsanitize=bounds

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Sorry, but I can't reproduce on linux with cross compiler for mingw32.

[Bug fortran/83017] DO CONCURRENT not parallelizing

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On November 16, 2017 1:22:37 PM GMT+01:00, cfztol at hotmail dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017
>
>--- Comment #3 from Christian Felter  ---
>Ultimately, I wanted to compute k like this
>
>k = permutation( j )
>
>where permutation is a 1D array of integers (from 1 to 4, e.g. [ 1, 4,
>2, 1, 3,
>... etc] ). This would allow an easy way of parallelizing the so-called
>"finite
>element assembly procedure". But I guess, this case is even harder.
>Clearly, I
>must have misunderstood the requirements for DO CONCURRENT... Maybe
>they could
>be relaxed ?

It's more an optimization pass issue or the frontend not communicating
guarantees for dependencies downstream. Might be a bit tricky for function
calls.

[Bug fortran/83017] DO CONCURRENT not parallelizing

[cfztol at hotmail dot com]

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

--- Comment #3 from Christian Felter  ---
Ultimately, I wanted to compute k like this

k = permutation( j )

where permutation is a 1D array of integers (from 1 to 4, e.g. [ 1, 4, 2, 1, 3,
... etc] ). This would allow an easy way of parallelizing the so-called "finite
element assembly procedure". But I guess, this case is even harder. Clearly, I
must have misunderstood the requirements for DO CONCURRENT... Maybe they could
be relaxed ?

[Bug c++/79331] ICE on valid C++14 code (with initialized lambda capture) on x86_64-linux-gnu: in canonicalize_component_ref, at gimplify.c:2451

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
This is the same as 81574 and now fixed:
PR c++/81574
* lambda.c (lambda_capture_field_type): Function references are
always catured by reference.