[Bug tree-optimization/69400] [5/6 Regression] wrong code with -O and int128

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-21
 CC||hjl.tools at gmail dot com
   Target Milestone|--- |5.4
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
It is very likely a wide-int bug.

[Bug c/52291] __sync_fetch_and_add and friends poorly specified for pointer types

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Thu Jan 21 03:38:32 2016
New Revision: 232662

URL: https://gcc.gnu.org/viewcvs?rev=232662=gcc=rev
Log:
PR c/52291 - __sync_fetch_and_add and friends poorly specified for pointer
types

2016-01-20  Martin Sebor  

* extend.texi (__sync Builtins): Clarify the semantics of
__sync_fetch_and_OP built-ins on pointers.
(__atomic Builtins): Same.

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

[Bug fortran/68442] ICE on kind specification, depending on ordering of functions

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #4)
> Related to pr69397. With the patch in pr69397 comment 2, the ICE is replaced
> with the error:
> 
> pr68442.f90:7:21:
> 
>character(kind=gkind()) :: x
>  1
> 
> Error: There is no specific function for the generic 'gkind' at (1)
> 
> When I applied the patch, I was not happy with this message: it points to
> the problem, but IMO with a wrong diagnostic.

I am currently getting:

$ gfc pr68442.f90 
pr68442.f90:10:21:

   character(kind=gkind()) :: x
 1

Error: Function ‘gkind’ in initialization expression at (1) must be an
intrinsic function

[Bug testsuite/69371] UNRESOLVED: special_functions/18_riemann_zeta/check_value.cc compilation failed to produce executable

[thopre01 at gcc dot gnu.org]

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

--- Comment #4 from Thomas Preud'homme  ---
Doh, I should have caught that earlier. The bug can be seen in:

% grep -c dg-option special_functions/18_riemann_zeta/check_value.cc
3

Using dg-additional-option for the timeout solves the issue. Maybe the patch
could also remove the redundant timeout adjustment in the testcase?

[Bug c/69407] New: -Wunused-value on __atomic_fetch_OP and __atomic_OP_fetch

[msebor at gcc dot gnu.org]

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

Bug ID: 69407
   Summary: -Wunused-value on __atomic_fetch_OP and
__atomic_OP_fetch
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Invoking the __atomic_fetch_OP and __atomic_OP_fetch intrinsics without using
their return value elicits a -Wunused-value warning.  The warning doesn't seem
useful, especially in the __atomic_OP_fetch(ptr, val) case, since a) whether
the computed value is used impossible to determine at the call site, and b) the
corresponding (*ptr OP= val) expressions don't cause any warnings.  (As
expected, the warnings can be suppressed by casting the result ti void).

No other CCC-compatible compiler emits warnings for these intrinsics.

$ cat z.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -S -Wall -Wextra -Wpedantic -o/dev/null
z.c 
void foo (int*i, int);

void foo (int *p, int a)
{
__atomic_fetch_add (, a, 0);
__atomic_add_fetch (, a, 0);

}

z.c: In function ‘foo’:
z.c:5:5: warning: value computed is not used [-Wunused-value]
 __atomic_fetch_add (, a, 0);
 ^

z.c:6:5: warning: value computed is not used [-Wunused-value]
 __atomic_add_fetch (, a, 0);
 ^

[Bug c/52291] __sync_fetch_and_add and friends poorly specified for pointer types

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Documentation patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01581.html

[Bug c/69404] New: atomic builtins silently discard cv-qualifiers

[msebor at gcc dot gnu.org]

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

Bug ID: 69404
   Summary: atomic builtins silently discard cv-qualifiers
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The atomic builtins such as __atomic_load and __atomic_exchange silently
discard qualifiers from the types of their operands.  The following test case
compiles without a warning with 6.0:

$ cat z.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -S -Wall -Wextra -Wpedantic -o/dev/null
z.c
int* foo (const int *p)
{
int *q;
__atomic_load (, , 0);
return q;
}

int* bar (const volatile int *p)
{
int *q;
__atomic_exchange (, , , 0);
return q;
}

The same test case produces the warnings below with Clang:

$ /build/llvm-trunk/bin/clang -S z.c
z.c:4:24: warning: passing 'int **' to parameter of type 'const int **'
discards
  qualifiers in nested pointer types
  [-Wincompatible-pointer-types-discards-qualifiers]
__atomic_load (, , 0);
   ^~
z.c:11:32: warning: passing 'int **' to parameter of type
  'const volatile int **' discards qualifiers in nested pointer types
  [-Wincompatible-pointer-types-discards-qualifiers]
__atomic_exchange (, , , 0);
   ^~
2 warnings generated.

[Bug c/69404] atomic builtins accept incompatible pointers

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
The GCC manual says the __atomic builtins are meant to be compatible with those
described in the Intel Itanium Processor-specific Application Binary Interface,
section 7.4.  Both the ABI and the GCC manual describe the builtins to operate
on objects of some /type/.  For example, __atomic_load is described like so:

  __atomic_load (type *ptr, type *ret, int memorder)

implying that ptr and ret should be compatible.  (The ABI doesn't describe
__atomic_load but it does describe many of the __atomic builtins.)

GCC rejects the test cases when the __atomic builtins are replaced with the
corresponding C11 atomic generic functions defined in , but only
because these are implemented as macros involving conversions that detect the
incompatibility.  The C11 generics that don't do such conversions are just as
impotent at detecting incompatibilities as the corresponding builtins.  For
example, GCC doesn't diagnose the program below (both Clang and Intel CC do
issue the expected diagnostic -- ICC when the _Atomic keyword is removed as it
doesn't seem to understand it yet).

$ cat z.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -S -Wall -Wextra -Wpedantic -o/dev/null
z.c 
#include 

int* foo (void (*p)(void))
{
int* _Atomic q;
atomic_init (, 0);

atomic_fetch_add (, p);
return q;
}

I certainly agree that GCC can define its own extensions any way it sees fit. 
But I can think of no use for this "extension" except to make it easier to
accidentally write incorrect code.

Incidentally, I came across this problem while testing a patch for bug 64843
(and improving the documentation of the builtins in the GCC manual op resolve
bug 52291).

[Bug c/52291] __sync_fetch_and_add and friends poorly specified for pointer types

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Fixed in r232662.

[Bug target/69403] New: Wrong thumb2_ior_scc_strict_it insn pattern.

[shenhan at google dot com]

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

Bug ID: 69403
   Summary: Wrong thumb2_ior_scc_strict_it insn pattern.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shenhan at google dot com
  Target Milestone: ---

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

For the attached case.c, "armv7a-cros-linux-gnueabi-gcc -march=armv8-a -O2
case.c -S -mthumb" results in the following wrong assembly:

bug:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 1, uses_anonymous_args = 0
push{r3, r4, r5, r6, r7, lr}
cmp r0, r2
add r7, sp, #0
bcc .L8
mvn r0, #-2147483648
pop {r3, r4, r5, r6, r7, pc}
.L8:
mov r6, r2
mov r4, r1
mov r5, r0
bl  FT_MSB(PLT)
rsb r3, r0, #31
addsr2, r0, #1
lslsr5, r5, r3
lsr r1, r4, r2
orrsr5, r5, r1
lsl r1, r4, r3
udivr0, r5, r6
mls r3, r6, r0, r5
.L3:
lsrsr4, r1, #31
lslsr0, r0, #1
orr r3, r4, r3, lsl #1
lslsr1, r1, #1
cmp r6, r3
sub r5, r3, r6
>>> it  ls
>>> movls   r0, #1
>>> it  ls
>>> orrls   r0, r0
it  ls
movls   r3, r5
subsr2, r2, #1
bne .L3
pop {r3, r4, r5, r6, r7, pc}
.size   bug, .-bug
.ident  "GCC: (4.9.2_cos_gg_b6125c7_4.9.2-r115)
.section.note.GNU-stack,"",%progbits


The ">>>" lines (corresponding to line 27 in case.c) effectively set r0 to 1.

