[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower

[ppalka at gcc dot gnu.org]

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

--- Comment #18 from Patrick Palka  ---
So with the patch, g++ -flto -Ofast is on par with gcc -flto -Ofast and better
than g++ -Ofast.  Could anyone confirm?

[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower

[ppalka at gcc dot gnu.org]

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

--- Comment #17 from Patrick Palka  ---
The following patch by itself closes the gap between the C++ and C FEs, to make
compilation with the C++ FE at least as good as with the C FE:

diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
index b6e1d27..8b1d020 100644
--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -237,8 +237,8 @@ genericize_cp_loop (tree *stmt_p, location_t start_locus,
tree cond, tree body,
   location_t cloc = EXPR_LOC_OR_LOC (cond, start_locus);
   exit = build1_loc (cloc, GOTO_EXPR, void_type_node,
 get_bc_label (bc_break));
-  exit = fold_build3_loc (cloc, COND_EXPR, void_type_node, cond,
- build_empty_stmt (cloc), exit);
+  exit = build3_loc (cloc, COND_EXPR, void_type_node, cond,
+ build_empty_stmt (cloc), exit);
 }

   if (exit && cond_is_first)

Here, when building the exit condition of a for-loop, fold_build3 decides to
swap the operands of the COND_EXPR (and invert its condition), which I suppose
causes subsequent optimization passes to generate worse code for these loops. 
Avoid having this done by using build3 instead.  This means that we won't fold
degenerate COND_EXPRs but I doubt that's a big deal in practice.  (An
alternative fix would be to adjust tree_swap_operands_p to avoid returning true
in this case -- maybe return false if the TREE_TYPEs are VOID_TYPEs?)

I haven't checked -flto or an optimization setting besides -Ofast.

[Bug target/70216] [SH] Implement __builtin_trap

[olegendo at gcc dot gnu.org]

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

--- Comment #8 from Oleg Endo  ---
(In reply to Rich Felker from comment #7)
> Is there a reason we don't use an undefined instruction that will trap?
> 0xfffd is mentioned as permanently undefined here on page 85:
> 
> http://documentation.renesas.com/doc/products/mpumcu/rej09b0003_sh4a.pdf
> 
> I actually had trouble getting Linux to trap this; it's one thing I need to
> investigate on the kernel side, which is why I didn't reply earlier. I'll
> report my findings later.

I think it's a bit odd and obscure to use 0xFFFD for this purpose.  There are
256 trap numbers to choose from.  Unless there's some clear benefit of using
0xFFFD, I'd rather avoid it.


> One other thing I'm wondering about is the contract for clobbers on the
> function call version.

I believe I've mentioned this in the docs section of the patch.  The compiler
would assume that only the PR is clobbered by the function call.

> Is __builtin_trap supposed to be able to return? I
> was under the impression that it's noreturn, in which case there would be no
> requirements on what it can clobber,

That's true.  Although it's technically possible for some trap to return, I
can't think of any practical case where it would be required.  If the function
implementation wants to return it has to take care of any other clobbers.

My plan was to re-use the same concept for trapping arithmetic (PR 54272),
where the trap function could do something like throwing an exception.  In any
case, I don't think it would want to return to the original code either.

On a second thought, it might be better to emit the function call like:

 sts.l   pr,@-r15
 jsr @r...
 nop

and officially not clobber PR either.  This might be useful when injecting an
exception, because the original PR value can be restored.

> but there may be calling-convention
> issues still: Is it callable via PLT? On FDPIC targets, does the function
> receive a valid GOT pointer in r12 so that it can make further calls/data
> access?

My idea was to have it like any other special support function in libgcc, which
are often implemented in asm directly.

> Also, if the expectation is that the trap will not return, does the
> trapa need the bug workaround? Does the bug (requiring the 5x or) take place
> at the time the trapa is executed, or at the time of return to the
> instruction after it? This is not well-documented and I remember looking
> into it before but I don't remember the answer.

I only know tnsh7456ae.pdf which doesn't explain what exactly goes wrong at
which stage in the CPU.  From what I understand it somehow seems to be related
to the instruction prefetching and decoding of the trapa instruction and what
follows it.

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[dominiq at lps dot ens.fr]

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

--- Comment #16 from Dominique d'Humieres  ---
> Created attachment 38090 [details]
> Updated patch correcting problem found by Dominique

With this updated patch and y = 643.125 and d=2, I get

-8pf18.2 y=  1.00
-7pf18.2 y=  1.00
-6pf18.2 y=  1.00
-5pf18.2 y=  1.00
-4pf18.2 y=  0.06
-3pf18.2 y=  0.64
-2pf18.2 y=  6.43
-1pf18.2 y= 64.31
0pf18.2 y=643.12
1pf18.2 y=   6431.25
2pf18.2 y=  64312.50
3pf18.2 y= 643125.00
4pf18.2 y=6431250.00
5pf18.2 y=   64312500.00
6pf18.2 y=  643125000.00
7pf18.2 y= 643125.00

while I get

-8pf18.2 y=  0.00
-7pf18.2 y=  0.00
-6pf18.2 y=  0.00
-5pf18.2 y=  0.00
-4pf18.2 y=  0.06
-3pf18.2 y=  0.64
-2pf18.2 y=  6.43
-1pf18.2 y= 64.31
0pf18.2 y=643.12
1pf18.2 y=   6431.25
2pf18.2 y=  64312.50
3pf18.2 y= 643125.00
4pf18.2 y=6431250.00
5pf18.2 y=   64312500.00
6pf18.2 y=  643125000.00
7pf18.2 y= 643125.00

Note that -5pf18.2 y= should be 0.01 if correctly rounded. The rounding error
comes from the addition of

+  precision += dtp->u.p.scale_factor;
+  if (precision < f->u.real.d)
+   precision = f->u.real.d;

in my patch.

[Bug c/70407] alignment of array elements is greater than element size

[dxin at usc dot edu]

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

Dehuan Xin  changed:

   What|Removed |Added

   Severity|normal  |minor

[Bug c/70407] New: alignment of array elements is greater than element size

[dxin at usc dot edu]

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

Bug ID: 70407
   Summary: alignment of array elements is greater than element
size
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dxin at usc dot edu
  Target Milestone: ---

To verify, declare a POD type plus aligned attribute as a custom type.

typedef struct S_ { short f[3]; } S __attribute__ ((aligned (8)));

Then make an array of such type.

S test[16]={};

Then the code won't compile, with "error: alignment of array elements is
greater than element size".

Basically the `__attribute__ ((aligned (8)));` left the size of such type
unchanged, as opposed to including the alignment/padding in the size and
violates the C standard that `sizeof` operator returns the storage size plus
all necessary padding and maintain `sizeof(Type[N])==N*sizeof(Type)`.

This error is added in 2005 (
https://gcc.gnu.org/ml/gcc-patches/2005-09/msg01853.html ) to prevent GCC from
generating broken code, and is brought up again in a stackoverflow.com question
(http://stackoverflow.com/questions/36211864/how-can-i-apply-attribute-aligned32-to-an-int)
.

Note that clang-3.8 does include the extra padding as the size and allow
declaring arrays of extra-aligned types.

This problem is verified on GCC 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.1) and also
here https://ideone.com/oxGyiN .

If this bug is not to be fixed, please update the documentation
(https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-Attributes)
and mark it as a feature.

[Bug target/70319] [6 Regression] FAIL: gcc.dg/sso/q2.c -O1 -fno-inline execution test

[danglin at gcc dot gnu.org]

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

--- Comment #13 from John David Anglin  ---
Author: danglin
Date: Fri Mar 25 01:00:40 2016
New Revision: 234476

URL: https://gcc.gnu.org/viewcvs?rev=234476&root=gcc&view=rev
Log:
PR target/70319
* config/pa/pa.md (bswapdi2): Use a scratch register.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/pa/pa.md

[Bug target/70319] [6 Regression] FAIL: gcc.dg/sso/q2.c -O1 -fno-inline execution test

[danglin at gcc dot gnu.org]

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

--- Comment #12 from John David Anglin  ---
Author: danglin
Date: Fri Mar 25 00:59:02 2016
New Revision: 234475

URL: https://gcc.gnu.org/viewcvs?rev=234475&root=gcc&view=rev
Log:
PR target/70319
* config/pa/pa.md (bswapdi2): Use a scratch register.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/pa.md

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #5)
> CCing authors of the other commits.  That said, complaining about size
> regressions generally should be only if it (significantly) increases sizes
> of some larger codebases (CSiBE, size of some large app, ...), when looking
> at a single function only, there will be always improvements and
> degradations, the compiler is changing.

A few comments about "my" patch (r228318), the reorder-blocks thing.
First of all, almost all it does is heuristic, so exactly as Jakub
says you have to look at bigger tests.  This patch makes -freorder-blocks
use a new algorithm ("simple") for -Os; after a few follow-up patches
this consistently gives smaller code.  The big difference with the old
("stc") algorithm is that that one can duplicate blocks, which sometimes
results in smaller code, while "simple" never does.  It may be interesting
to look at before and after of just this patch, to see if the heuristics
can be improved.

[Bug fortran/68441] ICE on using transfer with character parameter

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
There's a subtle wrong-code problem:

  character(huge(1_1)), parameter :: y = 'abc'
  character(   127_1 ), parameter :: z = 'abc'
  print *, len(y), len(z)
end


produces:

   3 127

instead of the expected:

 127 127

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

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

--- Comment #15 from Jerry DeLisle  ---
Created attachment 38091
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38091&action=edit
A more exhaustive testing program

This test allows at least visual inspection of the patterns. The test omits the
"starred" results where things dont fit the width.

The results at least look consistent using my previously attached updated
patch.

[Bug c/70400] GCC compiles a return statement with an expression in a void function (illegal under C90 6.6.6.4) with -std=c90 -pedantic

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
On Thu, 24 Mar 2016, ryao at gentoo dot org wrote:

> How would GCC "reject all programs" without emitting an error? If there is 
> some

By emitting a warning.  That's a rejection.  The standard requirement is 
to emit a diagnostic for such programs, and that's what this option does 
("Diagnostics consist of all the output sent to stderr by GCC.", as per 
implement-c.texi).  If you want a different definition of rejection, 
-pedantic-errors provides one.

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

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

--- Comment #14 from Jerry DeLisle  ---
Created attachment 38090
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38090&action=edit
Updated patch correcting problem found by Dominique

This is what I came up with independent of Dominiques patch.  This patch is
much simpler.  Lets continue testing.

[Bug fortran/70071] ICE on wrong usage of a subscript triplet

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #3 from Harald Anlauf  ---
(In reply to Gerhard Steinmetz from comment #0)
> $ cat z1.f90
> program p
>integer, allocatable :: z(:)[:,:]
>allocate (z(2)[1::2,*])
> end
> 
> $ gfortran-6 -fcoarray=single z1.f90
> f951: internal compiler error: gfc_ref_dimen_size(): Bad dimension

Potential fix (not regtested):

Index: gcc/fortran/array.c
===
--- gcc/fortran/array.c (revision 234170)
+++ gcc/fortran/array.c (working copy)
@@ -2173,9 +2184,15 @@ gfc_ref_dimen_size (gfc_array_ref *ar, int dimen,
   mpz_t diff;
   bool t;

-  if (dimen < 0 || ar == NULL || dimen > ar->dimen - 1)
+  if (dimen < 0 || ar == NULL)
 gfc_internal_error ("gfc_ref_dimen_size(): Bad dimension");

+  if (dimen > ar->dimen - 1)
+{
+  gfc_error ("Bad array dimension at %L", &ar->c_where[dimen]);
+  return false;
+}
+
   switch (ar->dimen_type[dimen])
 {
 case DIMEN_ELEMENT:


Which gives:

pr70071-z1.f90:3:18:

allocate (z(2)[1::2,*])
  1
Error: Bad array dimension at (1)

[Bug c++/70353] [5/6 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jason at gcc dot gnu.org,
   ||mliska at suse dot cz
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #11 from Jason Merrill  ---
Core issue 1962 talks about changing __func__ et al to be const char * rather
than array; Martin was investigating that change but it fell off my radar. 
I'll look at finishing up his patch.

[Bug target/69770] [ARM] -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg

[cbaylis at gcc dot gnu.org]

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

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |7.0

--- Comment #3 from cbaylis at gcc dot gnu.org ---
new patch posted to mailing list

https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01403.html

[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer

[chester.gingrich at gmail dot com]

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

--- Comment #27 from chester.gingrich at gmail dot com ---
Created attachment 38089
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38089&action=edit
workaround (of sorts)

This is how I get around this issue.

Note that I don't usually have to explicitly provide the dimensions
in my application.  The workaround is shown applied to the demo case.

I simply wrote a "do nothing" function, "remap" that does the pointer
assignment.

I hope someone can make use of this workaround to figure out a real solution!

[Bug c++/70386] [6 Regression] ICE with -Wall on valid code on x86_64-linux-gnu in verify_ctor_sanity, at cp/constexpr.c:2232

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug target/70216] [SH] Implement __builtin_trap

[bugdal at aerifal dot cx]

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

--- Comment #7 from Rich Felker  ---
Is there a reason we don't use an undefined instruction that will trap? 0xfffd
is mentioned as permanently undefined here on page 85:

http://documentation.renesas.com/doc/products/mpumcu/rej09b0003_sh4a.pdf

I actually had trouble getting Linux to trap this; it's one thing I need to
investigate on the kernel side, which is why I didn't reply earlier. I'll
report my findings later.

One other thing I'm wondering about is the contract for clobbers on the
function call version. Is __builtin_trap supposed to be able to return? I was
under the impression that it's noreturn, in which case there would be no
requirements on what it can clobber, but there may be calling-convention issues
still: Is it callable via PLT? On FDPIC targets, does the function receive a
valid GOT pointer in r12 so that it can make further calls/data access? Also,
if the expectation is that the trap will not return, does the trapa need the
bug workaround? Does the bug (requiring the 5x or) take place at the time the
trapa is executed, or at the time of return to the instruction after it? This
is not well-documented and I remember looking into it before but I don't
remember the answer.

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
All I wanted to say is that it is to be expected that on some code a newer GCC
version ends up needing one or two more instructions, even at -Os, and what
matters is not the size of a single function, but larger codebases.  If the
testcase here has been extracted from CSiBE and/or represents something that
happens often, then it is of course desirable to fix that.
So e.g. it would be interesting to find out what impact these above mentioned
commits have on larger codebases.  If they are in the end neutral or shrink
code size, then one testcase going in the other direction is fine, if they have
overal negative -Os code size effects, then it is something to work on.

[Bug target/70406] New: ICE: in extract_insn, at recog.c:2287 (unrecognizable insn) with -mtune=pentium2 -mavx512f

[zsojka at seznam dot cz]

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

Bug ID: 70406
   Summary: ICE: in extract_insn, at recog.c:2287 (unrecognizable
insn) with -mtune=pentium2 -mavx512f
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
Target: i686-pc-linux-gnu

Compiler output:
$ i686-pc-linux-gnu-gcc -O -mtune=pentium2 -mavx512f testcase.c 
testcase.c: In function 'foo':
testcase.c:9:1: error: unrecognizable insn:
 }
 ^
(insn 39 33 40 2 (set (reg/v:QI 1 dx [orig:89 i ] [89])
(not:HI (reg/v:QI 1 dx [orig:89 i ] [89]))) testcase.c:6 -1
 (nil))
testcase.c:9:1: internal compiler error: in extract_insn, at recog.c:2287
0xb37078 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.c:108
0xb37108 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.c:116
0xaec618 extract_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.c:2287
0xaec6c7 extract_insn_cached(rtx_insn*)
/repo/gcc-trunk/gcc/recog.c:2178
0x85140d cleanup_subreg_operands(rtx_insn*)
/repo/gcc-trunk/gcc/final.c:3104
0xae7ffa split_insn
/repo/gcc-trunk/gcc/recog.c:2901
0xaf03e7 split_all_insns()
/repo/gcc-trunk/gcc/recog.c:2955
0xaf04d8 rest_of_handle_split_after_reload
/repo/gcc-trunk/gcc/recog.c:3891
0xaf04d8 execute
/repo/gcc-trunk/gcc/recog.c:3920
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Tested revisions:
trunk r234391 - FAIL
5-branch r234412 - FAIL
4_9-branch r234243 - FAIL

[Bug target/70406] ICE: in extract_insn, at recog.c:2287 (unrecognizable insn) with -mtune=pentium2 -mavx512f

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  ---
Created attachment 38088
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38088&action=edit
reduced testcase

[Bug rtl-optimization/70405] New: -fcompare-debug failure with -mavx512f

[zsojka at seznam dot cz]

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

Bug ID: 70405
   Summary: -fcompare-debug failure with -mavx512f
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
Target: x86_64-pc-linux-gnu, i686-pc-linux-gnu

Created attachment 38087
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38087&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -mavx512f -fcompare-debug testcase.c
x86_64-pc-linux-gnu-gcc: error: testcase.c: -fcompare-debug failure (length)

The generated assembly differs significantly.

Tested revisions:
trunk r234391 - FAIL
5-branch r234412 - OK

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  ---
I would suggest that you definitely keep reporting these things and extracting
examples from csibe or other benchmarks to show the codesize increases.

While some folks will prioritize performance, it doesn't mean that codesize is
ignored.  Similarly for significant changes in compile-time, stack usage, etc.

[Bug c++/70403] A null pointer check removed with -O2 even with -fno-delete-null-pointers-checks

[thadula at ciena dot com]

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

--- Comment #5 from Hadula, Tomasz  ---
Created attachment 38086
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38086&action=edit
Original and preprocessed source

generated with -E

[Bug rtl-optimization/70174] [6 Regression] ICE at -O1 and above on x86_64-linux-gnu in gen_lowpart_general, at rtlhooks.c:63

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

 CC||vogt at linux dot vnet.ibm.com

--- Comment #12 from Dominik Vogt  ---
The new test case triggers an ICE on s390x.  See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70404

[Bug target/70404] New: pr71074.c fails on s390x

[vogt at linux dot vnet.ibm.com]

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

Bug ID: 70404
   Summary: pr71074.c fails on s390x
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vogt at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org
  Target Milestone: ---
  Host: s390x
Target: s390x

The new test case from #70174 triggers an ICE on s390x (svn rev 234414):

.../build/gcc/xgcc -B...//gcc/ .../gcc/testsuite/gcc.dg/pr70174.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -S -m64 -o pr70174.s
.../gcc/testsuite/gcc.dg/pr70174.c: In function 'foo':
.../gcc/testsuite/gcc.dg/pr70174.c:10:7: warning: assignment makes integer from
pointer without a cast [-Wint-conversion]
/home/vogt/src/git/gcc/gcc/testsuite/gcc.dg/pr70174.c:11:1: error:
unrecognizab\
le insn:
(insn 9 8 10 2 (set (zero_extract:DI (subreg:DI (reg:QI 66) 0)
(const_int 4 [0x4])
(const_int 56 [0x38]))
(symbol_ref:DI ("foo") [flags 0x3] )
.../gcc/testsuite/gcc.dg/pr70174.c:10 -1
 (nil))
.../gcc/testsuite/gcc.dg/pr70174.c:11:1: internal compiler error: in
extract_insn, at recog.c:2287
0x805b40dd _fatal_insn(char const*, rtx_def const*, char const*, int, char
cons\
t*)
.../gcc/rtl-error.c:108
0x805b411d _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
.../gcc/rtl-error.c:116
0x80582a2d extract_insn(rtx_insn*)
.../gcc/recog.c:2287
0x803b6af3 instantiate_virtual_regs_in_insn
.../gcc/function.c:1582
0x803b6af3 instantiate_virtual_regs
.../gcc/function.c:1950
0x803b6af3 execute
.../gcc/function.c:1999

[Bug c++/70386] [6 Regression] ICE with -Wall on valid code on x86_64-linux-gnu in verify_ctor_sanity, at cp/constexpr.c:2232

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Mar 24 19:21:38 2016
New Revision: 234469

URL: https://gcc.gnu.org/viewcvs?rev=234469&root=gcc&view=rev
Log:
PR c++/70386

* constexpr.c (cxx_eval_bare_aggregate): Handle PMFs.

Added:
trunk/gcc/testsuite/g++.dg/expr/pmf-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug c++/70403] A null pointer check removed with -O2 even with -fno-delete-null-pointers-checks

[thadula at ciena dot com]

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

--- Comment #4 from Hadula, Tomasz  ---
Created attachment 38085
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38085&action=edit
output from -fdump-tree-optimized

I attached dump from -fdump-tree-optimized for the affected source
(NewLogicalSwitch.cpp). Please look for ::CpSelect in it

[Bug c++/70403] A null pointer check removed with -O2 even with -fno-delete-null-pointers-checks

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Hadula, Tomasz from comment #2)
> The whole thing is huge (compiles for almost 2 hours).
> The problem is that when I attempt to make it smaller in form of a simple,
> standalone app, the problem doesn't happen anymore.

So provide preprocessed source of just the one file, which will only take a few
seconds. That way someone can compile that file and inspect the generated code.
It doesn't need to produce a running program. Without it this report is not
useful.

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[nathan at gcc dot gnu.org]

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

--- Comment #6 from Nathan Sidwell  ---
Indeed, manually editing the assembly to such an initializer results in  a
working program.

The CONSTRUCTOR created for ab's  DECL_INITIAL has the correct things in it,
but in declaration  order.  I.e. it looks like:
IDX=field-for-A-base VAL=CONSTRUCTOR (...)
IDX=field-for-B-base VAL=CONSTRUCTOR (...)

I think CONSTRUCTOR_ELTs are expected to be in ascending placement order?

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

[fredrik.hederstie...@securitas-direct.com]

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

--- Comment #6 from Fredrik Hederstierna 
 ---
Thanks for your analysis on this. One comment on this 'complaint', it's not
only about size - in my example the compiler uses 2 more regs push and pop, and
several more instructions, so I think causing performance regressions aswell? I
can file the 'complaints' as performance degradations next time if this is
better.

Actually this was derived from a larger code base analysis (CSiBE)

Bug 61578 - [4.9 regression] Code size increase for ARM thumb compared to 4.8.x
when compiling with -Os

Where CSiBE problems was analysed, but this issue unfortunately got too fuzzy
where its hard to define an issue on almost 1000 files, the conclusion was then
to create separate smaller examples to work on, because the CSiBE overall
benchmark was hard to overview.

I understand its much focus on performance speed on GCC development, but I do
think that size really is important aswell since GCC is used very widely also
for typically ARM based embedded systems.

I will continue to try track size on CSiBE on
http://gcc.hederstierna.com/csibe, but please comment if you think size
regressions are non-wanted, I can try to focus more on issues that have both
performance speed and size components combined (I guess they often go hand in
hand.).

Thanks, BR, Fredrik

[Bug target/63890] [4.9/5/6 regression] Compiling trivial program with -O -p leads to misaligned stack

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #29 from Jeffrey A. Law  ---
I've been able to confirm this on an older mac here. I've got a baseline
bootstrap & test running and will test the patch from c#9 once the baseline is
complete.

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #5 from Nathan Sidwell  ---
We're turning 'ab's initializer into a static one (so the lack of a dynamic
initializer is a red herring).  But we're flubbing the form of that initializer
because the placement of AB's bases is not their declaration order.  B is
chosen as the primary base, so AB is laid out as:
AB size 24 align 8
  A @ 16
  B @ 0

The  emitted initializer is:
_ZL2ab:
.zero   16
.long   1  <-- A::a
.quad   _ZTV2AB+16
.quad   2  <-- B::element

(I modified the testcase so the NSDMIs are distinct non-zero values).  The 16
zero bytes appear to be skipping over the B sub-object to place A's
initializer.

We should be emitting something more like:

_ZL2ab:
.quad   _ZTV2AB+16
.quad   2  <--B::element
.long   1  <-- A::a
.zero   4  <-- tail padding

[Bug c++/70403] A null pointer check removed with -O2 even with -fno-delete-null-pointers-checks

[thadula at ciena dot com]

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

--- Comment #2 from Hadula, Tomasz  ---
The whole thing is huge (compiles for almost 2 hours).
The problem is that when I attempt to make it smaller in form of a simple,
standalone app, the problem doesn't happen anymore.

I've been searching for something that dereferences pNewSel or some sort of
memcpy or memmove, but I can't find it.

Those are 2 methods used to obtain pNewSel. Hashlist is based on RogueWave
hashset:

UniCtp*
NewLogicalSwitch::FindCtpFromHashList (McCtpId ctpId)
{
UniCtp* pDummyCtp = mUniCtpPool.Get();

if (!pDummyCtp)
{
getSwitchCoreMemoryLog()->PrintRamLog (
"NewLogicalSwitch::FindCtpFromHashList: no more room in the CTP
pool");
return NULL;
}

pDummyCtp->CtpCpBase::Init(ctpId);   // call base class method; need
CtpCpBase:: qualifier because UniCtp redefines Init(), hiding the base class
version
UniCtp* pCtp = mCtpHashList.find(pDummyCtp);
pDummyCtp->Destroy();  // return to mempool

return pCtp;
}

UniCp*
NewLogicalSwitch::FindCpFromHashList (McCpId cpId)
{
// Note - The prot app is not used in the find process.
//Find just compares the ids of the two CPs.
//The prot app is not part of the id.
//We just needed to pass in a dummy prot app
//along with the real id to create the dummyCp.
//
TcmInfo dummyTcmInfo;
UniCp* pDummyCp, *pUniCp;

pDummyCp = mUniCpPool.Get();
if (!pDummyCp)
{
getSwitchCoreMemoryLog()->PrintRamLog (
   "NewLogicalSwitch::FindCpFromHashList: no more room in the CP
pool");
return NULL;
}

pDummyCp->Init(cpId, MC_CP_PROTECTION_APP_NONE,
MC_CP_PU_TYPE_NONE,
0, dummyTcmInfo, true, true, true, true, McId::InvalidId);


pUniCp = mCpHashList.find (pDummyCp);

// Return CP to MemPool
pDummyCp->Destroy();
return pUniCp;
}


Just a command line used to compile that particular source goes like this:

/usr/local/ciena/powerpc-e500-linux-gnuspe-20160316/bin/powerpc-e500-linux-gnuspe-g++
-Wp,-MD,/simdisk/thadula/oneos/branches/centaur/dev/main/build/centaur-cn5430/libNewLS.a/chassis/powerpc-e500/32/.NewLogicalSwitch.o.d,-MP
-g -pipe -O2 -fno-delete-null-pointer-checks -std=gnu++03 -Wall -Wextra
-Wno-unused-parameter -Wno-deprecated -Wno-unused-but-set-parameter
-Wno-unused-function -Wno-unused-parameter -fPIC
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/software/centaur/apps/core/txn/Switching/NewLS
-DCIENA_CTM -DCIENA_CENTAUR -DOSI_STACK_ENABLED -DCENTAUR_5430
-DCENTAUR_SPECIFIC -DWARM_RESTART
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/hardware/uio_ciena_hdpsm/lib/
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/hardware/uio_ciena_hdpsm/ko/
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/hardware/uio_ciena_hdsm/lib/
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/hardware/uio_ciena_hdsm/ko/
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/hardware/uio_ciena_sm/lib/
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/hardware/uio_ciena_sm/ko/
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/elf-utils
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/include
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/linxipc
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/log
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/onesies
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/subsys-elf
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/cad
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/compiler
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/apps/apis
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/apps/include
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/apps/infrastructure
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/apps/notifications
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/apps/utilities
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ntp
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/nonbranched
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/system/map
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/system/shared
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/system/shared/hal
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/system/branding
-D_REENTRANT -DRW_MULTI_THREAD -DRW_POSIX_THREADS -DRWDEBUG
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/event_mgr
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/osrp/osrputil
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/hardwa

[Bug c++/70386] [6 Regression] ICE with -Wall on valid code on x86_64-linux-gnu in verify_ctor_sanity, at cp/constexpr.c:2232

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug libstdc++/69945] Provide an equivalent of __libc_freeres to release emergency EH pool memory

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Thu Mar 24 18:13:40 2016
New Revision: 234465

URL: https://gcc.gnu.org/viewcvs?rev=234465&root=gcc&view=rev
Log:
libstdc++/69945 Add __gnu_cxx::__freeres hook

PR libstdc++/69945
* config/abi/pre/gnu.ver: Add new symbol.
* libsupc++/eh_alloc.cc (__gnu_cxx::__freeres): Define.
* testsuite/18_support/free_eh_pool.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/18_support/free_eh_pool.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/abi/pre/gnu.ver
trunk/libstdc++-v3/libsupc++/eh_alloc.cc

[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
Summary|[5/6 Regression] 16%|[5 Regression] 16%
   |tramp3d-v4.cpp compile time |tramp3d-v4.cpp compile time
   |regression  |regression

--- Comment #64 from Jeffrey A. Law  ---
Removing gcc-6 regression tag per c#63.  Keeping gcc-5 regression tag.

[Bug rtl-optimization/68695] [6 Regression] Performance regression related to ssa patch / ifcvt

[vmakarov at gcc dot gnu.org]

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

--- Comment #23 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #22)
> Going back to variants of the original testcase:
> int
> foo (int x, int y, int a)
> {
>   int i = x;
>   int j = y;
> #ifdef EX1
>   if (__builtin_expect (x > y, 1))
> #elif defined EX0
>   if (__builtin_expect (x > y, 0))
> #else
>   if (x > y)
> #endif
> {
>   i = a;
>   j = i;
> }
>   return i * j;
> }
> 
> at least for the -DEX1 case I'd think it is reasonable to assign one of i or
> j to the register holding argument a (%r4), because that will for the common
> case need one fewer register move.  But, there is one further constraint. 
> The multiplication wants the result to live in %r2, because then it can
> avoid a move, and the multiplication is commutative two operand one, so one
> of the operands needs to match the output.  Thus, from this the reasonable
> disposition choices are either i in %r2 and j in %r3 (this is especially
> desirable if the if is unlikely, i.e. -DEX0 case), or perhaps i in %r2 and j
> in %r4 (while this will need if/then/else rather than if/then only, it would
> use one fewer move in the expected likely block).
> The problem is that IRA chooses i in %r4 and j in %r3, so there are 2 moves
> even in the fast path (the i = a assignment is a nop, but j = i is needed,
> and then later on extra reload move is added, because pseudo 67 disposition
> (result of mulsi3) is properly in %r2 and if one argument is %r4 and another
> one %r3, it needs to copy one to %r2.
> 
> Vlad, can you please have a look?

I investigated it.  I don't think that the desired results can be achieved
without changing existing heuristics.  Changing the existing heuristics is a
big job.  Besides rewriting code, it requires a lot of benchmarking.

Also part of problem can be solved if we use conflicts built using value
numbering instead of live-range analysis.  I don't know a RA whose conflict
graph is based on value numbering.

What I don't like is that p67 originally got r4 and then it was changed to r2
in improve_allocation.  Fixing that will improve the code but not for all
possible combinations (EX1, EX0 etc).  In any case I'll continue my work on the
PR.

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  ---
Created attachment 38084
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38084&action=edit
A new patch for testing

With y = 1.0 and d=8 I now get

-8pf18.8 y=0.0001
-7pf18.8 y=0.0010
-6pf18.8 y=0.0100
-5pf18.8 y=0.1000
-4pf18.8 y=0.0001
-3pf18.8 y=0.0010
-2pf18.8 y=0.0100
-1pf18.8 y=0.1000
0pf18.8 y=1.
1pf18.8 y=   10.
2pf18.8 y=  100.
3pf18.8 y= 1000.
4pf18.8 y=1.
5pf18.8 y=   10.
6pf18.8 y=  100.
7pf18.8 y= 1000.

Note that without the addition

@@ -70,6 +70,10 @@ determine_precision (st_parameter_dt * d
   switch (f->format)
 {
 case FMT_F:
+  precision += dtp->u.p.scale_factor;
+  if (precision < f->u.real.d)
+   precision = f->u.real.d;
+  break;
 case FMT_G:
   precision += dtp->u.p.scale_factor;
   break;

I get

-8pf18.8 y=0.
-7pf18.8 y=0.
-6pf18.8 y=0.
-5pf18.8 y=0.
-4pf18.8 y=0.0001
-3pf18.8 y=0.0010
-2pf18.8 y=0.0100
-1pf18.8 y=0.1000
0pf18.8 y=1.
1pf18.8 y=   10.
2pf18.8 y=  100.
3pf18.8 y= 1000.
4pf18.8 y=1.
5pf18.8 y=   10.
6pf18.8 y=  100.
7pf18.8 y= 1000.

[Bug c++/55004] [meta-bug] constexpr issues

[jason at gcc dot gnu.org]

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

Bug 70323 Summary: [6 regression] missing error on integer overflow in 
constexpr function result converted to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70323

   What|Removed |Added

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

[Bug c++/70323] [6 regression] missing error on integer overflow in constexpr function result converted to bool

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #11 from Jason Merrill  ---
Fixed.

[Bug c++/70323] [6 regression] missing error on integer overflow in constexpr function result converted to bool

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  ---
Author: jason
Date: Thu Mar 24 17:59:58 2016
New Revision: 234463

URL: https://gcc.gnu.org/viewcvs?rev=234463&root=gcc&view=rev
Log:
PR c++/70323

* constexpr.c (cxx_eval_call_expression): Don't cache result if
*overflow_p.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-70323a.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug c++/70403] A null pointer check removed with -O2 even with -fno-delete-null-pointers-checks

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-03-24
 Ever confirmed|0   |1
   Severity|major   |normal

--- Comment #1 from Jonathan Wakely  ---
Please provide a complete testcase, and/or preprocessed source.

https://gcc.gnu.org/bugs/

[Bug middle-end/69845] [4.9/5/6 Regression] Expression getting incorrectly optimized after being rewritten by compiler

[law at gcc dot gnu.org]

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

--- Comment #8 from Jeffrey A. Law  ---
Author: law
Date: Thu Mar 24 17:52:11 2016
New Revision: 234462

URL: https://gcc.gnu.org/viewcvs?rev=234462&root=gcc&view=rev
Log:
2016-03-24  Richard Henderson  

PR middle-end/69845
* fold-const.c (extract_muldiv_1): Correct test for multiplication
overflow.

PR middle-end/69845
* gcc.dg/tree-ssa/pr69845-1.c: New test.
* gcc.dg/tree-ssa/pr69845-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr69845-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr69845-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70403] New: A null pointer check removed with -O2 even with -fno-delete-null-pointers-checks

[thadula at ciena dot com]

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

Bug ID: 70403
   Summary: A null pointer check removed with -O2 even with
-fno-delete-null-pointers-checks
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thadula at ciena dot com
  Target Milestone: ---

g++, powerpc-e500-linux-gnuspe-g++, version 4.9.2
compiled with -O2 and -fno-delete-null-pointers-checks

Code (look for ==> to mark the point in the code):


static const char* fnName = "NewLs::CpSelect - ";
tbr_t  tbrStart, tbrEnd, timediff;

tbrStart = tbrGet();

McId newCpId((McIdHandle)cpId);
McId newSelId((McIdHandle)selId);
McCpId*  pCpId= static_cast(&newCpId);
ComplexXCon* pXCon= NULL;
CtpCpBase*   pNewSel  = NULL;
ComplexXCon* pNewXCon = NULL;
UniCp*   pCp  = NULL;

rFailureReason = LS_SUCCESS;

if (!pCpId)
{
MEMORY_LOG_MCHECK (getSwitchCoreMemoryLog(), pCpId, NULL,
   "!!!ERROR!!!: " << fnName << "null CP id");
return false;
}

// Find the CP object
pCp = FindCpFromHashList(*pCpId);
if (!pCp)
{
LOGIC_SWITCH_ERRLOG_PRINTF (getSwitchCoreMemoryLog(),
"%sCannot find CP 0x%llX", fnName, cpId);
rFailureReason = END_POINT_NOT_FOUND;
return false;
}

McCpProtectionApp protApp = pCp->GetProtApp();

if (rxProtApp != protApp)
{
.
.
.
return false;
}

pXCon = pCp->GetXCon();
if (!pXCon)
{
char mcBuf[ 64 ];

pCpId->toString (mcBuf, sizeof (mcBuf));
LOGIC_SWITCH_ERRLOG_PRINTF (getSwitchCoreMemoryLog(),
"%sCannot find XCon for CP: %s", fnName, mcBuf);
rFailureReason = CROSS_CONNECT_NOT_FOUND;
return false;
}

if (!squelch)
{
if (newSelId == McId::InvalidId)
{
rFailureReason = BAD_END_POINT_ID;
return false;
}

//
// Find the CTP or CP (if it exists) and verify that it belongs to
pXCon
//
if (newSelId.IsCtpId())
{
McCtpId ctpId(newSelId);
pNewSel = FindCtpFromHashList(ctpId);
}
else if (newSelId.IsCpId())
{
McCpId newCpId((McCpIdHandle) newSelId.GetId());
pNewSel = FindCpFromHashList(newCpId);
}
==> if (pNewSel)
pNewXCon = pNewSel->GetXCon();
}
else
{
char mcBuf[ 64 ];

pCpId->toString (mcBuf, sizeof (mcBuf));
getSwitchCoreMemoryLog()->PrintRamLog ("%sSetting %s to be squelched.",
fnName, mcBuf);
}

if (squelch || (pNewSel && pNewXCon == pXCon))
{
if (pCp->GetSelectedCtpCp() == pNewSel
|| (isDefaultFromCac && pCp->GetDefaultSelector() == pNewSel))
{
.
.
.
return false;   // already selected
}

// Update current selector on CP.
pCp->SetSelectedCtpCp(pNewSel);
.
.
.
}


Segmentation fault:

Program terminated with signal 11, Segmentation fault.
#0  CtpCpBase::GetXCon (this=this@entry=0x0) at
src/software/centaur/apps/core/txn/Switching/NewLS/CtpCpBase.cpp:79
79  if( mpXCon && mpXCon->IsRemoteTAP() && !mpXCon->IsRemoteTAPParent()
)
(gdb) bt
#0  CtpCpBase::GetXCon (this=this@entry=0x0) at
src/software/centaur/apps/core/txn/Switching/NewLS/CtpCpBase.cpp:79
#1  0x1149b610 in NewLogicalSwitch::CpSelect (this=0x671d0038, cpId=, selId=, 
rFailureReason=@0x7019e6f0: LS_SUCCESS,
rxProtApp=rxProtApp@entry=MC_CP_PROTECTION_APP_UPSR_SNCP, squelch=true, 
isDefaultFromCac=isDefaultFromCac@entry=false) at
src/software/centaur/apps/core/txn/Switching/NewLS/NewLogicalSwitch.cpp:8221
#2  0x1149bfb4 in NewLogicalSwitch::CpSelectTest (this=,
cpId=cpId@entry=2, newSelId=)
at
src/software/centaur/apps/core/txn/Switching/NewLS/NewLogicalSwitch.cpp:5869
#3  0x114c704c in NewLsDcraft::ImplementMsg (this=0x6df9b338, pObj=0x836ea7e8)
at src/software/centaur/apps/core/txn/Switching/NewLS/NewLsDcraft.cpp:711
#4  0x11cafe6c in Actor::Run (this=0x6df9b338) at
src/generic/component/Actor/Actor.cpp:929
#5  0x11bdff9c in RunnableTask::TaskFunction (this=0x6df9c970) at
src/generic/component/UtilProg/RunnableTask.cpp:35
#6  0x11593080 in LnTask::TaskEntry (pThis=0x6df9c970) at
src/generic/component/Osencap/linux/LnTask.cpp:627
#7  0x0f1ecc04 in ?? ()
#8  0x09e4a5b4 in ?? ()
(gdb) up
#1  0x1149b610 in NewLogicalSwitch::CpSelect (this=0x671d0038, cpId=, selId=, 
rFailureReason=@0x7019e6f0: LS_SUCCESS,
rxProtApp=rxProtApp@entry=MC_CP_PROTECTION_APP_UPSR_SNCP, squelch=true, 
isDefaultFromCac=isDefaultFromCac@entry=false) at
src/software/centaur/apps/core/txn/Swi

[Bug target/64971] [5/6 Regression] gcc.c-torture/compile/pr37433.c ICEs with -mabi=ilp32

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug libstdc++/69332] [6 Regression] FAIL: libstdc++-prettyprinters/libfundts.cc print ab

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at redhat dot com

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug middle-end/70307] [6 Regression] ICE: in gimplify_expr, at gimplify.c:10915 on valid code

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
I think we need to teach c_fully_fold how to fold VEC_COND_EXPR.  Until r229128
this wasn't necessary as the C FE never saw any VEC_COND_EXPRs.  But since that
revision we create a VEC_COND_EXPR when building a vector comparison.

[Bug c++/70323] [6 regression] missing error on integer overflow in constexpr function result converted to bool

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug hsa/70402] New: HSA: SBR instruction can be undefined

[marxin at gcc dot gnu.org]

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

Bug ID: 70402
   Summary: HSA: SBR instruction can be undefined
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: hsa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org
  Target Milestone: ---

As reported here:
https://github.com/HSAFoundation/gccbrig/issues/3

current HSA back-end can produce a SBR isntruction with smaller or equal number
of labels than an index value.

Martin

[Bug rtl-optimization/70164] [6 Regression] Code/performance regression due to poor register allocation on Cortex-M0

[law at redhat dot com]

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

--- Comment #14 from Jeffrey A. Law  ---
Some further notes.

I was looking at what the impact would be if we just stopped recording the
problematical equivalences in CSE, both to see if the equivalences are useful
at all, and if they are, to get a sense of when (which might perhaps lead to
some useful conditions for recording them).  I was quite surprised at how much
of a difference in the resulting code generation these equivalences make.

One of the things that is emerging is that these equivalences are useful when
the copy propagation they enable allows one operand to die at the comparison
when it didn't die before.  That in turn may allow creation of REG_EQUIV note
on the insn that initializes the dying register.  Which then allows
substitution of the equivalent memory for the register in the comparison.

We still have the same number of memory references, but we use one less
register in that case and have one less instruction.

We obviously don't have that level of insight during CSE.  But given uses/sets
DF info, we can get a lot of the way there.

Anyway, just wanted to record some of my findings.  I'm putting this down for
now as it's not likely to be a gcc-6 kind of change.

[Bug c++/62212] [4.9/5 Regression] ICE compiling template function with array reference parameter whose size depends on a template parameter

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression] ICE|[4.9/5 Regression] ICE
   |compiling template function |compiling template function
   |with array reference|with array reference
   |parameter whose size|parameter whose size
   |depends on a template   |depends on a template
   |parameter   |parameter

--- Comment #6 from Patrick Palka  ---
Fixed for GCC 6 at least.

[Bug c++/62212] [4.9/5/6 Regression] ICE compiling template function with array reference parameter whose size depends on a template parameter

[ppalka at gcc dot gnu.org]

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

--- Comment #5 from Patrick Palka  ---
Author: ppalka
Date: Thu Mar 24 15:59:53 2016
New Revision: 234457

URL: https://gcc.gnu.org/viewcvs?rev=234457&root=gcc&view=rev
Log:
Fix PR c++/62212 (ICE during mangling of array type)

gcc/cp/ChangeLog:

PR c++/62212
* tree.c (build_cplus_array_type): Determine type-dependentess
with uses_template_parms instead of with dependent_type_p.

gcc/testsuite/ChangeLog:

PR c++/62212
* g++.dg/template/mangle2.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/template/mangle2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70029] [6 Regression] ICE with C++11 and -flto

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
The problem is that decl_attributes uses build_type_attribute_qual_variant,
which uses build_qualified_type, which doesn't understand C++ type variants and
blithely returns an attribute-qualified type which isn't ref-qualified like the
original type.  One way to address this would be to add a langhook for
check_qualified_type.  Otherwise the front end would need to stop representing
exception specifications and ref-qualifiers as type variants.

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||kugan at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
I see multiple points of the increases:
r224048 added 4 bytes.
r224995 added 8 bytes.
r228318 added 4 bytes.

