[Bug bootstrap/80887] gnat bootstrap fails at s-regpat.o: raised STORAGE_ERROR : stack overflow or erroneous memory access

[glisse at gcc dot gnu.org]

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

--- Comment #9 from Marc Glisse  ---
C testcase that ICEs (when the patch is installed):

int pos;
void f(){
  ++pos;
  unsigned u=(unsigned)pos-1;
  int a = pos;
  unsigned t1=a-1;
  unsigned t2=(unsigned)a-2;
}

where again, during FRE1, gimple_simplify gets called recursively on the same
arguments. I am quite convinced that the issue exists even without my patch, we
are lucky if none of the existing transformations can trigger it.

[Bug tree-optimization/80944] redundant memcpy/memset with non-constant size not eliminated

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
(In reply to Martin Sebor from comment #0)
> struct S { char *s; unsigned n; };
> 
> void f (struct S *s)
> {
>   __builtin_memset (s->s, 0, s->n);
>   __builtin_free (s->s);
>   __builtin_memset (s, 0, sizeof *s);
>   __builtin_free (s);
> }

If you replace the first 2 lines of f with

  char* t=s->s;
  __builtin_memset (t, 0, s->n);
  __builtin_free (t);

we optimize away both memset just fine. Consider:

struct S*s=malloc(sizeof(struct S));
s->s = s;
s->n = sizeof(char*);
f(s);

that is, the first memset may modify s->s, so it cannot be removed.

[Bug objc/80949] New: ICE in do_warn_duplicated_branches_r

[egall at gwmail dot gwu.edu]

ngs \
   nsselect.m
nsselect.m: In function ‘ns_string_from_pasteboard’:
nsselect.m:303:1: internal compiler error: Bus error
 }
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
make: *** [nsselect.o] Error 1


Adding -wrapper gdb,--args allows me to get this backtrace:

. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x0015c45d in do_warn_duplicated_branches_r ()
(gdb) bt
#0  0x0015c45d in do_warn_duplicated_branches_r ()
#1  0x00dfdd62 in walk_tree_1 ()
#2  0x00dfe2f4 in walk_tree_1 ()
#3  0x00dfe2f4 in walk_tree_1 ()
#4  0x00dfe2f4 in walk_tree_1 ()
#5  0x00dfd8ae in walk_tree_without_duplicates_1 ()
#6  0x0011ed29 in c_genericize ()
#7  0x00056e19 in finish_function ()
#8  0x000c92d0 in c_parser_declaration_or_fndef ()
#9  0x000d1467 in c_parser_external_declaration ()
#10 0x000d1ee0 in c_parse_file ()
#11 0x0012c4fb in c_common_parse_file ()
#12 0x00ad99d5 in compile_file ()
#13 0x017cf25f in toplev::main ()
#14 0x017d0cd4 in main ()


I'd have to rebuild gcc with debug info to get a better backtrace...

Version info for the gcc I'm using:

$ /usr/local/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/8.0.0/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../configure --disable-werror --disable-werror-always
--enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release,rtl
-C --with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --with-isl --disable-host-shared --enable-maintainer-mode
--disable-default-pie --with-ld64 --without-pic --enable-target-optspace
CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++ AUTOCONF=/usr/local/bin/autoconf
AUTOHEADER=/usr/local/bin/autoheader AUTORECONF=/usr/local/bin/autoreconf
AUTOM4TE=/usr/local/bin/autom4te AUTOSCAN=/usr/local/bin/autoscan
AUTOUPDATE=/usr/local/bin/autoupdate IFNAMES=/usr/local/bin/ifnames
Thread model: posix
gcc version 8.0.0 20170601 (experimental) (GCC)

[Bug tree-optimization/80948] [8 regression] test case gcc.dg/torture/pr68017.c fails with ICE starting with r248771

[paul.hua.gm at gmail dot com]

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

Paul Hua  changed:

   What|Removed |Added

 CC||paul.hua.gm at gmail dot com

--- Comment #1 from Paul Hua  ---
It's also fails on mips64el-unknown-linux-gnu.

spawn -ignore SIGHUP /home/xuchenghua/GCC/test/gcc-r248792_obj/gcc/xgcc
-B/home/xuchenghua/GCC/test/gcc-r248792_obj/gcc/
/home/xuchenghua/GCC/gcc_git_trunk/gcc/testsuite/gcc.dg/torture/pr68017.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -g -g -S -o
pr68017.s^M
/home/xuchenghua/GCC/gcc_git_trunk/gcc/testsuite/gcc.dg/torture/pr68017.c: In
function 'fn2':^M
/home/xuchenghua/GCC/gcc_git_trunk/gcc/testsuite/gcc.dg/torture/pr68017.c:13:1:
error: definition in block 3 follows the use^M
for SSA_NAME: _16 in statement:^M
_5 = _16 * 2;^M
during GIMPLE pass: tailc^M
/home/xuchenghua/GCC/gcc_git_trunk/gcc/testsuite/gcc.dg/torture/pr68017.c:13:1:
internal compiler error: verify_ssa failed^M
0x120b153b7 verify_ssa(bool, bool)^M
../../../gcc_git_trunk/gcc/tree-ssa.c:1183^M
0x1207546bf execute_function_todo^M
../../../gcc_git_trunk/gcc/passes.c:1995^M
0x120755bd7 execute_todo^M
../../../gcc_git_trunk/gcc/passes.c:2042^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
Please include the complete backtrace with any bug report.^M
See  for instructions.^M
compiler exited with status 1
output is: 
/home/xuchenghua/GCC/gcc_git_trunk/gcc/testsuite/gcc.dg/torture/pr68017.c: In
function 'fn2':^M
/home/xuchenghua/GCC/gcc_git_trunk/gcc/testsuite/gcc.dg/torture/pr68017.c:13:1:
error: definition in block 3 follows the use^M
for SSA_NAME: _16 in statement:^M
_5 = _16 * 2;^M
during GIMPLE pass: tailc^M
/home/xuchenghua/GCC/gcc_git_trunk/gcc/testsuite/gcc.dg/torture/pr68017.c:13:1:
internal compiler error: verify_ssa failed^M
0x120b153b7 verify_ssa(bool, bool)^M
../../../gcc_git_trunk/gcc/tree-ssa.c:1183^M
0x1207546bf execute_function_todo^M
../../../gcc_git_trunk/gcc/passes.c:1995^M
0x120755bd7 execute_todo^M
../../../gcc_git_trunk/gcc/passes.c:2042^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
Please include the complete backtrace with any bug report.^M
See  for instructions.^M