By examing the source code :
(define_insn "*thumb2_ior_scc_strict_it"
  [(set (match_operand:SI 0 "s_register_operand" "=l,l")
(ior:SI (match_operator:SI 2 "arm_comparison_operator"
 [(match_operand 3 "cc_register" "") (const_int 0)])
(match_operand:SI 1 "s_register_operand" "0,?l")))]
  "TARGET_THUMB2 && arm_restrict_it"
  "@
   it\\t%d2\;mov%d2\\t%0, #1\;it\\t%d2\;orr%d2\\t%0, %1  <<<=== Alternative 1
   mov\\t%0, #1\;orr\\t%0, %1\;it\\t%D2\;mov%D2\\t%0, %1"  <<<=== Alternative 2


It seemd to me: alternative 1, when register %1 == register %0 (which is
asserted in the insn constraints), the first move "mov%d2\\t%0, #1" apparently
destroys the value in the register. The result of this being register %0 =
register %1 = 1.

A quick fix, which we currently use as workaround, is:
   it\\t%d2\;orr%d2\\t%0, %1, #1  <<<=== Alternative 1
Which is a fallback to "thumb2_ior_scc" and assembly warns about 32-bit thumb
within armv8 itblocks.

A better fix is welcomed!

[Bug c/69404] atomic builtins accept incompatible pointers

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|atomic builtins silently|atomic builtins accept
   |discard cv-qualifiers   |incompatible pointers

--- Comment #1 from Martin Sebor  ---
Actually, with more testing I see the builtins do even more than that: they
silently convert between pointers to types of the same size.  (Clang diagnoses
those as well.)

$ cat z.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -S -Wall -Wextra -Wpedantic -o/dev/null
z.c
int* foo (void (*p)(void))
{
int *q;
__atomic_load (, , 0);
return q;
}

[Bug ipa/68273] [5/6 Regression] Wrong code on mips/mipsel with -fipa-sra

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #4 from Jeffrey A. Law  ---
It's starting to look like a problem in tree-ssa-pre.c

Essentially we have these these key statements in various blocks:

  _10 = yyvsp_1->sym;
  _15 = yyvsp_1->sym;
  _17 = enter (_14, _15);
  _22 = MEM[(union YYSTYPE *)yyvsp_1];

Respectively _10 and _22 have the types:

(gdb) p debug_tree (cfun->gimple_df->ssa_names.m_vecdata[10]->typed.type)
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x703842a0
fields 
unsigned SI file j.c line 4 col 9 size  unit size 
align 32 offset_align 64
offset 
bit offset  context
> context 
pointer_to_this  chain >
sizes-gimplified public unsigned SI size 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x703c6540>


(gdb) p debug_tree (cfun->gimple_df->ssa_names.m_vecdata[22]->typed.type)
 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x703843f0 context

pointer_to_this  chain >
sizes-gimplified unsigned SI
size  constant 32>
unit size  constant 4>
align 64 symtab 0 alias set -1 canonical type 0x70384d20>

The type of _15 is the same as the type of _10.

For reference, we're referring to instances of this structure:

union YYSTYPE
{
  Symbol *sym;
  Node rec;
};


The key thing to note from the types is they have different alignments.

Anyway, PRE detects the redundant memory reference and creates:

  # prephitmp_23 = PHI 


Where _23 and _26 will have the type with the 64 bit alignment.

That node feeds this statement:

  _17 = enter (_14, prephitmp_23);

Yow!  Remember that statement previously looked like:

  _17 = enter (_14, _15);

So the alignment associated with the second argument to "enter" has changed
from 32 to 64.  That in turn may change how the argument gets passed on some
ports (mips, epiphany, maybe others).   In this specific instance is causes the
MIPS backend to align the parameter, passing it in $6 rather than where the
callee expects it ($5), which in turn results in gsoap being mis-compiled on
MIPS.

Richi -- you know the PRE code better than anyone that's currently active. 
Thoughts?

[Bug tree-optimization/69400] [5/6 Regression] wrong code with -O and int128

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||mrs at gcc dot gnu.org

--- Comment #2 from H.J. Lu  ---
It is caused by r210113.

[Bug c/69405] New: [6 Regression] ICE in c_tree_printer on an invalid __atomic_fetch_add

[msebor at gcc dot gnu.org]

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

Bug ID: 69405
   Summary: [6 Regression] ICE in c_tree_printer on an invalid
__atomic_fetch_add
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Today's trunk fails with the ICE below on the following invalid test case (p is
not declared).  5.1.0 issues the expected errors and exits.

$ cat z.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -S -Wall -Wextra -Wpedantic -o/dev/null
z.c 
void foo (void)
{
int *q = 0;
__atomic_fetch_add (, , 0);
}

z.c: In function ‘foo’:
z.c:4:26: error: ‘p’ undeclared (first use in this function)
 __atomic_fetch_add (, , 0);
  ^

z.c:4:26: note: each undeclared identifier is reported only once for each
function it appears in
‘
in c_tree_printer, at c/c-objc-common.c:128
 __atomic_fetch_add (, , 0);
 ^~

0x7c05b4 c_tree_printer
/home/msebor/scm/fsf/gcc-git/gcc/c/c-objc-common.c:128
0x184814a pp_format(pretty_printer*, text_info*)
/home/msebor/scm/fsf/gcc-git/gcc/pretty-print.c:634
0x1841e2d diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/msebor/scm/fsf/gcc-git/gcc/diagnostic.c:797
0x18430ff error(char const*, ...)
/home/msebor/scm/fsf/gcc-git/gcc/diagnostic.c:1157
0x83fa29 sync_resolve_size
/home/msebor/scm/fsf/gcc-git/gcc/c-family/c-common.c:10708
0x840e78 resolve_overloaded_builtin(unsigned int, tree_node*, vec*)
/home/msebor/scm/fsf/gcc-git/gcc/c-family/c-common.c:11393
0x790edf c_build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*)
/home/msebor/scm/fsf/gcc-git/gcc/c/c-typeck.c:3098
0x7d3988 c_parser_postfix_expression_after_primary
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:8222
0x7d311e c_parser_postfix_expression
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:8034
0x7cf35e c_parser_unary_expression
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:6852
0x7ce7d7 c_parser_cast_expression
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:6681
0x7cd4d9 c_parser_binary_expression
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:6490
0x7ccd6f c_parser_conditional_expression
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:6261
0x7cca7f c_parser_expr_no_commas
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:6178
0x7d4140 c_parser_expression
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:8363
0x7d4395 c_parser_expression_conv
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:8396
0x7ca83d c_parser_statement_after_labels
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:5251
0x7c9c27 c_parser_compound_statement_nostart
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:4835
0x7c962f c_parser_compound_statement
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:4671
0x7c42ee c_parser_declaration_or_fndef
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:2088
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/69397] ICE on missing subprogram in generic interface

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #2)
> Related to/duplicate of pr68442.

Sort of related, but I find 68442 fixed already.


> -  gcc_assert (sym->attr.flavor == FL_PROCEDURE);
> +  /* gcc_assert (sym->attr.flavor == FL_PROCEDURE); */
> +  if (sym->attr.flavor != FL_PROCEDURE)
> +return false;
>  
How is this for error messages (I tweaked the second one):

$ gfc pr69397.f90 
pr69397.f90:3:18:

   procedure f1
  1

Error: Procedure ‘f1’ in generic interface 'f' at (1) is neither function nor
subroutine
pr69397.f90:7:11:

print *, f(z)
   1

Error: Generic procedure ‘f’ at (1) must have a specific procedure defined

[Bug tree-optimization/69400] [5/6 Regression] wrong code with -O and int128

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
Fix this may also fix PR 69399.

[Bug rtl-optimization/69377] [6 Regression] wrong code at -O2 on x86_64-linux-gnu (in 32-bit mode)

[kugan at gcc dot gnu.org]

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

kugan at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kugan at gcc dot gnu.org

--- Comment #3 from kugan at gcc dot gnu.org ---
I am not able to reproduce it.

This is my setup:

I had to initialise variables in gcc/ccmp.c to workaround uninitiated
variables.
I did ./contrib/download_prerequisites in source tree.

x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/home/kugan/test/install3/usr/local/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/kugan/test/install3/usr/local/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --enable-multilib
Thread model: posix
gcc version 6.0.0 20160119 (experimental) (GCC) 

x86_64-pc-linux-gnu-gcc -O2 -m32 t1.c; ./a.out
2
1
1

Also tried -O1/-Os/-O3

[Bug c/69404] atomic builtins accept incompatible pointers

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Martin Sebor from comment #1)
> Actually, with more testing I see the builtins do even more than that: they
> silently convert between pointers to types of the same size.  (Clang
> diagnoses those as well.)
> 
> $ cat z.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
> -B/home/msebor/build/gcc-trunk-git/gcc -S -Wall -Wextra -Wpedantic
> -o/dev/null z.c
> int* foo (void (*p)(void))
> {
> int *q;
> __atomic_load (, , 0);
> return q;
> }

Most likely because it treats it as void* :).

Since this is an GCC extension, GCC can define the behavior any which way it
wants.  If clang is not compatible is not GCC's fault.
Does stdatomic.h defines have the same issue then there is a problem there.

[Bug c/69404] atomic builtins accept incompatible pointers

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Oh one more thing about qualifiers: _Atomic is a qualifer.

[Bug tree-optimization/69400] [5/6 Regression] wrong code with -O and int128

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
Before wide-int:

Lattice value changed to CONSTANT 18446744073709551614.  Adding SSA edges to
worklist.

After wide-int:

Lattice value changed to CONSTANT 0xfffe.  Adding
SSA edges to worklist.

It is wrong to sign-extend (__int128) 0xfffe.

[Bug c++/69402] Incorrect dependency generation when precompiled headers are used

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 14933.

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

[Bug pch/14933] missing pre-compiled header depends with -MD

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||hcma at hcma dot info

--- Comment #14 from Andrew Pinski  ---
*** Bug 69402 has been marked as a duplicate of this bug. ***

[Bug c/69404] atomic builtins accept incompatible pointers

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
So this might be following C++ rules here dealing with qualifiers.

There is no discarding of qualifiers either but rather adding them according to
C++ rules.

Note C and C++ deals with inner qualifiers differently.

The reason why I said it does not discard here is because take:
__atomic_load (, , 0);


This is basically p = q;  so you need to add const qualifier to the inner most
type.  And __atomic_load supports pointers to pointers that have qualifiers on
the inner type.

