[Bug fortran/68968] Internal Compiler error with cpp

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-18
Summary|Internal Compiler error |Internal Compiler error
   ||with cpp
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
> If gfortran is replaced by cpp in the above, it seems to generate what one
> would expect.

Confirmed from 4.4 up to trunk (6.0). I get the same ICE if I compile the test
with -cpp.

> A workaround is to remove the apostrophes around 's', 'd', and 'q'.

This "fixes" the ICE, but the executable prints

C_FLOAT

for s, d, or q and ICE for -Dplet_=\'q\'.

[Bug tree-optimization/68963] [4.9/5/6 Regression] O3 vs. O2 discards part of loop and terminates early

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.7.4
   Keywords||wrong-code
   Last reconfirmed||2015-12-18
  Component|c   |tree-optimization
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|O3 vs. O2 discards part of  |[4.9/5/6 Regression] O3 vs.
   |loop and terminates early   |O2 discards part of loop
   ||and terminates early
   Target Milestone|--- |4.9.4
  Known to fail||4.8.5, 4.9.3, 5.3.0, 6.0

--- Comment #1 from Richard Biener  ---
Confirmed.  This is complete peeling doing sth wrong:

test123.c:10:2: note: loop with 4 iterations completely unrolled
Last iteration exit edge was proved true.

We have bogus range info in .pcom:

  :
  # RANGE [0, 3] NONZERO 3
  # i_23 = PHI <0(4), i_20(9)>
  if (K_5(D) > i_23)
goto ;
  else
goto ;
...
  :
  # RANGE [1, 4] NONZERO 7
  i_20 = i_23 + 1;
  if (i_20 < _21)
goto ;
  else
goto ;

  :
  goto ;

but disabling VRP1 doesn't help here (it uses niter analysis to derive the
above so niter analysis is wrong in some way).

[Bug tree-optimization/68707] [6 Regression] testcase gcc.dg/vect/O3-pr36098.c vectorized using VEC_PERM_EXPR rather than VEC_LOAD_LANES

[rguenther at suse dot de]

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

--- Comment #22 from rguenther at suse dot de  ---
On Thu, 17 Dec 2015, alalaw01 at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68707
> 
> --- Comment #21 from alalaw01 at gcc dot gnu.org ---
> Here's the smallest testcase I could come up with (where SLP gets cancelled,
> but we end up with fewer st2's than before)...the key seems to be things being
> used in multiple places.
> 
> #define N 1024
> 
> int in1[N], in2[N];
> int out1[N], out2[N];
> int w[N];
> 
> void foo() {
>   for (int i = 0; i < N; i+=2)
> {
>   int a = in1[i] & in2[i];
>   int b = in1[i+1] & in2[i+1];
>   out1[i] = a;
>   out1[i+1] = b;
>   out2[i] = (a + w[i]) ^ (b+w[i+1]);
>   out2[i+1] = (b + w[i]) ^ (a+w[i+1]);
> }
> }

With discarding the instance for out2 we end up using both
SLP and load-lanes for in1[], in2[] and w[] which ends up
making those loads redundantly.  The code

.L2:
ld2 {v16.4s - v17.4s}, [x2]
add x0, x0, 32
ld2 {v18.4s - v19.4s}, [x1]
ld2 {v2.4s - v3.4s}, [x3], 32
ldr q5, [x2, 16]
and v1.16b, v18.16b, v16.16b
and v0.16b, v19.16b, v17.16b
cmp x5, x3
ldr q21, [x1, 16]
ldr q4, [x2], 32
ldr q20, [x1], 32
add v17.4s, v0.4s, v3.4s
add v16.4s, v1.4s, v2.4s
add v0.4s, v0.4s, v2.4s
add v1.4s, v1.4s, v3.4s
and v5.16b, v5.16b, v21.16b
and v4.16b, v4.16b, v20.16b
eor v6.16b, v17.16b, v16.16b
eor v7.16b, v1.16b, v0.16b
str q5, [x0, -16]
str q4, [x0, -32]
st2 {v6.4s - v7.4s}, [x4], 32
bne .L2
ret

looks as expected - load/store-lanes for out2 and regular vector
loads for out1.  We need to unroll 4 times for load-lanes vs.
doing only SLP which requires only 2 times unrolling (I wondered
if load-lanes would require more unrolling we should prefer SLP anyway?).

With SLP

.L2:
ldr q3, [x0, x5]
ldr q2, [x0, x4]
ldr q0, [x0, x2]
rev64   v4.4s, v3.4s
rev64   v1.4s, v2.4s
and v2.16b, v2.16b, v3.16b
trn2v3.4s, v0.4s, v0.4s
trn1v0.4s, v0.4s, v0.4s
and v1.16b, v1.16b, v4.16b
str q2, [x0, x3]
add v0.4s, v0.4s, v2.4s
add v1.4s, v1.4s, v3.4s
eor v0.16b, v1.16b, v0.16b
str q0, [x0, x1]
add x0, x0, 16
cmp x0, 4096
bne .L2

indeed looks much nicer because it can share the actual loads and ANDs
(the vectorizer doesn't and doesn't know that, only later CSE does,
so we can't use that "knowledge" for our decision).  But note there
are no st2 remaining (as expected for a full SLP vectorization).

Such cases were why I was thinking to apply this logic to all
SLP instances at once (but then without knowing about actual
sharing we have to wheight N non-permuted SLP instances against
M (partially) permuted SLP instances).

We can build up load sharing information after we built all
SLP instances and then do some decision based on that (this would
also make it possible to improve SLP costing in general which
simply assumes no later CSE will happen).

Hybrid SLP stmts simply mean that we not only need to have
different permutations of loads but we also have to duplicate
shared compute stmts (as elements are permuted differently).
In this case the ANDs for computing a and b.

Another improvement possibility for the current heuristic would
be to query whether _all_ loads need to be permuted with SLP, like
with

  if (STMT_VINFO_STRIDED_P (stmt_vinfo)
  || ! SLP_TREE_LOAD_PERMUTATION (load_node).exists ()
  || ! vect_load_lanes_supported
 (STMT_VINFO_VECTYPE (stmt_vinfo),
  GROUP_SIZE (stmt_vinfo)))
break;

thus if there is a load node which is not permuted then retain the SLP.
This would preserve the SLP for out2 because there are unpermuted
uses of a and b.  It would also preserve the SLP if you comment the
out1 stores thus generate

.L2:
ldr q3, [x0, x4]
ldr q2, [x0, x3]
ldr q0, [x0, x2]
rev64   v5.4s, v3.4s
rev64   v1.4s, v2.4s
and v2.16b, v2.16b, v3.16b
trn2v4.4s, v0.4s, v0.4s
trn1v0.4s, v0.4s, v0.4s
and v1.16b, v1.16b, v5.16b
add v0.4s, v0.4s, v2.4s
add v1.4s, v1.4s, v4.4s
eor v0.16b, v1.16b, v0.16b
str q0, [x0, x1]
add x0, x0, 16
cmp x0, 4096
bne .L2

instead of

.L2:
ld2 {v6.4s - v7.4s}, [x2], 32
ld2 {v16.4s - v17.4s}, [x1], 32
ld2 {v2.4s - v3.4s}, [x3], 32
and v1.16b, v16.16b, v6.16b
and v0.16b, v17.16b, v7.16b
add

[Bug rtl-optimization/68796] Make use of and-immediate+compare instructions more robust

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Fri Dec 18 09:58:07 2015
New Revision: 231810

URL: https://gcc.gnu.org/viewcvs?rev=231810=gcc=rev
Log:
[AArch64] PR rtl-optimization/68796 Add compare-of-zero_extract pattern

PR rtl-optimization/68796
* config/aarch64/aarch64.md (*and3nr_compare0_zextract):
New pattern.
* config/aarch64/aarch64.c (aarch64_select_cc_mode): Handle
ZERO_EXTRACT comparison with zero.
(aarch64_mask_from_zextract_ops): New function.
* config/aarch64/aarch64-protos.h (aarch64_mask_from_zextract_ops):
New prototype.

* gcc.target/aarch64/tst_3.c: New test.
* gcc.target/aarch64/tst_4.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/tst_3.c
trunk/gcc/testsuite/gcc.target/aarch64/tst_4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-protos.h
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/aarch64.md
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/68956] [6 regression] Vectorizer miscompilation of 416.gamess

[ienkovich at gcc dot gnu.org]

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

--- Comment #5 from Ilya Enkovich  ---
Author: ienkovich
Date: Fri Dec 18 10:01:02 2015
New Revision: 231811

URL: https://gcc.gnu.org/viewcvs?rev=231811=gcc=rev
Log:
gcc/

PR tree-optimization/68956
* tree-vect-stmts.c (vect_init_vector): Fix constants
used for boolean vectors.

gcc/testsuite

PR tree-optimization/68956
* gcc.target/i386/pr68956.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr68956.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug tree-optimization/68956] [6 regression] Vectorizer miscompilation of 416.gamess

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #6 from Ilya Enkovich  ---
Fixed

[Bug target/68973] [6 regression] Internal compiler error on power for gcc/testsuite/g++.dg/pr67211.C

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||powerpc64*
   Target Milestone|--- |6.0

[Bug c++/68954] [5/6 Regression] -Wdeprecated-declarations -Werror errors for system header templates

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
To me the new behavior looks right.