FAIL: gcc.dg/torture/pr68017.c   -O3 -g  (internal compiler error)
FAIL: gcc.dg/torture/pr68017.c   -O3 -g  (test for excess errors)

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #26 from Eric Gallager  ---
(In reply to Keith Thompson from comment #3)
> I see no "-Walign" option, either in the versions of gcc I'm using or in the
> online documentation.  Were you thinking of a different option?
>

Maybe -Wpacked?

[Bug c++/62315] do not print typename in diagnostic if the original code does not have it

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-02
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
In such cases of TYPENAME_TYPEs, printing separately TYPE_CONTEXT and
TYPENAME_TYPE_FULLNAME, like we already do in grokdeclarator, should work:

Index: parser.c
===
--- parser.c(revision 248783)
+++ parser.c(working copy)
@@ -3270,9 +3270,21 @@ cp_parser_diagnose_invalid_type_name (cp_parser *p
}
   else if (TYPE_P (parser->scope)
   && dependent_scope_p (parser->scope))
-   error_at (location, "need % before %<%T::%E%> because "
- "%qT is a dependent scope",
- parser->scope, id, parser->scope);
+   {
+ if (TREE_CODE (parser->scope) == TYPENAME_TYPE)
+   error_at (location,
+ "need % before %<%T::%D::%E%> because "
+ "%<%T::%D%> is a dependent scope",
+ TYPE_CONTEXT (parser->scope),
+ TYPENAME_TYPE_FULLNAME (parser->scope),
+ id,
+ TYPE_CONTEXT (parser->scope),
+ TYPENAME_TYPE_FULLNAME (parser->scope));
+ else
+   error_at (location, "need % before %<%T::%E%> because "
+ "%qT is a dependent scope",
+ parser->scope, id, parser->scope);
+   }
   else if (TYPE_P (parser->scope))
{
  if (!COMPLETE_TYPE_P (parser->scope))

[Bug tree-optimization/80948] New: [8 regression] test case gcc.dg/torture/pr68017.c fails with ICE starting with r248771

[seurer at gcc dot gnu.org]

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

Bug ID: 80948
   Summary: [8 regression] test case gcc.dg/torture/pr68017.c
fails with ICE starting with r248771
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Fails on powerpc64 LE and BE for power8/7/6

make -k check-gcc RUNTESTFLAGS=dg-torture.exp=gcc.dg/torture/pr68017.c

spawn /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/torture/pr68017.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -g -g -S -o pr68017.s
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/torture/pr68017.c: In function
'fn2':
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/torture/pr68017.c:13:1: error:
definition in block 3 follows the use
for SSA_NAME: _16 in statement:
_5 = _16 * 2;
during GIMPLE pass: tailc
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/torture/pr68017.c:13:1: internal
compiler error: verify_ssa failed
0x10be7a9b verify_ssa(bool, bool)
/home/seurer/gcc/gcc-test/gcc/tree-ssa.c:1183
0x10829a0f execute_function_todo
/home/seurer/gcc/gcc-test/gcc/passes.c:1995
0x1082a613 do_per_function
/home/seurer/gcc/gcc-test/gcc/passes.c:1654
0x1082a893 execute_todo
/home/seurer/gcc/gcc-test/gcc/passes.c:2042
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
output is:
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/torture/pr68017.c: In function
'fn2':
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/torture/pr68017.c:13:1: error:
definition in block 3 follows the use
for SSA_NAME: _16 in statement:
_5 = _16 * 2;
during GIMPLE pass: tailc
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/torture/pr68017.c:13:1: internal
compiler error: verify_ssa failed
0x10be7a9b verify_ssa(bool, bool)
/home/seurer/gcc/gcc-test/gcc/tree-ssa.c:1183
0x10829a0f execute_function_todo
/home/seurer/gcc/gcc-test/gcc/passes.c:1995
0x1082a613 do_per_function
/home/seurer/gcc/gcc-test/gcc/passes.c:1654
0x1082a893 execute_todo
/home/seurer/gcc/gcc-test/gcc/passes.c:2042
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

FAIL: gcc.dg/torture/pr68017.c   -O3 -g  (internal compiler error)
FAIL: gcc.dg/torture/pr68017.c   -O3 -g  (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/torture/pr68017.c:13:1: error:
definition in block 3 follows the use
for SSA_NAME: _16 in statement:
_5 = _16 * 2;
during GIMPLE pass: tailc
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/torture/pr68017.c:13:1: internal
compiler error: verify_ssa failed
0x10be7a9b verify_ssa(bool, bool)
/home/seurer/gcc/gcc-test/gcc/tree-ssa.c:1183
0x10829a0f execute_function_todo
/home/seurer/gcc/gcc-test/gcc/passes.c:1995
0x1082a613 do_per_function
/home/seurer/gcc/gcc-test/gcc/passes.c:1654
0x1082a893 execute_todo
/home/seurer/gcc/gcc-test/gcc/passes.c:2042

[Bug c++/80947] New: 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

Bug ID: 80947
   Summary: Different visibility for the lambda and its capture
list members with -fvisibility=hidden
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladz at scylladb dot com
  Target Milestone: ---

I'm trying to compile a C++14 program using standard g++-6 and g++-7 compilers
coming with Ubuntu 16.04:

g++-6 (Ubuntu/Linaro 6.3.0-18ubuntu2~16.04) 6.3.0 20170519
g++-7 (Ubuntu 7.1.0-5ubuntu2~16.04) 7.1.0

The error I get with both of them is the same.

The issue doesn't reproduce with the
g++ (Ubuntu 5.4.1-2ubuntu1~16.04) 5.4.1 20160904

The issue doesn't reproduce when I use -fvisibility=default.

The error looks as follows:


g++-6 -MD -MT build/release/gms/versioned_value.o -MF
build/release/gms/versioned_value.o.d -std=gnu++1y -g  -Wall -Werror
-fvisibility-inlines-hidden -fvisibility=hidden  -pthread
-I/home/vladz/work/urchin/seastar -I/home/vladz/work/urchin/seastar/fmt
-I/home/vladz/work/urchin/seastar/build/release/gen  -march=nehalem -fconcepts
-Ifmt -DBOOST_TEST_DYN_LINK -Wno-overloaded-virtual -DFMT_HEADER_ONLY
-DHAVE_GCC6_CONCEPTS -DHAVE_HWLOC -DHAVE_NUMA -DHAVE_LZ4_COMPRESS_DEFAULT  -O2
-I/usr/include/jsoncpp -DBOOST_TEST_DYN_LINK  -Wno-maybe-uninitialized
-Wno-tautological-compare -Wno-missing-braces
-Wno-error=deprecated-declarations -DHAVE_LIBSYSTEMD=1 -I. -I build/release/gen
-I seastar -I seastar/build/release/gen -c -o
build/release/gms/versioned_value.o gms/versioned_value.cc
In file included from ./utils/exponential_backoff_retry.hh:25:0,
 from ./sstables/compaction_manager.hh:32,
 from ./database.hh:67,
 from ./repair/repair.hh:31,
 from ./message/messaging_service.hh:34,
 from gms/versioned_value.cc:39:
/home/vladz/work/urchin/seastar/core/sleep.hh: In instantiation of ‘struct
seastar::sleep(std::chrono::duration<_Rep,
_Period>)::sleeper::sleeper(std::chrono::duration<_Rep, _Period>) [with Clock =
std::chrono::_V2::steady_clock; Rep = long int; Period = std::ratio<1l,
1000l>]::’:
/home/vladz/work/urchin/seastar/core/sleep.hh:48:47:   required from
‘seastar::sleep(std::chrono::duration<_Rep,
_Period>)::sleeper::sleeper(std::chrono::duration<_Rep, _Period>) [with Clock =
std::chrono::_V2::steady_clock; Rep = long int; Period = std::ratio<1l,
1000l>]’
/home/vladz/work/urchin/seastar/core/sleep.hh:52:5:   required from
‘seastar::future<> seastar::sleep(std::chrono::duration<_Rep, _Period>) [with
Clock = std::chrono::_V2::steady_clock; Rep = long int; Period = std::ratio<1l,
1000l>]’
./utils/exponential_backoff_retry.hh:45:36:   required from here
/home/vladz/work/urchin/seastar/core/sleep.hh:48:24: error:
‘seastar::sleep(std::chrono::duration<_Rep,
_Period>)::sleeper::sleeper(std::chrono::duration<_Rep, _Period>) [with Clock =
std::chrono::_V2::steady_clock; Rep = long int; Period = std::ratio<1l,
1000l>]::’ declared with greater visibility than the type of its
field ‘seastar::sleep(std::chrono::duration<_Rep,
_Period>)::sleeper::sleeper(std::chrono::duration<_Rep, _Period>) [with Clock =
std::chrono::_V2::steady_clock; Rep = long int; Period = std::ratio<1l,
1000l>]::::’ [-Werror=attributes]
 : tmr([this] { done.set_value(); })
^
cc1plus: all warnings being treated as errors


Error message implies that the visibility of the lambda in question is  greater
than the visibility of the capture list value "this".

Since lambdas are translated into the classes with the operator()(...)  and (it
seems like) captured values are translated into the fields of this class it
looks like for some reason the visibility of that class is higher than the one
of those fields.

Another workaround that would make the error go away is to explicitly use the
__attribute__ ((visibility ("hidden"))) or __attribute__ ((visibility
("default"))) for the sleeper struct.

Attached is an *.ii value generated by g++-6

[Bug c/53037] warn_if_not_aligned(X)

[msebor at gcc dot gnu.org]

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

--- Comment #20 from Martin Sebor  ---
It would be useful to have the ability to trigger a warning when an object of a
type with an explicitly specified alignment (even if the alignment matches its
own native one) is defined in a way that would cause its alignment to be
reduced.  The specific use case where it came up is defining a packed struct
that contains a member of type std::mutex (or some type that contains it.)

A test case for the warning I was asking about (with no warn_if_not_aligned
attribute) is simply:

  struct __attribute___ ((aligned (8))) S8 { char a[8]; };   // explicitly
overaligned

  struct __attribute__ ((packed)) S {
struct S8 s8;   // warn here: alignment of 'struct A' reduced from 8 to 1
  };

[Bug tree-optimization/80934] bzero should be assumed not to escape pointer argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00083.html

[Bug tree-optimization/80933] redundant bzero/bcopy calls not eliminated

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00083.html

[Bug fortran/80945] Invalid code with allocatable character array in READ/WRITE statement

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
Really strange - the tree dumps look OK at first glance.

  D.3543 = (sizetype) NON_LVALUE_EXPR <.ca>;

and later on

parm.3.dtype = ((integer(kind=8)) SAVE_EXPR  << 6) + 49;
parm.3.dim[0].lbound = 1;
parm.3.dim[0].ubound = 3;
parm.3.dim[0].stride = 1;
parm.3.data = (void *) &(*(character(kind=1)[0:][1:.ca] * restrict)
ca.data)[1 - ca.dim[0].lbound];
parm.3.offset = 0;
_gfortran_transfer_array_write (_parm.2, , 1, .ca);

What am I missing?

[Bug c++/80943] Conversion function selected in list-initialization in C++1z mode

[barry.revzin at gmail dot com]

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

--- Comment #1 from Barry Revzin  ---
Sorry, it's a bug, but not for the reasons I cited. Both T t(s) and T t{s}
should consider constructors - which should find T(S const& ) and T(T&& ) by
way of the conversion function. But the former is an exact match, so it should
be the one preferred.

[Bug ada/80921] cross compiling fails to build Ada shared libraries

[ebotcazou at gcc dot gnu.org]

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

--- Comment #14 from Eric Botcazou  ---
> That's not strictly true; while they may not be essential, import libraries
> are, by no means, obsolete.  The search order, for the Windows linker[1], is:
> 
> libfoo.dll.a
> foo.dll.a
> libfoo.a
> foo.dll
> libfoo.dll
> 
> So, unless the foo.dll (or libfoo.dll) is in a different path from libfoo.a,
> and that path is searched earlier that the conventional lib path, then -lfoo
> will always cause static linking, if libfoo.dll.a is not provided.  Also,
> when the static library is libfoo.a, and the DLL is qualified by a version
> suffix, -lfoo will never find libfoo-N.dll; this entirely defeats the
> linker's -Bdynamic vs. -Bstatic selection for -lfoo.

I see, thanks for the detailed explanation.  There has been a long time since I
really toyed with Windows development and I thought that all this non-sense had
been eliminated, but apparently not...

In any case, the Windows GNAT folks are happy with the current situation.

[Bug other/80946] New: [8 regression] test cases gfortran.dg/vect/vect-2.f90 and gfortran.dg/vect/vect-5.f90 fail starting with r247544

[seurer at gcc dot gnu.org]

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

Bug ID: 80946
   Summary: [8 regression] test cases gfortran.dg/vect/vect-2.f90
and gfortran.dg/vect/vect-5.f90 fail starting with
r247544
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This is split from the earlier pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80618


make -k check-fortran RUNTESTFLAGS=vect.exp=gfortran.dg/vect/vect-2.f90
. . .
spawn /home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran9/../../gfortran
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran9/../../
-B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/vect/vect-2.f90
-fno-diagnostics-show-caret -fdiagnostics-color=never -O -O2 -ftree-vectorize
-fvect-cost-model=unlimited -fdump-tree-vect-details -maltivec -mpower8-vector
-S -o vect-2.s
PASS: gfortran.dg/vect/vect-2.f90   -O  (test for excess errors)
PASS: gfortran.dg/vect/vect-2.f90   -O   scan-tree-dump-times vect "vectorized
3 loops" 1
FAIL: gfortran.dg/vect/vect-2.f90   -O   scan-tree-dump-times vect "Alignment
of access forced using peeling" 3
FAIL: gfortran.dg/vect/vect-2.f90   -O   scan-tree-dump-times vect "Vectorizing
an unaligned access" 2


make -k check-fortran RUNTESTFLAGS=vect.exp=gfortran.dg/vect/vect-5.f90
. . .
PASS: gfortran.dg/vect/vect-5.f90   -O  execution test
PASS: gfortran.dg/vect/vect-5.f90   -O   scan-tree-dump-times vect "vectorized
1 loops" 1
FAIL: gfortran.dg/vect/vect-5.f90   -O   scan-tree-dump-times vect "Alignment
of access forced using peeling" 1
FAIL: gfortran.dg/vect/vect-5.f90   -O   scan-tree-dump-times vect "Vectorizing
an unaligned access" 1


Note that this is *not* related to this pr: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925

The test cases were failing in the revision (r248677) prior to the one that
triggered pr80925 (r248678).

[Bug fortran/80945] Invalid code with allocatable character array in READ/WRITE statement

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-01
 Ever confirmed|0   |1

--- Comment #2 from Thomas Koenig  ---
The dtype is messed up.  Breaking at _gfortran_transfer_array
for the test case in cmment #1 shows

Breakpoint 1, _gfortran_transfer_array (dtp=0x7fffd910,
desc=0x7fffdaf0, kind=1, charlen=10) at
../../../gcc-7/libgfortran/io/transfer.c:2409
2409  if ((dtp->common.flags & IOPARM_LIBRETURN_MASK) !=
IOPARM_LIBRETURN_OK)
(gdb) p *desc
$3 = {base_addr = 0x605ff0 "foo   bar   xyzzy ", offset =
18446744073709551615, dtype = 689, dim = {{_stride = 1, lower_bound = 1,
_ubound = 3}, {_stride = 8241976683187367782, 
  lower_bound = 2340036147838197792, _ubound = 2314885530818453536},
{_stride = 2314885530818453536, lower_bound = 2314885530818453536, _ubound =
2314885530818453536}, {_stride = 8224, 
  lower_bound = 44024187392, _ubound = 140737488346016}, {_stride = 0,
lower_bound = 4196368, _ubound = 140737488346240}, {_stride = 140737488346016,
lower_bound = 4197718, 
  _ubound = 140737488346248}, {_stride = 4294967296, lower_bound = 4197728,
_ubound = 140737336403265}}}
(gdb) c
Continuing.
foo  bar  xyzzy

Breakpoint 1, _gfortran_transfer_array (dtp=0x7fffd910,
desc=0x7fffd8e0, kind=1, charlen=10) at
../../../gcc-7/libgfortran/io/transfer.c:2409
2409  if ((dtp->common.flags & IOPARM_LIBRETURN_MASK) !=
IOPARM_LIBRETURN_OK)
(gdb) p *desc
$4 = {base_addr = 0x605ff0 "foo   bar   xyzzy ", offset = 0, dtype
= -60931979599, dim = {{_stride = 1, lower_bound = 1, _ubound = 3}, {_stride =
25769807872, lower_bound = 4198108, 
  _ubound = 13}, {_stride = 0, lower_bound = 0, _ubound = 0}, {_stride = 0,
lower_bound = 0, _ubound = 0}, {_stride = 4198114, lower_bound = 5, _ubound =
0}, {_stride = 0, lower_bound = 0, 
  _ubound = 0}, {_stride = 0, lower_bound = 0, _ubound = 0}}}

[Bug fortran/80945] Invalid code with allocatable character array in READ/WRITE statement

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Thomas Koenig  ---
1. write also fails (no surprise there)
2. ca is OK, ca(1:3) is not.

$ cat u.f90
program main
implicit none
integer:: i
integer, parameter:: N = 10
character(len=:), dimension(:),allocatable:: ca
character(len=50):: buffer
allocate(character(len=N):: ca(3))
buffer = "foo  bar  xyzzy"
ca(1) = "foo"
ca(2) = "bar"
ca(3) = "xyzzy"
write (*, '(3A5)') ca
write (*, '(3A5)') ca(1:3)
end program

$ gfortran u.f90 && ./a.out
foo  bar  xyzzy

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f38e528406f in ???
#1  0x7f38e5384440 in ???
#2  0x7f38e5eeb67c in formatted_transfer_scalar_write
at ../../../gcc-7/libgfortran/io/transfer.c:2059
#3  0x7f38e5eeb81c in formatted_transfer
at ../../../gcc-7/libgfortran/io/transfer.c:2279
#4  0x400d03 in ???
#5  0x400d55 in ???
#6  0x7f38e526f540 in ???
#7  0x400839 in ???
at ../sysdeps/x86_64/start.S:120
#8  0x in ???
Speicherzugriffsfehler (Speicherabzug geschrieben)

[Bug c/69502] attribute aligned reduces alignment contrary to documentation

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-01
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
The Common Variable Attributes section of the manual mentions the following:

When used as part of a typedef, the aligned attribute can both increase and
decrease alignment, and specifying the packed attribute generates a warning.

There is at least one test in the GCC test suite that exercises the ability to
decrease the alignment of a typedef (gcc/testsuite/gcc.dg/misaligned-expand-2.c
 added in r185336) so this is a documentation bug for not documenting the
feature in the right section of the manual (Common Type Attributes).

Confirming based bug 51628, comment #24.

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=69502

--- Comment #25 from Martin Sebor  ---
(In reply to Sven from comment #24)

Agreed.  This is the subject of bug 69502.

[Bug target/80618] [8 regression] test case gcc.dg/pr50310-2.c fails with ICE starting with 247544

[seurer at gcc dot gnu.org]

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

--- Comment #9 from seurer at gcc dot gnu.org ---
Segher's revision fixed the ICEs but the 4 other test case failures were due to
this (r247544) revision.

gcc.dg/vect/vect-50.c
gcc.dg/vect/vect-44.c
gfortran.dg/vect/vect-2.f90
gfortran.dg/vect/vect-5.f90


That said, the first two no longer fail but the two Fortran ones still do.

spawn /home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran9/../../gfortran
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran9/../../
-B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/vect/vect-2.f90
-fno-diagnostics-show-caret -fdiagnostics-color=never -O -O2 -ftree-vectorize
-fvect-cost-model=unlimited -fdump-tree-vect-details -maltivec -mpower8-vector
-S -o vect-2.s
PASS: gfortran.dg/vect/vect-2.f90   -O  (test for excess errors)
PASS: gfortran.dg/vect/vect-2.f90   -O   scan-tree-dump-times vect "vectorized
3 loops" 1
FAIL: gfortran.dg/vect/vect-2.f90   -O   scan-tree-dump-times vect "Alignment
of access forced using peeling" 3
FAIL: gfortran.dg/vect/vect-2.f90   -O   scan-tree-dump-times vect "Vectorizing
an unaligned access" 2




PASS: gfortran.dg/vect/vect-5.f90   -O  execution test
PASS: gfortran.dg/vect/vect-5.f90   -O   scan-tree-dump-times vect "vectorized
1 loops" 1
FAIL: gfortran.dg/vect/vect-5.f90   -O   scan-tree-dump-times vect "Alignment
of access forced using peeling" 1
FAIL: gfortran.dg/vect/vect-5.f90   -O   scan-tree-dump-times vect "Vectorizing
an unaligned access" 1

[Bug c++/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail

[db0451 at gmail dot com]

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

--- Comment #31 from DB  ---
Uh, sorry. I mean when compiling my own application against glibmm and gtkmm,
using LTO on my app (only).

[Bug c++/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail

[db0451 at gmail dot com]

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

DB  changed:

   What|Removed |Added

 CC||db0451 at gmail dot com

--- Comment #30 from DB  ---
I get similar issues when compiling glibmm-2.4 from git with g++ 6.3 and LTO,
but not without LTO: undefined references to destructors for
Glib::RefPtr and Glib::RefPtr.

Can this be related, or should I open another bug?

[Bug fortran/80945] New: Invalid code with allocatable character array in READ/WRITE statement

[koenigni at gcc dot gnu.org]

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

Bug ID: 80945
   Summary: Invalid code with allocatable character array in
READ/WRITE statement
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: koenigni at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41446
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41446=edit
Test Case

Trying to compile the testcase with "-O" produces invalid code, while compiling
it without leads to a segfault.

gcc@dcm-linux:~/pr/35339> gfortran -O z5.f90
gcc@dcm-linux:~/pr/35339> ./a.out   
 c  foo   bar   xyzzy   
 ca xyzzy   
gcc@dcm-linux:~/pr/35339> gfortran z5.f90   
gcc@dcm-linux:~/pr/35339> ./a.out   

Program received signal SIGSEGV: Segmentation fault - invalid memory reference. 

Backtrace for this error:   
#0  0x7f37dee45adf in ???   
#1  0x7f37dee97d15 in ???   
#2  0x7f37dfb03a50 in read_default_char1
at ../../../trunk/libgfortran/io/read.c:429 
#3  0x7f37dfb0809c in formatted_transfer_scalar_read
at ../../../trunk/libgfortran/io/transfer.c:1591
#4  0x7f37dfb08f2c in formatted_transfer
at ../../../trunk/libgfortran/io/transfer.c:2270
#5  0x400cb3 in ??? 
#6  0x400e43 in ??? 
#7  0x7f37dee31469 in ???   
#8  0x400909 in ??? 
at ../sysdeps/x86_64/start.S:120
#9  0x in ???
Segmentation fault (core dumped)

[Bug ada/80921] cross compiling fails to build Ada shared libraries

[keith.marshall at mailinator dot com]

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

--- Comment #13 from Keith Marshall  ---
(In reply to Eric Botcazou from comment #7)
> > With that in place, a clean configure and build does now produce:
> > 
> > gcc/ada/rts/libgnarl-6.dll
> > gcc/ada/rts/libgnat-6.dll
> > 
> > but there are no accompanying import libraries, (as there are for other
> > DLLs, produced for other languages in the GCC suite).  Definitely an
> > improvement, but perhaps not quite the entire solution.
> 
> Thanks for the feedback.  The Ada compiler doesn't use libtool to build its
> library so that's as expected (and import libraries are obsolete these days).

That's not strictly true; while they may not be essential, import libraries
are, by no means, obsolete.  The search order, for the Windows linker[1], is:

libfoo.dll.a
foo.dll.a
libfoo.a
foo.dll
libfoo.dll

So, unless the foo.dll (or libfoo.dll) is in a different path from libfoo.a,
and that path is searched earlier that the conventional lib path, then -lfoo
will always cause static linking, if libfoo.dll.a is not provided.  Also, when
the static library is libfoo.a, and the DLL is qualified by a version suffix,
-lfoo will never find libfoo-N.dll; this entirely defeats the linker's
-Bdynamic vs. -Bstatic selection for -lfoo.

A further problem with your DLL only convention is that the linker search path
(normally) isn't anywhere that a running application will expect to find its
shared objects, so we end up installing multiple copies of the DLL, spread
around the file system.

MinGW convention is to provide libfoo.dll.a and libfoo.a, in the linker search
path, with foo-N.dll (or libfoo-N.dll) in the runtime path.

[1]:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/win32.html

[Bug c/53037] warn_if_not_aligned(X)

[hjl.tools at gmail dot com]

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

--- Comment #19 from H.J. Lu  ---
(In reply to Martin Sebor from comment #18)
> This seems like a useful enhancement.  H.J., what is the status of the
> patch?  Do you have plans to submit it?

I was not sure if there were enough interests.  I need to rebase my code
to see if it still applies.

> On a related note, would warning on the use of a type explicitly decorated
> with a restrictive alignment attribute in an unaligned context achieve the
> same thing as the new attribute without false positives?  (That way existing
> code would automatically benefit from the new warning, without having to add
> a new attribute.)

A testcase?

[Bug c/53037] warn_if_not_aligned(X)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-01
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #18 from Martin Sebor  ---
This seems like a useful enhancement.  H.J., what is the status of the patch? 
Do you have plans to submit it?

On a related note, would warning on the use of a type explicitly decorated with
a restrictive alignment attribute in an unaligned context achieve the same
thing as the new attribute without false positives?  (That way existing code
would automatically benefit from the new warning, without having to add a new
attribute.)

[Bug tree-optimization/80944] New: redundant memcpy/memset with non-constant size not eliminated

[msebor at gcc dot gnu.org]

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

Bug ID: 80944
   Summary: redundant memcpy/memset with non-constant size not
eliminated
   Product: gcc
   Version: 7.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: ---

GCC eliminates redundant calls to memset (and memcpy) with the same destination
and known size, but it fails to eliminate such calls when the size is not
known.  This is a missed optimization opportunity (I haven't found a compiler
that does eliminate the first memset.)

As an example, consider the following function that tries to zero out the
memory occupied by the object just before releasing it (in C++, S could be a
std::string or similar class).  GCC retains the first memset call but
successfully eliminates the second, even though both could be eliminated.

$ cat t.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout t.c
struct S { char *s; unsigned n; };

void f (struct S *s)
{
  __builtin_memset (s->s, 0, s->n);
  __builtin_free (s->s);
  __builtin_memset (s, 0, sizeof *s);
  __builtin_free (s);
}

;; Function f (f, funcdef_no=0, decl_uid=1796, cgraph_uid=0, symbol_order=0)

f (struct S * s)
{
  unsigned int _1;
  long unsigned int _2;
  char * _3;
  char * _4;

   [100.00%]:
  _1 = s_6(D)->n;
  _2 = (long unsigned int) _1;
  _3 = s_6(D)->s;
  __builtin_memset (_3, 0, _2);
  _4 = s_6(D)->s;
  __builtin_free (_4);
  __builtin_free (s_6(D)); [tail call]
  return;

}

The following is a more comprehensive test case:

$ cat t.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout t.c

struct S { unsigned n; char a[32], b[]; };

void clear_cst (struct S *s)
{
  __builtin_memset (s->a, 0, sizeof s->a);
  __builtin_memset (s->a, 0, sizeof s->a);   // eliminated
}

void copy_cst (struct S *s)
{
  __builtin_memcpy (s->a, s->b, sizeof s->a);
  __builtin_memcpy (s->a, s->b, sizeof s->a);   // eliminated
}

void clear_var (struct S *s)
{
  __builtin_memset (s->b, 0, s->n);
  __builtin_memset (s->b, 0, s->n);   // not eliminated
}

void copy_var (struct S *s)
{
  __builtin_memcpy (s->b, s->a, s->n);
  __builtin_memcpy (s->b, s->a, s->n);   // not eliminated
}


;; Function clear_cst (clear_cst, funcdef_no=0, decl_uid=1797, cgraph_uid=0,
symbol_order=0)

clear_cst (struct S * s)
{
  char[32] * _1;

   [100.00%]:
  _1 = _2(D)->a;
  __builtin_memset (_1, 0, 32); [tail call]
  return;

}



;; Function copy_cst (copy_cst, funcdef_no=1, decl_uid=1800, cgraph_uid=1,
symbol_order=1)

copy_cst (struct S * s)
{
  char[0:] * _1;
  char[32] * _2;

   [100.00%]:
  _1 = _3(D)->b;
  _2 = _3(D)->a;
  __builtin_memcpy (_2, _1, 32); [tail call]
  return;

}



;; Function clear_var (clear_var, funcdef_no=2, decl_uid=1803, cgraph_uid=2,
symbol_order=2)

clear_var (struct S * s)
{
  unsigned int _1;
  long unsigned int _2;
  char[0:] * _3;

   [100.00%]:
  _1 = s_5(D)->n;
  _2 = (long unsigned int) _1;
  _3 = _5(D)->b;
  __builtin_memset (_3, 0, _2);
  __builtin_memset (_3, 0, _2); [tail call]
  return;

}



;; Function copy_var (copy_var, funcdef_no=3, decl_uid=1806, cgraph_uid=3,
symbol_order=3)

copy_var (struct S * s)
{
  unsigned int _1;
  long unsigned int _2;
  char[32] * _3;
  char[0:] * _4;

   [100.00%]:
  _1 = s_6(D)->n;
  _2 = (long unsigned int) _1;
  _3 = _6(D)->a;
  _4 = _6(D)->b;
  __builtin_memcpy (_4, _3, _2);
  __builtin_memcpy (_4, _3, _2); [tail call]
  return;

}

[Bug c++/80943] New: Conversion function selected in list-initialization in C++1z mode

[barry.revzin at gmail dot com]

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

Bug ID: 80943
   Summary: Conversion function selected in list-initialization in
C++1z mode
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider this example:

#include 

struct S;

struct T { 
T() = default;
T(S const& ) { std::cout << "1\n"; }
};

struct S { 
operator T() { std::cout << "2\n"; return T{}; }
};

int main() {
S s;
T t{s};
}

gcc 7.1 in C++1z mode prints 2. But it should print 1 (as it does in C++11/4
modes), as list-initialization doesn't consider conversion functions.

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[wschmidt at gcc dot gnu.org]

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

--- Comment #24 from Bill Schmidt  ---
Sadly, no.  This continues to be a problem on r248791.

[Bug tree-optimization/80933] redundant bzero/bcopy calls not eliminated

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
There is so much special handling of all these built-ins in so many places that
makes keeping them all in sync with one another tricky business.  I think it
would help if more of the salient properties of the major built-ins were
abstracted into general attributes and the handling code simplified to test for
the attributes instead.  For instance, if there were a helper, say 'bool
is_call_bzero_like_p (gimple *)' then code similar to this (tree-ssa-sccvn.c)

  if (((gimple_call_builtin_p (def_stmt, BUILT_IN_MEMSET))
   && integer_zerop (gimple_call_arg (def_stmt, 1))
   && tree_fits_uhwi_p (gimple_call_arg (def_stmt, 2)))
  || gimple_call_builtin_p (def_stmt, BUILT_IN_BZERO))

(that's currently missing the the BUILT_IN_BZERO test) could call
is_call_bzero_like_p(call) instead, and would handle not just these two
built-ins but any other built-in or user-defined function decorated with the
same attributes.

Transforming bzero() into memset(0) would get around the problem in the case
oif these two but not all equivalent built-ins can be easily transformed
without making compromises.  For example, transforming mempcpy to memcpy is
probably not a good approach to dealing with the problem.

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[wschmidt at gcc dot gnu.org]

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

--- Comment #23 from Bill Schmidt  ---
Testing now...

[Bug c/80942] New: -Woverlength-strings should no longer be implied by -Wpedantic

[vincent-gcc at vinc17 dot net]

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

Bug ID: 80942
   Summary: -Woverlength-strings should no longer be implied by
-Wpedantic
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

According to various messages in the following discussion:

  https://gcc.gnu.org/ml/gcc-help/2017-05/msg00208.html

the goal of -Wpedantic is not to check for strict ISO conformity and the
warnings implied by its use should not break some acceptable non-portable code
as allowed by the standard. In particular to avoid confusion, -Wpedantic should
no longer imply -Woverlength-strings.

Note also that -Woverlength-strings encourages to write unsafe code by
forbidding to use assert(expr) (or something equivalent) on potentially large
expressions (which may come from a succession of macro expansions, in
particular in C90 mode, where the implementation limit is ridiculously low)[*],
even though the program would be portable in practice.

[*] This happens in practice in the GNU MPFR code when full assertions are
enabled.

[Bug tree-optimization/80925] [8 Regression] vect peeling failures

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
The cost modeling doesn't explain failures on P6 and P7, I guess.  For P8 we
consider unaligned loads to be the same cost as aligned loads (this is a small
lie because of boundary-crossing costs, but these are much smaller than before
and amortized across a sequence of loads).  Prior to P8 there is a heavy
penalty in the cost model for using unaligned loads, so the P6/P7 failures are
still unexpected.

[Bug web/80941] New: Broken bookmarks on GCC internals PDF available online

[sebastian.peryt at intel dot com]

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

Bug ID: 80941
   Summary: Broken bookmarks on GCC internals PDF available online
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.peryt at intel dot com
  Target Milestone: ---

There is possible bug present in GCC internals documentation PDF file present
on GCC website under: https://gcc.gnu.org/onlinedocs/gccint.pdf

Whether document has been downloaded or is browsed online two bookmarks appear
to be broken:

- Machine  Descriptions
- Constraints for Particular Machines under Machine Descriptions -> Operand
Constraints

Whichever bookmark is pressed it jumps to the beginning of the document (when
PDF has been downloaded or on IE) or stays where it is (on Chrome). This bug is
present in current version as well as in 7.1.0
(https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gccint.pdf), but not in docs build
from sources using make pdf.

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail||7.1.0

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

[Bug tree-optimization/80933] redundant bzero/bcopy calls not eliminated

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
No we don't - we expand it as it were memset.  But yes, we should canonicalize
it so as well (the call to bzero is shorter with -Os, but I guess that doesn't
really matter).

[Bug rtl-optimization/80930] REE pass causes high memory usage via df_mir_alloc() with ASAN+UBSAN turned on

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||memory-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-01
  Component|middle-end  |rtl-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
#3  0x00c8d454 in df_analyze_problem (n_blocks=299166,
postorder=0x17168b2e0, blocks_to_consider=, dflow=0x16b830fb0)
at ../../gcc/df-core.c:1165
^^^

so it looks like the MIR probem is quadratic somehow (well, I can easily see
that it is, if sth is must-initialized in BB N then it is must-initialized in
all post-dominators).  REE should cap itself on some reasonably large
n_blocks * number_of_pseudos, at least at -O1 (which we recommend to
insanely large code bases).

Or it should work on sub-CFGs or simply only disable the cases that absoultely
need MIR info if the problem gets too large.

Confirmed by virtue of looking even w/o a testcase.

[Bug c++/57891] No diagnostic of narrowing conversion in non-type template argument

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||akrzemi1 at gmail dot com

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

[Bug c++/70500] Template deduction should fail on narrowing conversion

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
I think this is the same as PR 57891

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

[Bug libstdc++/80940] New: Private inheritance from std::ostream - compilation error for custom operator <

[witosx at gmail dot com]

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

Bug ID: 80940
   Summary: Private inheritance from std::ostream - compilation
error for custom operator <<
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: witosx at gmail dot com
  Target Milestone: ---

Even though custom operator <<(const char*) is defined compilation fails due to
the implementation of std::__is_convertible_to_basic_ostream trait. This breaks
code that compiled fine until libstdc++ 7.x




#include 

// Simple class uses private inheritance from std::ostream

class MyStream : private std::ostream
{
public:
MyStream& operator <<(const char*)
{
return *this;
}
};

int main()
{
MyStream stream{};
stream << "aaa"; // error in this line
}




/usr/include/c++/7.1.1/ostream: In instantiation of ‘struct
std::__is_convertible_to_basic_ostream’:
/usr/include/c++/7.1.1/ostream:656:5:   required by substitution of
‘template typename
std::enable_if >,
std::__is_convertible_to_basic_ostream<_Ostream>,
std::__is_insertable<_Ostream&, const _Tp&, void> >::value, typename
std::__is_convertible_to_basic_ostream<_Tp>::ostream_type>::type
std::operator<<(_Ostream&&, const _Tp&) [with _Ostream = MyStream&; _Tp = char
[4]]’
ls.cpp:40:15:   required from here
/usr/include/c++/7.1.1/ostream:625:23: error: ‘std::basic_ostream’ is an
inaccessible base of ‘MyStream’
   decltype(__check(declval::type*>()));
~~~^~
/usr/include/c++/7.1.1/ostream:625:23: error: ‘std::basic_ostream’ is an
inaccessible base of ‘MyStream’




The problem lies in   

  template
struct __is_convertible_to_basic_ostream
  {

// !!! compiler picks this version of __check and fails !!!

template
static basic_ostream<_Ch, _Up>& __check(basic_ostream<_Ch, _Up>*);

static void __check(...);

...
  };



Something like this works for me:

  template
  void __is_convertible_to_basic_ostream_test(basic_ostream<_Ch, _Up>*);

  template>
  struct __is_convertible_to_basic_ostream : false_type {};

  template
  struct __is_convertible_to_basic_ostream<_Tp,
void_t()))>> : true_type {};




$ gcc -v :(
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/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
Thread model: posix
gcc version 7.1.1 20170516 (GCC)

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[jamborm at gcc dot gnu.org]

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

--- Comment #22 from Martin Jambor  ---
So, PR 80898 is now fixed.  Can you please check if this is perhaps a
duplicate?  It may as well be.

[Bug tree-optimization/80898] [8 Regression] wrong code at -O2 and -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Jambor  ---
And indeed that was the case.  I have posted an updated patch with an
additional testcase to the mailing list as:

https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00028.html

Because Richi, promptly approved it, I have committed it straight away
and this is now fixed.

[Bug tree-optimization/80898] [8 Regression] wrong code at -O2 and -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  ---
Author: jamborm
Date: Thu Jun  1 12:14:29 2017
New Revision: 248790

URL: https://gcc.gnu.org/viewcvs?rev=248790=gcc=rev
Log:
[PR 80898] Propagate grp_write from disqualified SRA candidates

2017-06-01  Martin Jambor  

PR tree-optimization/80898
* tree-sra.c (process_subtree_disqualification): Removed.
(disqualify_candidate): Do not acll
process_subtree_disqualification.
(subtree_mark_written_and_enqueue): New function.
(propagate_all_subaccesses): Set grp_write of LHS subtree if the
RHS has been disqualified and re-queue LHS if necessary.  Apart
from that, ignore disqualified RHS.

testsuite/
* gcc.dg/tree-ssa/pr80898.c: New test.
* gcc.dg/tree-ssa/pr80898-2.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr80898-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr80898.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug c++/65043] Expected narrowing conversion during list initialization of bool from double

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-01
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Clang does now:

narrow.cc:9:9: error: type 'double' cannot be narrowed to 'bool' in initializer
list [-Wc++11-narrowing]
X x{d};
^
narrow.cc:9:9: note: insert an explicit cast to silence this issue
X x{d};
^
static_cast( )
1 error generated.


And EDG gives:

"narrow.cc", line 9: error: invalid narrowing conversion from "double" to
  "bool"
  X x{d};
  ^

1 error detected in the compilation of "narrow.cc".

[Bug c++/80691] Narrowing conversion in {} allowed in a SFINAE context

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
N.B. Bug 78244 is similar, and not restricted to C++17.

[Bug c++/80737] variant as class member resulting to compile errors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-01
   Target Milestone|--- |7.2
 Ever confirmed|0   |1

[Bug c++/80812] [8 Regression] ICE: in build_value_init_noctor, at cp/init.c:483

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #5 from Ville Voutilainen  ---
Fixed.

[Bug c++/80812] [8 Regression] ICE: in build_value_init_noctor, at cp/init.c:483

[ville at gcc dot gnu.org]

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

--- Comment #4 from ville at gcc dot gnu.org ---
Author: ville
Date: Thu Jun  1 11:09:41 2017
New Revision: 248788

URL: https://gcc.gnu.org/viewcvs?rev=248788=gcc=rev
Log:
PR c++/80812

cp/

PR c++/80812
* method.c (constructible_expr): Strip array types before calling
build_value_init.

libstdc++/

PR c++/80812
* testsuite/20_util/is_constructible/80812.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/is_constructible/80812.cc
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c

[Bug ada/80921] cross compiling fails to build Ada shared libraries

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #12 from Eric Botcazou  ---
Fixed for 6.4 and later releases.

[Bug ada/80921] cross compiling fails to build Ada shared libraries

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Jun  1 10:52:29 2017
New Revision: 248787

URL: https://gcc.gnu.org/viewcvs?rev=248787=gcc=rev
Log:
PR ada/80921
* configure.ac (default_gnatlib_target): Remove bogus condition.
(have_getipinfo): Tweak.
* configure: Regenerate.

Modified:
branches/gcc-6-branch/libada/ChangeLog
branches/gcc-6-branch/libada/configure
branches/gcc-6-branch/libada/configure.ac

[Bug ada/80921] cross compiling fails to build Ada shared libraries

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Jun  1 10:51:50 2017
New Revision: 248786

URL: https://gcc.gnu.org/viewcvs?rev=248786=gcc=rev
Log:
PR ada/80921
* configure.ac (default_gnatlib_target): Remove bogus condition.
(have_getipinfo): Tweak.
* configure: Regenerate.

Modified:
branches/gcc-7-branch/libada/ChangeLog
branches/gcc-7-branch/libada/configure
branches/gcc-7-branch/libada/configure.ac

[Bug ada/80921] cross compiling fails to build Ada shared libraries

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Jun  1 10:51:15 2017
New Revision: 248785

URL: https://gcc.gnu.org/viewcvs?rev=248785=gcc=rev
Log:
PR ada/80921
* configure.ac (default_gnatlib_target): Remove bogus condition.
(have_getipinfo): Tweak.
* configure: Regenerate.

Modified:
trunk/libada/ChangeLog
trunk/libada/configure
trunk/libada/configure.ac

[Bug ada/80921] cross compiling fails to build Ada shared libraries

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
> Looking in the build log, (i.e. output from 'make 2>&1 | tee build.log'), I
> now see the commands which create these DLLs; in both cases, they invoke:
> 
> mingw32-gcc -shared -shared-libgcc ...
> 
> which is correct, (although -static-libgcc may be safer);

No, -static-libgcc will break exception handling here.

[Bug ada/80921] cross compiling fails to build Ada shared libraries

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
> With that in place, a clean configure and build does now produce:
> 
> gcc/ada/rts/libgnarl-6.dll
> gcc/ada/rts/libgnat-6.dll
> 
> but there are no accompanying import libraries, (as there are for other
> DLLs, produced for other languages in the GCC suite).  Definitely an
> improvement, but perhaps not quite the entire solution.

Thanks for the feedback.  The Ada compiler doesn't use libtool to build its
library so that's as expected (and import libraries are obsolete these days).

[Bug c++/80896] [[nodiscard]] is ignored for functions returning references

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Jun  1 10:20:27 2017
New Revision: 248784

URL: https://gcc.gnu.org/viewcvs?rev=248784=gcc=rev
Log:
/cp
2017-06-01  Paolo Carlini  

PR c++/80896
* cvt.c (convert_to_void): Possibly call maybe_warn_nodiscard
for case INDIRECT_REF too in the main switch.

/testsuite
2017-06-01  Paolo Carlini  

PR c++/80896
* g++.dg/cpp1z/nodiscard5.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/nodiscard5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cvt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/80896] [[nodiscard]] is ignored for functions returning references

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
   Target Milestone|--- |8.0

--- Comment #3 from Paolo Carlini  ---
Fixed.

[Bug sanitizer/80932] UBSAN: false positive as a result of distribution: c1*(c2*v1-c3*v2)=>c1*c2*v1-c1*c3*v2

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-01
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  I'll take a look.

[Bug fortran/77420] [5/6/7 Regression] gfortran and equivalence produces internal compiler error

[m...@rolf-sander.net]

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

--- Comment #11 from Rolf Sander  ---
OK. Thanks for the explanations!

[Bug fortran/77420] [5/6/7 Regression] gfortran and equivalence produces internal compiler error

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
> The status says "RESOLVED FIXED", what does this mean?

It means that the gfortran maintainer has done his job.

> When will the bug fix be applied?

On the trees after the dates and revisions in comments 6 and 8 if you do your
own builds. Then it has to propagate to the releases, which is the case for
6.3.0 and 7.1.0, but not for 5.4.0. It will be fixed in 5.5.0 expected soon (it
will be the last supported release).

> I'm using Linux Mint 18, and so far there was no new version
> in the update manager :-(

I suggest you update your gfortran to at least 6.3 or better 7.1.

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[daniel.santos at pobox dot com]

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

--- Comment #21 from Daniel Santos  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #20)
> > failures, but if you call dg-runtest, you are using gcc's hack-daptation of
> > parallelization.  However, your patch doesn't remove *my* hack-daptation of
> > parallelization, so we end up with two different parallelization schemes 
> > that
> > step on each other's toes.
> >
> > Another problem with the already present parallelization is that it bunches
> > tests into groups of 10 per job which will perform very poorly for these 
> > tests.
> >
> > (https://github.com/gcc-mirror/gcc/blob/master/gcc/testsuite/lib/gcc-defs.exp#L170).
> >  I presume this is to reduce disk I/O and it makes sense from that 
> > standpoint
> > (I don't want to know what it would take to get a ramdisk/tmpfs in a
> > platform-neutral fashion.)
> 
> My basic point still stands: running your ms-sysv tests sequentially
> takes just a few minutes even on an old and (by today's standards) slow
> CPU, so there's absolutely no point investing lots of effort and
> complexity to parallelize what already runs adequately fast sequentially!

There is plenty of point!  It may be fast without --enable-checking=rtl, but
it's very slow with it.  A very large portion of my development lifecycle was
spent waiting for tests to run.  Using --enable-checking=rtl caught SO many
errors that didn't (or might not have) cause an ICE without it.

Now at the time, all I had was a phenom and when I had more than 64 tests run
in a single function it was very slow (I presume due to thrashing the data
cache) which is the reason the generator splits the tests out into multiple
functions that run 64 tests each.  I have a nice quad i7 now, so it's going
faster.  But one thing I hadn't gotten back to yet was adding more extensive
tests using features and optimizations that effect the stack (-fsplit-stack,
-pg, etc.).


> > However, I'm learning a little more about how the test harness works, and it
> > MAY be possible to call gcc_parallel_test_enable 0 at the start of 
> > ms-sysv.exp
> > and be able to use all of the built-in dg-runtest, et. al. functions!  If I 
> > can
> > get this to work (and not break something else in the process), then we may 
> > be
> > on to a pathway to clean up ms-sysv.exp a little bit -- that is except for a
> > few outstanding (possibly surmountable) issues:
> >
> > 1.) Can the default time-out of 5 minutes be changed?  I need 20 minutes for
> > the slowest processors and a whole HOUR when full tests are enabled.
> 
> Sure it can: for one there are dg-timeout (and preferably dg-timeout
> factor) per testcase.  I still wonder why you'd need that, though: if
> all your tests together take no more than a few minutes, why would you
> need to increase the timeout at all?  Which processor would this be that
> takes 20 minutes or even an hour to run the tests *and complete all
> other tests well within the five minute timeout*?

Thanks for that!  I *may* have a better solution (described below).  But the 5
minute timeout even happens on my new i7 when --enable-checking=rtl is on.

> In fact, every test that takes more than about a minute on a resonably
> current CPU is frowned upon because under parallel testing/load such
> tests tend to run into the timeout.

The time is taken during compilation and also during linking when -flto is used
(again, with rtl checking).

> If your tests regularly exceed the timeout, there's something wrong with
> them: you need to split the so individual tests complete within the
> minute just mentioned.

Hah! That is actually the direction I had decided to go and have been testing
it the last few days. :)  However, they can still run longer than 1 minute
(with rtl checking).  I can split them apart even further with a few changes to
the code generator.

> If really necessary in a setup, it is possible to set
> board_info(unix,gcc,timeout) in a global site.exp file, e.g. to deal
> with really slow/ancient systems.  This would be necessary without your
> test anyway.
> 
> > 2.) The test description should include the generator flags and not just the
> > CFLAGS.  Is that possible from dg-runtest, et. al.?  I suppose it's always
> > possible to add them to CFLAGS with -DGEN_FLAGS="-p0-12" as a hack.
> 
> That's a requirement actually: the summary lines for different runs of a
> test must differ so you can tell them apart if one of them fails.  How
> this is done in the end is primarily a cosmetic issue, though.

I seem to have worked this out, although I have to do a regsub to replace
spaces in the generator_args with an escaped space and it prints a little ugly,
but at least it works.

set escaped_generator_args [regsub -all " " $generator_args "\\ "]
set cflags "$cflags\"-DGEN_ARGS=$escaped_generator_args\""

> > I guess you can see why I said that I was "semi-content" to leave it like it
> > is. :)  But I'm also glad to better understand how the 

[Bug fortran/80931] ICE on move_alloc in gimplify_expr, at gimplify.c:11335

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-01
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, started with GCC 4.9.0.

[Bug fortran/77420] [5/6/7 Regression] gfortran and equivalence produces internal compiler error

[m...@rolf-sander.net]

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

--- Comment #9 from Rolf Sander  ---
The status says "RESOLVED FIXED", what does this mean? When will the bug fix be
applied? I'm using Linux Mint 18, and so far there was no new version in the
update manager :-(

[Bug ada/80921] Cross compiling for mingw32 target fails to build Ada shared libraries

[keith.marshall at mailinator dot com]

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

--- Comment #6 from Keith Marshall  ---
(In reply to Keith Marshall from comment #5)
> ... a clean configure and build does now produce:
> 
> gcc/ada/rts/libgnarl-6.dll
> gcc/ada/rts/libgnat-6.dll
> 
> but there are no accompanying import libraries, (as there are for other
> DLLs, produced for other languages in the GCC suite).  Definitely an
> improvement, but perhaps not quite the entire solution.

Looking in the build log, (i.e. output from 'make 2>&1 | tee build.log'), I now
see the commands which create these DLLs; in both cases, they invoke:

mingw32-gcc -shared -shared-libgcc ...

which is correct, (although -static-libgcc may be safer); however, both
commands also include the -Wl,-soname, linker option, which is wrong. 
AIUI, that option is applicable only for building ELF shared objects, but we
are creating a PECOFF shared object; in this case, the preferred option would
be the PECOFF linker's -Wl,--out-implib, option, (and we would
typically omit the DLL version suffix), such that we would produce:

gcc/ada/rts/libgnarl.dll.a
gcc/ada/rts/libgnat.dll.a

to accompany:

gcc/ada/rts/libgnarl-6.dll
gcc/ada/rts/libgnat-6.dll

[Bug tree-optimization/80925] [8 Regression] vect peeling failures

[rdapp at linux dot vnet.ibm.com]

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

--- Comment #7 from rdapp at linux dot vnet.ibm.com ---
I could reproduce the fails on a power8 machine now.
Looking at the vect-28.c FAIL now - the loop to be vectorized is:

  for (i = 0; i < N; i++)
{
  ia[i+off] = 5;
}

It still gets vectorized but not peeled anymore because the costs for no
peeling equal the costs for peeling (for unknown alignment).  Costs for an
unaligned store are the same (1) as for a regular store so this is to be
expected.

At first sight, the situation is similar for vect-87.c, vect-88.c and maybe
most of the fails with '"Vectorizing an unaligned access" 0'.

How should we deal with this?  If the cost function is correct as it is and
unaligned stores are not slower at all, I don't think we should be peeling. 
What is expected for real workloads and unaligned loads/stores?

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Biener  ---
Author: rguenth
Date: Thu Jun  1 08:05:24 2017
New Revision: 248771

URL: https://gcc.gnu.org/viewcvs?rev=248771=gcc=rev
Log:
2017-06-01  Richard Biener  

PR middle-end/66313
* fold-const.c (fold_plusminus_mult_expr): If the factored
factor may be zero use a wrapping type for the inner operation.
* tree-tailcall.c (independent_of_stmt_p): Pass in to_move bitmap
and handle moved defs.
(process_assignment): Properly guard the unary op case.  Return a
tri-state indicating that moving the stmt before the call may allow
to continue.  Pass through to_move.
(find_tail_calls): Handle moving unrelated defs before
the call.

* c-c++-common/ubsan/pr66313.c: New testcase.
* gcc.dg/tree-ssa/loop-15.c: Adjust.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr66313.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-15.c
trunk/gcc/tree-tailcall.c

[Bug libstdc++/80939] New: Various helper function templates in incorrectly marked constexpr

[rs2740 at gmail dot com]

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

Bug ID: 80939
   Summary: Various helper function templates in 
incorrectly marked constexpr
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

No specialization of the following helper function templates can meet the
constexpr function requirements, and therefore they should not be marked
constexpr:

__erased_ctor (contains a new-expression)
__erased_dtor (evaluates either a pseudodestructor call or an actual destructor
call, which is a call to a non-constexpr function)

The following are technically valid - because __ref_cast is subject to ADL -
but in reality can never be constexpr anyway and so probably shouldn't be
marked constexpr:

__erased_assign
__erased_swap
__erased_hash