[Bug c/69405] [6 Regression] ICE in c_tree_printer on an invalid __atomic_fetch_add

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-01-21
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Looks like my own r232147 is the responsible commit.

[Bug c/69405] [6 Regression] ICE in c_tree_printer on an invalid __atomic_fetch_add

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||6.0

--- Comment #2 from Martin Sebor  ---
Fix posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01592.html

[Bug testsuite/69406] New: FAIL: 17_intro/headers/c++2011/linkage.cc (test for excess errors)

[thopre01 at gcc dot gnu.org]

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

Bug ID: 69406
   Summary: FAIL: 17_intro/headers/c++2011/linkage.cc (test for
excess errors)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

17_intro/headers/c++2011/linkage.cc fails on arm-none-eabi targets with the
error:

17_intro/headers/c++2011/linkage.cc:47:19: fatal error: uchar.h: No such file
or directory
(...)
FAIL: 17_intro/headers/c++2011/linkage.cc (test for excess errors)

This is because arm-none-eabi uses newlib which does not provide uchar.h. I am
not sure about the correct course of action. Should a xfail be added for newlib
targets? Since uchar.h seems to come from C11, maybe it would be more
appropriate to xfail all tests involving C11 for newlib target?

Best regards.

[Bug preprocessor/55115] [4.9/5/6 Regression] missing headers as fatal breaks cproto logic

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |WONTFIX

--- Comment #17 from Jeffrey A. Law  ---
Fundamentally, trying to include a non-existent header should trigger a fatal
error.  The fact that cproto has depended on GCC not doing that is unfortunate,
but I don't think catering to this broken cproto design is something we ought
to do.

[Bug testsuite/69366] All MPX tests are unsupported

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Jan 20 14:34:55 2016
New Revision: 232617

URL: https://gcc.gnu.org/viewcvs?rev=232617=gcc=rev
Log:
Require non-x32 target for compile-time MPX tests

Compile-time MPX tests don't need the MPX run-time library.  They
should pass for non-x32 target.

Backport from mainline
PR testsuite/69366
* g++.dg/pr63995-1.C: Require non-x32 target, instead of,
the MPX run-time library, for compile-time MPX test.
* gcc.target/i386/chkp-always_inline.c: Likewise.
* gcc.target/i386/chkp-bndret.c: Likewise.
* gcc.target/i386/chkp-builtins-1.c: Likewise.
* gcc.target/i386/chkp-builtins-2.c: Likewise.
* gcc.target/i386/chkp-builtins-3.c: Likewise.
* gcc.target/i386/chkp-builtins-4.c: Likewise.
* gcc.target/i386/chkp-const-check-1.c: Likewise.
* gcc.target/i386/chkp-const-check-2.c: Likewise.
* gcc.target/i386/chkp-hidden-def.c: Likewise.
* gcc.target/i386/chkp-label-address.c: Likewise.
* gcc.target/i386/chkp-lifetime-1.c: Likewise.
* gcc.target/i386/chkp-narrow-bounds.c: Likewise.
* gcc.target/i386/chkp-remove-bndint-1.c: Likewise.
* gcc.target/i386/chkp-remove-bndint-2.c: Likewise.
* gcc.target/i386/chkp-strchr.c: Likewise.
* gcc.target/i386/chkp-strlen-1.c: Likewise.
* gcc.target/i386/chkp-strlen-2.c: Likewise.
* gcc.target/i386/chkp-strlen-3.c: Likewise.
* gcc.target/i386/chkp-strlen-4.c: Likewise.
* gcc.target/i386/chkp-strlen-5.c: Likewise.
* gcc.target/i386/chkp-stropt-1.c: Likewise.
* gcc.target/i386/chkp-stropt-10.c: Likewise.
* gcc.target/i386/chkp-stropt-11.c: Likewise.
* gcc.target/i386/chkp-stropt-12.c: Likewise.
* gcc.target/i386/chkp-stropt-13.c: Likewise.
* gcc.target/i386/chkp-stropt-14.c: Likewise.
* gcc.target/i386/chkp-stropt-15.c: Likewise.
* gcc.target/i386/chkp-stropt-16.c: Likewise.
* gcc.target/i386/chkp-stropt-2.c: Likewise.
* gcc.target/i386/chkp-stropt-3.c: Likewise.
* gcc.target/i386/chkp-stropt-4.c: Likewise.
* gcc.target/i386/chkp-stropt-5.c: Likewise.
* gcc.target/i386/chkp-stropt-6.c: Likewise.
* gcc.target/i386/chkp-stropt-7.c: Likewise.
* gcc.target/i386/chkp-stropt-8.c: Likewise.
* gcc.target/i386/chkp-stropt-9.c: Likewise.
* gcc.target/i386/pr63995-2.c: Likewise.
* gcc.target/i386/pr64805.c: Likewise.
* gcc.target/i386/pr65044.c: Likewise.
* gcc.target/i386/pr65167.c: Likewise.
* gcc.target/i386/pr65183.c: Likewise.
* gcc.target/i386/pr65184.c: Likewise.
* gcc.target/i386/thunk-retbnd.c: Likewise.

Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/g++.dg/pr63995-1.C
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-always_inline.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-bndret.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-builtins-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-builtins-2.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-builtins-3.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-builtins-4.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-const-check-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-const-check-2.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-hidden-def.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-label-address.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-lifetime-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-narrow-bounds.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-remove-bndint-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-remove-bndint-2.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-strchr.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-strlen-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-strlen-2.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-strlen-3.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-strlen-4.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-strlen-5.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-10.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-11.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-12.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-13.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-14.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-15.c

[Bug testsuite/69371] UNRESOLVED: special_functions/18_riemann_zeta/check_value.cc compilation failed to produce executable

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Ed Smith-Rowland from comment #2)
> The message looks more like a header - cmath - is not included or that 
> the line
> // { dg-options "-D__STDCPP_WANT_MATH_SPEC_FUNCS__" }
> or equivalent is not set.
> 
> But my fresh checkout has the necessary things..

Yes, I wondered if including  first was somehow preventing the extra
bits of  being included but it looks OK to me.

Preprocessed source will tell us what's happening.

[Bug target/65546] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #4 from Bill Schmidt  ---
I will take a look at this relatively soon.  Probably just a testsuite issue as
Richard surmises.

[Bug target/46393] [4.9/5/6 Regression] m68k code size regression

[law at redhat dot com]

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

--- Comment #1 from Jeffrey A. Law  ---
It appears the problem starts with forwprop turning the pointer accesses into
array/structure memory accesses.  This is generally a good thing.

However, in this instance it makes it awful hard to recover the CSE
opportunities  that are needed to get good compact code. 

We have 3 instances of:

  30 003e D3C2  add.l %d2,%a1
  31 0040 D3C9  add.l %a1,%a1
  32 0042 D3C2  add.l %d2,%a1

That's 12 wasted bytes.

ANd we two have two instances of:

  24 0032 5200  addq.b #1,%d0
  25 0034 5288  addq.l #1,%a0


Another two wasted bytes.

Also related we end up selecting poor addressing modes which probably another
10-16 bytes.

But at the core AFAICT is recovery of array/structure access from what was
pointer accesses.   In theory PRE ought to come along and pull out the
redundant address arithmetic, but it doesn't (not even with -O2).

It's not clear how prelevant this is across other architectures, so I'm keeping
a P4 for now.  If someone can show this causing problems on non-dead targets,
then we might consider bumping this up to a P2 priority.

[Bug c++/69390] dynamic_cast on rvalue fails

[kyle.strand at beckman dot com]

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

Kyle J Strand  changed:

   What|Removed |Added

 CC||kyle.strand at beckman dot com

--- Comment #1 from Kyle J Strand  ---
See http://stackoverflow.com/q/34901154/1858225. According to comments Clang
accepts this code.

[Bug preprocessor/69391] [5/6 Regression] Incorrect __LINE__ expansion with -ftrack-macro-expansion=0 on g++5.2

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Manuel López-Ibáñez from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > This changed behavior with r213102 aka PR61861.
> 
> Perhaps this comment is relevant?
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61861#c8


But the patch by Dodji is also wrong with rspect to this:

"I think the problem is that enter_macro_context() is passed the
location of the expansion point of the macro that is about to be
expanded.  But when that macro is built-in, builtin_macro() that is
then called by enter_macro_context() doesn't use the macro expansion
point location when expanding the __LINE__ builtin (in, e.g,
_cpp_builtin_macro_text) .  Rather, what it used is the location of
the closing parenthesis of the enclosing function-like macro
invocation or, more generally, the location of the previous token in
the stream."

according to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61817#c3

[Bug target/46393] [4.9/5/6 Regression] m68k code size regression

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
Summary|m68k code size regression   |[4.9/5/6 Regression] m68k
   ||code size regression

[Bug c/24293] Undefined behaviour not diagnosed with -fsyntax-only

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #5 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Wed Jan 20 16:25:23 2016
New Revision: 232622

URL: https://gcc.gnu.org/viewcvs?rev=232622=gcc=rev
Log:
2016-01-15  Prathamesh Kulkarni  

PR c/24293
* c-tree.h (incomplete_record_decls): Declare.
* c-parser.c (incomplete_record_decls): Define.
(c_parser_translation_unit): Iterate through incomplete_record_decls
and
report error if any decl has zero size.
* c-decl.c (finish_decl): Append static decl with incomplete
struct/union
or enum type to incomplete_record_decls.