[Bug tree-optimization/68906] [6 Regression] ICE at -O3 on x86_64-linux-gnu: verify_ssa failed

[ienkovich at gcc dot gnu.org]

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

--- Comment #4 from Ilya Enkovich  ---
Author: ienkovich
Date: Fri Dec 18 10:16:56 2015
New Revision: 231812

URL: https://gcc.gnu.org/viewcvs?rev=231812=gcc=rev
Log:
gcc/

2015-12-18  Yuri Rumyantsev  

PR tree-optimization/68906
* tree-ssa-loop-unswitch.c (tree_unswitch_outer_loop): Add check
that an exit block belongs to LOOP.

gcc/testsuite/

2015-12-18  Yuri Rumyantsev  

PR tree-optimization/68906
* gcc.dg/torture/pr68906.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr68906.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-unswitch.c

[Bug tree-optimization/68951] [6 Regression] ICE in vect_update_misalignment_for_peel

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/68964] [6 regression] Internal compiler error for test case gcc.dg/tm/20100610.c since r231674

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org
   Target Milestone|--- |6.0

--- Comment #2 from Richard Biener  ---
So TM does expand_assign_tm on

# .MEM_47 = VDEF <.MEM_4>
MEM[(double *)elementPtr_1 + 56B] = vect_cst__54;

doing

  else if (store_p && !load_p)
{
  transaction_subcode_ior (region, GTMA_HAVE_STORE);
  gcall = build_tm_store (loc, lhs, rhs, gsi);
}

