[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs

[yselkowi at redhat dot com]

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

--- Comment #5 from Yaakov Selkowitz  ---
Possible patch included in attachment 38505 for bug 71133.

[Bug libstdc++/71133] msp430-elf -mlarge FTBFS in libstdc++-v3

[yselkowi at redhat dot com]

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

--- Comment #1 from Yaakov Selkowitz  ---
Created attachment 38505
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38505=edit
Draft patch for 6.1

The results of this test are (so far) used only in the code that will later
fail to compile on <32-bit-pointer targets anyway (bug 71135).  There's
probably a much better way of doing this, but the attached patch seems to be a
workaround.

[Bug c/71157] New: -Wnull-dereference false alarm in wrong function

[eggert at gnu dot org]

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

Bug ID: 71157
   Summary: -Wnull-dereference false alarm in wrong function
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at gnu dot org
  Target Milestone: ---

Created attachment 38504
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38504=edit
preprocessed source code for emacs/lib-src/etags.c

I discovered this when compiling bleeding-edge GNU Emacs with GCC 6.1.0 on
x86-64. For the attached file e.i, the shell command:

gcc -O2 -S -Wnull-dereference e.i

issues the diagnostics:

e.i: In function 'Forth_words':
e.i:9690:10: warning: potential null pointer dereference [-Wnull-dereference]
   while (*cp != '\0' && !c_isspace (*cp))
  ^~~
e.i:9690:10: warning: potential null pointer dereference [-Wnull-dereference]
e.i:9690:10: warning: potential null pointer dereference [-Wnull-dereference]

I see three things wrong with these diagnostics. First, line 9690 is nowhere
near the function Forth_words. Second, I see no path to line 9690 in which its
pointer CP can possibly be null. Furthermore, CP is dereferenced only twice in
line 9690, so why are there three warnings?

[Bug fortran/70959] [6/7 Regression] Invalid type determination due to expression in a type declaration statement

[w.clodius at icloud dot com]

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

--- Comment #5 from William Clodius  ---
1. Maybe the placement of the warning is spurious, but is there any chance it
is actually assigning the type REAL(4) to e18?

2. It sounds as if the logic of arith.c is in an incorrect order. What should
be done is roughly?
Is this a parenthesized expression?
  If yes is the expression comma deliminated?
If yes is it a single comma delimination?
  If yes is the first part REAL(4)?
If yes is the second part REAL(4)?
  If yes then it is a COMPLEX(8) expression
Else the parts are inconsistent in type and might be recognized as an
extension
  Else if no is the first part REAL(8)?
If yes then is the second part REAL(8) expression
  If yes then it is a COMPLEX(16) expression
Else the parts are inconsistent in type and might be recognized as an
extension
  Else is the first part another type you want to allow as an extension
...
   Else is it a multi comma deliminated expression?
 if yes then a syntax error, unrecognized expression
   Else it is a scalar expression of the type of the "first" expression

3. By the above if it mistakenly recognizing a complex constant  I would expect
it
   to be to a OMPLEX(16) constant. The message reads as if it might be
converting
   the INTEGER(8) to REAL(8) then deciding that it is part of a COMPLEX(8)
constant.

[Bug preprocessor/69665] Internal error on #pragma push_macro("__FILE__")

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
  Known to fail||4.9.3, 5.3.0, 6.1.0

--- Comment #2 from Martin Sebor  ---
I hit Save Changes prematurely.  Confirmed with all recent versions of GCC
including today's top of trunk (7.0).  The test case looks invalid though
(programs likely shouldn't be allowed to redefine __FILE__ or other standard
predefined macros).

[Bug preprocessor/69665] Internal error on #pragma push_macro("__FILE__")

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-17
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.0

--- Comment #1 from Martin Sebor  ---

$ cat uu.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -c
-Wall -Wextra -Wpedantic uu.c
#pragma push_macro  ("__FILE__")
#define __FILE__ "foobar.c"
#pragma pop_macro ("__FILE__")
uu.c:1:33: internal compiler error: invalid hash type 1 in cpp_macro_definition
 #pragma push_macro  ("__FILE__")
 ^
0x856ad9 c_cpp_error(cpp_reader*, int, int, rich_location*, char const*,
__va_list_tag (*) [1])
/src/gcc-svn/gcc/c-family/c-common.c:10232
0x18ccc54 cpp_diagnostic
/src/gcc-svn/libcpp/errors.c:61
0x18ccd26 cpp_error(cpp_reader*, int, char const*, ...)
/src/gcc-svn/libcpp/errors.c:76
0x18e716e cpp_macro_definition(cpp_reader*, cpp_hashnode*)
/src/gcc-svn/libcpp/macro.c:3352
0x18c9b4e do_pragma_push_macro
/src/gcc-svn/libcpp/directives.c:1542
0x18c9760 do_pragma
/src/gcc-svn/libcpp/directives.c:1457
0x18c79e4 _cpp_handle_directive
/src/gcc-svn/libcpp/directives.c:510
0x18dab37 _cpp_lex_token
/src/gcc-svn/libcpp/lex.c:2214
0x18e52cf cpp_get_token_1
/src/gcc-svn/libcpp/macro.c:2458
0x18e5719 cpp_get_token_with_location(cpp_reader*, unsigned int*)
/src/gcc-svn/libcpp/macro.c:2644
0x87281a c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
/src/gcc-svn/gcc/c-family/c-lex.c:398
0x7d86ce c_lex_one_token
/src/gcc-svn/gcc/c/c-parser.c:274
0x7d8add c_parser_peek_token
/src/gcc-svn/gcc/c/c-parser.c:455
0x80c026 c_parse_file()
/src/gcc-svn/gcc/c/c-parser.c:17903
0x87e56c c_common_parse_file()
/src/gcc-svn/gcc/c-family/c-opts.c:1064
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs

[yselkowi at redhat dot com]

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

--- Comment #4 from Yaakov Selkowitz  ---
(In reply to Yaakov Selkowitz from comment #3)
> It seems that #define _GLIBCXX_USE_WEAK_REF 1 would fix this; the question
> is where exactly it should go (config/os/generic/os_defines.h ?) and under
> what conditions.

Sorry, that should be #define _GLIBCXX_USE_WEAK_REF 0 and (due to
--with-newlib) in config/os/newlib/os_defines.h (which is already defined
inside an ifdef __CYGWIN__ block).

[Bug fortran/71156] New: PURE interface/definition inconsistency: accepts invalid, rejects valid

[damian at sourceryinstitute dot org]

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

Bug ID: 71156
   Summary: PURE interface/definition inconsistency: accepts
invalid, rejects valid
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

As shown below, gfortran 6.1.0 rejects the application of the PURE attribute
consistently in a procedure interface body and the corresponding procedure
definition. 
Conversely, gfortran accepts the inconsistent approach (not shown) of using
PURE in the interface body but omitting PURE from the procedure definition.  By
contrast, the Cray and Intel compilers behave opposite to gfortran: Intel and
Cray accept the consistent syntax below and reject the inconsistent syntax in
which PURE appears only in the interface body or only in the definition.  If
Intel and Cray are correct, then gfortran is accepting invalid code and
rejecting the complementary valid code and it would be great if a fix could be
applied to the 6 and 7 branches.

$ cat consistency.f90 
module my_interface
  implicit none
  interface
pure module subroutine f
end subroutine
  end interface
end module 

submodule(my_interface) my_implementation
  implicit none
contains
pure module subroutine f
end subroutine
end submodule

$ gfortran -c consistency.f90 
consistency.f90:12:28:

 pure module subroutine f
1
Error: Duplicate PURE attribute specified at (1)

$ gfortran --version
GNU Fortran (MacPorts gcc6 6.1.0_0) 6.1.0

[Bug c++/70979] [C++14] g++ falsely accepts constexpr function returning a lambda

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Including the following test case from the duplicate bug 71116 (which is
expected to pass in C+++ 14 and prior):

$ cat uu.cpp && /home/msebor/build/gcc-fortify-source/gcc/xgcc
-B/home/msebor/build/gcc-fortify-source/gcc -S uu.cpp
void oops () {
  auto fn = []{ };
  static_assert (!__is_literal_type (decltype (fn)), "oops");
}


uu.cpp: In function ‘void oops()’:
uu.cpp:3:3: error: static assertion failed: oops
   static_assert (!__is_literal_type (decltype (fn)), "oops");
   ^

[Bug libstdc++/71108] to_string is relatively slow

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  ---
(In reply to Adrian Wielgosik from comment #0)
> For example, this function is 3-7x faster than 6.1 std::to_string(unsigned
> int) in a microbenchmark.

https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html

[Bug c++/70979] [C++14] g++ falsely accepts constexpr function returning a lambda

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||eric.niebler at gmail dot com

--- Comment #3 from Martin Sebor  ---
*** Bug 71116 has been marked as a duplicate of this bug. ***

[Bug c++/71116] Lambdas should not be literal types

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Last reconfirmed||2016-5-16
 CC||msebor at gcc dot gnu.org
 Resolution|--- |DUPLICATE
  Known to fail||4.9.3, 5.3.0, 6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed with all supported versions of GCC as well as today's trunk of 7.0. 
A slightly simplified test case independent of libstdc++:

$ cat uu.cpp && /home/msebor/build/gcc-fortify-source/gcc/xgcc
-B/home/msebor/build/gcc-fortify-source/gcc -S uu.cpp
void oops () {
  auto fn = []{ };
  static_assert (!__is_literal_type (decltype (fn)), "oops");
}


uu.cpp: In function ‘void oops()’:
uu.cpp:3:3: error: static assertion failed: oops
   static_assert (!__is_literal_type (decltype (fn)), "oops");
   ^

I think this needs to be fixed in tandem with bug 70979 and so is probably
simplest to treat it as a duplicate.

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

[Bug c/71152] NULL is not cast to (void *) as it ought to be if compiling code with -c

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Sorry, I didn't finish the sentence: ...please attach the complete preprocessor
output on the off change that the NULL macro isn't expanded to (void*)0 for
some reason.

[Bug c/71152] NULL is not cast to (void *) as it ought to be if compiling code with -c

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #3 from Martin Sebor  ---
I'm not able to reproduce this with either 6.1 or the current trunk, or find an
older revision that fails to give the warning.  I would suggest opening a bug
against the Fedora GCC (please att

[Bug middle-end/71155] New: symbol in wrong section .data.rel.local on mips64el

[aurelien at aurel32 dot net]

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

Bug ID: 71155
   Summary: symbol in wrong section .data.rel.local on mips64el
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---
  Host: mips64el-linux-gnuabi64
Target: mips64el-linux-gnuabi64
 Build: mips64el-linux-gnuabi64

Created attachment 38503
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38503=edit
preprocessed source file

When compiling the GNU libc on mips64el-linux-gnuabi64 with GCC >= 4.9, the
resulting libc causes lua 5.2 to not work correcty. It happens this is due to
wrong the compilation of libio/oldstdfiles.c. When using GCC <= 4.8, the
_IO_stdin_ symbol ends up in the data.rel section just like _IO_stdout_ and
_IO_stderr_. When using GCC >= 4.9, the _IO_stdin_ symbol is moved to the
.data.rel.local section, while the two others are unchanged.

This is also reproducible with GCC 5 and GCC 6.

The issue seems to have been introduced by the following patch:
https://gcc.gnu.org/ml/gcc-patches/2014-01/msg01169.html

I have attached the preprocessed source file, the original source file can be
found there:
https://sourceware.org/git/?p=glibc.git;a=blob;f=libio/oldstdfiles.c;h=609b7d9ef2d78f851a29b3d25efbb03f9c76ca91;hb=HEAD

[Bug target/71153] aarch64 LSE __atomic_fetch_and() generates inversion for constants

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
The other way of fixing this is to expose the NOT in RTL before register
allocator.  That is harder but still doable.

[Bug target/71153] aarch64 __atomic_fetch_and() generates probably incorrect double inversion

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-16
 CC||pinskia at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
LDCLRL does MEM &= ~op.

LDCLR – atomic AND NOT (bitclear) of a location with value in a register, with
original data loaded into a register.
Applies to 8, 16, 32, 64 bits. Each instruction can have one of four possible
orderings - acquire, release,
acquire, no order, as it performs both a load and a store.

So the code is correct just not optimal.


Something like this should get the code back to optimal:
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 236c819..ad92f6a 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -11607,6 +11607,7 @@ aarch64_gen_atomic_ldop (enum rtx_code code, rtx
out_data, rtx out_result,
   aarch64_atomic_load_op_code ldop_code;
   rtx src;
   rtx x;
+  bool already_swapped = false;

   if (out_data)
 out_data = gen_lowpart (mode, out_data);
@@ -11614,6 +11615,12 @@ aarch64_gen_atomic_ldop (enum rtx_code code, rtx
out_data, rtx out_result,
   if (out_result)
 out_result = gen_lowpart (mode, out_result);

+  if (code == AND && CONST_INT_P (value))
+{
+  value = simplify_gen_unary (NOT, mode, value, mode);
+  already_swapped = true;
+}
+
   /* Make sure the value is in a register, putting it into a destination
  register if it needs to be manipulated.  */
   if (!register_operand (value, mode)
@@ -11670,8 +11677,11 @@ aarch64_gen_atomic_ldop (enum rtx_code code, rtx
out_data, rtx out_result,
if (short_mode)
  src = gen_lowpart (wmode, src);

-   not_src = gen_rtx_NOT (wmode, src);
-   emit_insn (gen_rtx_SET (src, not_src));
+   if (!already_swapped)
+ {
+   not_src = gen_rtx_NOT (wmode, src);
+   emit_insn (gen_rtx_SET (src, not_src));
+ }

if (short_mode)
  src = gen_lowpart (mode, src);

[Bug c++/71154] Attributes for an explicit template instantiation are ignored

[abbeyj+gcc at gmail dot com]

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

--- Comment #1 from James Abbatiello  ---
Created attachment 38502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38502=edit
Too simple patch

[Bug c++/71154] New: Attributes for an explicit template instantiation are ignored

[abbeyj+gcc at gmail dot com]

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

Bug ID: 71154
   Summary: Attributes for an explicit template instantiation are
ignored
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abbeyj+gcc at gmail dot com
  Target Milestone: ---

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

Trying to apply attributes (like visibility("default")) to an explicit template
instantiation does not work if the type has been previously mentioned in the
translation unit.

This was previously reported as part of bug #50044.  But that bug was
eventually marked as a duplicate of bug #40068 which only seems to cover the
problem with typeinfo.  The part about the problem with attributes seems to
have been lost so I'm opening this bug to cover it.

STR:
==
$ cat main.cpp
template 
class C
{
void foo();
};

C g_c_int;
C g_c_double;

template 
void C::foo() {}

template class __attribute__((visibility("default"))) C;
template class C;


$ g++ -fvisibility=hidden -fPIC -shared main.cpp -o main.so
main.cpp:13:55: warning: type attributes ignored after type is already defined
[-Wattributes]
 template class __attribute__((visibility("default"))) C;
   ^~


$ nm -C main.so | grep foo
061c t C::foo()
0610 t C::foo()

==

Note that C::foo() is marked as local (lowercase t) when the intent was to
make it global (uppercase).  When compiled with clang++ instead there are no
warnings and nm reports:
0510 t C::foo()
0500 W C::foo()

where C::foo() is global as desired.

Similar code, with the __attribute__ replaced with __declspec(dllexport), works
as expected with MSVC 2012.  That is, C::foo() is exported from the DLL
and C::foo() is not.


I have a patch for this which I will attach.  It just removes the relevant
checks entirely.  This seems likely to cause problems elsewhere but perhaps it
gives somebody an idea on where to start.

[Bug target/71153] aarch64 __atomic_fetch_and() generates probably incorrect double inversion

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
(In reply to dhowe...@redhat.com from comment #0)
> ... If nothing else, the MOVN and MOV could be condensed into just a MOV. ...

The MOVN and the MVN could be condensed, that is.

[Bug target/71153] New: aarch64 __atomic_fetch_and() generates probably incorrect double inversion

[dhowells at redhat dot com]

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

Bug ID: 71153
   Summary: aarch64 __atomic_fetch_and() generates probably
incorrect double inversion
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Compiling this code:

static __always_inline
void clear_bit_unlock(long bit, volatile unsigned long *addr)
{
unsigned long mask = 1UL << (bit & (64 - 1));
addr += bit >> 6;
__atomic_fetch_and(addr, ~mask, __ATOMIC_RELEASE);
}

void bar_clear_bit_unlock(unsigned long *p)
{
clear_bit_unlock(22, p);
}

for aarch64-linux-gnu with "-march=armv8-a+lse -Os" generates a double negation
of the mask value in the assembly:

007c :
  7c:   92a00801mov x1, #0xffbf // #-4194305
  80:   aa2103e1mvn x1, x1
  84:   f8611001ldclrl  x1, x1, [x0]
  88:   d65f03c0ret

The instruction at 7c is loading an inverted value into x1 (it's actually a
MOVN instruction according to the opcode table that I can find); the value in
x1 is then inverted *again* by the MVN instruction.

Now, I can't find a description of how the LDCLRL instruction works, so I can't
say that it doesn't invert the parameter a third time (ie. apply an A AND-NOT B
operation), but it looks suspicious.  If nothing else, the MOVN and MOV could
be condensed into just a MOV.

If a parameter is used instead of a constant:

void foo_clear_bit_unlock(long bit, unsigned long *p)
{
clear_bit_unlock(bit, p);
}

then two MVN instructions are generated:

0048 :
  48:   12001403and w3, w0, #0x3f
  4c:   9346fc02asr x2, x0, #6
  50:   d2800020mov x0, #0x1// #1
  54:   8b020c21add x1, x1, x2, lsl #3
  58:   9ac32000lsl x0, x0, x3
  5c:   aa2003e0mvn x0, x0
  60:   aa2003e2mvn x2, x0
  64:   f8621022ldclrl  x2, x2, [x1]
  68:   d65f03c0ret

The C code appears to be correct, because on x86_64 it generates:

004c :
  4c:   f0 48 81 27 ff ff bflock andq $0xffbf,(%rdi)
  53:   ff 
  54:   c3  retq

[Bug libstdc++/11196] _GNU_SOURCE vs. M_PI

[j.v.dijk at tue dot nl]

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

Jan van Dijk  changed:

   What|Removed |Added

 CC||j.v.dijk at tue dot nl

--- Comment #10 from Jan van Dijk  ---
Has this been (partly) fixed in the meantime? The OP's test program compiles
just fine with:

  g++ (SUSE Linux) 4.8.3 20140627 [gcc-4_8-branch revision 212064]
  g++ (SUSE Linux) 5.3.1 20160412 [gcc-5-branch revision 234894]
  g++ (GCC) 7.0.0 20160516 (experimental)
  x86_64-w64-mingw32.shared-g++ (GCC) 4.9.3

I also see that GNU_SOURCE is no longer implicitly defined. At least, I do not
see that in the output of "g++ -dM -E - < /dev/null" anymore.

Are there any remaining issues, or should this report be closed?

[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090

[dominiq at lps dot ens.fr]

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

--- Comment #18 from Dominique d'Humieres  ---
> smoke test passes, I'll leave it to Dominique's full-run to confirm.

With the patch in comment 15 applied on top of revision r236286 the reported
failures are gone.

From the fix, would it be possible to derive a test failing on linux?

Also the test gcc.target/i386/pr70799-1.c fails

FAIL: gcc.target/i386/pr70799-1.c scan-assembler movdqa[ t]+.LC0

In the assembly I see

movdqa  LC0-L3$pb(%eax), %xmm0

with nothing between \t and L.

[Bug rtl-optimization/71150] [7 Regression] ICE on valid code at -O1 and above in 64-bit mode on x86_64-linux-gnu in lra_eliminate_reg_if_possible, at lra-eliminations.c:1402

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

 Target||i386*
 Status|NEW |ASSIGNED

--- Comment #2 from Jiong Wang  ---
r236181 was assuming SUBREG_REG (x) is a REG, but actually it might be not, at
least for i386. A simple new guard of REG_P check can fix this regression.

Will explore more to see what's the best fix and propose a patch shortly.

[Bug c/71152] NULL is not cast to (void *) as it ought to be if compiling code with -c

[rstrode at redhat dot com]

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

--- Comment #2 from Ray Strode  ---
this test case works as expected with gcc-5.3.1-6.fc23.x86_64

[Bug c++/71145] Alpha: Error: No lda !gpdisp!278 was found

[mcree at orcon dot net.nz]

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

--- Comment #3 from Michael Cree  ---
Created attachment 38500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38500=edit
compressed preprocessed source

Failing preprocessed source compressed with gzip; hopefully this goes through
okay.

[Bug c/71152] NULL is not cast to (void *) as it ought to be if compiling code with -c

[rstrode at redhat dot com]

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

--- Comment #1 from Ray Strode  ---
$ rpm -q gcc
gcc-6.0.0-0.20.fc25.x86_64

[Bug c/71152] New: NULL is not cast to (void *) as it ought to be if compiling code with -c

[rstrode at redhat dot com]

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

Bug ID: 71152
   Summary: NULL is not cast to (void *) as it ought to be if
compiling code with -c
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rstrode at redhat dot com
  Target Milestone: ---

Created attachment 38499
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38499=edit
small test case try compiling with -c and without

I was refactoring code in a project and moved some code off to a helper
function.
The helper function returns an integer error code and the main function returns
a pointer.

When I moved the error handling code over from the main function to the helper
function, I neglected to change the return code from NULL to -1.

gcc didn't warn about this.

So I wrote a quick test case (attached) and discovered something very strange.

gcc does warn if you compile and link the code in one step, i.e.:

$ gcc nulltest.c
nulltest.c: In function ‘NULL_as_int’:
nulltest.c:6:12: warning: return makes integer from pointer without a cast
[-Wint-conversion]
 return NULL;
^~~~
$ 


But if you pass -c to defer linking, the bug manifests:

$ gcc nulltest.c -c
$

[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs

[yselkowi at redhat dot com]

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

--- Comment #3 from Yaakov Selkowitz  ---
It seems that #define _GLIBCXX_USE_WEAK_REF 1 would fix this; the question is
where exactly it should go (config/os/generic/os_defines.h ?) and under what
conditions.

[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs

[yselkowi at redhat dot com]

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

--- Comment #2 from Yaakov Selkowitz  ---
(In reply to Jonathan Wakely from comment #1)
> I think we just want to disable TM library support for such targets.

Okay, h8300-elf and xstormy16-elf are both similarly affected.  msp430-elf
probably will be as well once configure works again (bug 71133).

[Bug bootstrap/70835] New: internal compiler error on libiberty/floatformat.c when bootstrapping 5.3.0 with 5.3.0

[LpSolit at netscape dot net]

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

Bug ID: 70835
   Summary: internal compiler error on libiberty/floatformat.c
when bootstrapping 5.3.0 with 5.3.0
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nunya223bidness at streetwisemail dot com
  Target Milestone: ---

../gcc-5.3.0/configure --prefix=/usr/local
--with-native-system-header-files=/opt/include:/volume1/mmt/x-tools/x86_64-unknown-linux-gnu/include
--enable-bootstrap --enable-lto --with-{gmp,mpc,mpfr,isl}=/usr/local
--with-gnu-ld --enable-twoprocess --enable-gather-detailed-mem-stats
--enable-multilib --enable-multiarch --enable-decimal-float=yes
--enable-fixed-point --enable-plugin --disable-dependency-tracking
--disable-nls --disable-canonical-system-headers --with-glibc-version=2.20
--without-cuda-driver --enable-languages=c,c++
--with-build-time-tools=/usr/local --with-build-libsubdir=lib CFLAGS="-v
-save-temps" ; make

[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
make[2]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
make[3]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
rm -f stage_current
make[3]: Leaving directory '/volume1/local/src/gcc-5.3.0-build'
make[2]: Leaving directory '/volume1/local/src/gcc-5.3.0-build'
make[2]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
make[3]: Entering directory '/volume1/local/src/gcc-5.3.0-build/libiberty'
if [ x"-fpic" != x ]; then \
  gcc -c -DHAVE_CONFIG_H -g  -I. -I../../gcc-5.3.0/libiberty/../include  -W
-Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fpic
../../gcc-5.3.0/libiberty/floatformat.c -o pic/floatformat.o; \
else true; fi
GNU MP: Cannot allocate memory (size=4611686018427387859)
../../gcc-5.3.0/libiberty/floatformat.c: In function 'floatformat_to_double':
../../gcc-5.3.0/libiberty/floatformat.c:529:2: internal compiler error: Aborted
  dto = ldexp (1.0, exponent);
  ^
0x9bed4f crash_signal
../../gcc-5.3.0/gcc/toplev.c:383
0x93c390 real_from_mpfr(real_value*, __mpfr_struct const*, tree_node*,
mpfr_rnd_t)
../../gcc-5.3.0/gcc/realmpfr.c:92
0x939b49 real_from_string(real_value*, char const*)
../../gcc-5.3.0/gcc/real.c:2073
0x93a3bc real_from_string3(real_value*, char const*, machine_mode)
../../gcc-5.3.0/gcc/real.c:2123
0x6576a3 interpret_float
../../gcc-5.3.0/gcc/c-family/c-lex.c:897
0x65834c c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
../../gcc-5.3.0/gcc/c-family/c-lex.c:442
0x602fef c_lex_one_token
../../gcc-5.3.0/gcc/c/c-parser.c:258
0x613d1a c_parser_peek_token
../../gcc-5.3.0/gcc/c/c-parser.c:440
0x613d1a c_parser_next_token_is
../../gcc-5.3.0/gcc/c/c-parser.c:452
0x613d1a c_parser_postfix_expression_after_primary
../../gcc-5.3.0/gcc/c/c-parser.c:7865
0x60e067 c_parser_postfix_expression
../../gcc-5.3.0/gcc/c/c-parser.c:7715
0x61031a c_parser_unary_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6602
0x610e8f c_parser_cast_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6440
0x611072 c_parser_binary_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6255
0x611ba5 c_parser_conditional_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6031
0x611ff0 c_parser_expr_no_commas
../../gcc-5.3.0/gcc/c/c-parser.c:5949
0x61206a c_parser_expr_no_commas
../../gcc-5.3.0/gcc/c/c-parser.c:5991
0x6124e2 c_parser_expression
../../gcc-5.3.0/gcc/c/c-parser.c:8022
0x612c99 c_parser_expression_conv
../../gcc-5.3.0/gcc/c/c-parser.c:8055
0x60c096 c_parser_statement_after_labels
../../gcc-5.3.0/gcc/c/c-parser.c:5115

sh-4.3# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/volume1/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.3.0/configure
--with-buildtime-tools=/volume1/mmt/x-tools/x86_64-unknown-linux-gnu/bin
--with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local
--with-isl=/usr/local --disable-multilib
--with-sysroot=/volume1/mmt/x-tools/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/sysroot
--enable-bootstrap --disable-lto
Thread model: posix
gcc version 5.3.0 (GCC) 

sh-4.3# uname -s -r -v -m -p -i -o
Linux 3.10.77 #7321 SMP Thu Apr 21 14:35:22 CST 2016 x86_64 unknown unknown
GNU/Linux

[Bug ipa/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments

[hubicka at ucw dot cz]

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

--- Comment #6 from Jan Hubicka  ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71146
> 
> --- Comment #5 from Marek Polacek  ---
> And of course I found it (I think) just after posting the previous commit:

Ah, thanks. It looks OK to me.  I was wondering if it is cleaner to split the
BB just to make the outer loop continue where it started or do something
smarter.
I wonder how we managed to redirect call within thunk to unreachable?

Honza

[Bug ipa/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
And of course I found it (I think) just after posting the previous commit:

--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -4486,6 +4486,7 @@ expand_call_inline (basic_block bb, gimple *stmt,
copy_body_data *id)
   update_stmt (stmt);
   id->src_node->remove ();
   expand_call_inline (bb, stmt, id);
+  maybe_remove_unused_call_args (cfun, stmt);
   return true;
 }
   fn = cg_edge->callee->decl;

[Bug target/71151] New: -fmerge-constants and -fdata-sections results in string constants in .progmem.gcc_sw section

[senthil.thecoder at gmail dot com]

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

Bug ID: 71151
   Summary: -fmerge-constants and -fdata-sections results in
string constants in .progmem.gcc_sw section
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: senthil.thecoder at gmail dot com
  Target Milestone: ---

Using -fdata-sections causes string literals in functions to go into
.progmem.sw_gcc, instead of .rodata.str. This is incorrect, since code using
them expects data memory addresses, not flash.

$ cat printf.c
extern void bar(const char*);
void foo(void)
{
  bar("BB");
}

$ avr-gcc -mmcu=atmega32u2 printf.c -S -Os -fdata-sections -ffunction-sections
$ cat printf.s
jaguar:~/scratch$ cat printf.s
.file   "printf.c"
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__SREG__ = 0x3f
__tmp_reg__ = 0
__zero_reg__ = 1
.section.progmem.gcc_sw_table.foo.str1.1,"aMS",@progbits,1
.LC0:
.string "BB"
.section.text.foo,"ax",@progbits
.global foo
.type   foo, @function
foo:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
ldi r24,lo8(.LC0)
ldi r25,hi8(.LC0)
jmp bar
.size   foo, .-foo
.ident  "GCC: (GNU) 6.1.0"


As the testcase shows, the string goes into progmem.gcc_sw_table..*,
and this gets placed in flash by the linker script. Reading from the address in
r25:24 will obviously not give the correct results - it will read from whatever
happens to be mapped at the same address in the data address space.

[Bug ipa/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
It would appear that we need to call maybe_remove_unused_call_args somewhere,
but so far haven't found the right spot...

[Bug tree-optimization/71149] missing modulo 2 optimization converting result to bool

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-16
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Most likely the opt needs to be moved from fold-const to match.pd .  Should
> be a simple patch.

Yes:
  /* If this is an NE or EQ comparison of zero against the result of a
 signed MOD operation whose second operand is a power of 2, make
 the MOD operation unsigned since it is simpler and equivalent.  */
  if (integer_zerop (arg1)
  && !TYPE_UNSIGNED (TREE_TYPE (arg0))
  && (TREE_CODE (arg0) == TRUNC_MOD_EXPR
  || TREE_CODE (arg0) == CEIL_MOD_EXPR
  || TREE_CODE (arg0) == FLOOR_MOD_EXPR
  || TREE_CODE (arg0) == ROUND_MOD_EXPR)
  && integer_pow2p (TREE_OPERAND (arg0, 1)))
{
  tree newtype = unsigned_type_for (TREE_TYPE (arg0));
  tree newmod = fold_build2_loc (loc, TREE_CODE (arg0), newtype,
 fold_convert_loc (loc, newtype,
   TREE_OPERAND (arg0, 0)),
 fold_convert_loc (loc, newtype,
   TREE_OPERAND (arg0,
1)));

  return fold_build2_loc (loc, code, type, newmod,
  fold_convert_loc (loc, newtype, arg1));
}


Something like:
(for mod (ceil_mod floor_mod round_mod trunc_mod)
 (for eqne (ne eq)
  (simplify (eqne (mod @1 integer_pow2p@2) integer_zerop)
   (if (!TYPE_UNSIGNED (TREE_TYPE (@1)))
(  

I am lazy to fill in the ... part right now but you get the idea.

[Bug rtl-optimization/71150] [7 Regression] ICE on valid code at -O1 and above in 64-bit mode on x86_64-linux-gnu in lra_eliminate_reg_if_possible, at lra-eliminations.c:1402

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-16
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|ICE on valid code at -O1|[7 Regression] ICE on valid
   |and above in 64-bit mode on |code at -O1 and above in
   |x86_64-linux-gnu in |64-bit mode on
   |lra_eliminate_reg_if_possib |x86_64-linux-gnu in
   |le, at  |lra_eliminate_reg_if_possib
   |lra-eliminations.c:1402 |le, at
   ||lra-eliminations.c:1402
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with:

commit 4fe01ba94e99e792ebe9da2ccb3b071aa1bac388
Author: jiwang 
Date:   Thu May 12 17:00:52 2016 +

[LRA] PR70904, relax the restriction on subreg reload for wide mode

2016-05-12  Jiong Wang  

gcc/
  PR rtl-optimization/70904
  * lra-constraint.c (process_addr_reg): Relax the restriction on
  subreg reload for wide mode.



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@236181
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug rtl-optimization/71150] New: ICE on valid code at -O1 and above in 64-bit mode on x86_64-linux-gnu in lra_eliminate_reg_if_possible, at lra-eliminations.c:1402

[su at cs dot ucdavis.edu]

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

Bug ID: 71150
   Summary: ICE on valid code at -O1 and above in 64-bit mode on
x86_64-linux-gnu in lra_eliminate_reg_if_possible, at
lra-eliminations.c:1402
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O1 and above on x86_64-linux-gnu in the 64-bit mode.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160516 (experimental) [trunk revision 236272] (GCC)
$
$ gcc-trunk -O0 -c small.c
$
$ gcc-trunk -O1 -c small.c
small.c: In function ‘fn2’:
small.c:11:1: internal compiler error: in lra_eliminate_reg_if_possible, at
lra-eliminations.c:1402
 }
 ^
0xa5d0fe lra_eliminate_reg_if_possible(rtx_def**)
../../gcc-source-trunk/gcc/lra-eliminations.c:1402
0xa4d9ee in_class_p
../../gcc-source-trunk/gcc/lra-constraints.c:266
0xa51031 process_addr_reg
../../gcc-source-trunk/gcc/lra-constraints.c:1320
0xa54b11 process_address_1
../../gcc-source-trunk/gcc/lra-constraints.c:2983
0xa55ce9 process_address
../../gcc-source-trunk/gcc/lra-constraints.c:3233
0xa55ce9 curr_insn_transform
../../gcc-source-trunk/gcc/lra-constraints.c:3534
0xa5a736 lra_constraints(bool)
../../gcc-source-trunk/gcc/lra-constraints.c:4530
0xa46484 lra(_IO_FILE*)
../../gcc-source-trunk/gcc/lra.c:2290
0x9fd839 do_reload
../../gcc-source-trunk/gcc/ira.c:5381
0x9fd839 execute
../../gcc-source-trunk/gcc/ira.c:5565
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$


--


long a;

void fn1 () {}

void
fn2 ()
{ 
  unsigned b = (unsigned long) fn1;
  if (a ^ b)
a--;
}

[Bug tree-optimization/71149] missing modulo 2 optimization converting result to bool

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Most likely the opt needs to be moved from fold-const to match.pd .  Should be
a simple patch.

[Bug tree-optimization/71149] New: missing modulo 2 optimization converting result to bool

[msebor at gcc dot gnu.org]

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

Bug ID: 71149
   Summary: missing modulo 2 optimization converting result to
bool
   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: ---

One would expect GCC to emit comparably efficient code for all three functions
below, but it only does so for odd_mod and odd_and but not for the equivalent
odd_mod_cvt function.  Clang emits the same optimal code for all three
functions.

$ cat xxx.cpp && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc
-Dbool=_Bool -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout -o/dev/null
-xc xxx.cpp
int odd_mod (int a) {
return (a % 2) != 0;
}

_Bool odd_mod_cvt (int a) {
return a % 2;
}

int odd_and (int a) {
return (a & 1) != 0;
}


;; Function odd_mod (odd_mod, funcdef_no=0, decl_uid=1745, cgraph_uid=0,
symbol_order=0)

odd_mod (int a)
{
  int _1;

  :
  _1 = a_4(D) & 1;
  return _1;

}



;; Function odd_mod_cvt (odd_mod_cvt, funcdef_no=1, decl_uid=1748,
cgraph_uid=1, symbol_order=1)

odd_mod_cvt (int a)
{
  int _1;
  _Bool _3;

  :
  _1 = a_2(D) % 2;
  _3 = _1 != 0;
  return _3;

}



;; Function odd_and (odd_and, funcdef_no=2, decl_uid=1751, cgraph_uid=2,
symbol_order=2)

odd_and (int a)
{
  int _1;

  :
  _1 = a_3(D) & 1;
  return _1;

}

[Bug hsa/70857] [6/7 Regression] ICE with -fopenmp -fopenacc in insert_vi_for_tree, at tree-ssa-structalias.c:2813

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Jambor  ---
Fixed.

[Bug hsa/70857] [6/7 Regression] ICE with -fopenmp -fopenacc in insert_vi_for_tree, at tree-ssa-structalias.c:2813

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  ---
Author: jamborm
Date: Mon May 16 15:57:06 2016
New Revision: 236292

URL: https://gcc.gnu.org/viewcvs?rev=236292=gcc=rev
Log:
[PR 70857] Copy RESULT_DECL of HSA outlined kernel function

2016-05-16  Martin Jambor  

PR hsa/70857
* omp-low.c (grid_expand_target_grid_body): Copy RESULT_DECL of
the outlined kernel function.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/omp-low.c

[Bug c++/71121] Spurious warning: "the address of [...] will never be NULL [-Waddress]"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-16
 CC||jason at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
  Known to work||5.3.0
 Blocks||55004
 Ever confirmed|0   |1
  Known to fail||6.1.0

--- Comment #1 from Martin Sebor  ---
Confirmed with 6.1.0 and today's top of trunk (7.0).  Both the auto and the
constexpr appear to be necessary to trigger the warning.  The regression
appears to have been introduced in r234940.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug hsa/70857] [6/7 Regression] ICE with -fopenmp -fopenacc in insert_vi_for_tree, at tree-ssa-structalias.c:2813

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  ---
Author: jamborm
Date: Mon May 16 15:40:30 2016
New Revision: 236291

URL: https://gcc.gnu.org/viewcvs?rev=236291=gcc=rev
Log:
[PR 70857] Copy RESULT_DECL of HSA outlined kernel function

2016-05-16  Martin Jambor  

PR hsa/70857
* omp-low.c (grid_expand_target_grid_body): Copy RESULT_DECL of
the outlined kernel function.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c

[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-16
 Ever confirmed|0   |1

[Bug libstdc++/71133] msp430-elf -mlarge FTBFS in libstdc++-v3

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-16
 CC||torvald at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||torvald at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
I think we just want to disable TM library support for such targets.

[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090

[iains at gcc dot gnu.org]

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

--- Comment #17 from Iain Sandoe  ---
smoke test passes, I'll leave it to Dominique's full-run to confirm.

[Bug driver/68463] Offloading fails when some objects are compiled with LTO and some without

[jnorris at gcc dot gnu.org]

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

--- Comment #7 from jnorris at gcc dot gnu.org ---
Author: jnorris
Date: Mon May 16 13:47:47 2016
New Revision: 236287

URL: https://gcc.gnu.org/viewcvs?rev=236287=gcc=rev
Log:
Backport from mainline r236098.
2016-05-10  James Norris  

PR driver/68463
* config/rs6000/sysv4.h (CRTOFFLOADBEGIN): Define. Add
crtoffloadbegin.o
if offloading is enabled and -fopenacc or -fopenmp is specified.
(CRTOFFLOADEND): Likewise.
(STARTFILE_LINUX_SPEC): Add CRTOFFLOADBEGIN.
(ENDFILE_LINUX_SPEC): Add CRTOFFLOADEND.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/sysv4.h

[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090

[ienkovich at gcc dot gnu.org]

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

--- Comment #16 from Ilya Enkovich  ---
(In reply to Iain Sandoe from comment #15)
> that code won't build - did you mean :
> 

Sure.  Thanks for noticing!

[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090

[iains at gcc dot gnu.org]

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

--- Comment #15 from Iain Sandoe  ---
(In reply to Dominique d'Humieres from comment #14)
> > Looks I found the problem.  validize_mem generates new instructions which
> > are placed wrongly.  This patch should help.  Unfortunately I can't test
> > it properly on Darwin.
> 
> Thanks for the feedback. I just started a clean regstrap, allow for ~6h+.

that code won't build - did you mean :

   if (!standard_sse_constant_p (vec_cst, V2DImode))
-   vec_cst = validize_mem (force_const_mem (V2DImode, vec_cst));
+   {
+ start_sequence ();
+ vec_cst = validize_mem (force_const_mem (V2DImode, vec_cst));
+ rtx_insn *seq = get_insns ();
+ end_sequence ();
+ emit_insn_before (seq, insn);
+   }

?

[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090

[dominiq at lps dot ens.fr]

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

--- Comment #14 from Dominique d'Humieres  ---
> Looks I found the problem.  validize_mem generates new instructions which
> are placed wrongly.  This patch should help.  Unfortunately I can't test
> it properly on Darwin.

Thanks for the feedback. I just started a clean regstrap, allow for ~6h+.

[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090

[ienkovich at gcc dot gnu.org]

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

--- Comment #13 from Ilya Enkovich  ---
Looks I found the problem.  validize_mem generates new instructions which are
placed wrongly.  This patch should help.  Unfortunately I can't test it
properly on Darwin.

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 046717b..5fdd12b 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3688,7 +3688,13 @@ dimode_scalar_chain::convert_op (rtx *op, rtx_insn
*insn)
gen_rtvec (2, *op, const0_rtx));

   if (!standard_sse_constant_p (vec_cst, V2DImode))
-   vec_cst = validize_mem (force_const_mem (V2DImode, vec_cst));
+   {
+ start_sequence ();
+ vec_cst = validize_mem (force_const_mem (V2DImode, vec_cst));
+ rtx_insn *seq = get_insns ();
+ end_sequence ();
+ emit_insn_before (insns, insn)
+   }

   emit_insn_before (gen_move_insn (tmp, vec_cst), insn);
   *op = tmp;

[Bug ipa/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-16
 CC||mpolacek at gcc dot gnu.org
  Component|middle-end  |ipa
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #3 from Marek Polacek  ---
Started with:

commit 76e435b59827b24023218ca99d634ed81cd28e7d
Author: hubicka 
Date:   Sun May 8 18:44:02 2016 +

* cgraph.c (thunk_adjust): Export.
* cgraphclones.c (cgraph_node::create_clone): Clone thunk info.
* cgraphunit.c (thunk_adjust): Export.
(cgraph_node::assemble_thunks_and_aliases): Do not assemble inlined
thunks.
* ipa-inline-analyssi.c (compute_inline_parameters): Thunks are
inlinable.
* tree-inline.c (expand_call_inline): Expand thunks inline.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@236012
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug tree-optimization/71132] [7 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu with “seg fault”

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-16
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|gcc ICE at -O3 on valid |[7 Regression] gcc ICE at
   |code on x86_64-linux-gnu|-O3 on valid code on
   |with “seg fault”|x86_64-linux-gnu with “seg
   ||fault”
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with:

commit f52a3ef65a923faa1c22a8c04cda64ed8f0b2234
Author: rguenth 
Date:   Thu May 12 07:18:58 2016 +

2016-05-12  Richard Biener  

PR tree-optimization/70986
* cfganal.c: Include cfgloop.h.
(dfs_find_deadend): Prefer to take edges exiting loops.

* gcc.dg/torture/pr70986-1.c: New testcase.
* gcc.dg/torture/pr70986-2.c: Likewise.
* gcc.dg/torture/pr70986-3.c: Likewise.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@236158
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090

[iains at gcc dot gnu.org]

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

--- Comment #12 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #11)
> I wonder if it's a stack/data alignment problem

maybe not;
comparing 6.1 and trunk with the function annotated to
__attribute__((noinline)) it seems that the problem is introduced before the
inlining; and it looks, as you say, to be related to the load of the constant
value equivalent to data[0].

For 6.1 since the function is static the constant load is moved into
variable_shift() and the value of i is passed in eax.

This all shows up in a Linux X x86_64-apple-darwin10 configured like:

../gcc-mainline/configure --prefix=/somewhere --target=x86_64-apple-darwin10
--host=x86_64-linux-gnu --build=x86_64-linux-gnu --enable-languages=c
--enable-targets=all

[Bug middle-end/39275] -funroll-loop fails

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #5 from Arseny Solokha  ---
I cannot reproduce it w/ any supported (as of today) version of gcc, as well as
w/ trunk. Seems to be fixed long ago.

[Bug tree-optimization/71109] gcc ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-16
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with:

commit 5c2b6d9bed3b944469ab387325476d1188000f46
Author: segher 
Date:   Tue Sep 15 00:38:21 2015 +

shrink-wrap: Rewrite

This patch rewrites the shrink-wrapping algorithm, allowing non-linear
pieces of CFG to be duplicated for use without prologue instead of just
linear pieces.

* shrink-wrap.c (requires_stack_frame_p): Fix formatting.
(dup_block_and_redirect): Delete function.
(can_dup_for_shrink_wrapping): New function.
(fix_fake_fallthrough_edge): New function.
(try_shrink_wrapping): Rewrite function.
(convert_to_simple_return): Call fix_fake_fallthrough_edge.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@227775
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug tree-optimization/71148] New: [7 Regression] Compile time hog w/ -O3 -funroll-loops

[asolokha at gmx dot com]

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

Bug ID: 71148
   Summary: [7 Regression] Compile time hog w/ -O3 -funroll-loops
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

It take indefinite (or very long?) time for gcc-7.0.0-alpha20160515 to compile
the following snippet w/ -O3 -funroll-loops:

int rh, ok, kq, fu;

void
js (int cs)
{
  rh = fu;
  if (fu != 0)
{
  cs /= 3;
  if (cs <= 0)
{
  int z9;
  for (z9 = 0; z9 < 2; ++z9)
{
  z9 += cs;
  ok += z9;
  fu += ok;
}
}
}
}

void
vy (int s3)
{
  int yo, g2 = 0;
sd:
  js (g2);
  for (yo = 0; yo < 2; ++yo)
{
  if (fu != 0)
goto sd;
  kq += (s3 != (g2 ? s3 : 0));
  for (s3 = 0; s3 < 72; ++s3)
g2 *= (~0 - 1);
  g2 -= yo;
}
  for (fu = 0; fu < 18; ++fu)
for (yo = 0; yo < 17; ++yo)
  if (g2 < 0)
goto sd;
}

et_splay(et_occ *) is the absolute leader in perf top w/ 32%, almost like in
PR51005.

[Bug fortran/70959] [6/7 Regression] Invalid type determination due to expression in a type declaration statement

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
As shown by the following reduced test

  integer(8), parameter :: e18 = 1000_8
  integer(8) :: e19

  e19= (e18)

  print *, e18, e19
end

there are two issues:

(1) a bogus warning,
(2) more annoying, the warning is misplaced, hence misleading.

IMO if one tries to fix this PR the priority should be the second issue.

[Bug middle-end/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||hubicka at ucw dot cz

--- Comment #2 from Markus Trippelsdorf  ---
-fno-devirtualize-speculatively "fixes" the issue.

[Bug middle-end/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
trippels@gcc2-power8 http % cat Http2Session.ii
typedef enum {} nsresult;
struct A {
  virtual void SetConnection();
};
struct B {
  virtual nsresult OnReadSegment(const char *, int, int *) = 0;
};
struct C : A, B {
  nsresult OnReadSegment(const char *, int, int *);
  void FlushOutputQueue();
  B *mSegmentReader;
};
void C::FlushOutputQueue() {
  if (!mSegmentReader)
return;
  mSegmentReader->OnReadSegment(0, 0, 0);
}
nsresult C::OnReadSegment(const char *, int, int *) {
  FlushOutputQueue();
  mSegmentReader = 0;
  OnReadSegment(0, 0, 0);
}

trippels@gcc2-power8 http % g++ -O3 -c Http2Session.ii
Http2Session.ii: In member function ‘virtual nsresult C::OnReadSegment(const
char*, int, int*)’:
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
   mSegmentReader->OnReadSegment(0, 0, 0);
 ^
__builtin_unreachable (adjusted_this.9_275, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.10_280, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.11_290, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.12_295, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.13_300, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.14_305, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.15_317, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.16_322, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.17_327, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.18_332, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.19_337, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.20_342, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.21_356, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.22_361, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.23_366, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.24_371, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.25_376, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.26_381, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.27_386, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.28_391, 0B, 0, 0B);
Http2Session.ii:16:41: internal compiler error: verify_gimple failed
0x10b1c447 verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:5166
0x109be22f execute_function_todo
../../gcc/gcc/passes.c:1964
0x109bf083 do_per_function
../../gcc/gcc/passes.c:1648
0x109bf39f execute_todo
../../gcc/gcc/passes.c:2016

[Bug rtl-optimization/70978] [5 Regression] internal compiler error: in assign_by_spills, at lra-assigns.c:1428 on arm

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-16
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  ---
Confirmed.

[Bug c++/71147] [6 REGRESSION] Flexible array member wrongly rejected in template

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

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

Avi Kivity  changed:

   What|Removed |Added

  Attachment #38497|0   |1
is obsolete||

--- Comment #1 from Avi Kivity  ---
Created attachment 38498
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38498=edit
Slightly simpler reproducer (no std::atomic)

[Bug c++/71147] New: [6 REGRESSION] Flexible array member wrongly rejected in template

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

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

Bug ID: 71147
   Summary: [6 REGRESSION] Flexible array member wrongly rejected
in template
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a...@cloudius-systems.com
  Target Milestone: ---

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

gcc (GCC) 6.1.1 20160510 (Red Hat 6.1.1-2)

The attached code does not compile under g++ 6.  It works fine under 5.3 (with
-std=gnu++14).

Removing "template , or converting the array to be an array of
unsigned (instead of array of struct) hides the problem.

[Bug c++/71145] Alpha: Error: No lda !gpdisp!278 was found

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
Similar to PR 64113. Maybe we need to move the mentioned peephole2s to
post-epilogue_completed splitter.

[Bug c++/71145] Alpha: Error: No lda !gpdisp!278 was found

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
(In reply to Michael Cree from comment #0)

> I will attempt to attach preprocessed source of SubscriberInfo.cpp from
> libavg.  Um, no I can't; it's too large for the 1000kB limit.  How can I
> provide the file?

Even when you compress it?

[Bug middle-end/71146] New: [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments

[trippels at gcc dot gnu.org]

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

Bug ID: 71146
   Summary: [7 Regression] error: __builtin_unreachable or
__builtin_trap call with arguments
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

Created attachment 38496
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38496=edit
unreduced testcase

trippels@gcc2-power8 ~ % ~/gcc_test/usr/local/bin/g++ -w -O3 -c Http2Session.ii
/home/trippels/gecko-dev/netwerk/protocol/http/Http2Session.cpp: In member
function ‘nsresult mozilla::net::Http2Session::BufferOutput(const char*,
uint32_t, uint32_t*)’:
/home/trippels/gecko-dev/netwerk/protocol/http/Http2Session.cpp:2898:62: error:
__builtin_unreachable or __builtin_trap call with arguments
 rv = mSegmentReader->OnReadSegment(buf, count, countRead);
  ^
__builtin_unreachable (adjusted_this.1907_86, _52, avail_47, );
/home/trippels/gecko-dev/netwerk/protocol/http/Http2Session.cpp:2898:62:
internal compiler error: verify_gimple failed
0x10b1c447 verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:5166
0x109be22f execute_function_todo
../../gcc/gcc/passes.c:1964
0x109bf083 do_per_function
../../gcc/gcc/passes.c:1648
0x109bf39f execute_todo
../../gcc/gcc/passes.c:2016

Reducing...

[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe  ---
I wonder if it's a stack/data alignment problem

[Bug c++/71145] New: Alpha: Error: No lda !gpdisp!278 was found

[mcree at orcon dot net.nz]

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

Bug ID: 71145
   Summary: Alpha: Error: No lda !gpdisp!278 was found
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mcree at orcon dot net.nz
  Target Milestone: ---
Target: alpha

In certain packages on debian-ports build logs for the Alpha architecture I am
seeing compile failures of the nature:

{standard input}: Assembler messages:
{standard input}:7233: Error: No lda !gpdisp!278 was found

One such example is src/player/SubscriberInfo.o of the source package libavg
(build log is at
https://buildd.debian.org/status/fetch.php?pkg=libavg=alpha=1.8.1-2.1=1461798687).
 Compile failure happens with gcc-5 (Debian version 5.3.1-19) and also with
gcc/g++ (7.0.0) built from the trunk about a week ago (though the line number
of the failure changes).

I will attempt to attach preprocessed source of SubscriberInfo.cpp from libavg.
 Um, no I can't; it's too large for the 1000kB limit.  How can I provide the
file?

Compiling with:

g++ -pthread -ffast-math -pipe -g -O2 -c SubscriberInfo-preprocessed.cpp  -fPIC
-o .libs/SubscriberInfo.o

results in the No lda gpdisp error.

It successfully compiles if the -O2 is changed to -O0 or -O1.

[Bug c++/71143] [7 Regression] bogus error: ‘A’ is not a base of ‘B< >’

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Started with r236221.

[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090

[iains at gcc dot gnu.org]

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

--- Comment #10 from Iain Sandoe  ---
(In reply to Ilya Enkovich from comment #9)
> (In reply to Iain Sandoe from comment #8)
> > Created attachment 38495 [details]
> > assembly for linux case
> > 
> > Here's the asm for the case from my build, although I don't expect it'll
> > help much if you can't reproduce it.
> 
> But I can build and run this asm with no problem.  What's wrong with it then?

not sure, I'll see if I can analyse more.

[Bug c++/70466] ICE on invalid code on x86_64-linux-gnu in tree check: expected constructor, have parm_decl in convert_like_real, at cp/call.c:6371 with -std=c++11

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #2 from Paolo Carlini  ---
Mine.

[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )

[nsz at gcc dot gnu.org]

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

--- Comment #3 from nsz at gcc dot gnu.org ---
simplified a bit further:

void foo(void);
int vfork(void);
int *p;

void bar(void)
{
  foo();
  *p = vfork();
}

[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090

[ienkovich at gcc dot gnu.org]

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

--- Comment #9 from Ilya Enkovich  ---
(In reply to Iain Sandoe from comment #8)
> Created attachment 38495 [details]
> assembly for linux case
> 
> Here's the asm for the case from my build, although I don't expect it'll
> help much if you can't reproduce it.

But I can build and run this asm with no problem.  What's wrong with it then?

[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090

[iains at gcc dot gnu.org]

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

--- Comment #8 from Iain Sandoe  ---
Created attachment 38495
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38495=edit
assembly for linux case

Here's the asm for the case from my build, although I don't expect it'll help
much if you can't reproduce it.

[Bug tree-optimization/71144] New: [6/7 Regression] isl_aff.c:1001: position out of bounds

[ktkachov at gcc dot gnu.org]

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

Bug ID: 71144
   Summary: [6/7 Regression] isl_aff.c:1001: position out of
bounds
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

The testcase:
int a, c, d, e, f;
int b[1];
short g;

void
fn1 ()
{
  for (; a; a++)
if (f)
  for (; e; e--)
{
  d = 0;
  for (; d <= 0; d++)
if (c)
  break;
  (g = a) || (b[a] = 0);
}
}


ICEs with -Ofast -floop-interchange:
../../gcc/isl/isl_aff.c:1001: position out of bounds
mycrash.c: In function ‘fn1’:
mycrash.c:6:1: internal compiler error: Aborted
 fn1 ()
 ^~~
0xbab71f crash_signal
../../gcc/gcc/toplev.c:333
0x13a4fe2 isl_handle_error
../../gcc/isl/isl_ctx.c:96
0x1365fa1 isl_aff_set_coefficient_si
../../gcc/isl/isl_aff.c:1000
0x12342da extract_affine_chrec
../../gcc/gcc/graphite-sese-to-poly.c:239
0x12342da extract_affine
../../gcc/gcc/graphite-sese-to-poly.c:381
0x123418e extract_affine
../../gcc/gcc/graphite-sese-to-poly.c:421
0x123523d add_condition_to_pbb
../../gcc/gcc/graphite-sese-to-poly.c:458
0x123523d add_conditions_to_domain
../../gcc/gcc/graphite-sese-to-poly.c:525
0x123523d build_iteration_domains
../../gcc/gcc/graphite-sese-to-poly.c:1017
0x1234fe5 build_iteration_domains
../../gcc/gcc/graphite-sese-to-poly.c:1040
0x123579f build_poly_scop(scop*)
../../gcc/gcc/graphite-sese-to-poly.c:1364
0x121fb9a graphite_transform_loops()
../../gcc/gcc/graphite.c:319
0x12201a0 graphite_transforms
../../gcc/gcc/graphite.c:356
0x12201a0 execute
../../gcc/gcc/graphite.c:433
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

This is using ISL 0.15 as downloaded from contrib/download_prerequisites.
Don't know if this is an ISL bug or a bug in the way GCC communicates with it.

[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090

[ienkovich at gcc dot gnu.org]

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

--- Comment #7 from Ilya Enkovich  ---
(In reply to Dominique d'Humieres from comment #2)
> Created attachment 38486 [details]
> Assembly for gcc.c-torture/execute/ashldi-1.c compiled with r236090
> 
> Assembly for gcc.c-torture/execute/ashldi-1.c compiled with r236090 and -Os
> -m32.

This part looks wrong:

movd%xmm1, %edi
movaps  (%edi), %xmm0

Most probably it is an attempt to load a constant.  Unfortunately I still don't
have a way to reproduce it.  Will try more.

[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090

[ienkovich at gcc dot gnu.org]

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

--- Comment #6 from Ilya Enkovich  ---
(In reply to Iain Sandoe from comment #5)
> Also fails on Linux for the m32 multilib with -msse2avx :
>  make -k check-gcc-c
> RUNTESTFLAGS="--target_board=unix/-msse/-msse2avx\{-m32,-m64\}
> execute.exp=ashldi-1.c"

Can't reproduce the problem on Linux (using r236170)

=== gcc Summary for unix/-msse/-msse2avx/-m32 ===

# of expected passes16
Running target unix/-msse/-msse2avx/-m64

=== gcc Summary for unix/-msse/-msse2avx/-m64 ===

# of expected passes16

[Bug c++/71143] New: [7 Regression] bogus error: ‘A’ is not a base of ‘B< >’

[trippels at gcc dot gnu.org]

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

Bug ID: 71143
   Summary: [7 Regression] bogus error: ‘A’ is not a base of
‘B< >’
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

trippels@gcc2-power8 llvm_build % cat LockFileManager.ii
struct A;
template  struct B {
  void m_fn1() { this->A::assign; }
};

trippels@gcc2-power8 llvm_build % clang++ -std=c++14 -c LockFileManager.ii
trippels@gcc2-power8 llvm_build % /home/trippels/gcc_5/usr/local/bin/g++
-std=c++14 -c LockFileManager.ii
trippels@gcc2-power8 llvm_build % /home/trippels/gcc_6/usr/local/bin/g++ -c
LockFileManager.ii
trippels@gcc2-power8 llvm_build % /home/trippels/gcc_test/usr/local/bin/g++ -c
LockFileManager.ii
LockFileManager.ii: In member function ‘void B< >::m_fn1()’:
LockFileManager.ii:3:27: error: ‘A’ is not a base of ‘B< >’
   void m_fn1() { this->A::assign; }
   ^~

[Bug rtl-optimization/70978] [5 Regression] internal compiler error: in assign_by_spills, at lra-assigns.c:1428 on arm

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
CC'ing Vlad on LRA opinion

[Bug tree-optimization/71142] New: [6/7 Regression] ICE: Segmentation fault in ssa_default_def

[ktkachov at gcc dot gnu.org]

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

Bug ID: 71142
   Summary: [6/7 Regression] ICE: Segmentation fault in
ssa_default_def
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

The testcase:

int a, b, d, e;
int c[10];
short f;
unsigned g;

void
fn1 ()
{
  int *h = 
  for (; f; f--)
{
  a = 0;
  for (; a <= 1; a++)
{
  d = 1;
  for (; d >= 0; d--)
{
  b = 0;
  for (; b < 7; b++)
c[b] = b;
}
  *h ^= g;
}
}
  *h = *h & e;
}

ICEs on aarch64-none-linux-gnu with -Ofast -floop-interchange:

mycrash.c: In function 'fn1':
mycrash.c:7:1: internal compiler error: Segmentation fault
 fn1 ()
 ^~~
0xb02b4f crash_signal
$SRC/gcc/toplev.c:335
0xb58db5 ssa_default_def(function*, tree_node*)
$SRC/gcc/tree-dfa.c:305
0xb5b9c4 get_or_create_ssa_default_def(function*, tree_node*)
$SRC/gcc/tree-dfa.c:357
0xb9665f get_reaching_def
$SRC/gcc/tree-into-ssa.c:1168
0xb9b6b4 rewrite_update_phi_arguments
$SRC/gcc/tree-into-ssa.c:2017
0xb9b6b4 rewrite_update_dom_walker::before_dom_children(basic_block_def*)
$SRC/gcc/tree-into-ssa.c:2137
0x1063b49 dom_walker::walk(basic_block_def*)
$SRC/gcc/domwalk.c:265
0xb9427c rewrite_blocks
$SRC/gcc/tree-into-ssa.c:2194
0xb9cccf update_ssa(unsigned int)
$SRC/gcc/tree-into-ssa.c:3356
0x1091de5 graphite_regenerate_ast_isl(scop*)
$SRC/gcc/graphite-isl-ast-to-gimple.c:3204
0x1088995 graphite_transform_loops()
$SRC/gcc/graphite.c:329
0x1088b34 graphite_transforms
$SRC/gcc/graphite.c:356
0x1088b34 execute
$SRC/gcc/graphite.c:433
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug testsuite/70227] pr69589 does not check for -rdynamic availability

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

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

--- Comment #4 from Jiong Wang  ---
Fixed r236265.

[Bug testsuite/70227] pr69589 does not check for -rdynamic availability

[jiwang at gcc dot gnu.org]

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

--- Comment #3 from Jiong Wang  ---
Author: jiwang
Date: Mon May 16 08:11:42 2016
New Revision: 236265

URL: https://gcc.gnu.org/viewcvs?rev=236265=gcc=rev
Log:
[testsuite] PR70227, skip g++.dg/lto/pr69589_0.C on targets without -rdynamic
support

  PR testsuite/70227
  * g++.dg/lto/pr69589_0.C: Skip arm and aarch64 bare-metal targets. 


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lto/pr69589_0.C

[Bug c++/71092] [6/7 Regression] ICE: in cxx_eval_call_expression, at cp/constexpr.c:1449; only with -Os

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #6 from Markus Trippelsdorf  ---
Both issues started with r232848.

[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Target|x86_64-apple-darwin*|x86_64-apple-darwin*,x86_64
   ||-pc-linux-gnu
   Host|x86_64-apple-darwin*|x86_64-apple-darwin*,x86_64
   ||-pc-linux-gnu
  Build|x86_64-apple-darwin*|x86_64-apple-darwin*,x86_64
   ||-pc-linux-gnu

--- Comment #5 from Iain Sandoe  ---
Also fails on Linux for the m32 multilib with -msse2avx :
 make -k check-gcc-c
RUNTESTFLAGS="--target_board=unix/-msse/-msse2avx\{-m32,-m64\}
execute.exp=ashldi-1.c"

[Bug c++/71092] [6/7 Regression] ICE: in cxx_eval_call_expression, at cp/constexpr.c:1449; only with -Os

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
(In reply to schoko.teddy from comment #3)
> Created attachment 38494 [details]
> Preprocessed source
> 
> This Error occurs while compiling this motioncontrollayer.cpp file from a Qt
> project. Gzipped because of largeness.

Looks like a ICE on invalid and is probably unrelated to the original issue:

markus@x4 tmp % cat motioncontrollayer.ii
namespace std {
template  struct A { static constexpr _Tp value = 0; };
typedef A false_type;
struct B : false_type {};
template  struct is_floating_point : B {};
template  struct enable_if { typedef int type; };
}
typedef int Value;
namespace detail {
template ::value,
 bool>::type = false>
constexpr Value toValue(T) {}
}
struct Quantity {
  template  constexpr Quantity(T) : value(detail::toValue(0)) {}
  Value value;
};
struct Pose {
  int x;
  int y;
  Quantity phi;
  constexpr Pose() : x(), y(), phi(0) {}
};
struct C {
  Pose pose;
};
struct D {
  Pose route[1];
};
void fn1() { C obj; }
void fn2() { D obj; }

markus@x4 tmp % clang++ -std=c++14 -ferror-limit=1 -c motioncontrollayer.ii
motioncontrollayer.ii:12:17: error: no return statement in constexpr function
constexpr Value toValue(T) {}
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
2 errors generated.

markus@x4 tmp % icpc -std=c++14 -c motioncontrollayer.ii
motioncontrollayer.ii(12): error: missing return statement at end of non-void
function "detail::toValue(T)"
  constexpr Value toValue(T) {}
  ^
  detected during instantiation of "Quantity::Quantity(T) [with T=int]"
at line 22

compilation aborted for motioncontrollayer.ii (code 2)

markus@x4 tmp % g++ -c motioncontrollayer.ii
motioncontrollayer.ii: In constructor ‘constexpr D::D()’:
motioncontrollayer.ii:27:8:   in constexpr expansion of ‘Pose()’
motioncontrollayer.ii:22:37:   in constexpr expansion of
‘((Pose*)this)->Pose::phi.Quantity::Quantity(0)’
motioncontrollayer.ii:15:70:   in constexpr expansion of ‘detail::toValue(0)’
motioncontrollayer.ii:27:8: internal compiler error: in
cxx_eval_call_expression, at cp/constexpr.c:1449

[Bug target/70947] regrename Go breakage on powerpc64

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
Version|7.0 |6.2.0
 Resolution|--- |FIXED

--- Comment #3 from Alan Modra  ---
Fixed everywhere split-stack supported