testsuite/
* gcc.dg/pr24293.c: New test.
* gcc.dg/Wcxx-compat-8.c: Adjust to accept error due to
incomplete struct type.
* gcc.dg/declspec-1.c: Likewise.
* gcc.dg/pr63549.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.dg/pr24293.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/c/c-parser.c
trunk/gcc/c/c-tree.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Wcxx-compat-8.c
trunk/gcc/testsuite/gcc.dg/declspec-1.c
trunk/gcc/testsuite/gcc.dg/pr63549.c

[Bug c/24293] Undefined behaviour not diagnosed with -fsyntax-only

[prathamesh3492 at gcc dot gnu.org]

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||prathamesh3492 at gcc dot 
gnu.org

--- Comment #6 from prathamesh3492 at gcc dot gnu.org ---
Fixed on trunk.

[Bug target/69176] [6 Regression] ICE in in final_scan_insn, at final.c:2981 on aarch64-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #19 from Matthias Klose  ---
here is a test case from an ICE I saw when backporting the patch to the gcc-5
Linaro branch. Fails with -O2, works with -O1

typedef int Nlm_Int4, ValNodePtr;
Nlm_Int4 b, e;
char c, d;
void fn1();
typedef struct { double patternProbability; } patternSearchItems;
char fn2();
void fn3();
patternSearchItems a;
void fn4() {
  Nlm_Int4 f[2];
  char g[1];
  a = *(patternSearchItems *)fn3;
  while (fn2(c, d & e, b))
if (a.patternProbability) {
  fn1(g);
  fn1(f);
}
}

[Bug libstdc++/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15

[torvald at gcc dot gnu.org]

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

--- Comment #14 from torvald at gcc dot gnu.org ---
Author: torvald
Date: Wed Jan 20 17:47:03 2016
New Revision: 232628

URL: https://gcc.gnu.org/viewcvs?rev=232628=gcc=rev
Log:
libstdc++: Darwin does not support weak refs without definition.

PR libstdc++/69310
* config/os/bsd/darwin/os_defines.h (_GLIBCXX_USE_WEAK_REF): Define.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/os/bsd/darwin/os_defines.h

[Bug preprocessor/69391] [5/6 Regression] Incorrect __LINE__ expansion with -ftrack-macro-expansion=0 on g++5.2

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Jakub Jelinek from comment #3)
> This changed behavior with r213102 aka PR61861.

Perhaps this comment is relevant?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61861#c8

[Bug c++/59463] Illegal Instruction: min() _GLIBCXX_USE_NOEXCEPT { return __FLT_MIN__; }

[dank at kegel dot com]

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

dank at kegel dot com changed:

   What|Removed |Added

 CC||dank at kegel dot com

--- Comment #4 from dank at kegel dot com ---
I saw two other similar problems on the web.
https://bugs.archlinux.org/task/46562 suggests it might be a microcode problem.
http://permalink.gmane.org/gmane.linux.lfs.support/40714 suggests it can
be caused (repeatably) by the compiler's gmp being built for a different
machine.

I just ran into this myself on six jobs in a parallel build on a big
xeon vmware box.  It's reproduced in two out of two full runs, but
if I just rerun "make -j8", the build completes correctly, so it may
have to do with cpu load.

The simplified test case in #2 also doesn't seem to reproduce it.

// Thread model: posix
// gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)

The error varies; sometimes it's

// /usr/include/c++/5/limits:1598:7: internal compiler error: Illegal
instruction
//min() _GLIBCXX_USE_NOEXCEPT { return __FLT_MIN__; }

and sometimes it's

// /home/buildbot/src/yovo/libLoam/c++/Quat.h:440:3: internal compiler error:
Illegal instruction
//Quat Pow (float64 t, float64 thresh = 0.)  const
//^

So in my case it doesn't sound like a gcc problem.  Posting here for
completeness only.

[Bug lto/69394] New: [5.3] ICE when linking with lto

[daniel.f.starke at freenet dot de]

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

Bug ID: 69394
   Summary: [5.3] ICE when linking with lto
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.f.starke at freenet dot de
  Target Milestone: ---

Created attachment 37410
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37410=edit
ICE backtrace

Configured with: ../../src/gcc-5.3.0/configure --enable-languages=c,c++
--enable-seh-exceptions --enable-threads=posix --disable-nls
--enable-shared=libstdc++ --enable-static --enable-fully-dynamic-string
--enable-lto --enable-plugin --enable-libgomp --with-dwarf2
--disable-win32-registry --enable-version-specific-runtime-libs --prefix=/mingw
--with-sysroot=/mingw --target=x86_64-w64-mingw32 --enable-targets=all
--enable-checking=yes --with-gmp=/new-gcc/lib/gmp-5.0.5
--with-mpfr=/new-gcc/lib/mpfr-2.4.2 --with-mpc=/new-gcc/lib/mpc-0.9
--with-isl=/new-gcc/lib/isl-0.12.2 --with-cloog=/new-gcc/lib/cloog-0.18.3
--with-host-libstdcxx='-lstdc++ -lsupc++' --disable-cloog-version-check
--enable-cloog-backend=isl

Linking my C++ application leads to an ICE. The command invoked is:
x86_64-w64-mingw32-g++ -O3 -s -static -municode -D_UNICODE
-Wl,--allow-multiple-definition -flto -flto-partition=none -fuse-linker-plugin
-Wl,--gc-sections -Llib64 -L../libpcfxx/lib64 -o bin/pp.exe bin/pp.o
bin/posix_main.o bin/pp/Script.o bin/pp/Execution.o bin/pp/Variable.o
bin/pp/Shell.o bin/pp/Database.o bin/pp/Type.o bin/pp/parser/Utility.o
lib64/libpcfxx.a -lpcfxx -lboost_program_options -lboost_locale
-lboost_filesystem -lboost_iostreams -lboost_date_time -lboost_thread
-lboost_regex -lboost_system -lpcf -lsqlite3 -lws2_32
Passing -fno-use-linker-plugin instead of -fuse-linker-plugin works just fine
even if all files were compiled with -flto (flat object file).
Attached you can find the backtrace of the ICE.

[Bug target/69343] [6 Regression] Bootstrap failure on s390{,x}-linux

[rth at gcc dot gnu.org]

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

--- Comment #2 from Richard Henderson  ---
Author: rth
Date: Wed Jan 20 18:53:56 2016
New Revision: 232631

URL: https://gcc.gnu.org/viewcvs?rev=232631=gcc=rev
Log:
PR bootstrap/69343
PR bootstrap/69339
PR tree-opt/68964

Revert:
gcc/
  * tree.c (tm_define_builtin): New.
  (find_tm_vector_type): New.
  (build_tm_vector_builtins): New.
  (build_common_builtin_nodes): Call it.
libitm/
  * Makefile.am (libitm_la_SOURCES) [ARCH_AARCH64]: Add vect128.cc
  (libitm_la_SOURCES) [ARCH_ARM]: Add neon.cc
  (libitm_la_SOURCES) [ARCH_PPC]: Add vect128.cc
  (libitm_la_SOURCES) [ARCH_S390]: Add vect128.cc
  * configure.ac (ARCH_AARCH64): New conditional.
  (ARCH_PPC, ARCH_S390): Likewise.
  * Makefile.in, configure: Rebuild.
  * libitm.h (_ITM_TYPE_M128): Always define.
  * vect64.cc: Split ...
  * vect128.cc: ... out of...
  * config/x86/x86_sse.cc: ... here.
  * config/arm/neon.cc: New file.

Added:
trunk/libitm/config/x86/x86_sse.cc
  - copied, changed from r232628, trunk/libitm/vect128.cc
Removed:
trunk/libitm/config/arm/neon.cc
trunk/libitm/vect128.cc
trunk/libitm/vect64.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree.c
trunk/libitm/ChangeLog
trunk/libitm/Makefile.am
trunk/libitm/Makefile.in
trunk/libitm/configure
trunk/libitm/configure.ac
trunk/libitm/libitm.h

[Bug libstdc++/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15

[howarth.at.gcc at gmail dot com]

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

--- Comment #12 from Jack Howarth  ---
I can confirm that the following change allows current gcc trunk to bootstrap
on x86_64-apple-darwin15.

Index: libstdc++-v3/config/os/bsd/darwin/os_defines.h
===
--- libstdc++-v3/config/os/bsd/darwin/os_defines.h  (revision 232606)
+++ libstdc++-v3/config/os/bsd/darwin/os_defines.h  (working copy)
@@ -47,4 +47,7 @@
 #define _GLIBCXX_USE_NANOSLEEP 1
 #define _GLIBCXX_USE_SCHED_YIELD 1

+// No support for referencing weak symbols without a definition.
+#define _GLIBCXX_USE_WEAK_REF 0
+
 #endif

[Bug libstdc++/60401] stdlib.h does not provide abs(long) overload

[vogt at linux dot vnet.ibm.com]

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

--- Comment #7 from Dominik Vogt  ---
Created attachment 37408
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37408=edit
List of errors

This is a list of all remaining errors of the Plumhall test.  I've not checked
whether they all depend on math.h.

[Bug target/67439] [4.9 Regression]ICE: unrecognizable insn compiling arm-fp16 testcases with -march=armv7-a and -mrestrict-it

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from ktkachov at gcc dot gnu.org ---
Fixed on all active branches

[Bug libstdc++/60401] stdlib.h does not provide abs(long) overload

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Wed Jan 20 17:44:58 2016
New Revision: 232627

URL: https://gcc.gnu.org/viewcvs?rev=232627=gcc=rev
Log:
Add C++11  overloads to the global namespace

PR libstdc++/60401
* include/c_compatibility/math.h (acosh, asinh, atanh, acbrt,
copysign, erf, erfc, exp2, expm1, fdim, fma, fmax, fmin, hypot, ilogb,
lgamma, llrint, llround, log1p, log2, logb, lrint, lround, nearbyint,
nextafter, nexttoward, remainder, remquo, rint, round, scalbln, scalbn,
tgamma, trunc) [__cplusplus >= 201103L && _GLIBCXX_USE_C99_MATH_TR1]:
Add using declarations.
* testsuite/26_numerics/headers/cmath/60401.cc: New.

Added:
trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/60401.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/c_compatibility/math.h

[Bug rtl-optimization/64895] RA picks the wrong register for -fipa-ra

[renlin at gcc dot gnu.org]

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

Renlin Li  changed:

   What|Removed |Added

 CC||renlin at gcc dot gnu.org

--- Comment #12 from Renlin Li  ---
The same happens for aarch64.

> [hjl@gnu-tools-1 gcc]$ cat /tmp/x.c 
> static int __attribute__((noinline))
> bar (int x)
> {
>   if (x > 4)
> return bar (x - 3);
>   return 0;
> }
> 
> int __attribute__((noinline))
> foo (int y)
> {
>   return y + bar (y);
> }
> 

There is another problem here actually.

In this particular case, bar() is a static function which is not exported.
Although -fpic option is provided, pic_offset_table_rtx is not used at all in
function foo().

In this case, pic_offset_table_rtx may not be initialized at all. The target
hook TARGET_INIT_PIC_REG can be improved to initialize pic register only when
necessary.


On the other hand, if pic_offset_table_rtx is not used at all,
lra_risky_transformations_p should not be true. Does it make sensible?

diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index a78edd8..d4a950f 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -4221,7 +4221,8 @@ lra_constraints (bool first_p)
 lra_constraint_iter);
   changed_p = false;
   if (pic_offset_table_rtx
-  && REGNO (pic_offset_table_rtx) >= FIRST_PSEUDO_REGISTER)
+  && (i = REGNO (pic_offset_table_rtx)) >= FIRST_PSEUDO_REGISTER
+  && lra_reg_info[i].nrefs > 0)
 lra_risky_transformations_p = true;
   else
 lra_risky_transformations_p = false;

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