Perhaps the middle one could change from
(if (single_use (@2)
 || (TREE_CODE (@1) == INTEGER_CST && TREE_CODE (@3) == INTEGER_CST))
to
(if (single_use (@2)
 || (!optimize_size && TREE_CODE (@1) == INTEGER_CST && TREE_CODE (@3) ==
INTEGER_CST))
(or some optimize*for_speed*)?
CCing authors of the other commits.  That said, complaining about size
regressions generally should be only if it (significantly) increases sizes of
some larger codebases (CSiBE, size of some large app, ...), when looking at a
single function only, there will be always improvements and degradations, the
compiler is changing.

[Bug c/70400] GCC compiles a return statement with an expression in a void function (illegal under C90 6.6.6.4) with -std=c90 -pedantic

[ryao at gentoo dot org]

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

Richard Yao  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #3 from Richard Yao  ---
It says "reject all programs that use forbidden extensions, and some other
programs that do not follow ISO C and ISO C++." This is C++ extension as far as
ISO C is concerned:

"A return statement with an operand of type void shall be used only in a
function whose return type is cv void."

http://eel.is/c++draft/stmt.return

[Bug target/70216] [SH] Implement __builtin_trap

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo  ---
Created attachment 38083
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38083&action=edit
Proposed patch

This patch adds two new target options:
  -msh4-trapa-sleep-bug
  -mbuiltin-trap=

and two configure options:
  --with-builtin-trap
  --enable-sh4-trapa-sleep-bug / --disable-sh4-trapa-sleep-bug

On sh*-linux it should configure itself to use -mbuiltin-trap=trapa,imm=84 by
default.

I'm not sure if the -msh4-trapa-sleep-bug should be enabled by default on
sh*-linux to always emit the workaround insn sequence (trap + 5x or r0,r0).  If
--enable-sh4-trapa-sleep-bug is not specified, it will only be enabled when
compiling code for SH4.

[Bug c/70400] GCC compiles a return statement with an expression in a void function (illegal under C90 6.6.6.4) with -std=c90 -pedantic

[ryao at gentoo dot org]

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

--- Comment #4 from Richard Yao  ---
How would GCC "reject all programs" without emitting an error? If there is some
other way, it is not being done as GCC emits assembly that assembles and links
without a problem. Rejecting the program should not allow things to go so far.
If `-pedantic` does not cause programs to be rejected under any circumstance,
then the documentation is wrong.

[Bug c++/70401] New: [c++1z on mingw]compile variadic template failed

[xiangli_zhao at hotmail dot com]

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

Bug ID: 70401
   Summary: [c++1z on mingw]compile variadic template failed
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xiangli_zhao at hotmail dot com
  Target Milestone: ---

Created attachment 38082
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38082&action=edit
a variadic template class fizzbuzz in attached.

mingw version gcc download from 
http://120.52.73.49/tenet.dl.sourceforge.net/project/mingw-w64/Toolchains%20targetting%20Win64/Personal%20Builds/dongsheng-daily/6.x/gcc-6-win64_6.0.0-20160318.7z

when I compile variadic template aa.cpp （see attached), 
g++ -std=c++1z aa.cpp -o aa.exe
I got an error said

Internal compiler error: Error reporting routines re-entered.
libbacktrace could not find executable to open

Thanks a lot

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #3 from Patrick Palka  ---
(In reply to Jakub Jelinek from comment #2)
> Started with r217664.

I assume that's with -std=c++11?  I wonder which commit introduced the
regression when the test case is compiled with -std=c++14.

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Yeah, that was with -std=c++0x.  With -std=c++1y it started one revision
earlier (r217663).

[Bug c/70400] GCC compiles a return statement with an expression in a void function (illegal under C90 6.6.6.4) with -std=c90 -pedantic

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Jonathan Wakely  ---
(In reply to Richard Yao from comment #0)
> GCC will only emit a warning when -pendantic is specified and adding
> -std=c90 does not change the behavior to a warning. The documentation for
> -pedantic clearly states that things disallowed by the specification emit
> errors:
> 
> https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/Warning-Options.html

No, it clearly states that it produces warnings (I count six mentions of
warnings and none of errors). And it clearly says -pedantic-errors means you
get errors not warnings.

[Bug c/70400] GCC compiles a return statement with an expression in a void function (illegal under C90 6.6.6.4) with -std=c90 -pedantic

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
Use -pedantic-errors to turn pedantic diagnostics into errors.

[Bug ipa/70366] [6 Regression] chromium fails to build with LTO due to segfault in ipa-inline-transform.c:inline_call

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #5 from prathamesh3492 at gcc dot gnu.org ---
(In reply to prathamesh3492 from comment #4)
> Created attachment 38076 [details]
> patch
> 
> Hi,
> The attached patch suggested by Richard fixes the chromium build.
> It passes bootstrap+test on x86_64-unknown-linux-gnu
> and cross-tested on arm*-*-* and aarch64*-*-*.
> The patch however regresses libstdc++ for arm-none-eabi:
> http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/
> 234391-70366/arm-none-eabi/diff-libstdc++-rh60-arm-none-eabi-arm-cortex-a9-
> default.txt
> Looking at the logs there isn't much information:
> compiler exited with status 1
> FAIL: 25_algorithms/partial_sort/moveable.cc (test for excess errors)
> Excess errors:
> exit status is 1
> WARNING: 25_algorithms/partial_sort/moveable.cc compilation failed to
> produce executable
> The complete log is at:
> http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/
> 234391-70366/arm-none-eabi/libstdc++-rh60-arm-none-eabi-arm-cortex-a9-
> default.log.xz
Hi,
The failure was probably due to validation issues and not the patch.
Re-running the validation didn't show up any regressions on arm*-*-*
and aarch64*-*-*.
I posted the patch upstream:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01376.html

Thanks,
Prathamesh
> 
> I don't have much ideas on how to proceed.
> I am trying to reduce the test-case, and reproduce the above regression
> locally and will get back if I find more information.
> 
> Thanks,
> Prathamesh

[Bug c/70400] New: GCC compiles a return statement with an expression in a void function (illegal under C90 6.6.6.4) with -std=c90 -pedantic

[ryao at gentoo dot org]

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

Bug ID: 70400
   Summary: GCC compiles a return statement with an expression in
a void function (illegal under C90 6.6.6.4) with
-std=c90 -pedantic
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryao at gentoo dot org
  Target Milestone: ---

Created attachment 38081
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38081&action=edit
Test case where GCC allows a void function to return an expression

ISO C90 6.6.6.4 says that "A return statement with an expression shall not
appear in a function whose return type is void."

Both Sun Studio and the TenDRA make this a build failure as the specification
requires while Clang does what GCC does. The sudo project had a bug filed
agaisnt it because of Sun Studio:

https://bugzilla.sudo.ws/show_bug.cgi?id=727

GCC will only emit a warning when -pendantic is specified and adding -std=c90
does not change the behavior to a warning. The documentation for -pedantic
clearly states that things disallowed by the specification emit errors:

https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/Warning-Options.html

This probably should be a warning even without `-pendantic`.

[Bug hsa/70399] New: HSA: Wrong emission of st_align(4)_u8 HSAIL insn

[marxin at gcc dot gnu.org]

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

Bug ID: 70399
   Summary: HSA:  Wrong emission of st_align(4)_u8 HSAIL insn
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: hsa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org
  Target Milestone: ---

Hello.

Attached source file is miscompiled with HSA back-end:

$ HSAILasm -disassemble phsa-temp/program-0.brig 
$ HSAILasm phsa-temp/program-0.hsail

>   st_align(4)_u8  9, 0, 0, 0, [$d0+8];
>  ^
input(10,20): Invalid operand 1, expected: an address

Martin

[Bug hsa/70399] HSA: Wrong emission of st_align(4)_u8 HSAIL insn

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 38080
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38080&action=edit
test case

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

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

--- Comment #12 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #11)
> > Created attachment 38075 [details]
> > A patch for testing
> 
> With the patch and using the test attached to comment 5 with y = 1.0 and
> d=8, I get the following output
> 
> -8pf18.8 y=0.000.
> -7pf18.8 y=0.00.0
... snip ...
> which is wrong for P<=-2.

OK great, this is related to the conditions for the shift, thanks.  I will keep
at it.

[Bug tree-optimization/70396] ICE on valid code at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (in immed_wide_int_const, at emit-rtl.c:606)

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Mar 24 14:07:42 2016
New Revision: 234455

URL: https://gcc.gnu.org/viewcvs?rev=234455&root=gcc&view=rev
Log:
2016-03-24  Richard Biener  

PR tree-optimization/70396
* tree-vect-stmts.c (vectorizable_comparison): Use
get_vectype_for_scalar_type.

* gcc.dg/torture/pr70396.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr70396.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug tree-optimization/70396] ICE on valid code at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (in immed_wide_int_const, at emit-rtl.c:606)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug c/70297] [5/6 Regression] GCC Segfaults when using -g3

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
Patch posted .

[Bug rtl-optimization/70398] [6 Regression] gcc.dg/vect/slp-multitypes-9.c FAILs with -fno-tree-loop-optimize -fno-tree-ter

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-24
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.

[Bug c++/70353] [5/6 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #10 from Patrick Palka  ---
It's a hack, but we could pull the STRING_CST out from the artificial VAR_DECL
during constexpr evaluation to avoid referring to __func__'s symbol.

--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -3354,6 +3354,11 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx,
tree t,

 case VAR_DECL:
 case CONST_DECL:
+  if (VAR_P (t)
+ && DECL_ARTIFICIAL (t)
+ && TREE_STATIC (t)
+ && TREE_CODE (DECL_INITIAL (t)) == STRING_CST)
+   return DECL_INITIAL (t);
   /* We used to not check lval for CONST_DECL, but darwin.c uses
 CONST_DECL for aggregate constants.  */
   if (lval)

[Bug rtl-optimization/70398] [6 Regression] gcc.dg/vect/slp-multitypes-9.c FAILs with -fno-tree-loop-optimize -fno-tree-ter

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ra
   Target Milestone|--- |6.0

[Bug hsa/70394] HSA: kernel dispatch packet mechanism uses uninitialized memory

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Martin Liška  ---
Fixed.

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |5.4

--- Comment #2 from Jakub Jelinek  ---
Started with r217664.

[Bug c++/70395] [C++11] Error when initializing array of non-copyable non-trivial type in constructor initializer list

[mosra at centrum dot cz]

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

--- Comment #2 from Vladimír Vondruš  ---
Forgot to add that if I default the move constructor/assignment, it also
compiles fine (as the error message suggests).

[Bug rtl-optimization/70398] New: [6 Regression] gcc.dg/vect/slp-multitypes-9.c FAILs with -fno-tree-loop-optimize -fno-tree-ter

[zsojka at seznam dot cz]

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

Bug ID: 70398
   Summary: [6 Regression] gcc.dg/vect/slp-multitypes-9.c FAILs
with -fno-tree-loop-optimize -fno-tree-ter
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
Target: aarch64-unknown-linux-gnu

Created attachment 38079
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38079&action=edit
reduced testcase

Output (qemu userspace emulation):
$ aarch64-unknown-linux-gnu gcc -O -fno-tree-loop-optimize -fno-tree-ter
-static testcase.c
$ ./a.out 
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

Crash is at:
Dump of assembler code for function main:
   0x00400ac8 <+0>: mov w2, #0x0// #0
   0x00400acc <+4>: adrpx4, 0x49
   0x00400ad0 <+8>: add x4, x4, #0x10
   0x00400ad4 <+12>:adrpx3, 0x493000 
   0x00400ad8 <+16>:add x3, x3, #0x530
   0x00400adc <+20>:lsl w0, w2, #1
=> 0x00400ae0 <+24>:ldrbw1, [x4,x5]
   0x00400ae4 <+28>:add w1, w1, #0x1
   0x00400ae8 <+32>:strbw1, [x3,w0,sxtw]

x5 is never initialised.

.ira has:
(insn 8 7 11 3 (set (reg:SI 74 [ _5 ])
(ashift:SI (reg/v:SI 82 [ i ])
(const_int 1 [0x1]))) testcase.c:13 636
{*aarch64_ashl_sisd_or_int_si3}
 (nil))
(note 11 8 12 3 NOTE_INSN_DELETED)
(insn 12 11 13 3 (set (reg:SI 75 [ _6 ])
(mem:SI (plus:DI (sign_extract:DI (mult:DI (subreg:DI (reg:SI 74 [ _5
]) 0)
(const_int 4 [0x4]))
(const_int 34 [0x22])
(const_int 0 [0]))
(reg/f:DI 102)) [1 in S4 A64])) testcase.c:13 49
{*movsi_aarch64}
 (expr_list:REG_EQUIV (mem:SI (plus:DI (sign_extract:DI (mult:DI (subreg:DI
(reg:SI 74 [ _5 ]) 0)
(const_int 4 [0x4]))
(const_int 34 [0x22])
(const_int 0 [0]))
(reg/f:DI 102)) [1 in S4 A64])
(nil)))
(insn 13 12 14 3 (set (reg:SI 76 [ _7 ])
(zero_extend:SI (subreg:QI (reg:SI 75 [ _6 ]) 0))) testcase.c:13 90
{*zero_extendqisi2_aarch64}
 (expr_list:REG_DEAD (reg:SI 75 [ _6 ])
(nil)))

but .reload has:
(insn 8 7 11 3 (set (reg:SI 0 x0 [orig:74 _5 ] [74])
(ashift:SI (reg/v:SI 2 x2 [orig:82 i ] [82])
(const_int 1 [0x1]))) testcase.c:13 636
{*aarch64_ashl_sisd_or_int_si3}
 (nil))
(note 11 8 12 3 NOTE_INSN_DELETED)
(note 12 11 13 3 NOTE_INSN_DELETED)
(insn 13 12 14 3 (set (reg:SI 1 x1 [orig:76 _7 ] [76])
(zero_extend:SI (mem:QI (plus:DI (reg/f:DI 4 x4 [102])
(reg:DI 5 x5 [139])) [1 in S1 A64]))) testcase.c:13 90
{*zero_extendqisi2_aarch64}
 (nil))


.ira might be correct, but .reload is wrong. Insn 12 is deleted without any
replacement (and it turns out, the same happens with insn 25)


@@ -23,12 +23,14 @@
 .L2:
.loc 1 13 0 is_stmt 0 discriminator 3
lsl w0, w2, 1
-   ldrbw1, [x4, x5]
+   lsl w5, w0, 2
+   ldrbw1, [x4, w5, sxtw]
add w1, w1, 1
strbw1, [x3, w0, sxtw]
.loc 1 14 0 is_stmt 1 discriminator 3
add w0, w0, 1
-   ldrbw1, [x4, x6]
+   lsl w6, w0, 2
+   ldrbw1, [x4, w6, sxtw]
add w1, w1, 2
strbw1, [x3, w0, sxtw]
.loc 1 11 0 discriminator 3


fixes the asm.


Tested revisions:
trunk r234405 - FAIL
5-branch r234375 - OK

[Bug tree-optimization/70396] ICE on valid code at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (in immed_wide_int_const, at emit-rtl.c:606)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
  /* Invariant comparison.  */
  if (!vectype)
{
  vectype = build_vector_type (TREE_TYPE (rhs1), nunits);
  if (tree_to_shwi (TYPE_SIZE_UNIT (vectype)) != current_vector_size)
return false;

it should _always_ use get_vectype_for_scalar_type

[Bug tree-optimization/70396] ICE on valid code at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (in immed_wide_int_const, at emit-rtl.c:606)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-24
  Component|rtl-optimization|tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

604   /* Allow truncation but not extension since we do not know if the
605  number is signed or unsigned.  */
606   gcc_assert (prec <= v.get_precision ());
607
608   if (len < 2 || prec <= HOST_BITS_PER_WIDE_INT)
609 return gen_int_mode (v.elt (0), mode);
610
(gdb) p prec
$1 = 8
(gdb) p mode
$2 = QImode
(gdb) p v.get_precision ()
$3 = 3

we indeed have

  constant 8>
unit size  constant 1>
align 8 symtab 0 alias set 2 canonical type 0x7698b2a0 precision 3 min
 max >
$7 = void

constants in the VECTOR_CST we expand and it has a vector type with
bit-precision element type.

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-24
  Known to work||4.9.3
Summary|Miscompilation: missing |[5/6 Regression]
   |constructor call for static |Miscompilation: missing
   |object  |constructor call for static
   ||object
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
ubsan prints lots of errors confirming that the vptr is not setup up correctly.

[Bug c++/70395] [C++11] Error when initializing array of non-copyable non-trivial type in constructor initializer list

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Probably a dup of PR 63707

[Bug middle-end/70370] ICE in execute_todo, at passes.c:2003 when using __real__ or __imag__ as lvalue in asm

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Thu Mar 24 12:19:56 2016
New Revision: 234453

URL: https://gcc.gnu.org/viewcvs?rev=234453&root=gcc&view=rev
Log:
2016-03-24  Richard Biener  

PR middle-end/70370
* gimplify.c (gimplify_asm_expr): Handle !allows_mem outputs
with register bases.

* gcc.dg/torture/pr70370.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr70370.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/70370] ICE in execute_todo, at passes.c:2003 when using __real__ or __imag__ as lvalue in asm

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
Fixed for GCC 6.

[Bug fortran/70397] New: ice while allocating ultimate polymorphic

[valeryweber at hotmail dot com]

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

Bug ID: 70397
   Summary: ice while allocating ultimate polymorphic
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valeryweber at hotmail dot com
  Target Milestone: ---

Dear All
The following code is ICEing.
v

cat gcc-ice-polym.f90
module mod

  TYPE, PUBLIC :: base_type
  END TYPE base_type

  TYPE, PUBLIC :: dict_entry_type
 PRIVATE
 CLASS( * ), ALLOCATABLE :: key
 CLASS( * ), ALLOCATABLE :: val
  END TYPE dict_entry_type


contains

  SUBROUTINE dict_put ( this, key, val )
CLASS(dict_entry_type), INTENT(INOUT) :: this
CLASS(base_type), INTENT(IN) :: key, val
INTEGER  :: istat
ALLOCATE( this%key, SOURCE=key, STAT=istat )
  end SUBROUTINE dict_put
end module mod

gfortran-5.3.0  -c gcc-ice-polym.f90
gcc-ice-polym.f90:19:0:

 ALLOCATE( this%key, SOURCE=key, STAT=istat )
 1
internal compiler error: Segmentation fault
0xa3420f crash_signal
../../gcc-5.3.0/gcc/toplev.c:383
0x69c8b8 gfc_class_len_get(tree_node*)
../../gcc-5.3.0/gcc/fortran/trans-expr.c:170
0x69fcb7 gfc_copy_class_to_class(tree_node*, tree_node*, tree_node*, bool)
../../gcc-5.3.0/gcc/fortran/trans-expr.c:1052
0x6d6fec gfc_trans_allocate(gfc_code*)
../../gcc-5.3.0/gcc/fortran/trans-stmt.c:5630
0x678bd7 trans_code
../../gcc-5.3.0/gcc/fortran/trans.c:1820
0x6995c4 gfc_generate_function_code(gfc_namespace*)
../../gcc-5.3.0/gcc/fortran/trans-decl.c:5851
0x67a1b9 gfc_generate_module_code(gfc_namespace*)
../../gcc-5.3.0/gcc/fortran/trans.c:2036
0x635118 translate_all_program_units
../../gcc-5.3.0/gcc/fortran/parse.c:5330
0x635118 gfc_parse_file()
../../gcc-5.3.0/gcc/fortran/parse.c:5540
0x674dd5 gfc_be_parse_file
../../gcc-5.3.0/gcc/fortran/f95-lang.c:229
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/70396] New: ICE on valid code at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (in immed_wide_int_const, at emit-rtl.c:606)

[chengniansun at gmail dot com]

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

Bug ID: 70396
   Summary: ICE on valid code at -O3 in 32-bit and 64-bit modes on
x86_64-linux-gnu (in immed_wide_int_const, at
emit-rtl.c:606)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

The following code crashes the trunk at -O3 in 32-bit and 64-bit modes on
x86_64-linux-gnu.



$: 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/6.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
Thread model: posix
gcc version 6.0.0 20160324 (experimental) [trunk revision 234448] (GCC) 
$: 
$: gcc-trunk -O3 small.c
small.c:4:5: warning: array ‘a’ assumed to have one element
 int a[];
 ^
small.c: In function ‘fn1’:
small.c:11:14: warning: iteration 2147483645 invokes undefined behavior
[-Waggressive-loop-optimizations]
   for (; c; c++) {
 ~^~
small.c:11:3: note: within this loop
   for (; c; c++) {
   ^~~
small.c:7:6: internal compiler error: in immed_wide_int_const, at
emit-rtl.c:606
 void fn1() {
  ^~~
0x806f7d immed_wide_int_const(generic_wide_int >
const&, machine_mode)
../../gcc-source-trunk/gcc/emit-rtl.c:606
0x82b5ce const_vector_from_tree
../../gcc-source-trunk/gcc/expr.c:11531
0x82b5ce expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-source-trunk/gcc/expr.c:9748
0xa65c6a expand_expr
../../gcc-source-trunk/gcc/expr.h:256
0xa65c6a vector_compare_rtx
../../gcc-source-trunk/gcc/optabs.c:5299
0xa7025d expand_vec_cond_expr(tree_node*, tree_node*, tree_node*, tree_node*,
rtx_def*)
../../gcc-source-trunk/gcc/optabs.c:5629
0x840c35 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc-source-trunk/gcc/expr.c:9358
0x7274a1 expand_gimple_stmt_1
../../gcc-source-trunk/gcc/cfgexpand.c:3654
0x7274a1 expand_gimple_stmt
../../gcc-source-trunk/gcc/cfgexpand.c:3714
0x7296ea expand_gimple_basic_block
../../gcc-source-trunk/gcc/cfgexpand.c:5720
0x72eafe execute
../../gcc-source-trunk/gcc/cfgexpand.c:6335
Please submit a full bug report,
with preprocessed source if appropriate.
gcc version 6.0.0 20160324 (experimental) [trunk revision 234448] (GCC)
$:
$: gcc-trunk -O3 small.c
small.c:4:5: warning: array ‘a’ assumed to have one element
 int a[];
 ^
small.c: In function ‘fn1’:
small.c:11:14: warning: iteration 2147483645 invokes undefined behavior
[-Waggressive-loop-optimizations]  
   for (; c; c++) {
 ~^~
small.c:11:3: note: within this loop
   for (; c; c++) {
   ^~~
small.c:7:6: internal compiler error: in immed_wide_int_const, at
emit-rtl.c:606
 void fn1() {
  ^~~
0x806f7d immed_wide_int_const(generic_wide_int >
const&, machine_mode)
../../gcc-source-trunk/gcc/emit-rtl.c:606
0x82b5ce const_vector_from_tree
../../gcc-source-trunk/gcc/expr.c:11531
0x82b5ce expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-source-trunk/gcc/expr.c:9748
0xa65c6a expand_expr
../../gcc-source-trunk/gcc/expr.h:256
0xa65c6a vector_compare_rtx
../../gcc-source-trunk/gcc/optabs.c:5299
0xa7025d expand_vec_cond_expr(tree_node*, tree_node*, tree_node*, tree_node*,
rtx_def*)
../../gcc-source-trunk/gcc/optabs.c:5629
0x840c35 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc-source-trunk/gcc/expr.c:9358
0x7274a1 expand_gimple_stmt_1
../../gcc-source-trunk/gcc/cfgexpand.c:3654
0x7274a1 expand_gimple_stmt
../../gcc-source-trunk/gcc/cfgexpand.c:3714
0x7296ea expand_gimple_basic_block
../../gcc-source-trunk/gcc/cfgexpand.c:5720
0x72eafe execute
../../gcc-source-trunk/gcc/cfgexpand.c:6335
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.
$:
$: cat small.c
struct S2 {
  signed f1 : 3;
};
int a[];
int b, c;
char d;
void fn1() {
  struct S2 e;
  b / e.f1;
  c = 2;
  for (; c; c++) {
d = 0;
a[c] = ~e.f1 != d;
  }
}
$:

[Bug c++/70395] New: [C++11] Error when initializing array of non-copyable non-trivial type in constructor initializer list

[mosra at centrum dot cz]

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

Bug ID: 70395
   Summary: [C++11] Error when initializing array of non-copyable
non-trivial type in constructor initializer list
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mosra at centrum dot cz
  Target Milestone: ---

I am getting an error when trying to compile the following snippet:

struct NonCopyable {
NonCopyable(const NonCopyable&) = delete;
NonCopyable(NonCopyable&&) = delete;
NonCopyable& operator=(const NonCopyable&) = delete;
NonCopyable& operator=(NonCopyable&&) = delete;

NonCopyable() {}

~NonCopyable() {} // to make it non-trivial
};

union A {
A(): _a{} {}
~A() {}

NonCopyable _a[5];
} a;

int main() {}

GCC 5.3 complains that `error: use of deleted function
‘NonCopyable::NonCopyable(NonCopyable&&)’`, both Clang 3.7 and MSVC 2015
compile fine. I really don't see why it should use a move constructor for
initializing the elements. The behavior differs when I make the following
changes:

- If I make the `_a` member a non-array, it compiles fine.
- If I remove the `NonCopyable` destructor, the struct is trivial again and
everything compiles fine
- If I use placement new instead of `_a{}`, everything compiles fine (but
that's verbose)

The behavior is the same for struct and union, I used union to emphasize that I
need to do the initialization explicitly.

This probably affects also older versions, didn't have a chance to test.

[Bug hsa/70394] New: HSA: kernel dispatch packet mechanism uses uninitialized memory

[marxin at gcc dot gnu.org]

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

Bug ID: 70394
   Summary: HSA: kernel dispatch packet mechanism uses
uninitialized memory
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: hsa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org
  Target Milestone: ---

As seen in PHSA runtime:

==7960== Thread 2:
==7960== Conditional jump or move depends on uninitialised value(s)
==7960==at 0xCEA5714: __phsa_launch_wg_function (in
/home/visit0r/src/phsa-finalizer/build/rt/libphsa-rt.so)
==7960==by 0xBA89C35: main__omp_fn_0 (in
/home/visit0r/temp/test_cases/phsa-temp/program-0.so)
==7960==by 0x5EF1B32: CpuAgent::DoWork() (cpu_agent.cpp:155)
==7960==by 0x5EF15ED: CpuKernelExecutorThread(CpuAgent*) (cpu_agent.cpp:68)
==7960==by 0x5EFAE8A: void boost::_bi::list1
>::operator()(boost::_bi::type,
void (*&)(CpuAgent*), boost::_bi::list0&, int) (bind.hpp:253)
==7960==by 0x5EFAB24: boost::_bi::bind_t > >::operator()()
(bind_template.hpp:20)
==7960==by 0x5EFA771: boost::detail::thread_data > >
>::run() (thread.hpp:117)
==7960==by 0x6B11A49: ??? (in
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0)
==7960==by 0x506D181: start_thread (pthread_create.c:312)
==7960==by 0x537D47C: clone (clone.S:111)

Our current code does not properly set packet->header field.

Martin

[Bug target/70290] -mavx512vl breaks parsing of C++ vector condition

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 24 11:26:44 2016
New Revision: 234450

URL: https://gcc.gnu.org/viewcvs?rev=234450&root=gcc&view=rev
Log:
PR target/70290
* g++.dg/ext/pr70290.C: Add -Wno-psabi -w to dg-options.  Formatting.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/pr70290.C

[Bug other/70346] [libvtv] 6.0-20160313 build succeeds, install fails: cannot stat '.libs/libvtv.a': No such file or directory

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-03-24
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Botcazou  ---
> Build succeeds and seems to build libvtv.la and libvtv.so*, but the install
> step fails because it can't find libvtv.a. It seems like there are missing
> targets/dependencies or some kind of make race:

Which version of GNU make do you use?

[Bug c++/70305] 5.3.0 solaris: ld: fatal: relocation error: R_SPARC_DISP32: file ../src/c++11/.libs/libc++11convenience.a

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-03-24
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Botcazou  ---
> Example showing where the `-z relax=comdat` flag needed to be applied in the
> generated configure files to get a working build. Ultimately this flag
> should not be necessary and the compiler should be emitting correct
> relocations.

This looks like the Solaris linker putting itself in a corner: if it cannot
deal with relocations to discarded sections, then it should not discard the
sections in the first place!  Please report this to Oracle first.

[Bug c++/70393] New: Miscompilation: missing constructor call for static object

[js at alien8 dot de]

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

Bug ID: 70393
   Summary: Miscompilation: missing constructor call for static
object
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: js at alien8 dot de
  Target Milestone: ---

Created attachment 38078
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38078&action=edit
Testcase

For the attached testcase, g++ on Linux miscompiles and there is no constructor
called for the static object. That results in the vtable being 0 and the
program segfaulting. clang compiles this without problem.

% g++ --version
g++ (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

To reproduce do the following:

% g++ -std=c++11 -o testcase testcase.cpp
% ./testcase 
set_element() on B @ 0x602070
call_element() on B @ 0x602070
zsh: segmentation fault (core dumped)  ./testcase

Expected output is this:
% clang++ -std=c++11 -o testcase testcase.cpp 
% ./testcase 
set_element() on B @ 0x602068
call_element() on B @ 0x602068
vfunc() on AB @ 0x602068

[Bug c/70389] uint_16t left shift with -Wconversion produces incorrect warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
For unsigned short x <<= 1U is after integral promotions
x = (((int) x) << 1U);
and -Wconversion warns about the conversion of the int value to unsigned short.
Consider e.g. x being 0x8000, x << 1U then is 0x1 and the implicit
conversion alters the value.
If x is unsigned int, there is no promotion, so if x is e.g. 0x8000U, then
x << 1U is 0 and nothing is altered.

[Bug tree-optimization/70390] [6 Regression] internal compiler error: in copy_loop_close_phi_args, at graphite-isl-ast-to-gimple.c:2114

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug c++/70387] -fnon-call-exceptions has no effect

[jwjagersma at gmail dot com]

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

--- Comment #2 from jwjagersma at gmail dot com ---
Created attachment 38077
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38077&action=edit
Test case

I reduced my code to the bare minimum required to reproduce this issue.

Compile with djgpp:
"g++ -std=gnu++14 -fnon-call-exceptions -fasynchronous-unwind-tables -o
traptest.exe traptest.cpp"

[Bug tree-optimization/70392] New: [openacc] inconsistent line numbers in uninitialised warnings for if clause

[vries at gcc dot gnu.org]

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

Bug ID: 70392
   Summary: [openacc] inconsistent line numbers in uninitialised
warnings for if clause
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

I. uninitialized warning, regular

1. In fortran, the line number for the uninitialized warning is the one for the
use:
...
$ cat -n uninit.f95 
 1  subroutine foo
 2  
 3integer :: i
 4  
 5i = i + 1
 6  
 7  end subroutine foo
$ gfortran -Wuninitialized uninit.f95 -S
uninit.f95:5:0:

   i = i + 1

Warning: ‘i’ is used uninitialized in this function [-Wuninitialized]


2. In C, that's the same:
...
$ cat -n uninit.c
 1  void
 2  foo (void)
 3  {
 4int i;
 5  
 6i++;
 7  }
$ gcc -Wuninitialized uninit.c -S
uninit.c: In function ‘foo’:
uninit.c:6:4: warning: ‘i’ is used uninitialized in this function
[-Wuninitialized]
   i++;
   ~^~
...

3. And in C++, still the same:
...
$ g++ -Wuninitialized uninit.c -S
uninit.c: In function ‘void foo()’:
uninit.c:6:6: warning: ‘i’ is used uninitialized in this function
[-Wuninitialized]
   i++;
  ^
...


II. uninitialized warning, openacc if-clause

1. Again, in Fortran, the line number for the uninitialized warning is the one
for the use:
...
$ cat -n uninit-if.f95
 1  
 2  program test
 3implicit none
 4logical :: b, b2, b3, b4
 5integer :: data, data2
 6  
 7!$acc parallel if(b)
 8!$acc end parallel
 9  
10!$acc kernels if(b2)
11!$acc end kernels
12  
13!$acc data if(b3)
14!$acc end data
15  
16!$acc update if(b4) self(data2)
17  
18  end program test
$ gfortran -Wuninitialized uninit-if.f95 -S -fopenacc
uninit-if.f95:7:0:

   !$acc parallel if(b)

Warning: ‘b’ is used uninitialized in this function [-Wuninitialized]
uninit-if.f95:10:0:

   !$acc kernels if(b2)

Warning: ‘b2’ is used uninitialized in this function [-Wuninitialized]
uninit-if.f95:13:0:

   !$acc data if(b3)

Warning: ‘b3’ is used uninitialized in this function [-Wuninitialized]
uninit-if.f95:16:0:

   !$acc update if(b4) self(data2)

Warning: ‘b4’ is used uninitialized in this function [-Wuninitialized]
...

2. In C, that's the same:
...
$ cat -n uninit-if.c
 1  #include 
 2  
 3  int
 4  main (void)
 5  {
 6int i, i2, i3, i4;
 7bool b, b2, b3, b4;
 8int data, data2;
 9  
10#pragma acc parallel if(i)
11;
12  
13#pragma acc parallel if(b)
14;
15  
16#pragma acc kernels if(i2)
17;
18  
19#pragma acc kernels if(b2)
20;
21  
22#pragma acc data if(i3)
23;
24  
25#pragma acc data if(b3)
26;
27  
28#pragma acc update if(i4) self(data)
29;
30  
31#pragma acc update if(b4) self(data2)
32;
33  
34  }
$ ./lean/install/bin/gcc -Wuninitialized uninit-if.c -S -fopenacc
uninit-if.c: In function ‘main’:
uninit-if.c:10:27: warning: ‘i’ is used uninitialized in this function
[-Wuninitialized]
   #pragma acc parallel if(i)
   ^
uninit-if.c:13:27: warning: ‘b’ is used uninitialized in this function
[-Wuninitialized]
   #pragma acc parallel if(b)
   ^
uninit-if.c:16:26: warning: ‘i2’ is used uninitialized in this function
[-Wuninitialized]
   #pragma acc kernels if(i2)
  ^~
uninit-if.c:19:26: warning: ‘b2’ is used uninitialized in this function
[-Wuninitialized]
   #pragma acc kernels if(b2)
  ^~
uninit-if.c:22:23: warning: ‘i3’ is used uninitialized in this function
[-Wuninitialized]
   #pragma acc data if(i3)
   ^~
uninit-if.c:25:23: warning: ‘b3’ is used uninitialized in this function
[-Wuninitialized]
   #pragma acc data if(b3)
   ^~
uninit-if.c:28:25: warning: ‘i4’ is used uninitialized in this function
[-Wuninitialized]
   #pragma acc update if(i4) self(data)
 ^~
uninit-if.c:31:25: warning: ‘b4’ is used uninitialized in this function
[-Wuninitialized]
   #pragma acc update if(b4) self(data2)
 ^~
...

3. For C++ however, for the bool variables, we get the line number of the
declaration:
...
$ ./lean/install/bin/g++ -Wuninitialized uninit-if.c -S -fopenacc
uninit-if.c: In function ‘int main()’:
uninit-if.c:10:29: warning: ‘i’ is used uninitialized in this function
[-Wuninitialized]
   #pragma acc parallel if(i)
 ^
uninit-if.c:7:8: warning: ‘b’ is used uninitialized in this function
[-Wuninitialized]
   bool b, b2, b3, b4;
^
uninit-if.c

[Bug tree-optimization/70390] [6 Regression] internal compiler error: in copy_loop_close_phi_args, at graphite-isl-ast-to-gimple.c:2114

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
graphite uses a strange "premature optimization" with scev_analyzable_p
which seems to be confused about a degenerate IV we have in the loop.

  
  _1 = PHI <_2, _3>
  _3 = _1;

   if ()  goto exit

   goto bbN;

  exit:
   _5 = PHI <_3>

interestingly the copyprop pass before graphite doesn't fix this up.

Ah, before copyprop we have

  _57 = -1;

...

  # prephitmp_59 = PHI 
  _16 = _57 & prephitmp_59;

which SCCP introduces (during it's constant "non-"propagation, not during
final value replacement).

Note that copyprop doesn't visit "uninteresting" stmts (like _16 = _57 &
prephitmp_59), it merely folds them at the end of propagation which
figures out _57 is -1.

Not sure if the GRAPHITE assert is necessary or merely a hint that some
optimization didn't apply - that is, do we actually generate wrong-code
if it triggers?

Index: gcc/graphite-isl-ast-to-gimple.c
===
--- gcc/graphite-isl-ast-to-gimple.c(revision 234449)
+++ gcc/graphite-isl-ast-to-gimple.c(working copy)
@@ -2112,7 +2112,7 @@ copy_loop_close_phi_args (basic_block ol

   if (is_gimple_reg (res) && scev_analyzable_p (res, region->region))
/* Loop close phi nodes should not be scev_analyzable_p.  */
-   gcc_unreachable ();
+   /*gcc_unreachable ()*/;

   gphi *new_close_phi = create_phi_node (SSA_NAME_VAR (res), new_bb);
   tree new_res = create_new_def_for (res, new_close_phi,
@@ -2497,7 +2497,7 @@ copy_cond_phi_nodes (basic_block bb, bas
continue;
   if (is_gimple_reg (res) && scev_analyzable_p (res, region->region))
/* Cond phi nodes should not be scev_analyzable_p.  */
-   gcc_unreachable ();
+   /*gcc_unreachable ()*/;

   gphi *new_phi = create_phi_node (SSA_NAME_VAR (res), new_bb);
   tree new_res = create_new_def_for (res, new_phi,

"fixes" the ICE.

Sebastian?

[Bug hsa/70391] New: HSA back-end produces wrong alignment load/store instructions

[marxin at gcc dot gnu.org]

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

Bug ID: 70391
   Summary: HSA back-end produces wrong alignment load/store
instructions
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: hsa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org
  Target Milestone: ---

Hello.

As reported here:
https://github.com/HSAFoundation/gccbrig/issues/6#issuecomment-197986345

current HSA back-end produces wrong alignment load/stores, for instance in
following example:

prog function &foo(align(4) arg_u8 %res[12])(align(4) arg_u8 %c[12]) <--- 'c'
has alignment just 4 
{
align(4) private_u8 %__private_0[12];
align(4) private_u8 %__hsa_anonymous_2357[12];
ld_arg_align(8)_u64 $d0, [%c]; < alignment == 8


Martin