but gcall is NULL and thus

  if (!gcall)
{
  tree lhs_addr, rhs_addr, tmp;
...
  else
{
  tmp = NULL_TREE;
  lhs_addr = gimplify_addr (gsi, lhs);
}
  rhs_addr = gimplify_addr (gsi, rhs);

which builds the address of vect_cst__54 which is obviously not going to work.

Not sure what TM people were thinking of here.  If you really need sth in
memory then you need to create a stack var, store to it and use its address.

Simply doing the above isn't going to work.

Leaving to rth.

[Bug fortran/68800] Fortran FE produces many memory leaks

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-18
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
There are six PR already opened for memory leak.

[Bug c/68971] -Woverflow false alarm in code unreachable after __builtin_mul_overflow

[eggert at gnu dot org]

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

--- Comment #6 from Paul Eggert  ---
(In reply to Martin Sebor from comment #5)
> This is a valid constant expression

I'm aware of the distinction between constant and other expressions. I'm trying
to give the ordinary user's viewpoint, not the viewpoint of a language
standards nerd. From the ordinary user's viewpoint GCC is busted here because
it is crying wolf. There are tons of other places where GCC could cry wolf
while following the letter of the standard, but GCC doesn't do that because in
practice crying wolf is counterproductive.

> since __builtin_mul_overflow has already computed the product it
> seems that the result should be used rather than computed again using plain
> multiplication.

It's a test program, and it's doing things twice in order to test them for
consistency. You're right, most likely this particular combination wouldn't
occur except in test programs. So it could be that the use of -Wno-overflow can
be limited to test programs, if we're lucky. Still, it'd be better if GCC were
fixed to not cry wolf in situations like these.

[Bug c++/68795] [6 Regression] Use of uninitialised value of size 8 in cp_parser_postfix_expression (parser.c:6831)

[nickc at redhat dot com]

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

--- Comment #4 from Nick Clifton  ---
Hi David,

> Bother; I have another patch for this I was about to post, which is
> bootstrapping right now

Oops - sorry for treading on your toes!

Cheers
   Nick

[Bug tree-optimization/68946] [6 Regression] ICE at -O3 on x86_64-linux-gnu in both 32- and 64-bit modes (in vect_analyze_stmt, at tree-vect-stmts.c:8013)

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #7 from ktkachov at gcc dot gnu.org ---
*** Bug 68962 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/68962] [6 Regression] internal compiler error: in vect_analyze_stmt, at tree-vect-stmts.c:8013 when building 416.gamess on aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

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

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

[Bug fortran/68196] [4.9/5 Regression] ICE on function result with procedure pointer component

[pault at gcc dot gnu.org]

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

--- Comment #10 from Paul Thomas  ---
Author: pault
Date: Fri Dec 18 09:34:13 2015
New Revision: 231807

URL: https://gcc.gnu.org/viewcvs?rev=231807=gcc=rev
Log:
2015-12-18  Paul Thomas  

PR fortran/68196
*expr.c (gfc_has_default_initializer): Prevent infinite recursion
through this function for procedure pointer components.
* trans-array.c (structure_alloc_comps): Ditto twice.


2015-12-18  Paul Thomas  

PR fortran/68196
* gfortran.dg/proc_ptr_48.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/proc_ptr_48.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/68954] [5/6 Regression] -Wdeprecated-declarations -Werror errors for system header templates

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Thu, 17 Dec 2015, manu at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68954
> 
> --- Comment #4 from Manuel López-Ibáñez  ---
> (In reply to Richard Biener from comment #0)
> > std::auto_ptr is marked as deprecated in
> > libstdc++-v3/include/backward/auto_ptr.h
> > and
> > 
> > #include 
> > 
> > int main()
> > {
> >   int i;
> >   std::auto_ptr x;
> > }
> > 
> > warns about this even without -Wsystem-headers.  What is worse, since GCC 
> > 5.3
> 
> Perhaps something changed in the location passed to the warning? Or there
> should be an explicit check of whether the location of the declaration is at a
> system header.
> 
> > adding -Werror makes this an error while with 5.2 it was a warning despite
> > -Werror:
> 
> Sorry, how is this a bug and not simply working as intended?

I just wanted clarification for that.  Yes, it looks like it now works
as intended but it makes packages that previously build fine with -Werror
fail now when updating from GCC 5.2 to 5.3.

I agree the new behavior makes sense but I wondered if it was 
intentionally that for warnings enabled by default (no -W*) we
continue issueing a warning rather than an error with -Werror.

[Bug fortran/68534] No error on mismatch in number of arguments between submodule and module interface

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #6 from Paul Thomas  ---
I corrected this error on 2015-12-05 but, for some reason, the commit has not
appeared below.

Anyway, it's done (I just checked :-) ) and I am closing the PR.

Thanks for the report

Paul

[Bug tree-optimization/68961] [6 regression] Test case gcc.target/powerpc/pr60203.c fails since r231674

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #3 from Richard Biener  ---
As said I can't reproduce this with a cross.  The function is optimized way
before we get to vectorization.

spawn /home/abuild/rguenther/obj-ppc64le-g/gcc/xgcc
-B/home/abuild/rguenther/obj-ppc64le-g/gcc/
/space/rguenther/src/svn/trunk3/gcc/testsuite/gcc.target/powerpc/pr60203.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -mcpu=power8 -O3 -S -o
pr60203.s^M
PASS: gcc.target/powerpc/pr60203.c (test for excess errors)
PASS: gcc.target/powerpc/pr60203.c scan-assembler-not stfd
PASS: gcc.target/powerpc/pr60203.c scan-assembler-not lfd
PASS: gcc.target/powerpc/pr60203.c scan-assembler-not lxsdx
PASS: gcc.target/powerpc/pr60203.c scan-assembler-not stxsdx
PASS: gcc.target/powerpc/pr60203.c scan-assembler-not mfvsrd
PASS: gcc.target/powerpc/pr60203.c scan-assembler-not mtvsrd

pack:
blr

this is for ppc64le.  Already .fre1 has

pack (double a, double aa)
{
  double u$d$0;
  union u_ld u;

  :
  u.d[1] = aa_4(D);
  u ={v} {CLOBBER};
  return a_2(D);

}

where u is later trivially deleted as dead.

Cross from x86_64 configured as

> ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: powerpc64le-suse-linux
Configured with: /space/rguenther/src/svn/trunk3/configure --disable-bootstrap
--target=powerpc64le-suse-linux --enable-languages=c,c++,fortran :
(reconfigured) /space/rguenther/src/svn/trunk3/configure --disable-bootstrap
--target=powerpc64le-suse-linux --enable-languages=c,c++,fortran :
(reconfigured) /space/rguenther/src/svn/trunk3/configure --disable-bootstrap
--target=powerpc64le-suse-linux --enable-languages=c,c++,fortran :
(reconfigured) /space/rguenther/src/svn/trunk3/configure --disable-bootstrap
--target=powerpc64le-suse-linux --enable-languages=c,c++,fortran :
(reconfigured) /space/rguenther/src/svn/trunk3/configure --disable-bootstrap
--target=powerpc64le-suse-linux target_alias=powerpc64le-suse-linux CFLAGS=-g
CXXFLAGS=-g --enable-languages=c,c++,fortran,lto --no-create --no-recursion
Thread model: posix
gcc version 6.0.0 20151217 (experimental) [trunk revision 221942] (GCC)

[Bug c++/67592] A virtual member function declared constexpr fails to trigger a diagnostic

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-18
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
 Ever confirmed|0   |1

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

[Bug target/68937] i686: -fno-plt produces wrong code (maybe only with tailcall)

[zsojka at seznam dot cz]

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

--- Comment #11 from Zdenek Sojka  ---
(In reply to H.J. Lu from comment #10)
> (In reply to Zdenek Sojka from comment #9)
...
> >
> 
> Please try
> 
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01759.html

Testsuite run with "-fPIC -fno-plt" patched by
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01838.html doesn't introduce any
new ICEs, and fixes all exec failures, compared to trunk.

[Bug testsuite/68776] [6 regression] gcc.dg/vect/vect-widen-mult-const-[su]16.c failures since r226675

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to rguent...@suse.de from comment #6)
> On December 17, 2015 4:19:00 PM GMT+01:00, "wschmidt at gcc dot gnu.org"
>  wrote:
> >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68776
> >
> >--- Comment #5 from Bill Schmidt  ---
> >(In reply to Bill Schmidt from comment #4)
> >> Yep.  I'll verify the fix and commit today if all goes well.  Thanks
> >for the
> >> investigation!
> >
> >Actually, looking at check_effective_target_vect_int_mult, this won't
> >work (and
> >I've confirmed it doesn't):
> >
> >  if { ([istarget powerpc*-*-*] && ![istarget powerpc-*-linux*paired*])
> > || [istarget spu-*-*]
> > || [istarget i?86-*-*] || [istarget x86_64-*-*]
> > || [istarget ia64-*-*]
> > || [istarget aarch64*-*-*]
> > || [check_effective_target_arm32] } {
> >   set et_vect_int_mult_saved 1
> >
> >So the proposal will still expect powerpc64le to find 2 instances
> >instead of 4.
> >
> >I've verified that we are generating the expected widening
> >multiplication
> >sequences for foo and bar, and generating 32-bit multiplies for baz.
> 
> But if ppc can do int mult the mult pattern should not apply...

Specifically:

static gimple *
vect_recog_mult_pattern (vec *stmts,
 tree *type_in, tree *type_out)
{
...
  vectype = get_vectype_for_scalar_type (itype);
  if (vectype == NULL_TREE)
return NULL;

  /* If the target can handle vectorized multiplication natively,
 don't attempt to optimize this.  */
  optab = optab_for_tree_code (MULT_EXPR, vectype, optab_default);
  if (optab != unknown_optab)
{
  machine_mode vec_mode = TYPE_MODE (vectype);
  int icode = (int) optab_handler (optab, vec_mode);
  if (icode != CODE_FOR_nothing)
return NULL;

so powerpc can _not_ do integer multiplication (V2DI in this case).

Ok, so if you take "int" literally it can do vect_int_mult and we don't
have a vect_long_mult target.

I would say it would help to make the "pattern recognized" printing more
specific but that requires some extra work.  Let me try sth simple...

[Bug c++/68978] New: [6 Regression] bogus error: lvalue required as left operand of assignment

[trippels at gcc dot gnu.org]

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

Bug ID: 68978
   Summary: [6 Regression] bogus error: lvalue required as left
operand of assignment
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

Boost-1.60 fails to compile:

markus@x4 tmp % cat test.ii
template  int toi() {
  int i = 0, c = 0, radix = 10, max = 0x7fff;
  if (max < ((i *= radix) += c))
return 0;
  return i;
}

markus@x4 tmp % g++ -c test.ii
test.ii: In function ‘int toi()’:
test.ii:3:30: error: lvalue required as left operand of assignment
   if (max < ((i *= radix) += c))
  ^

[Bug rtl-optimization/68910] [5/6 regression] huge stack frame and poor code with instruction scheduling at -O2

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
> In case I revert (e.g. double revert) to enable the LRA for SPARC
> 
> commit a28f6dc56909fc35dd83d4364bc68c69e2450a51
> Author: davem 
> Date:   Tue Sep 22 03:52:45 2015 +
> 
> Revert LRA SPARC changes for now.
> 
> gcc/
> 
> PR/67622
> Revert:
> 2015-09-11  David S. Miller  
> 
> then the clr instructions are gone.

Interesting, but we cannot do it on the 5 branch and there are apparently still
issues even on the mainline.  In any case, I have a trivial fix for the code
generation issue and a safe change for the stack frame so I'll go for them.

[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  ---
This is of course Fortran FE bug.

What is the Fortran FE emitting right now is kind like invalid C (and invalid
middle-end) below.  It wouldn't be invalid C++, but for C++ that would be
different baz functions and name mangling would differentiate those; that is
not what is going on in C or in what libgfortran expects:

typedef __SIZE_TYPE__ size_t;
struct D { long stride, lower_bound, ubound; };
struct A { float *base_addr; size_t offset; long dtype; struct D dim[7]; };
struct A1 { float *base_addr; size_t offset; long dtype; struct D dim[1]; };
struct A2 { float *base_addr; size_t offset; long dtype; struct D dim[2]; };

void
foo (void)
{
  extern void baz (struct A1 *);
  struct A1 a1 = { 0, 0, 0, { { 0, 0, 0 } } };
  baz ();
}

void
bar (void)
{
  extern void baz (struct A2 *);
  struct A2 a2 = { 0, 0, 0, { { 0, 0, 0 }, { 0, 0, 0 } } };
  baz ();
}

Above, A stands for generic real(8) array descriptor type that supports up to
maximum number of dimensions, A1 for rank 1 and A2 for rank 2 real(8) array
descriptor.  IMHO you want instead:

typedef __SIZE_TYPE__ size_t;
struct D { long stride, lower_bound, ubound; };
struct A { float *base_addr; size_t offset; long dtype; struct D dim[7]; };
struct A1 { float *base_addr; size_t offset; long dtype; struct D dim[1]; };
struct A2 { float *base_addr; size_t offset; long dtype; struct D dim[2]; };

void
foo (void)
{
  extern void baz (struct A *);
  struct A1 a1 = { 0, 0, 0, { { 0, 0, 0 } } };
  baz ((struct A *) );
}

void
bar (void)
{
  extern void baz (struct A *);
  struct A2 a2 = { 0, 0, 0, { { 0, 0, 0 }, { 0, 0, 0 } } };
  baz ((struct A *) );
}

and ensure that A/A1/A2 etc. (the various types created by
gfc_get_array_type_bounds) have the same TYPE_ALIAS to make the alias oracle
happy.
I hope only the libgfortran intrinsics that handle various ranks by the same
function are a problem, therefore I'd say you should be marking the symbols for
those intrinsics with some flag that you want to treat their arguments like
assumed rank arrays, and then just cast the addresses of the descriptors you
want to pass to them to some reference type to assumed rank descriptor type
(dunno if just array7_real(kind=8) (i.e. maximum rank), or something else).
Now, the question is if this affects just the intrinsic routines from
libgfortran, or user written functions/subroutines too.  I hope the latter only
should be called with the right rank except for assumed

[Bug c++/68385] [6 Regression] ICE building libstdc++ on arm-none-eabi

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
So, is this fixed now?

[Bug c++/68978] [6 Regression] bogus error: lvalue required as left operand of assignment

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-18
 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Started with r231640:

commit d175f0193ed47b61eafd213ca2d3dde73f8f5996
Author: ppalka 
Date:   Tue Dec 15 03:33:53 2015 +

Fix PR c++/21802 (two-stage name lookup fails for operators)

[Bug ada/62236] : error: aggregate value used where an integer was expected

[porton at narod dot ru]

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

--- Comment #5 from Victor Porton  ---
Not fixed in 5.3.1.

[Bug rtl-optimization/65980] [6 Regression] -fcompare-debug failure building Linux kernel

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug bootstrap/67598] [6 Regression] Target powerpc-e500v2-linux-gnuspe failed to bootstrap

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #3 from Nick Clifton  ---
(In reply to Arseny Solokha from comment #2)
> Fixed during the last week, as of 6.0.0-alpha20151122 snapshot (in r230440,
> apparently).

If it is fixed, please could you close this PR ?

Cheers
  Nick

[Bug ada/62042] Missing optimization of copying non-limited objects

[porton at narod dot ru]

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

--- Comment #9 from Victor Porton  ---
Not fixed in 5.3.1.

[Bug other/66827] [6 Regression] left shifts of negative value warnings due to C++14 switch

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #8 from Nick Clifton  ---
Created attachment 37079
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37079=edit
Convert to unsigned before shifting

(In reply to Jakub Jelinek from comment #7)
> The question is about the others, but it has been so long that the 
> locations are all useless.

I have just checked.  The only problems that still remain are in
libiberty/regex.c.

The uploaded patch fixes this problem.  I plan to submit it for review after
running a few more regression tests.

[Bug ada/62235] segmentation fault on Ada 2012 code

[porton at narod dot ru]

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

--- Comment #7 from Victor Porton  ---
Not fixed in 5.3.1.

[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Isn't this related or dup of PR66745 ?

As for the lvalue error, reduced testcase is:
template 
int
foo (int max, int i, int radix, int c)
{
  if (max < ((i *= radix) += c))
return i / radix;
  return 0;
}

int
bar (int max, int i, int radix, int c)
{
  return foo <0> (max, i, radix, c);
}
and that one started with r231640 (doesn't error out if foo is not a template).
Do we have a PR for that already, or shall I file a new one?

[Bug target/65931] [5/6 regression] dsymutil assertion failure building libgnat-5.dylib

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Any news on this?  If we want to workaround it, it should be bisected and
analyzed what is the difference in the debug info.
Or just use a sane OS ;).

[Bug ipa/66764] [6 Regression] ICE in analyze_function() on AIX

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #2 from Nick Clifton  ---
Hi David,

> Analyzing compilation unit

I am unable to reproduce this ICE.  What command line options were being used
when it happened ?

Cheers
  Nick

[Bug c++/68979] New: [6 Regression] error: left operand of shift expression ‘(-1 << 4)’ is negative

[trippels at gcc dot gnu.org]

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

Bug ID: 68979
   Summary: [6 Regression] error: left operand of shift expression
‘(-1 << 4)’ is negative
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

markus@x4 tmp % cat enum.ii
enum A { bit_mask = ~(-1 << 4) };

markus@x4 tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3/g++ -std=c++14 -Wall
-Wextra -c enum.ii
markus@x4 tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/5.3.1/g++ -std=c++14 -Wall
-Wextra -c enum.ii
markus@x4 tmp % clang++ -std=c++14 -Wall -Wextra -c enum.ii
markus@x4 tmp % icpc -std=c++14 -Wall -Wextra -c enum.ii
markus@x4 tmp % g++ -Wall -Wextra -c enum.ii
enum.ii:1:29: warning: left shift of negative value [-Wshift-negative-value]
 enum A { bit_mask = ~(-1 << 4) };
 ^

enum.ii:1:26: error: left operand of shift expression ‘(-1 << 4)’ is negative
 enum A { bit_mask = ~(-1 << 4) };
  ^

enum.ii:1:30: error: enumerator value for ‘bit_mask’ is not an integer constant
 enum A { bit_mask = ~(-1 << 4) };
  ^

[Bug tree-optimization/68977] [gomp4] FAIL: c-c++-common/goacc/loop-2.c (internal compiler error)

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #2 from vries at gcc dot gnu.org ---
minimal version:
...
int
main ()
{
  int i, j;

#pragma acc parallel
  {
#pragma acc loop gang
for (i = 0; i < 10; i++)
  {
#pragma acc loop gang
for (j = 1; j < 10; j++)
  { }
  }

#pragma acc loop gang worker
for (i = 0; i < 10; i++)
  { }
  }

  return 0;
}
...

The problem is that we have stmt:
...
  .step.4_68 = _85;
...
And the defining stmt of _85 is NULL.

Before oaccdevlow, the assignment loops like:
...
  .step.4_68 = GOACC_LOOP (1, 1, 10, 1, -1, 0);
...

During oaccdevlow we translate the GOACC_LOOP, and we try to gimplify an
assign:
...
19254 gimplify_assign (lhs, r, );
(gdb) call debug_generic_expr (lhs)
.step.4_68
(gdb) call debug_generic_expr (r)
(D.1697 * D.1698) * 1
(gdb) call debug_gimple_seq (seq)
D.1697 = GOACC_DIM_SIZE (0);
D.1698 = GOACC_DIM_SIZE (1);
...

But during gimplification, we run into:
...
case INIT_EXPR:
  ...
  if (seen_error ())
return GS_ERROR;
...
And we're left with the uninitialized ssa name.

An easy fix seems to be:
...
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 185426f..c1aeddd 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -19128,7 +19128,7 @@ oacc_xform_loop (gcall *call)
-> chunks=ceil (range/(chunksize*threads*step))
  striding=false,chunking=false
-> chunk_size=ceil(range/(threads*step)),chunks=1  */
-  push_gimplify_context (true);
+  push_gimplify_context (false);

   switch (code)
 {
...

It means we're left with an uninitialized var, but ssa updating rewrites that
into a default def, so we have valid ssa.

We could also adopt the omp_lower strategy:
...
  /* If we have issued syntax errors, avoid doing any heavy
 lifting.
 Just replace the OMP directives with a NOP to avoid
 confusing RTL expansion.  */
  if (seen_error () && is_gimple_omp (stmt))
{
  gsi_replace (gsi_p, gimple_build_nop (), true);
  return;
}
...

[Bug c++/68979] [6 Regression] error: left operand of shift expression ‘(-1 << 4)’ is negative

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Why do you think this is a bug?  Note that -1 << 4 is rejected in a context
where an integer constant expression is required only in C++11/14.

[Bug c++/68979] [6 Regression] error: left operand of shift expression ‘(-1 << 4)’ is negative

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
(In reply to Marek Polacek from comment #1)
> Why do you think this is a bug?  Note that -1 << 4 is rejected in a context
> where an integer constant expression is required only in C++11/14.

I think that erroring out in this case is too harsh from a QOI standpoint.
A warning should be sufficient.

[Bug go/68980] [6 regression] ps -o cmd in gotest isn't portable

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug go/68980] New: [6 regression] ps -o cmd in gotest isn't portable

[ro at gcc dot gnu.org]

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

Bug ID: 68980
   Summary: [6 regression] ps -o cmd in gotest isn't portable
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: ro at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---
  Host: *-*-solaris2.*
Target: *-*-solaris2.*
 Build: *-*-solaris2.*

The use of ps -o cmd in gotest isn't portable: on Solaris, this leads to lots
of usage messages in libgo.log

PASS
ps: unknown output format: -o cmd
usage: ps [ -aAdeflcjLPyZ ] [ -o format ] [ -t termlist ]
[ -u userlist ] [ -U userlist ] [ -G grouplist ]
[ -p proclist ] [ -g pgrplist ] [ -s sidlist ] [ -z zonelist ]
  'format' is one or more of:
user ruser group rgroup uid ruid gid rgid pid ppid pgid sid taskid ctid
pri opri pcpu pmem vsz rss osz nice class time etime stime zone zoneid
f s c lwp nlwp psr tty addr wchan fname comm args projid project pset
/vol/gcc/src/hg/trunk/local/libgo/testsuite/gotest[623]: 19046 Terminated
PASS: bufio

and sometimes, in cases where there really some process needs to be killed, to
a
hang of the whole make check.

Solaris ps offers ps -o comm instead, and I suspect there might be more
differences
on other targets.

  Rainer

[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
trippels@gcc2-power8 ~ % ../gcc/configure --enable-checking=valgrind
--with-cpu=power8 --disable-libsanitizer --disable-bootstrap
--disable-libstdcxx-pch --disable-libvtv --disable-libitm --disable-libcilkrts
--disable-libssp --disable-libgomp --disable-werror --disable-multilib
--enable-languages=c,c++  

trippels@gcc2-power8 ~ % make -j60

Because of the high parallelism, it is hard to tell exactly which file triggers
the issue.

[Bug libstdc++/68982] New: Missing explicit qualification for std::forward in functional

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 68982
   Summary: Missing explicit qualification for std::forward in
functional
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk
  Target Milestone: ---

I notice that  is no longer consistently prefixing forward with
std:: and this means ADL gets invoked, which causes trouble when the argument
is from boost namespace and boost::forward is available.

As an example, consider libstdc++-v3/include/std/functional at r229290, line
616:

operator()(_Tp&& __obj) const
noexcept(noexcept(std::__invoke(_M_pm, forward<_Tp>(__obj
-> decltype(std::__invoke(_M_pm, std::forward<_Tp>(__obj)))
{ return std::__invoke(_M_pm, std::forward<_Tp>(__obj)); }

This can produce compiler errors when, for instance, the instantiating type _Tp
is boost::shared_ptr.

I get failures building proprietary code, have not yet produced a simple
standa-alone example.

[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #1 from Nick Clifton  ---
Hi Markus,

  How do I reproduce this ?  IE please could you upload a testcase to
demonstrate this problem.

Cheers
  Nick

[Bug target/68895] [ARM] ICE with target attributes

[chrbr at gcc dot gnu.org]

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

--- Comment #3 from chrbr at gcc dot gnu.org ---
Created attachment 37083
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37083=edit
fix under validation

Initial patch to recompute DECL_MODE

[Bug target/65931] [5/6 regression] dsymutil assertion failure building libgnat-5.dylib

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #9 from Jakub Jelinek  ---
> Any news on this?  If we want to workaround it, it should be bisected and
> analyzed what is the difference in the debug info.
> Or just use a sane OS ;).

Using sane tools seems enough ;-)  I'd been using a copy of dsymutils
from dwarfutils-119, so I didn't notice.

Checking back now, the dsymutil from Xcode 7.2 (Apple LLVM 7.0.2
(clang-700.1.81)) works just fine, too.  No idea when this started
working again.

Rainer

[Bug middle-end/67639] ICE at -O1 and above on x86_64-linux-gnu in expand_gimple_basic_block, at cfgexpand.c:5697

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #3 from Bernd Schmidt  ---
Looking into it.

[Bug libstdc++/68982] Missing explicit qualification for std::forward in functional

[rogero at howzatt dot demon.co.uk]

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

--- Comment #2 from Roger Orr  ---
Created attachment 37082
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37082=edit
Example of failure, against code using boost 1.57.0

[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595

[chrbr at gcc dot gnu.org]

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

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from chrbr at gcc dot gnu.org ---
Created attachment 37085
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37085=edit
new preliminary fix

[Bug tree-optimization/68977] [gomp4] FAIL: c-c++-common/goacc/loop-2.c (internal compiler error)

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
As the code is ill-formed, and IIUC the error only happens if we;ve seen an
error, I suggest
push_gimplify_context (!seen_error ());

No point making the compiler work harder than necesary in the usual case?

[Bug c++/68975] Request: Provide alternate keyword for decltype in C++03

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
I see that clang supports __decltype (but not __decltype__, strangely)

[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132

[trippels at gcc dot gnu.org]

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

--- Comment #11 from Markus Trippelsdorf  ---
(In reply to Jakub Jelinek from comment #9)
> Isn't this related or dup of PR66745 ?
> 
> As for the lvalue error, reduced testcase is:
> template 
> int
> foo (int max, int i, int radix, int c)
> {
>   if (max < ((i *= radix) += c))
> return i / radix;
>   return 0;
> }
> 
> int
> bar (int max, int i, int radix, int c)
> {
>   return foo <0> (max, i, radix, c);
> }
> and that one started with r231640 (doesn't error out if foo is not a
> template).
> Do we have a PR for that already, or shall I file a new one?

I've opened PR68978 for this issue.

[Bug tree-optimization/68835] [5 Regression] ICE in set_value_range, at tree-vrp.c:387, with __int128 bit field

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Fri Dec 18 14:38:17 2015
New Revision: 231817

URL: https://gcc.gnu.org/viewcvs?rev=231817=gcc=rev
Log:
Backported from mainline
2015-12-17  Jakub Jelinek  

PR tree-optimization/68835
* tree.c (get_int_cst_ext_nunits): Return
cst.get_precision () / HOST_BITS_PER_WIDE_INT + 1
for all unsigned wi::neg_p (cst) constants.
(build_new_int_cst): If cst.get_precision is not a multiple
of HOST_BITS_PER_WIDE_INT, zero extend -1 to the precision
% HOST_BITS_PER_WIDE_INT.

* gcc.dg/pr68835-1.c: New test.
* gcc.dg/pr68835-2.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr68835-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr68835-2.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/tree.c

[Bug libstdc++/68276] ios_base::_M_grow_words should use new (std::nothrow)

[ville at gcc dot gnu.org]

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

--- Comment #2 from ville at gcc dot gnu.org ---
Author: ville
Date: Fri Dec 18 15:17:09 2015
New Revision: 231819

URL: https://gcc.gnu.org/viewcvs?rev=231819=gcc=rev
Log:
2015-12-18  Ville Voutilainen  

PR libstdc++/68276

* src/c++11/ios.cc (_M_grow_words): Use nothrow new.
* testsuite/27_io/ios_base/storage/11584.cc: Adjust.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++11/ios.cc
trunk/libstdc++-v3/testsuite/27_io/ios_base/storage/11584.cc

[Bug libstdc++/68984] New: error: ‘constexpr bool std::isinf(double)’ conflicts with a previous declaration

[trippels at gcc dot gnu.org]

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

Bug ID: 68984
   Summary: error: ‘constexpr bool std::isinf(double)’ conflicts
with a previous declaration
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

markus@x4 tmp % cat isinf.cpp
#include 
using std::isinf;

markus@x4 tmp % g++ -std=c++11 -c isinf.cpp
isinf.cpp:2:12: error: ‘constexpr bool std::isinf(double)’ conflicts with a
previous declaration
 using std::isinf;
^

In file included from /usr/include/features.h:368:0,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/x86_64-pc-linux-gnu/bits/os_defines.h:39,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/x86_64-pc-linux-gnu/bits/c++config.h:493,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/cmath:41,
 from isinf.cpp:1:
/usr/include/bits/mathcalls.h:201:1: note: previous declaration ‘int
isinf(double)’
 __MATHDECL_1 (int,isinf,, (_Mdouble_ __value)) __attribute__ ((__const__));
 ^

markus@x4 tmp % clang++ -stdlib=libc++ -std=c++11 -c isinf.cpp
markus@x4 tmp %

[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595

[chrbr at gcc dot gnu.org]

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

--- Comment #13 from chrbr at gcc dot gnu.org ---
Created attachment 37084
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37084=edit
preliminary fix

[Bug ipa/68981] New: [4.9/5/6 Regression] g++.dg/ipa/pr60640-4.C FAILs with -ftree-vectorize

[zsojka at seznam dot cz]

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

Bug ID: 68981
   Summary: [4.9/5/6 Regression] g++.dg/ipa/pr60640-4.C FAILs with
-ftree-vectorize
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

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

Output:
$ i686-pc-linux-gnu-g++ -O3 -ftree-vectorize
gcc/testsuite/g++.dg/ipa/pr60640-4.C
$ ./a.out 
Segmentation fault

For the reduced testcase, -O3 is enough:
$ i686-pc-linux-gnu-g++ -O3 testcase.C
$ ./a.out 
Aborted

The original testcase segfaults on i686, but the reduced testcase Aborts on all
other architectures - but only in 4.9 and 5 branches:

$ x86_64-pc-linux-gnu-g++-4.9.3 -O3 testcase.C
$ ./a.out 
Aborted

Tested revisions for the reduced testcase @ -O3:
r231814 - FAIL (segfault) (for i686 only)
5-branch r231650 - FAIL (segfault) (for i686 only)
5_2_0-release, 5_3_0-release - FAIL (abort) (all architectures)
4_9-branch r231643 - FAIL (abort) (all architectures)
4_8-branch r224828 - OK

[Bug libstdc++/68982] Missing explicit qualification for std::forward in functional

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-18
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
My fault.

[Bug c++/68983] [6 Regression] ICE: in store_field, at expr.c:6659

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Created attachment 37081
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37081=edit
unreduced testcase

[Bug c++/68970] Missing "expected ; after class" message

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-18
 Ever confirmed|0   |1

[Bug tree-optimization/68835] [5 Regression] ICE in set_value_range, at tree-vrp.c:387, with __int128 bit field

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #14 from Jakub Jelinek  ---
Fixed.

[Bug libstdc++/68276] ios_base::_M_grow_words should use new (std::nothrow)

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #3 from Ville Voutilainen  ---
Done.

[Bug target/67710] FAIL: gcc.dg/darwin-*version-*.c (test for excess errors) with Xcode 7

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
Unfortunately, it doesn't work on Mac OS X 10.11.2: every link test
FAILs with

FAIL: 17_intro/freestanding.cc (test for excess errors)
Excess errors:
ld: warning: object file
(/var/folders/1d/k16rgv6d5039jhvlj8_dzk4h00021y/T//cc0iIoOX.o) was built for
newer OSX version (10.11.2) than being linked (10.11)

I've found that while ld strips the micro version passed to
-mmacosx_version_min, clang does not, resulting in this mess.  Given
that ld(1) documents the version number format as ., for
now it seems that gcc should only pass this to as and ld.

Looking...

Rainer

[Bug testsuite/68776] [6 regression] gcc.dg/vect/vect-widen-mult-const-[su]16.c failures since r226675

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug testsuite/68776] [6 regression] gcc.dg/vect/vect-widen-mult-const-[su]16.c failures since r226675

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Fri Dec 18 13:52:11 2015
New Revision: 231815

URL: https://gcc.gnu.org/viewcvs?rev=231815=gcc=rev
Log:
2015-12-18  Richard Biener  

PR testsuite/68776
* tree-vect-patterns.c (struct vect_recog_func): New.
(vect_vect_recog_func_ptrs): Make an array of function name pairs.
(vect_pattern_recog_1): Print the recognized pattern name.  Return
true if a pattern was recognized.
(vect_pattern_recog): Adjust.  Stop iterating over pattern recognition
functions on a stmt if a pattern was recognized.

* gcc.dg/vect/vect-widen-mult-const-s16.c: Adjust.
* gcc.dg/vect/vect-widen-mult-const-u16.c: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c
trunk/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-u16.c
trunk/gcc/tree-vect-patterns.c

[Bug c++/68983] New: [6 Regression] ICE: in store_field, at expr.c:6659

[trippels at gcc dot gnu.org]

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

Bug ID: 68983
   Summary: [6 Regression] ICE: in store_field, at expr.c:6659
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

Trying to build LibreOffice shows:

markus@x4 tmp % g++ -c -w scmod.ii
scmod.ii: In constructor ‘ScGridOptions::ScGridOptions(const SvxOptionsGrid&)’:
scmod.ii:5039:163: internal compiler error: in store_field, at expr.c:6659
  class ScGridOptions : public SvxOptionsGrid { public:  ScGridOptions() :
SvxOptionsGrid() {}  ScGridOptions( const SvxOptionsGrid& rOpt ) :
SvxOptionsGrid( rOpt ) {}  void SetDefaults();  const ScGridOptions& operator=
( const ScGridOptions& rCpy );  bool operator== ( const ScGridOptions& rOpt )
const;  bool operator!= ( const ScGridOptions& rOpt ) const { return
!(operator==(rOpt)); } };
   
   
   ^

0x9f28a6 store_field
../../gcc/gcc/expr.c:6659
0x9ed991 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.c:5020
0x8e07fe expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3606
0x8e07fe expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3702
0x8e3ee4 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5708
0x8e8ed6 execute
../../gcc/gcc/cfgexpand.c:6323

Started with r228704:

commit ab48ece0923ded0cbd089ce31d1b3d26c239bc4e
Author: jason 
Date:   Mon Oct 12 07:58:43 2015 +

PR c++/67557

* expr.c (store_field): Call store_constructor directly when
storing a CONSTRUCTOR into a target smaller than its type.
Guard against unsafe bitwise copy.

Reducing will take a while (8 Mb boost testcase)...

[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
Regarding the verify_unstripped_args ICE, what I see is that the ICE is while
some parts of strip_typedefs check if recursion has changed anything and only
build new trees if it changed, other parts rely on various other mechanisms.
Say for POINTER_TYPE we use build_pointer_type and hope (the caching should
hopefully ensure that it is fine) that we get the same pointer as we called it
with if nothing changed, but say for METHOD_TYPE which is the problem here
even if nothing really changed we still construct full new argument list etc.
and then call build_method_type_directly (or build_function_type for
FUNCTION_TYPE) and hope we get the same method type back.  I'd say that is
rather costly, depends on how often nothing really needs to be stripped, if
that is often the case, we'd better just check first if anything changed and
only in that case build the list.
On the testcase for some reason build_method_type_directly returns a different
type though.

[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132

[trippels at gcc dot gnu.org]

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

--- Comment #12 from Markus Trippelsdorf  ---
*** Bug 66745 has been marked as a duplicate of this bug. ***

[Bug c++/66745] [6 Regression] ice in check_unstripped_args

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from Markus Trippelsdorf  ---
Lets close this one. There is more analysis in the duplicate bug.

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

[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595

[chrbr at gcc dot gnu.org]

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

--- Comment #12 from chrbr at gcc dot gnu.org ---
(In reply to ktkachov from comment #8)
> (In reply to chrbr from comment #7)
> > I was suggesting in #68934 to make this code invalid and report an error.
> > Since SIMD types should not be used for declarations in NOSIMD context. But
> > I don't have a strong position about this. We might make this code work by
> > repairing the DECL_MODE depending on the usage context, but certainly less
> > practical than handle the error.
> > 
> > Other opinions ?
> > 
> > thanks
> 
> I agree about considering this code invalid.
> In the context where the variables are being declared there is no SIMD, so
> they don't really have a meaning. In the testcase if we wrap the
> declarations in a pargma like so:
> #pragma GCC push_options
> #pragma GCC target ("+simd")
> int8x8_t a, b;
> int16x8_t e;
> #pragma GCC pop_options
> 
> then we don't ICE.
> I suspect repairing DECL_MODE will be a messy affair. So unless you see a
> clean/safe way of doing this I'd propose just somehow detecting this error
> and throwing an error instead of an ICE.

I changed my mind :-) :

- The surrounding of global declaration by the #pragma is too heavy to be used.
The compiler is able to derive the type from the attribute target when using
it.

- The compiler already handle this partially:
 see the comment in stor-layout:
   /* Vector types need to re-check the target flags each time we report
   the machine mode.  We need to do this because attribute target can
   change the result of vector_mode_supported_p and have_regs_of_mode
   on a per-function basis.  Thus the TYPE_MODE of a VECTOR_TYPE can
   change on a per-function basis.  */

I'm testing a central fix in expand_expr. Will need to check on the other
targets but it fixes the case it for arm and aarch64.

patch attached for first feedback and early review.

[Bug rtl-optimization/49847] [4.8 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[law at gcc dot gnu.org]

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

--- Comment #40 from Jeffrey A. Law  ---
Author: law
Date: Fri Dec 18 17:17:14 2015
New Revision: 231821

URL: https://gcc.gnu.org/viewcvs?rev=231821=gcc=rev
Log:
[PATCH] [PR rtl-optimization/49847] Fix ICE in CSE due to cc0-setter and
cc0-user in different blocks

PR rtl-optimization/49847
* cse.c (record_jump_equiv): Handle fold_rtx returning NULL_RTX.

PR rtl-optimization/49847
* g++.dg/pr49847-2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr49847-2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cse.c
trunk/gcc/testsuite/ChangeLog

[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
Created attachment 37091
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37091=edit
unreduced testcase

[Bug testsuite/68913] [6 Regression] gcc.dg/lto/pr61886 FAILs

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #2 from Nick Clifton  ---
Created attachment 37086
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37086=edit
Provide weak version of __fread_chk

It seems to me that we could solve this problem by providing our own definition
of __fread_chk.  It does not have to work, since this is a link test, and the
real purpose of the test is to check that __fread_chk_warn is not referenced at
link time.

So I plan on submitting the uploaded patch after a few more local checks.

[Bug rtl-optimization/55598] LRA on powerpc does not like assembler in libgcc

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #3 from Bill Schmidt  ---
What's the status here?

[Bug c++/60044] Template argument of alias template not evaluated

[roman.perepelitsa at gmail dot com]

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

Roman Perepelitsa  changed:

   What|Removed |Added

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

--- Comment #3 from Roman Perepelitsa  ---
Fixed by r217250.

[Bug sanitizer/65479] sanitizer stack trace missing frames past #0 on powerpc64

[msebor at gcc dot gnu.org]

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

--- Comment #12 from Martin Sebor  ---
The sanitizer tests are still failing and this bug still hasn't been fixed.

The patch in r224402 was only partial, committed on the assumption that the
LLVM AddressSantitizer maintainers would approve my patch for it. 
Unfortunately, I never managed to convince them to approve the trivial patch
there and after much back and forth I gave up (the review is here:
http://reviews.llvm.org/D10065).

[Bug c++/68978] [6 Regression] bogus error: lvalue required as left operand of assignment

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick Palka  ---
It looks like lvalue_kind() does not handle MODOP_EXPRs correctly.  It does not
consider (i *= radix) (encoded at that point as an unlowered MODOP_EXPR) to be
an lvalue.  I am testing this fix:

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index ae176d0..ac22e45 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -186,6 +186,7 @@ lvalue_kind (const_tree ref)
   break;

 case MODIFY_EXPR:
+case MODOP_EXPR:
 case TYPEID_EXPR:
   return clk_ordinary;

[Bug c/68473] [6 Regression] ICE: in contains_point, at diagnostic-show-locus.c:340 after error

[law at redhat dot com]

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

--- Comment #10 from Jeffrey A. Law  ---
Created attachment 37089
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37089=edit
Another testcase,

Attaching another testcase.  Hopefully it's fixed by the pending patch from
David.

[Bug libfortran/68987] New: double free or corruption in _gfortran_st_write_done when a write statement to an internal file uses an invalid format and the ERR= specifier appears.

[mathewc at nag dot co.uk]

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

Bug ID: 68987
   Summary: double free or corruption in _gfortran_st_write_done
when a write statement to an internal file uses an
invalid format and the ERR= specifier appears.
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mathewc at nag dot co.uk
  Target Milestone: ---

I'm using

> gfortran --version
GNU Fortran (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2)

on

> uname -a
Linux cuivienen.nag.co.uk 4.2.7-300.fc23.x86_64 #1 SMP Wed Dec 9 22:28:30 UTC
2015 x86_64 x86_64 x86_64 GNU/Linux

> /lib/libc.so.6
GNU C Library (GNU libc) stable release version 2.22, by Roland McGrath et al.
...
Compiled by GNU CC version 5.1.1 20150618 (Red Hat 5.1.1-4).

and then with

> cat foo.f90 && gfortran foo.f90 && ./a.out
Program foo
  Call s('(foo)')
End Program
Subroutine s(fmt)
  Character (*) :: fmt
  Character (1) :: c
  Integer :: i
  Write (c, fmt, Iostat=i) 42
  If (i==0) Stop 'FAIL1'
  Write (c, fmt, Err=100) 42
  Stop 'FAIL2'
100 Continue
  Print *, 'ok'
End Subroutine
*** Error in `./a.out': double free or corruption (out): 0x01050360 ***
=== Backtrace: =
/lib64/libc.so.6(+0x77e35)[0x2b46ad0cae35]
/lib64/libc.so.6(+0x8051a)[0x2b46ad0d351a]
/lib64/libc.so.6(cfree+0x4c)[0x2b46ad0d6ccc]
/lib64/libgfortran.so.3(_gfortran_st_write_done+0x7b)[0x2b46ac6bcdab]
./a.out[0x400a0a]
./a.out[0x400a9e]
./a.out[0x400ad5]
/lib64/libc.so.6(__libc_start_main+0xf0)[0x2b46ad073580]
./a.out[0x4007b9]
=== Memory map: 
0040-00401000 r-xp  00:2b 43527338  
/fserver/mathewc/test_f/a.out
0060-00601000 r--p  00:2b 43527338  
/fserver/mathewc/test_f/a.out
00601000-00602000 rw-p 1000 00:2b 43527338  
/fserver/mathewc/test_f/a.out
0104d000-0106e000 rw-p  00:00 0  [heap]
2b46ac3ac000-2b46ac3cd000 r-xp  fd:01 1315819   
/usr/lib64/ld-2.22.so
2b46ac3cd000-2b46ac3cf000 rw-p  00:00 0 
2b46ac3ec000-2b46ac3ef000 rw-p  00:00 0 
2b46ac5cc000-2b46ac5cd000 r--p 0002 fd:01 1315819   
/usr/lib64/ld-2.22.so
2b46ac5cd000-2b46ac5ce000 rw-p 00021000 fd:01 1315819   
/usr/lib64/ld-2.22.so
2b46ac5ce000-2b46ac5cf000 rw-p  00:00 0 
2b46ac5cf000-2b46ac6f7000 r-xp  fd:01 1321356   
/usr/lib64/libgfortran.so.3.0.0
2b46ac6f7000-2b46ac8f7000 ---p 00128000 fd:01 1321356   
/usr/lib64/libgfortran.so.3.0.0
2b46ac8f7000-2b46ac8f9000 r--p 00128000 fd:01 1321356   
/usr/lib64/libgfortran.so.3.0.0
2b46ac8f9000-2b46ac8fb000 rw-p 0012a000 fd:01 1321356   
/usr/lib64/libgfortran.so.3.0.0
2b46ac8fb000-2b46ac9fc000 r-xp  fd:01 1321296   
/usr/lib64/libm-2.22.so
2b46ac9fc000-2b46acbfb000 ---p 00101000 fd:01 1321296   
/usr/lib64/libm-2.22.so
2b46acbfb000-2b46acbfc000 r--p 0010 fd:01 1321296   
/usr/lib64/libm-2.22.so
2b46acbfc000-2b46acbfd000 rw-p 00101000 fd:01 1321296   
/usr/lib64/libm-2.22.so
2b46acbfd000-2b46acc13000 r-xp  fd:01 1312410   
/usr/lib64/libgcc_s-5.3.1-20151207.so.1
2b46acc13000-2b46ace12000 ---p 00016000 fd:01 1312410   
/usr/lib64/libgcc_s-5.3.1-20151207.so.1
2b46ace12000-2b46ace13000 r--p 00015000 fd:01 1312410   
/usr/lib64/libgcc_s-5.3.1-20151207.so.1
2b46ace13000-2b46ace14000 rw-p 00016000 fd:01 1312410   
/usr/lib64/libgcc_s-5.3.1-20151207.so.1
2b46ace14000-2b46ace52000 r-xp  fd:01 1312475   
/usr/lib64/libquadmath.so.0.0.0
2b46ace52000-2b46ad051000 ---p 0003e000 fd:01 1312475   
/usr/lib64/libquadmath.so.0.0.0
2b46ad051000-2b46ad052000 r--p 0003d000 fd:01 1312475   
/usr/lib64/libquadmath.so.0.0.0
2b46ad052000-2b46ad053000 rw-p 0003e000 fd:01 1312475   
/usr/lib64/libquadmath.so.0.0.0
2b46ad053000-2b46ad20a000 r-xp  fd:01 1321289   
/usr/lib64/libc-2.22.so
2b46ad20a000-2b46ad40a000 ---p 001b7000 fd:01 1321289   
/usr/lib64/libc-2.22.so
2b46ad40a000-2b46ad40e000 r--p 001b7000 fd:01 1321289   
/usr/lib64/libc-2.22.so
2b46ad40e000-2b46ad41 rw-p 001bb000 fd:01 1321289   
/usr/lib64/libc-2.22.so
2b46ad41-2b46ad414000 rw-p  00:00 0 
2b46b000-2b46b0021000 rw-p  00:00 0 
2b46b0021000-2b46b400 ---p  00:00 0 
7ffdd7827000-7ffdd7848000 rw-p  00:00 0 
[stack]
7ffdd785d000-7ffdd785f000 r--p  00:00 0  [vvar]
7ffdd785f000-7ffdd7861000 r-xp  00:00 0 

[Bug c/68971] -Woverflow false alarm in code unreachable after __builtin_mul_overflow

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
I didn't mean to sound like I was lecturing you, just trying to draw a clear
distinction between the cases.

Perhaps what's needed is for GCC to treat the builtins as constant expressions
when they're invoked with them as operands.  If you agree with that approach, I
suggest closing this bug and opening a new one with that request.

FWIW, in my experience, because sophisticated warnings that try to avoid
issuing false positives for unreachable code (e.g., -Wmaybe-uninutialized)
depend on optimizations they tend to be inconsistent not only between
optimization settings but also between different targets.  That in turn causes
hard to prevent build failures for the same code, which prompts some
people/teams to disable them altogether.

[Bug c/68971] -Woverflow false alarm in code unreachable after __builtin_mul_overflow

[eggert at gnu dot org]

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

--- Comment #8 from Paul Eggert  ---
(In reply to Martin Sebor from comment #7)

> Perhaps what's needed is for GCC to treat the builtins as constant
> expressions when they're invoked with them as operands.  If you agree with
> that approach, I suggest closing this bug and opening a new one with that
> request.

Yes, I already filed a bug report along these lines, as Bug#68120.

> because sophisticated warnings that try to avoid
> issuing false positives for unreachable code (e.g., -Wmaybe-uninutialized)
> depend on optimizations they tend to be inconsistent not only between
> optimization settings but also between different targets.

Yes, that issue is well known. We generally work around the problem by enabling
fancy warnings only on one platform (x86-64) with known settings, and not
bothering with other platforms. A corollary of this practice is that
warning-related GCC bugs tend not to be reported or fixed on platforms other
than x86-64.

However, this workaround does not suffice for -Woverflow because -Woverflow is
enabled by default. This raises the priority of getting -Woverflow right.

[Bug sanitizer/65479] sanitizer stack trace missing frames past #0 on powerpc64

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Target||powerpc64*-*-linux*
 CC||wschmidt at gcc dot gnu.org

--- Comment #11 from Bill Schmidt  ---
Martin, can this be closed?

[Bug c/68986] New: internal compiler error: Segmentation fault

[jas...@3db-labs.com]

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

Bug ID: 68986
   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jas...@3db-labs.com
  Target Milestone: ---

Created attachment 37087
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37087=edit
C source file that demonstrates the error

I'm running on Ubuntu 14.04 (x86_64) using gcc 5.3.0. I've also observed this
problem with 5.2.0 and 5.2.1 at least, however. I haven't seen any problems
with any gcc versions in the 4.x series; it appears to be isolated to 5.x at
least.

Here is the output of gcc run with the `-v` argument:

$ gcc-5 -v
Using built-in specs.
COLLECT_GCC=gcc-5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.3.0-3ubuntu1~14.04' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=gcc4-compatible --disable-libstdcxx-dual-abi
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.3.0 20151204 (Ubuntu 5.3.0-3ubuntu1~14.04)

I compile the attached C file (which is reduced down from the original file,
down to the minimum code required to show the compiler error) using the
following command line:

gcc-5 tracesig.c -c -fPIC -mpreferred-stack-boundary=5
-mincoming-stack-boundary=4

The stack-related options come from source code elsewhere in this project that
has particular SIMD requirements. When I execute the above command line, I get
the following output:

tracesig.c: In function ‘char* __check_point_msg_buffer()’:
tracesig.c:20:1: internal compiler error: Segmentation fault
 }
 ^
0xa8842f crash_signal
../../src/gcc/toplev.c:383
0xcca22c ix86_expand_prologue()
../../src/gcc/config/i386/i386.c:11503
0xda9dca gen_prologue()
../../src/gcc/config/i386/i386.md:12254
0x877cbf thread_prologue_and_epilogue_insns()
../../src/gcc/function.c:5930
0x8784a2 rest_of_handle_thread_prologue_and_epilogue
../../src/gcc/function.c:6500
0x8784a2 execute
../../src/gcc/function.c:6538
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I will attach the preprocessed file in a subsequent reply to the report.

[Bug c/68986] internal compiler error: Segmentation fault

[jas...@3db-labs.com]

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

--- Comment #1 from jas...@3db-labs.com ---
Created attachment 37088
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37088=edit
preprocessed output file from gcc

[Bug tree-optimization/68967] Build and test parloops on by default

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #37069|0   |1
is obsolete||

--- Comment #7 from vries at gcc dot gnu.org ---
Created attachment 37090
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37090=edit
0003-compile-target-libgomp-before-configuring-other-libs.patch

Updated version.

With this version, I was able to do a c bootstrap with --disable-multilib.

[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-18
 Ever confirmed|0   |1

--- Comment #4 from Markus Trippelsdorf  ---
trippels@gcc2-power8 c++98 % valgrind --trace-children=yes --track-origins=yes
~/gcc_test/usr/local/bin/g++ -std=gnu++98 -O2 -c parallel_settings.ii
==124421== Memcheck, a memory error detector
==124421== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==124421== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==124421== Command: /home/trippels/gcc_test/usr/local/bin/g++ -std=gnu++98 -O2
-c parallel_settings.ii
==124421== 
==124423== Memcheck, a memory error detector
==124423== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==124423== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==124423== Command:
/home/trippels/gcc_test/usr/local/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/6.0.0/cc1plus
-fpreprocessed parallel_settings.ii -quiet -dumpbase parallel_settings.ii
-mcpu=power8 -auxbase parallel_settings -O2 -std=gnu++98 -o
/home/trippels/tmp/ccj9CuMk.s
==124423== 
==124423== Conditional jump or move depends on uninitialised value(s)
==124423==at 0x10A76104: default_secondary_reload(bool, rtx_def*, int,
machine_mode, secondary_reload_info*) (targhooks.c:940)
==124423==by 0x10E4DDB3: rs6000_secondary_reload(bool, rtx_def*, int,
machine_mode, secondary_reload_info*) (rs6000.c:18415)
==124423==by 0x1085CE37: copy_cost(rtx_def*, machine_mode, int, bool,
secondary_reload_info*) [clone .part.7] (ira-costs.c:445)
==124423==by 0x1085CEA7: copy_cost (ira-costs.c:434)
==124423==by 0x1085CEA7: copy_cost(rtx_def*, machine_mode, int, bool,
secondary_reload_info*) [clone .part.7] (ira-costs.c:452)
==124423==by 0x1085D3E3: copy_cost (ira-costs.c:434)
==124423==by 0x1085D3E3: record_reg_classes(int, int, rtx_def**,
machine_mode*, char const**, rtx_insn*, reg_class*) [clone .constprop.43]
(ira-costs.c:984)
==124423==by 0x1085F77F: record_operand_costs(rtx_insn*, reg_class*)
(ira-costs.c:1325)
==124423==by 0x1085FCCB: scan_one_insn (ira-costs.c:1462)
==124423==by 0x1085FCCB: process_bb_for_costs(basic_block_def*)
(ira-costs.c:1583)
==124423==by 0x10855A2F: ira_traverse_loop_tree(bool, ira_loop_tree_node*,
void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
(ira-build.c:1798)
==124423==by 0x108626FF: find_costs_and_classes(_IO_FILE*)
(ira-costs.c:1680)
==124423==by 0x10862EB3: ira_costs() (ira-costs.c:2213)
==124423==by 0x10859D9B: ira_build() (ira-build.c:3419)
==124423==by 0x1084FA4B: ira (ira.c:5219)
==124423==by 0x1084FA4B: (anonymous
namespace)::pass_ira::execute(function*) (ira.c:5511)
==124423==  Uninitialised value was created by a stack allocation
==124423==at 0x1085CDA8: copy_cost(rtx_def*, machine_mode, int, bool,
secondary_reload_info*) [clone .part.7] (ira-costs.c:426)

[Bug c++/68985] New: braced initializer bug when defining a static constexpr int within a class

[ryan.burn at gmail dot com]

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

Bug ID: 68985
   Summary: braced initializer bug when defining a static
constexpr int within a class
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

The follow code compiles fine with clang
(http://melpon.org/wandbox/permlink/VNNQJW7whi3CmEKH) but gives this error with
gcc:

prog.cc:12:39: error: cannot convert 'my_t' to 'const int' in
initialization
   static constexpr int x = my_t{};
   ^


template 
struct A{   
  constexpr operator int() { return I; }
};  

template
using my_t = A;  

template
class B {   
 public:
  static constexpr int x = my_t{};
};  

int main() {
  return 0; 
} 

[Bug rtl-optimization/58967] Powerpc -mlra cannot compile quadrature_lib.cc in Spec2006 with -O3 -ffast-math -funroll-loops -m32

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||wschmidt at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Bill Schmidt  ---
Fixed some time ago.

[Bug c/68120] can't easily deal with integer overflow at compile time

[eggert at gnu dot org]

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

--- Comment #2 from Paul Eggert  ---
(In reply to Paul Eggert from comment #0)
> I am working around the problem with macro definitions like this:
> 
>  # define INT_ADD_OVERFLOW(a, b) \
>(__builtin_constant_p ((a) == (b)) \
> ? _GL_INT_ADD_OVERFLOW (a, b) \
> : __builtin_add_overflow (a, b, &(__typeof__ ((a) + (b))) {0}))

Just to follow up on my own bug report, the above approach turned out not to
work, because the resulting macro expands to an expression that is not an
integer constant expression according to GCC's current rules. I eventually gave
up on this approach entirely, and INT_ADD_OVERFLOW (a, b) now expands to this:

  (0 * (0 * (b) + (a)) - (1)) < 0) ? - (~ (0 * (0 * (b) + (a)) + (0)) ==
-1) - 0 * (0 * (b) + (a)) + (1)) << (sizeof ((0 * (b) + (a)) + 0) * 8 - 2))
- 1) * 2 + 1) : (0 * (0 * (b) + (a)) + (0 < 0 ? ((b) < 0 ? (a) < 0 * (0
* (b) + (a)) - (1)) < 0) ? - (~ (0 * (0 * (b) + (a)) + (0)) == -1) - 0 * (0
* (b) + (a)) + (1)) << (sizeof ((0 * (b) + (a)) + 0) * 8 - 2)) - 1) * 2 + 1) :
(0 * (0 * (b) + (a)) + (0 - (b) : 0 * (0 * (b) + (a)) - (1)) < 0) ?
0 * (0 * (b) + (a)) + (1)) << (sizeof ((0 * (b) + (a)) + 0) * 8 - 2)) - 1)
* 2 + 1) : (0 * (0 * (b) + (a)) - (1 - (b) < (a)) : (a) < 0 ? (b) <= (a) +
(b) : (b) < 0 ? (a) <= (a) + (b) : (a) + (b) < (b))

Although this *is* an integer constant expression, it is less nice than a
simple call to __builtin_add_overflow would be, and it generates less-efficient
code in some cases when A and B are not constants.

[Bug target/65421] inefficient code returning float aggregates on powepc64le

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2015-03-18 00:00:00 |2015-12-18
  Known to fail||5.1.0, 6.0

--- Comment #2 from Martin Sebor  ---
Today's trunk emits the same code as 5.1.0.

[Bug c++/67592] A virtual member function declared constexpr fails to trigger a diagnostic

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri Dec 18 18:18:47 2015
New Revision: 231824

URL: https://gcc.gnu.org/viewcvs?rev=231824=gcc=rev
Log:
/cp
2015-12-18  Paolo Carlini  

PR c++/67592
* decl.c (grokdeclarator): Reject constexpr virtual member functions;
in error messages, prefer % and % to virtual
and constexpr, respectively.

/testsuite
2015-12-18  Paolo Carlini  

PR c++/67592
* g++.dg/cpp0x/constexpr-virtual5.C: New.
* g++.dg/cpp0x/pr51463.C: Adjust dg-error string.
* g++.dg/inherit/pure1.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-virtual5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/pr51463.C
trunk/gcc/testsuite/g++.dg/inherit/pure1.C

[Bug c++/68819] Invalid "-Wmisleading-indentation" warning if location_t >=LINE_MAP_MAX_LOCATION_WITH_COLS

[dmalcolm at gcc dot gnu.org]

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

--- Comment #10 from David Malcolm  ---
Updated patch, which addresses the LINE_MAP_MAX_LOCATION_WITH_COLS limit:
  https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01921.html

[Bug c++/67592] A virtual member function declared constexpr fails to trigger a diagnostic

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

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

[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9

[glaubitz at physik dot fu-berlin.de]

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

John Paul Adrian Glaubitz  changed:

   What|Removed |Added

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

--- Comment #25 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #24)
> Will report back by then.

This issue no longer occurs with gcc-5_5.3.1-3 from Debian (SVN/gcc-5 branch
r231361) and this bug can therefore be marked as RESOLVED/FIXED.

Full build log:
https://people.debian.org/~glaubitz/gcc-5_5.3.1-3+sh4_sh4-20151216-2227.build

[Bug rtl-optimization/68988] reload_pseudo_compare_func violates qsort requirements

[y.gribov at samsung dot com]

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

--- Comment #1 from Yury Gribov  ---
The bug was detected with SortChecker tool (https://github.com/yugr/sortcheck).

[Bug c++/68983] [6 Regression] ICE: in store_field, at expr.c:6659

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-18
 Ever confirmed|0   |1

--- Comment #2 from Markus Trippelsdorf  ---
class SvxOptionsGrid {
  int nFldDrawX;
  bool bEqualGrid;
public:
  ~SvxOptionsGrid();
};
class A : SvxOptionsGrid {
public:
  A(SvxOptionsGrid p1) : SvxOptionsGrid(p1) {}
};
SvxOptionsGrid a;
void fn1() { A b(a); }

[Bug libfortran/68987] [5/6 Regression] double free or corruption in _gfortran_st_write_done when a write statement to an internal file uses an invalid format and the ERR= specifier appears.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-18
 CC||jvdelisle at gcc dot gnu.org
Summary|double free or corruption   |[5/6 Regression] double
   |in _gfortran_st_write_done  |free or corruption in
   |when a write statement to   |_gfortran_st_write_done
   |an internal file uses an|when a write statement to
   |invalid format and the ERR= |an internal file uses an
   |specifier appears.  |invalid format and the ERR=
   ||specifier appears.
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed around revision r222140, may be r222111 (pr65089) for trunk (6.0) and
r229935 for the 5 branch.

[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Created attachment 37092
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37092=edit
gcc6-pr68763.patch

SO, I've tried to write a patch for this, and it passed bootstrap, but
introduced:
+FAIL: g++.dg/ext/attr-aligned01.C  -std=c++11  (test for warnings, line 18)
+FAIL: g++.dg/ext/attr-aligned01.C  -std=c++11 (test for excess errors)
+FAIL: g++.dg/ext/attr-aligned01.C  -std=c++14  (test for warnings, line 18)
+FAIL: g++.dg/ext/attr-aligned01.C  -std=c++14 (test for excess errors)
+FAIL: g++.dg/ext/attr-aligned01.C  -std=c++98  (test for warnings, line 18)
+FAIL: g++.dg/ext/attr-aligned01.C  -std=c++98 (test for excess errors)
+FAIL: 20_util/decay/requirements/alias_decl.cc (test for excess errors)
+FAIL: 20_util/function/cons/57465.cc (test for excess errors)
+UNRESOLVED: 20_util/function/cons/57465.cc compilation failed to produce
executable
regressions.  The attr-aligned01.C seems to be from the ARRAY_TYPE hunk, for
the others dunno.  But I'm afraid I need to give up at this point.