[rth at gcc dot gnu.org]

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

--- Comment #9 from Richard Henderson  ---
Author: rth
Date: Wed Jan 20 18:53:56 2016
New Revision: 232631

URL: https://gcc.gnu.org/viewcvs?rev=232631=gcc=rev
Log:
PR bootstrap/69343
PR bootstrap/69339
PR tree-opt/68964

Revert:
gcc/
  * tree.c (tm_define_builtin): New.
  (find_tm_vector_type): New.
  (build_tm_vector_builtins): New.
  (build_common_builtin_nodes): Call it.
libitm/
  * Makefile.am (libitm_la_SOURCES) [ARCH_AARCH64]: Add vect128.cc
  (libitm_la_SOURCES) [ARCH_ARM]: Add neon.cc
  (libitm_la_SOURCES) [ARCH_PPC]: Add vect128.cc
  (libitm_la_SOURCES) [ARCH_S390]: Add vect128.cc
  * configure.ac (ARCH_AARCH64): New conditional.
  (ARCH_PPC, ARCH_S390): Likewise.
  * Makefile.in, configure: Rebuild.
  * libitm.h (_ITM_TYPE_M128): Always define.
  * vect64.cc: Split ...
  * vect128.cc: ... out of...
  * config/x86/x86_sse.cc: ... here.
  * config/arm/neon.cc: New file.

Added:
trunk/libitm/config/x86/x86_sse.cc
  - copied, changed from r232628, trunk/libitm/vect128.cc
Removed:
trunk/libitm/config/arm/neon.cc
trunk/libitm/vect128.cc
trunk/libitm/vect64.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree.c
trunk/libitm/ChangeLog
trunk/libitm/Makefile.am
trunk/libitm/Makefile.in
trunk/libitm/configure
trunk/libitm/configure.ac
trunk/libitm/libitm.h

[Bug target/69339] [6 Regression] Failed to bootstrap powerpc-e500v2-linux-gnuspe target: libitm/vect128.cc:1:0: error: AltiVec and SPE instructions cannot coexist

[rth at gcc dot gnu.org]

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

--- Comment #1 from Richard Henderson  ---
Author: rth
Date: Wed Jan 20 18:53:56 2016
New Revision: 232631

URL: https://gcc.gnu.org/viewcvs?rev=232631=gcc=rev
Log:
PR bootstrap/69343
PR bootstrap/69339
PR tree-opt/68964

Revert:
gcc/
  * tree.c (tm_define_builtin): New.
  (find_tm_vector_type): New.
  (build_tm_vector_builtins): New.
  (build_common_builtin_nodes): Call it.
libitm/
  * Makefile.am (libitm_la_SOURCES) [ARCH_AARCH64]: Add vect128.cc
  (libitm_la_SOURCES) [ARCH_ARM]: Add neon.cc
  (libitm_la_SOURCES) [ARCH_PPC]: Add vect128.cc
  (libitm_la_SOURCES) [ARCH_S390]: Add vect128.cc
  * configure.ac (ARCH_AARCH64): New conditional.
  (ARCH_PPC, ARCH_S390): Likewise.
  * Makefile.in, configure: Rebuild.
  * libitm.h (_ITM_TYPE_M128): Always define.
  * vect64.cc: Split ...
  * vect128.cc: ... out of...
  * config/x86/x86_sse.cc: ... here.
  * config/arm/neon.cc: New file.

Added:
trunk/libitm/config/x86/x86_sse.cc
  - copied, changed from r232628, trunk/libitm/vect128.cc
Removed:
trunk/libitm/config/arm/neon.cc
trunk/libitm/vect128.cc
trunk/libitm/vect64.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree.c
trunk/libitm/ChangeLog
trunk/libitm/Makefile.am
trunk/libitm/Makefile.in
trunk/libitm/configure
trunk/libitm/configure.ac
trunk/libitm/libitm.h

[Bug preprocessor/69391] Incorrect __LINE__ expansion with -ftrack-macro-expansion=0 on g++5.2

[mail at bobah dot net]

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

mail at bobah dot net changed:

   What|Removed |Added

Summary|Incorrect __LINE__  |Incorrect __LINE__
   |expansion with  |expansion with
   |-ftrack-macro-expansion=0   |-ftrack-macro-expansion=0
   ||on g++5.2

--- Comment #1 from mail at bobah dot net ---
command line: g++ -ftrack-macro-expansion=0 test.cpp

[Bug target/67439] [4.9 Regression]ICE: unrecognizable insn compiling arm-fp16 testcases with -march=armv7-a and -mrestrict-it

[ktkachov at gcc dot gnu.org]

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

--- Comment #9 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Wed Jan 20 17:05:43 2016
New Revision: 232623

URL: https://gcc.gnu.org/viewcvs?rev=232623=gcc=rev
Log:
[ARM] PR 67439: Allow matching of *arm32_movhf when -mrestrict-it is on

Backport from mainline
2015-09-10  Kyrylo Tkachov  

PR target/67439
* config/arm/arm.md (*arm32_movhf): Remove !arm_restrict_it from
predicate.  Set predicable_short_it attr to "no".

* gcc.target/arm/pr67439_1.c: New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr67439_1.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/arm/arm.md
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=all

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
Hi,

The immediate problem is that

  if (gfc_option.rtcheck & GFC_RTCHECK_MEM
  && gfc_expr_attr (expr1).allocatable
  && expr1->rank
  && !expr2->rank)
{

in gfc_trans_assignment_1 needs to be replaced with:

  if (gfc_option.rtcheck & GFC_RTCHECK_MEM
  && !init_flag
  && gfc_expr_attr (expr1).allocatable
  && expr1->rank
  && !expr2->rank)
{

This fixes this PR. However, looking again at this block, I think that the code
is just not right. I will work on it.

Cheers

Paul

[Bug libstdc++/60401] stdlib.h does not provide abs(long) overload

[vogt at linux dot vnet.ibm.com]

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

--- Comment #6 from Dominik Vogt  ---
The fix seems to be incomplete.  This program still does not compile:

-- snip --
#include 
static long double (*p3c_)(long double) = acosh;
-- snip --

  $ g++ -std=c++11 -S x.C
  x.C:3:43: error: invalid conversion from ‘double (*)(double) throw ()’ to
‘long double (*)(long double)’ [-fpermissive]
   static long double (*p3c_)(long double) = acosh;
 ^
  $ g++ --version
  g++ (GCC) 6.0.0 20160120 (experimental)

[Bug libstdc++/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  ---
> I can confirm that the following change allows current gcc trunk
> to bootstrap on x86_64-apple-darwin15.

I confirm also.

[Bug c++/69116] [4.9/5/6 Regression] compile error when including valarray

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||jason at gcc dot gnu.org
  Component|libstdc++   |c++
  Known to fail|4.8.4   |4.8.1

--- Comment #4 from Jonathan Wakely  ---
The errors started with r196733, the library code didn't change.

namespace std
{
  template
class basic_ostream
{
public:
  basic_ostream&
  operator<<(basic_ostream& (*__pf)(basic_ostream&))
  {
return __pf(*this);
  }
};

  typedef basic_ostream ostream;

  template
inline basic_ostream<_CharT>&
endl(basic_ostream<_CharT>& __os)
{ return __os; }
}

template struct foo {
T f();
void g(T);
};
template void operator<<(const T&, const foo&) {}

struct x : public std::ostream
{
  virtual void flush() = 0;
};

void bar(x& os)
{
  os << std::endl;
}

[Bug target/65096] Illegal memory access beyond packed struct ARCH: ppc64

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
I would say so.  OP may reopen if he can reproduce on 5.2 or later.  Almost
certainly a dup.

[Bug libstdc++/60401] stdlib.h does not provide abs(long) overload

[vogt at linux dot vnet.ibm.com]

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

--- Comment #8 from Dominik Vogt  ---
List of functions the test complains about:

acosh, asinh, atanh, cbrt, copysign, erf, erfc, exp2, expm1, fdim, fma, fmax,
fmin, hypot, ilogb, isinf, isnan, lgamma, llrint, llround, log1p, log2, logb,
lrint, lround, nearbyint, nextafter, nexttoward, remainder, remquo, rint,
round, scalbln, scalbn, tgamma, trunc

[Bug preprocessor/69391] Incorrect __LINE__ expansion with -ftrack-macro-expansion=0 on g++5.2

[mail at bobah dot net]

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

--- Comment #2 from mail at bobah dot net ---
And if I make this change it works even with '-ftrack-macro-expansion=0'

- #define LINE STR(__LINE__) STR(__LINE__)
+ #define LINE() STR(__LINE__) STR(__LINE__)
- std::cout << LINE << "\n";
+ std::cout << LINE() << "\n";

[Bug libstdc++/60401] stdlib.h does not provide abs(long) overload

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
The isnan and isinf errors need a glibc fix, which will be in glibc 2.23, the
rest I have a patch for.

[Bug preprocessor/69391] [5/6 Regression] Incorrect __LINE__ expansion with -ftrack-macro-expansion=0 on g++5.2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |5.4
Summary|Incorrect __LINE__  |[5/6 Regression] Incorrect
   |expansion with  |__LINE__ expansion with
   |-ftrack-macro-expansion=0   |-ftrack-macro-expansion=0
   |on g++5.2   |on g++5.2

[Bug c++/69392] New: G++ can't capture 'this' pointer to templated type using init-capture

[kyle.strand at beckman dot com]

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

Bug ID: 69392
   Summary: G++ can't capture 'this' pointer to templated type
using init-capture
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kyle.strand at beckman dot com
  Target Milestone: ---

Created attachment 37409
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37409=edit
Tarball with source (with comments), preprocessed source, and compiler output

G++ erroneously fails to deduce the type of the `this` pointer inside a
template-class member function when using init-capture to copy `this` into a
lambda.

My GCC version is 5.1.0 on an x86_64 architecture. My OS is Debian 8.

More information, including a comparison to Clang++ and a list of variations
that do or do not work, is available on this StackOverflow question:
http://stackoverflow.com/q/34889310/1858225

[Bug preprocessor/69391] [5/6 Regression] Incorrect __LINE__ expansion with -ftrack-macro-expansion=0 on g++5.2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-20
 CC||jakub at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
This changed behavior with r213102 aka PR61861.
Self-contained testcase:
#define STR_I(X) #X
#define STR(X) STR_I(X)
#define LINE STR(__LINE__) STR(__LINE__)
#define LINE2() STR(__LINE__) STR(__LINE__)

int main()
{
  __builtin_printf ("%s\n", LINE);
  __builtin_printf ("%s\n", LINE2 ());
  return 0;
}

I'm getting the same behavior for function-like macros like other macros
though.

[Bug target/69339] [6 Regression] Failed to bootstrap powerpc-e500v2-linux-gnuspe target: libitm/vect128.cc:1:0: error: AltiVec and SPE instructions cannot coexist

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Henderson  ---
Fixed.

[Bug target/69343] [6 Regression] Bootstrap failure on s390{,x}-linux

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

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

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

[Bug fortran/69396] New: ICE on type mismatch, in update_ppc_arglist, at fortran/resolve.c:5580

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 69396
   Summary: ICE on type mismatch, in update_ppc_arglist, at
fortran/resolve.c:5580
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

$ cat z1.f90
module m1
   type t1
   end type
end

module m2
   use m1
   type t2
  procedure(f), pointer :: f2 => f2a
  procedure(g), pointer :: g2 => g2a
   end type

   abstract interface
  subroutine f (this, x)
 import :: t1, t2
 class(t2) :: this
 type(t1) :: x
  end

  subroutine g (this, x)
 import :: t1, t2
 class(t2) :: this
 type(t1) :: x
  end
   end interface

contains

   subroutine f2a (this, x)
  class(t2) :: this
  type(t2) :: x
  call this%g2 (x)
   end

   subroutine g2a (this, x)
  class(t2) :: this
  type(t1) :: x
   end
end


$ gfortran-6.0.0 -c z1.f90
z1.f90:9:40:

   procedure(f), pointer :: f2 => f2a
1

Error: Interface mismatch in procedure pointer assignment at (1): Type mismatch
in argument 'x' (TYPE(t1)/TYPE(t2))
z1.f90:9:40:

   procedure(f), pointer :: f2 => f2a
1

Error: Interface mismatch in procedure pointer assignment at (1): Type mismatch
in argument 'x' (TYPE(t1)/TYPE(t2))
z1.f90:9:40:

   procedure(f), pointer :: f2 => f2a
1

Error: Interface mismatch in procedure pointer assignment at (1): Type mismatch
in argument 'x' (TYPE(t1)/TYPE(t2))
z1.f90:9:40:

   procedure(f), pointer :: f2 => f2a
1

Error: Interface mismatch for procedure-pointer component ‘f2’ in structure
constructor at (1): Type mismatch in argument 'x' (TYPE(t1)/TYPE(t2))
f951: internal compiler error: in update_ppc_arglist, at fortran/resolve.c:5580

---

$ gfortran-5.3.1 -c z1.f90
...
(null):0: confused by earlier errors, bailing out


$ gfortran-4.9.0 -c z1.f90
...
f951: internal compiler error: in update_ppc_arglist, at fortran/resolve.c:5346

[Bug fortran/69396] ICE on type mismatch, in update_ppc_arglist, at fortran/resolve.c:5580

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
FYI, works with correct type specification :


$ cat z2.f90
module m1
   type t1
   end type
end

module m2
   use m1
   type t2
  procedure(f), pointer :: f2 => f2a
  procedure(g), pointer :: g2 => g2a
   end type

   abstract interface
  subroutine f (this, x)
 import :: t1, t2
 class(t2) :: this
 type(t1) :: x
  end

  subroutine g (this, x)
 import :: t1, t2
 class(t2) :: this
 type(t1) :: x
  end
   end interface

contains

   subroutine f2a (this, x)
  class(t2) :: this
  type(t1) :: x  !!! t1 instead of t2
  call this%g2 (x)
   end

   subroutine g2a (this, x)
  class(t2) :: this
  type(t1) :: x
   end
end

[Bug fortran/69397] New: ICE on missing subprogram in generic interface

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 69397
   Summary: ICE on missing subprogram in generic interface
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

$ cat z1.f90
program p
   interface f
  procedure f1
  !... more
   end interface
   integer, allocatable :: z
   print *, f(z)
contains
   integer function f2 (x)
  integer, allocatable :: x
  f2 = 1
   end
end


$ gfortran-6.0.0 -c z1.f90
z1.f90:3:18:

   procedure f1
  1

Error: Procedure 'f1' in generic interface 'f' at (1) is neither function nor
subroutine
f951: internal compiler error: in gfc_arglist_matches_symbol, at
fortran/interface.c:3509

---

$ gfortran-5.3.1 -c z1.f90
...
(null):0: confused by earlier errors, bailing out


$ gfortran-4.9.0 -c z1.f90
...
f951: internal compiler error: in gfc_arglist_matches_symbol, at
fortran/interface.c:3406

[Bug fortran/69398] ICE on class with duplicate dimension attribute specified

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
Whereas, detected :

$ cat z2.f90
program p
   type t
   end type
   type(t), allocatable :: z(:)
   target :: z(:)
   allocate (z(2))
end


$ gfortran -c z2.f90
z2.f90:5:14:

target :: z(:)
  1

Error: Duplicate DIMENSION attribute specified at (1)

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

[seurer at linux dot vnet.ibm.com]

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

--- Comment #6 from Bill Seurer  ---
As of Tuesday (19 January 2015) morning this test case was no longer failing. 
Something fixed things up in the Friday-Monday timespan though I do not know
what it was.

[Bug target/68609] PowerPC reciprocal estimate missed opportunities

[dje at gcc dot gnu.org]

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

--- Comment #7 from David Edelsohn  ---
Author: dje
Date: Wed Jan 20 19:39:08 2016
New Revision: 232632

URL: https://gcc.gnu.org/viewcvs?rev=232632=gcc=rev
Log:
PR target/68609
* config/rs6000/rs6000.c (rs6000_emit_swsqrt): Add vector sqrt
domain check.
* config/rs6000/vector.md (sqrt2): Call rs6000_emit_swsqrt
for V4SFmode.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/vector.md

[Bug fortran/69395] New: ICE on declaring array with more than 7 dimensions+codimensions

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 69395
   Summary: ICE on declaring array with more than 7
dimensions+codimensions
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

These variants with sum of dimensions and codimensions
greater than 7 (actual limit) :


$ cat z1.f90
program p
   real, dimension(2,2,2,2), codimension[2,2,2,*] :: z4a
   real, dimension(2,2,2,2) :: z4b[2,2,2,*]
   real, codimension[2,2,2,*] :: z4c(2,2,2,2)
   real :: z4x
   dimension :: z4x(2,2,2,2)
   codimension :: z4x[2,2,2,*]
end


$ cat z3.f90
program p
   real, dimension(2), codimension[2,2,2,2,2,2,*] :: z1a
   real, dimension(2,2), codimension[2,2,2,2,2,*] :: z2a
   real, dimension(2,2,2), codimension[2,2,2,2,*] :: z3a
   real, dimension(2,2,2,2), codimension[2,2,2,*] :: z4a
   real, dimension(2,2,2,2,2), codimension[2,2,*] :: z5a
   real, dimension(2,2,2,2,2,2), codimension[2,*] :: z6a
   real, dimension(2,2,2,2,2,2,2), codimension[*] :: z7a
   !...
end


yield (with 5.3.1 and 6.0.0) :

$ gfortran -fcoarray=single z1.f90
f951: internal compiler error: free_expr0(): Bad expr type

[Bug fortran/69395] ICE on declaring array with more than 7 dimensions+codimensions

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
Whereas, detected with this declaration variant :

$ cat z2.f90
program p
   real :: z4d(2,2,2,2)[2,2,2,*]
end


$ gfortran -fcoarray=single z2.f90
z2.f90:2:30:

real :: z4d(2,2,2,2)[2,2,2,*]
  1

Error: Array specification at (1) has more than 7 dimensions

[Bug fortran/69398] ICE on class with duplicate dimension attribute specified

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #2 from Gerhard Steinmetz  
---
BTW :

$ cat z1c.f90
program p
   type t
   end type
   class(t), allocatable :: z(:)
   target :: z(2)
   allocate (z(2))
end


$ gfortran-5.3.1 -c z1c.f90
z1c.f90:1:0:

 program p
 1
internal compiler error: in gfc_build_null_descriptor, at
fortran/trans-array.c:432

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

[seurer at linux dot vnet.ibm.com]

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

--- Comment #7 from Bill Seurer  ---
I should say that it succeeds on power8 LE.  I haven't tried it on a BE system
nor targeting power7.

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

[meissner at gcc dot gnu.org]

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

--- Comment #8 from Michael Meissner  ---
I did try it with svn id 232575 yesterday on a power7 BE target, using various
optimization levels and various -mcpu=/-mtune= combinations.

[Bug fortran/69397] ICE on missing subprogram in generic interface

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #1 from Jerry DeLisle  ---
We have a gcc_assert in there so we should probably turn it into an error or
bail out instead of give an ICE.

I will take it.

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

[meissner at gcc dot gnu.org]

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

--- Comment #9 from Michael Meissner  ---
Whoops, I saved the response too soon.  I meant I tried various combinations of
optimization, -mcpu=, -mtune=, -mbig/-mlittle, -m32 and I couldn't get it to
fail with subversion id 232575.

[Bug target/69269] [6 Regression] ICE on ibm-ldouble.c in extract_constrain_insn_cached, at recog.c:2201

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
The ICE seems to have been resolved.

[Bug fortran/69398] New: ICE on class with duplicate dimension attribute specified

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 69398
   Summary: ICE on class with duplicate dimension attribute
specified
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With duplicate dimension attribute specified :

$ cat z1.f90
program p
   type t
   end type
   class(t), allocatable :: z(:)
   target :: z(:)
   allocate (z(2))
end


$ gfortran-5.3.1 -c z1.f90
z1.f90:1:0:

 program p
 1
internal compiler error: in gfc_is_nodesc_array, at fortran/trans-types.c:1309


$ gfortran-6.0.0 -c z1.f90
...
internal compiler error: in gfc_conv_component_ref, at
fortran/trans-expr.c:2295


$ gfortran-4.9.0 -c z1.f90
...
z1.f90:1:0: internal compiler error: in gfc_is_nodesc_array, at
fortran/trans-types.c:1291

[Bug ipa/68273] [5/6 Regression] Wrong code on mips/mipsel with -fipa-sra

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #2 from Jeffrey A. Law  ---
My current theory is ipa-sra is increasing the alignment of an object during
its transformations.  As a result, the mechanisms to determine which registers
to use for argument passing believe the 2nd arg must be in an aligned register
pair.

[Bug tree-optimization/69399] New: [5/6 Regression] wrong code with -O and int128 (due to ccp?)

[zsojka at seznam dot cz]

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

Bug ID: 69399
   Summary: [5/6 Regression] wrong code with -O and int128 (due to
ccp?)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-*-gnux32, aarch64-*, powerpc64-*, sparc64-*

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

Compiler output:
$ x86_64-pc-linux-gnux32-gcc -O testcase.c
$ ./a.out 
Aborted

$ x86_64-pc-linux-gnux32-gcc -O testcase.c -fno-tree-ccp
$ ./a.out 

$ x86_64-pc-linux-gnux32-gcc -v   
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-x32/bin/x86_64-pc-linux-gnux32-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-232548-checking-yes-rtl-df-nographite-x32/bin/../libexec/gcc/x86_64-pc-linux-gnux32/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnux32
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--with-abi=mx32 --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnux32 --with-ld=/usr/bin/x86_64-pc-linux-gnux32-ld
--with-as=/usr/bin/x86_64-pc-linux-gnux32-as
--with-sysroot=/usr/x86_64-pc-linux-gnux32 --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-232548-checking-yes-rtl-df-nographite-x32
Thread model: posix
gcc version 6.0.0 20160119 (experimental) (GCC) 

The first broken dump seems to be .ccp1:

__attribute__((noclone, noinline))
foo (u64D.1749 uD.1751)
{
  u64D.1749 u_1(D) = uD.1751;
  u128D.1750 vD.1754;
  long long unsigned intD.14 _2;

;;   basic block 2, loop depth 0, count 0, freq 0, maybe hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE)
;;pred:   ENTRY (FALLTHRU,EXECUTABLE)
  _2 = u_1(D) | 4294967169;
  v_3 = (u128D.1750) _2;
  # VUSE <.MEM_6(D)>
  return 4294967169;
;;succ:   EXIT

}


Tested revisions:
trunk r232548 - FAIL (native x86_64-pc-linux-gnu has PASS here)
5-branch r232545 - FAIL
4_[6789]-branch - OK

[Bug jit/64296] link failure of libgccjit.so for "in tree" gmp/mpc/mpfr/isl

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
See also bug 67137 for a possible duplicate.

[Bug target/34087] ICE in regrename.c for movdf_hardfloat64_mfpgpr

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

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

--- Comment #5 from Pat Haugen  ---
Closing since it is working and hasn't reared it's head in many years...

[Bug target/47122] vax-*-openbsd* configuration purports to require openbsd-pthread.h

[rep.dot.nop at gmail dot com]

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

--- Comment #4 from rep.dot.nop at gmail dot com  
---
On January 18, 2016 3:57:22 PM GMT+01:00, "bernds at gcc dot gnu.org"
 wrote:

>Can this be closed?

Sorry, yes, i think so.

[Bug tree-optimization/69400] New: [5/6 Regression] wrong code with -O and int128

[zsojka at seznam dot cz]

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

Bug ID: 69400
   Summary: [5/6 Regression] wrong code with -O and int128
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-*, aarch64-*, powerpc64-*, sparc64-*

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

This PR shows the problem might be more common than just ccp (PR69399).

Output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c
$ ./a.out 
Aborted

First broken dump is .ccp1:
...
Folding statement: return _3;
Folded into: return 0xfffe;
...
Thus:
$ x86_64-pc-linux-gnu-gcc -O testcase.c -fno-tree-ccp
$ ./a.out 
Aborted

First broken dump is .forwprop1:
...
gimple_simplified to u_2 = 0xfffe;
gimple_simplified to _3 = 0xfffe;
...
Thus:
$ x86_64-pc-linux-gnu-gcc -O testcase.c -fno-tree-ccp -fno-tree-forwprop
$ ./a.out 
Aborted

First broken dump is .fre1:
...
Replaced u_1 % 18446744073709551615 with 0xfffe in
all uses of u_2 = u_1 % 18446744073709551615;
...
Thus:
$ x86_64-pc-linux-gnu-gcc -O testcase.c -fno-tree-ccp -fno-tree-forwprop
-fno-tree-fre
$ ./a.out 
Aborted

I stopped there.


$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-232548-checking-yes-rtl-df-nographite/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-232548-checking-yes-rtl-df-nographite
Thread model: posix
gcc version 6.0.0 20160119 (experimental) (GCC) 



Tested revisions:
trunk r232548 - FAIL
5-branch r232545 - FAIL
4_[6789]-branch - OK

[Bug bootstrap/67137] --enable-languages=jit and --disable-shared

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
See also bug 64296 for a report of what seems like the same problem and a
suggested workaround.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[sje at gcc dot gnu.org]

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

--- Comment #20 from Steve Ellcey  ---
I have still not been able to reproduce this or understand what is happening.

Aurelien, could you try applying the patch that has been submitted for PR 69129
to see if that helps?  The failure modes for this bug and 69129 don't look the
same but I think both may be related to uninitialized memory usage and I can't
reproduce either one so I am hoping maybe they have the same root cause.

Patch for PR 69129:

https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01407.html

[Bug fortran/69397] ICE on missing subprogram in generic interface

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-01-20
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Related to/duplicate of pr68442.

> We have a gcc_assert in there so we should probably turn it into an error
> or bail out instead of give an ICE.
>
> I will take it.

I have the following patch in my working tree:

--- ../_clean/gcc/fortran/interface.c   2016-01-04 19:51:09.0 +0100
+++ gcc/fortran/interface.c 2016-01-15 22:14:17.0 +0100
@@ -3506,7 +3506,9 @@ gfc_arglist_matches_symbol (gfc_actual_a
   gfc_formal_arglist *dummy_args;
   bool r;

-  gcc_assert (sym->attr.flavor == FL_PROCEDURE);
+  /* gcc_assert (sym->attr.flavor == FL_PROCEDURE); */
+  if (sym->attr.flavor != FL_PROCEDURE)
+return false;

   dummy_args = gfc_sym_get_dummy_args (sym);

With it the iCE is replaced with the error

pr69397.f90:7:11:

print *, f(z)
   1

Error: There is no specific function for the generic 'f' at (1)

[Bug debug/67355] [5 Regression] ICE compiling LTP testcase, endless cselib recursion from var-tracking

[aurelien at aurel32 dot net]

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

Aurelien Jarno  changed:

   What|Removed |Added

 CC||aurelien at aurel32 dot net

--- Comment #12 from Aurelien Jarno  ---
*** Bug 68302 has been marked as a duplicate of this bug. ***

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #21 from Aurelien Jarno  ---
(In reply to Steve Ellcey from comment #20)
> I have still not been able to reproduce this or understand what is happening.
> 
> Aurelien, could you try applying the patch that has been submitted for PR
> 69129
> to see if that helps?  The failure modes for this bug and 69129 don't look
> the same but I think both may be related to uninitialized memory usage and I
> can't reproduce either one so I am hoping maybe they have the same root
> cause.
> 
> Patch for PR 69129:
> 
> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01407.html

It happens I am not able to reproduce the problem given the problem has been
fixed in the meantime. It is actually the same bug than PR67355.

Sorry for not noticing that earlier, and thanks for your help debugging this
issue.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

Aurelien Jarno  changed:

   What|Removed |Added

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

--- Comment #22 from Aurelien Jarno  ---
This bug is a duplicate of PR67355

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

[Bug preprocessor/69391] New: Incorrect __LINE__ expansion with -ftrack-macro-expansion=0

[mail at bobah dot net]

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

Bug ID: 69391
   Summary: Incorrect __LINE__ expansion with
-ftrack-macro-expansion=0
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mail at bobah dot net
  Target Milestone: ---

The below test program
- incorrectly prints "83" on g++ 5.2 with '-ftrack-macro-expansion=0'
- correctly prints "88" on g++ 5.2 with '-ftrack-macro-expansion=1'
- correctly prints "88" on g++ 4.9 regardless of '-ftrack-macro-expansion' flag

#define STR_I(X) #X
#define STR(X) STR_I(X)
#define LINE STR(__LINE__) STR(__LINE__)

#include 
int main()
{
std::cout << LINE << "\n";
return 0;
}

[Bug c++/69355] [5/6 Regression] Wrong results with -O1 optimization

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #16 from Jeffrey A. Law  ---
FWIW, I'm tracking an independent SRA issue that I might send Martin's way as
well.  I'm still trying to wrap my head around it and I've got a nice small
little testcase now to help with that... But if I get stuck, I'll be looking
for Martin's help :-)

[Bug ipa/68273] [5/6 Regression] Wrong code on mips/mipsel with -fipa-sra

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law  ---
Created attachment 37414
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37414=edit
Reduced testcase

Reduced testcase.  Compile with a mipsel-linux-gnu cross compiler with -O2.

It's easiest to see the problem looking at the .expand dump:

;; _17 = enter (_14, prephitmp_23);

(insn 81 80 82 (set (reg/f:SI 262)
(symbol_ref:SI ("sp")  )) j.c:58 -1
 (nil))

(insn 82 81 83 (set (reg/f:SI 261)
(mem/f/c:SI (reg/f:SI 262) [10 sp+0 S4 A32])) j.c:58 -1
 (nil))

(insn 83 82 84 (set (reg:SI 263)
(mem/f:SI (reg/f:SI 261) [12 sp.0_13->table+0 S4 A32])) j.c:58 -1
 (nil))

(insn 84 83 85 (set (reg:SI 6 $6)
(reg/f:SI 255 [ prephitmp_23 ])) j.c:58 -1
 (nil))

(insn 85 84 86 (set (reg:SI 4 $4)
(reg:SI 263)) j.c:58 -1
 (nil))

(call_insn 86 85 87 (parallel [
(set (reg:SI 2 $2)
(call (mem:SI (symbol_ref:SI ("enter") [flags 0x41] 
) [0 enter S4 A32])
(const_int 16 [0x10])))
(clobber (reg:SI 31 $31))
]) j.c:58 -1
 (expr_list:REG_CALL_DECL (symbol_ref:SI ("enter") [flags 0x41] 
)
(nil))
(expr_list (use (reg:SI 79 $fakec))
(expr_list:SI (use (reg:SI 4 $4))
(expr_list:SI (use (reg:SI 6 $6))
(nil)


Note carefully the 2nd argument to the enter call is loaded into $6.  It should
have been loaded into $5.  AFAICT, SRA is mucking around with the alignment of
the object, which in turn causes the MIPS backend to want to pass the object in
an aligned register pair.

[Bug ipa/68273] [5/6 Regression] Wrong code on mips/mipsel with -fipa-sra

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-20
 Ever confirmed|0   |1

[Bug fortran/69396] ICE on type mismatch, in update_ppc_arglist, at fortran/resolve.c:5580

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-20
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk.

[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
In fact I have hit the same ICE with a slightly different test case:


program test

  implicit none

  type :: t
real, allocatable :: r(:)
  end type

  type(t) :: a

  a%r = 0.

end

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[rogero at howzatt dot demon.co.uk]

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

--- Comment #14 from Roger Orr  ---
I don't know I'm afraid: I'm a very occasional mingw user and I haven't
(yet...) tried building gcc on mingw...

[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
Summary|[6 regression] ICE on valid |[6 regression] ICE on valid
   |with -fcheck=all|with -fcheck=mem

--- Comment #4 from janus at gcc dot gnu.org ---
The test case can be further condensed into:

module utilities
  implicit none

  type :: string
character(len=:), allocatable :: s
  end type

contains

  function getCmdLine()
type(string),dimension(:),allocatable :: getCmdLine
allocate(getCmdLine(command_argument_count()))
  end function

end module


In particular the offending check (out of the range of stuff done with
-fcheck=all) is -fcheck=mem.


With a current trunk build the backtrace is:

internal compiler error: in wide_int_to_tree, at tree.c:1488
0xc757a3 wide_int_to_tree(tree_node*,
generic_wide_int const&)
/home/janus/gcc/trunk/gcc/tree.c:1488
0xc75899 build_int_cst(tree_node*, long)
/home/janus/gcc/trunk/gcc/tree.c:1296
0x6bf425 gfc_trans_assignment_1
/home/janus/gcc/trunk/gcc/fortran/trans-expr.c:9305
0x687ce5 trans_code
/home/janus/gcc/trunk/gcc/fortran/trans.c:1704
0x6abeec gfc_generate_function_code(gfc_namespace*)
/home/janus/gcc/trunk/gcc/fortran/trans-decl.c:6107
0x68b449 gfc_generate_module_code(gfc_namespace*)
/home/janus/gcc/trunk/gcc/fortran/trans.c:2058
0x642ccd translate_all_program_units
/home/janus/gcc/trunk/gcc/fortran/parse.c:5599
0x642ccd gfc_parse_file()
/home/janus/gcc/trunk/gcc/fortran/parse.c:5818
0x684f32 gfc_be_parse_file
/home/janus/gcc/trunk/gcc/fortran/f95-lang.c:201

[Bug fortran/69398] ICE on class with duplicate dimension attribute specified

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-20
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0). Note that the ICEs for the tests in
comment 0 and 2 are

internal compiler error: in gfc_conv_component_ref, at
fortran/trans-expr.c:2295

with trunk.