[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

--- Comment #39 from Manuel López-Ibáñez  ---
A summary of what is still pending:

1. Handle macros

#define c   " %d "
  __builtin_printf(c, 0.5);

2. Handle non-contiguous strings:

  __builtin_printf(" %" "d ", 0.5);

3. Handle const arrays:

  const char a[] = " %d ";
  __builtin_printf(a, 0.5);


I have an idea on how to fix 1 and 2 but no idea how to fix 3.

[Bug sanitizer/61955] libsanitizer fails to compile on RHEL4

[ossman at cendio dot se]

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

Pierre Ossman  changed:

   What|Removed |Added

 CC||ossman at cendio dot se

--- Comment #4 from Pierre Ossman  ---
Unfortunately the git history doesn't go further back than 2.6.12 so I don't
know when aio_abi.h got added. But the code only needs the enum, so something
like this should work:

#include 
/* aio_abi.h was added in 2.6.10 (FIXME: check this) */
#if LINUX_VERSION_CODE < 132624
enum {
IOCB_CMD_PREAD = 0,
IOCB_CMD_PWRITE = 1,
IOCB_CMD_FSYNC = 2,
IOCB_CMD_FDSYNC = 3,
IOCB_CMD_NOOP = 6,
};
#else
#include_next 
#endif
/* IOCB_CMD_PREADV/PWRITEV has been added in 2.6.19 */
#if LINUX_VERSION_CODE < 132627
#define IOCB_CMD_PREADV 7
#define IOCB_CMD_PWRITEV 8
#endif

[Bug sanitizer/61955] libsanitizer fails to compile on RHEL4

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

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

--- Comment #5 from Andreas Schwab  ---
 was added in 2.5.32.

https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/?id=ea5097be4e814a2a9457e60653052306295941e8

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener  ---
(In reply to Douglas Mencken from comment #20)
> I'm lost. “Vanilla” 5.1.0 configured without --disable-checking went thru
> stage2 w/o any issue...

That's interesting - we might run into a miscompilation here.  Can you
check with --disable-checking again but with just the gcc_checking_assert
in hash_table_mod1 removed?

Please also attach preprocessed source of genmatch.c for the stage2 build
so it's possible to investigate that with a cross compiler.  (preprocessed
source with --disable-checking and the assert left in place)

Btw, thanks for your help in tracking this down.

I wonder if anybody tried a powerpc-linux bootstrap with --disable-checking...

[Bug c++/66211] [5/6 Regression] Rvalue conversion in ternary operator causes internal compiler error

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Wed, 20 May 2015, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66211
> 
> --- Comment #5 from Jakub Jelinek  ---
> Perhaps just guard this particular match.pd pattern with GIMPLE guard for now
> (until the delayed C++ folding is committed)?

Will try.

[Bug sanitizer/61955] libsanitizer fails to compile on RHEL4

[dvyukov at google dot com]

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

Dmitry Vyukov  changed:

   What|Removed |Added

 CC||dvyukov at google dot com

--- Comment #6 from Dmitry Vyukov  ---
How does LINUX_VERSION_CODE relate to linux kernel version? What is the
LINUX_VERSION_CODE value for 2.5.32? Is the other LINUX_VERSION_CODE value
(132627) correct?

[Bug sanitizer/61955] libsanitizer fails to compile on RHEL4

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

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

--- Comment #7 from Andreas Schwab  ---
Format it as a hexadecimal number.

[Bug target/66215] [4.8/4.9/5/6 Regression] Wrong after label NOP emission for -mhotpatch

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
No, IMHO you can have many debug insns after that and before first real insn.
I'd go for something like:
  rtx_insn *insn = get_insns ();
  if (!active_insn_p (insn))
insn = next_active_insn (insn);
and insert before, rather than after (otherwise you don't handle the
hypothetical case of an active insn being the first one).
That would require rewriting the nop insertion code after it, because you want
to insert the 6 byte nops first.  Or just gcc_assert the first insn is not
active, or if the first insn is active, emit a NOTE_INSN_DELETED note before
that
first active insn, emit the nops after that note and perhaps kill the note at
the end.
Please test
void foo (void) { __builtin_unreachable (); }
actually generates any active insns.

[Bug sanitizer/61955] libsanitizer fails to compile on RHEL4

[dvyukov at google dot com]

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

--- Comment #8 from Dmitry Vyukov  ---
Kostya, Alexey, Eugeniy, please land this fix to llvm tree while I am OOO.

[Bug sanitizer/61955] libsanitizer fails to compile on RHEL4

[ossman at cendio dot se]

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

--- Comment #9 from Pierre Ossman  ---
(In reply to Andreas Schwab from comment #5)
>  was added in 2.5.32.
> 
> https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/
> ?id=ea5097be4e814a2a9457e60653052306295941e8

How can it be missing on RHEL 4 with 2.6.9 in that case?

[Bug rtl-optimization/66207] Switch alpha to LRA

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
Native bootstrap with alphaev68-linux-gnu (a BWX architecture) with the patch
from Comment #1 succeeded, the testresults are at [1]. Comparing to non-LRA
testsuite run, here is only one new test failure in the entire testsuite:

FAIL: gcc.c-torture/execute/pr42691.c   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gcc.c-torture/execute/pr42691.c   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (test for excess errors)
UNRESOLVED: gcc.c-torture/execute/pr42691.c   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gcc.c-torture/execute/pr42691.c   -O3 -fomit-frame-pointer -funroll-loops
 (internal compiler error)
FAIL: gcc.c-torture/execute/pr42691.c   -O3 -fomit-frame-pointer -funroll-loops
 (test for excess errors)
UNRESOLVED: gcc.c-torture/execute/pr42691.c   -O3 -fomit-frame-pointer
-funroll-loops  compilation failed to produce executable

Executing on host: /space/uros/gcc-build/gcc/xgcc -B/space/uros/gcc-build/gcc/
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gcc.c-torture/execute/pr42691.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never-O3
-fomit-frame-pointer -funroll-loops  -w  -lm-o ./pr42691.exe(timeout =
300)
spawn /space/uros/gcc-build/gcc/xgcc -B/space/uros/gcc-build/gcc/
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gcc.c-torture/execute/pr42691.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -fomit-frame-pointer
-funroll-loops -w -lm -o ./pr42691.exe^M
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gcc.c-torture/execute/pr42691.c:
In function 'add':^M
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gcc.c-torture/execute/pr42691.c:32:1:
error: unrecognizable insn:^M
(insn 87 86 29 5 (set (subreg:DI (reg:V4HI 90) 0)^M
(reg:V4HI 94))
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gcc.c-torture/execute/pr42691.c:19
-1^M
 (expr_list:REG_DEAD (reg:V4HI 94)^M
(nil)))^M
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gcc.c-torture/execute/pr42691.c:32:1:
internal compiler error: in extract_insn, at recog.c:2341^M
0x1207809c7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)^M
../../gcc-svn/trunk/gcc/rtl-error.c:110^M
0x120780a17 _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)^M
../../gcc-svn/trunk/gcc/rtl-error.c:118^M
0x120747bcf extract_insn(rtx_insn*)^M
../../gcc-svn/trunk/gcc/recog.c:2341^M
0x120b99d5f union_match_dups^M
../../gcc-svn/trunk/gcc/web.c:118^M
0x120b99d5f execute^M
../../gcc-svn/trunk/gcc/web.c:395^M


[1] https://gcc.gnu.org/ml/gcc-testresults/2015-05/msg02573.html

[Bug tree-optimization/66233] [4.8/4.9/5/6 Regression] internal compiler error: in expand_fix, at optabs.c:5358

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-21
 CC||jakub at gcc dot gnu.org
  Component|c   |tree-optimization
   Target Milestone|--- |4.8.5
Summary|internal compiler error: in |[4.8/4.9/5/6 Regression]
   |expand_fix, at  |internal compiler error: in
   |optabs.c:5358   |expand_fix, at
   ||optabs.c:5358
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r193246, don't see anything invalid on that testcase.

[Bug middle-end/66221] [CHKP, 6 regression] lto1: error: type variant has different TYPE_ARG_TYPES

[ienkovich at gcc dot gnu.org]

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

--- Comment #1 from Ilya Enkovich  ---
Author: ienkovich
Date: Thu May 21 08:32:52 2015
New Revision: 223471

URL: https://gcc.gnu.org/viewcvs?rev=223471&root=gcc&view=rev
Log:
gcc/

PR middle-end/66221
* ipa-chkp.c (chkp_copy_function_type_adding_bounds): Use
build_distinct_type_copy to copy bounds.

gcc/testsuite/

PR middle-end/66221
* gcc.dg/lto/pr66221_0.c: New test.
* gcc.dg/lto/pr66221_1.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/lto/pr66221_0.c
trunk/gcc/testsuite/gcc.dg/lto/pr66221_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-chkp.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/61955] libsanitizer fails to compile on RHEL4

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

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

--- Comment #10 from Andreas Schwab  ---
Are you sure their user-space kernel headers are at 2.6.9 level?

https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/?id=31a3791056e43c6dd7386b8bc0f5fb94848c5a61
https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/tree/include/linux?id=31a3791056e43c6dd7386b8bc0f5fb94848c5a61

[Bug tree-optimization/66233] [4.8/4.9/5/6 Regression] internal compiler error: in expand_fix, at optabs.c:5358

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Sounds like gimple folding issue.
We have:
vect__4.9_31 = (vector(4) float) { 0, 1, 2, 3 };
vect__5.10_32 = (vector(4) unsigned int) vect__4.9_31;
where the first stmt's rhs_code is FLOAT_EXPR and rhs1 is VECTOR_CST vector(4)
int, and the second stmt's rhs_code is FIX_TRUNC_EXPR.
So, for this combined together we should use VIEW_CONVERT_EXPR, but we use
FIX_TRUNC_EXPR.

[Bug rtl-optimization/66207] Switch alpha to LRA

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #4)
> Native bootstrap with alphaev68-linux-gnu (a BWX architecture) with the
> patch from Comment #1 succeeded, the testresults are at [1]. Comparing to
> non-LRA testsuite run, here is only one new test failure in the entire
> testsuite:

No, this failure is not RA related.

[Bug c++/66234] New: Too much output from pragma message with g++ 4.8 and above

[simon at newtec dot dk]

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

Bug ID: 66234
   Summary: Too much output from pragma message with g++ 4.8 and
above
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at newtec dot dk
  Target Milestone: ---

Created attachment 35584
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35584&action=edit
Quick test, just compile with g++ 

I'm using pragma message to output a couple of messages during compilation, but
after a toolchain upgrade (from OSELAS-2012 to 2014, and thus from gcc-4.7.2 to
gcc-4.9.2 - but I've also recreated this on my host with gcc-4.6.4 which is
working fine, and gcc-4.8.3 which exhibits the problem), a lot of extra output
is shown.

A quick test is attached.

Compiling with 4.7.2 / 4.6.4 gives the file location and:

note: #pragma message: Setting builddate to: ("May 21 2015" " " "10:33:13")

 - which is just what I want.

Compiling with 4.9.2 / 4.8.3 gives (file locations removed):

note: #pragma message: Setting builddate to: ("May 21 2015" " " "10:34:51")
 #pragma message "Setting builddate to: " STR(BUILDTAG)
 ^
note: in definition of macro 'STR_HELPER'
 #define STR_HELPER(x) #x
^
note: in expansion of macro 'STR'
 #pragma message "Setting builddate to: " STR(BUILDTAG)
  ^
The output that I want is still there, but together with a lot of extra
clutter.

I can hide the extra output with -ftrack-macro-expansion=0 and
-fno-diagnostics-show-caret, but I suspect that that may also in some cases
hide compilation messages that I *do* want to see.

As I see it, pragma message should (by default) just output the desired message
and nothing else - or is it just that I'm using it the wrong way?

A related post on stackoverflow can be found here:
http://stackoverflow.com/questions/30255294/how-to-hide-extra-output-from-pragma-message

[Bug target/66235] New: [SH] Optimize tst reg,const movrt sequence

[olegendo at gcc dot gnu.org]

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

Bug ID: 66235
   Summary: [SH] Optimize tst reg,const movrt sequence
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

The following example:

bool test_00 (unsigned int x)
{
  return (x & 0x1042A) != 0;
}

compiled with -O2 -m4:

mov.l   .L3,r1
tst r1,r4
mov #-1,r1
rts
negcr1,r0
.L4:
.align 2
.L3:
.long   0x1042A

On non-SH2A there is no movrt insn and a !T -> reg move is done via negc.  If
the preceeding tst insn uses a constant, the constant can be complemented to
avoid the negc and #-1 constant load:

mov.l   .L3,r1
tst r1,r4
rts
movtr0
.L4:
.align 2
.L3:
.long   0xFFFEFBD5

The tstsi_t splitter could be extended to look for a following movrt insn and
optimize it accordingly.

The downside of doing this is an increased constant pool size, if the original
(non-complemented) constant is used for something else.  Moreover, it is only
beneficial to do this if there are no other negc #-1 movrt insns which share
the #-1 constant.  On the other hand, sharing the #-1 constant increases the
life time of regs and thus increases reg pressure.

[Bug sanitizer/61955] libsanitizer fails to compile on RHEL4

[ossman at cendio dot se]

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

--- Comment #11 from Pierre Ossman  ---
Not really. :)

I stumbled upon this trying to use 2.4 headers, so I honestly haven't tried
2.6.9, RHEL variant or otherwise.

[Bug lto/66228] Compiling simple program with -flto -O1 causes mad behaviour

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-21
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.8.4, 4.9.2

--- Comment #1 from Richard Biener  ---
I think this is an effective duplicate of PR61886.  With GCC 5 I get

rguenther@murzim:/tmp> gcc-5 t.i -O -flto 
/usr/include/bits/error.h: In function ‘error’:
/usr/include/bits/error.h:37:1: error: inlining failed in call to always_inline
‘error’: recursive inlining
 error (int __status, int __errnum, const char *__format, ...)
 ^
/usr/include/bits/error.h:40:5: error: called from here
 __error_noreturn (__status, __errnum, __format, __va_arg_pack ());
 ^
/usr/include/bits/error.h:37:1: error: inlining failed in call to always_inline
‘error’: recursive inlining
 error (int __status, int __errnum, const char *__format, ...)
 ^
/usr/include/bits/error.h:40:5: error: called from here
 __error_noreturn (__status, __errnum, __format, __va_arg_pack ());
 ^
...

I can reproduce the odd code generation with GCC 4.9 and 4.8.  I suspect
the issue is related to the above.

[Bug middle-end/66221] [CHKP, 6 regression] lto1: error: type variant has different TYPE_ARG_TYPES

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c/66219] The gcc generated section start/stop pointers become undefined when option -flto is used

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Well, likely flags[] is optimized away.  If you need the symbol to prevail (for
whatever reason?) you need to add __attribute__((used)) to it.

[Bug tree-optimization/66233] [4.8/4.9/5/6 Regression] internal compiler error: in expand_fix, at optabs.c:5358

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Seems this is the
/* Handle cases of two conversions in a row.  */
patterns in match.pd that are causing this.
I'd say the bug is that those simplifications are just handling
{inside,inter,final}_vec the same, no matter if it is vectors of float, ints,
unsigned ints etc.
Supposedly before match.pd has been added the bug was elsewhere, but similarly
didn't take care precisely what kind of vectors it is optimizing.
FLOAT_EXPR is used for conversion of vector {int,unsigned} to vector float,
FIX_TRUNC_EXPR fpr vector float to vector {int,unsigned} and convert
(NOP_EXPR/VIEW_CONVERT_EXPR?) for other conversions.

[Bug target/66215] [4.8/4.9/5/6 Regression] Wrong after label NOP emission for -mhotpatch

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.5

[Bug tree-optimization/66233] [4.8/4.9/5/6 Regression] internal compiler error: in expand_fix, at optabs.c:5358

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Indeed, in 4.9 this is in tree-ssa-forwprop.c (combine_conversions) and in
fold-const.c (fold_unary_loc).
Perhaps we need {inter,inside,final}_vec_{int,float,unsignedp} variables too
and use them?

[Bug rtl-optimization/66236] New: [6 Regression] FAIL: gcc.c-torture/execute/pr42691.c on alpha-linux-gnu

[ubizjak at gmail dot com]

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

Bug ID: 66236
   Summary: [6 Regression] FAIL: gcc.c-torture/execute/pr42691.c
on alpha-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---
Target: alpha-linux-gnu

FAIL: gcc.c-torture/execute/pr42691.c   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gcc.c-torture/execute/pr42691.c   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (test for excess errors)
UNRESOLVED: gcc.c-torture/execute/pr42691.c   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gcc.c-torture/execute/pr42691.c   -O3 -fomit-frame-pointer -funroll-loops
 (internal compiler error)
FAIL: gcc.c-torture/execute/pr42691.c   -O3 -fomit-frame-pointer -funroll-loops
 (test for excess errors)
UNRESOLVED: gcc.c-torture/execute/pr42691.c   -O3 -fomit-frame-pointer
-funroll-loops  compilation failed to produce executable

Executing on host: /space/uros/gcc-build/gcc/xgcc -B/space/uros/gcc-build/gcc/
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gcc.c-torture/execute/pr42691.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never-O3
-fomit-frame-pointer -funroll-loops  -w  -lm-o ./pr42691.exe(timeout =
300)
spawn /space/uros/gcc-build/gcc/xgcc -B/space/uros/gcc-build/gcc/
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gcc.c-torture/execute/pr42691.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -fomit-frame-pointer
-funroll-loops -w -lm -o ./pr42691.exe^M
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gcc.c-torture/execute/pr42691.c:
In function 'add':^M
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gcc.c-torture/execute/pr42691.c:32:1:
error: unrecognizable insn:^M
(insn 87 86 29 5 (set (subreg:DI (reg:V4HI 90) 0)^M
(reg:V4HI 94))
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gcc.c-torture/execute/pr42691.c:19
-1^M
 (expr_list:REG_DEAD (reg:V4HI 94)^M
(nil)))^M
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gcc.c-torture/execute/pr42691.c:32:1:
internal compiler error: in extract_insn, at recog.c:2341^M
0x1207809c7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)^M
../../gcc-svn/trunk/gcc/rtl-error.c:110^M
0x120780a17 _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)^M
../../gcc-svn/trunk/gcc/rtl-error.c:118^M
0x120747bcf extract_insn(rtx_insn*)^M
../../gcc-svn/trunk/gcc/recog.c:2341^M
0x120b99d5f union_match_dups^M
../../gcc-svn/trunk/gcc/web.c:118^M
0x120b99d5f execute^M
../../gcc-svn/trunk/gcc/web.c:395^M

[Bug c++/66223] Diagnostic of pure virtual function call broken, including __cxa_pure_virtual

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #1 from Jonathan Wakely  ---
I still get the same output for 5.1:

pure virtual method called
terminate called without an active exception
Aborted (core dumped)

How did you configure GCC? (Please provide the output of 'gcc -v`' as requested
in the bug reporting instructions)

[Bug target/64208] [4.9 Regression][iwmmxt] ICE: internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|4.9.3   |6.0

--- Comment #6 from Ramana Radhakrishnan  ---
Fixed on trunk.

[Bug libgcc/58660] ARM/Thumb non-interworking code broken in libgcc

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

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

[Bug target/26702] .size is not emitted for BSS variables

[ramana at gcc dot gnu.org]

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

--- Comment #13 from Ramana Radhakrishnan  ---
Author: ramana
Date: Thu May 21 09:23:14 2015
New Revision: 223473

URL: https://gcc.gnu.org/viewcvs?rev=223473&root=gcc&view=rev
Log:
Fix PR target/26702

For Kwok Cheung Yeung.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/pr26702.c

[Bug rtl-optimization/66237] New: [6.0 regression] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE (internal compiler error)

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

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

Bug ID: 66237
   Summary: [6.0 regression] FAIL: gcc.dg/tree-prof/pr34999.c
compilation,  -fprofile-use -D_PROFILE_USE (internal
compiler error)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: miyuki at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*-*

$ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.dg/tree-prof/pr34999.c -O2
-freorder-blocks-and-partition -fprofile-generate -D_PROFILE_GENERATE -lm -o
pr34999.x01
$ ./pr34999.x01
$ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.dg/tree-prof/pr34999.c -O2
-freorder-blocks-and-partition -fprofile-use -D_PROFILE_USE -lm -o pr34999.x02
../gcc/testsuite/gcc.dg/tree-prof/pr34999.c: In function ‘main’:
../gcc/testsuite/gcc.dg/tree-prof/pr34999.c:44:1: internal compiler error: in
as_a, at is-a.h:192
 }
 ^
0xe72e5f rtx_jump_insn* as_a(rtx_insn*)
../../gcc/is-a.h:192
0xe72e5f fix_crossing_conditional_branches
../../gcc/bb-reorder.c:2047
0xe72e5f execute
../../gcc/bb-reorder.c:2742

f9a00e9e5f0f056b558f8615e3c030d37923ee72 is the first bad commit
commit f9a00e9e5f0f056b558f8615e3c030d37923ee72
Author: miyuki 
Date:   Wed May 20 19:39:42 2015 +

Promote types of RTL expressions to more derived ones.

[Bug rtl-optimization/66236] [6 Regression] FAIL: gcc.c-torture/execute/pr42691.c on alpha-linux-gnu

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org,
   ||thopre01 at gcc dot gnu.org

--- Comment #1 from Uroš Bizjak  ---
Caused by r223113.

This problem can be triggered by a crosscompiler to alpha-linux-gnu.

[Bug target/65937] FAIL: gcc.target/arm/pr26702.c scan-assembler \\.size[\\t ]+static_foo, 4

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #1 from Ramana Radhakrishnan  ---
fixed.

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[olegendo at gcc dot gnu.org]

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

--- Comment #19 from Oleg Endo  ---
(In reply to Oleg Endo from comment #18)

> Yes, that is true.  However, because op0, op1, op2 are all "arith_reg_dest"
> the peephole will only match if those are GP regs.  Each captured insn will
> only reference a single GP reg, because DImode moves should have been
> smashed into SImode moves before the peephole2 pass.  Thus, I think it
> should be safe to just force the mode of op0 to SImode.  I'll try it out.

The following seems to work OK and I'd propose this as a fix for the problem:

Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 223416)
+++ gcc/config/sh/sh.md (working copy)
@@ -14721,7 +14721,11 @@
|| REGNO (operands[2]) == REGNO (operands[5]))"
   [(const_int 0)]
 {
-  sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[3]));
+  if (REGNO (operands[1]) == REGNO (operands[2]))
+  operands[2] = gen_rtx_REG (SImode, REGNO (operands[0]));
+
+  sh_check_add_incdec_notes (emit_insn (gen_rtx_SET (operands[2],
+operands[3])));
   emit_insn (gen_tstsi_t (operands[2],
  gen_rtx_REG (SImode, (REGNO (operands[1]);
 })
@@ -14748,7 +14752,8 @@
|| REGNO (operands[2]) == REGNO (operands[5]))"
   [(const_int 0)]
 {
-  sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[3]));
+  sh_check_add_incdec_notes (emit_insn (gen_rtx_SET (operands[2],
+operands[3])));
   emit_insn (gen_tstsi_t (operands[2],
  gen_rtx_REG (SImode, (REGNO (operands[1]);
 })


Could you guys please test this patch?  Actually, now it looks quite obvious I
think.

[Bug target/66235] [SH] Optimize tst reg,const movrt sequence

[olegendo at gcc dot gnu.org]

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

--- Comment #1 from Oleg Endo  ---
This is actually a special case of PR 65250.

[Bug c/66230] Using optimizations causes program to segfault

[gpnuma at centaurean dot com]

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

--- Comment #2 from gpnuma at centaurean dot com ---
I understand you're short of time but this problem is very difficult to
reproduce !!

I did try to compile and link with -fsanitize=undefined this morning, now
here's the interesting part :
* no warning was generated by ubsan 
* everything works fine
As soon as I remove -fsanitize=undefined, I get the segfault again, so I
suspect the problem happens during the optimization stages.

The fact that if I add a useless line of code like printf("...") at the start
of the called function cancelling the problem makes me wonder if it could be
that the function pointer is not properly "captured" by gcc or that it
"changes" after optimizations.

Here is what I'm doing to be more accurate :
1) I have a set of functions at the top of a file (functionA, functionB, ...)
2) At the bottom of that file I have another function which stores the function
pointers of these functions using &functionA, &functionB etc... in an array.
3) Later on, I access the functions using an index to that array, and with gcc
4.8 / -O3 *only*, this fails and segfaults.

So my thinking is maybe the function pointers are stored correctly, but then
the optimizer "changes" this function's address or the function itself making
the initial pointer wrong which leads to a segfault... just a wild guess.
I think that adding the printf or a void function maybe adds some sort of
"unoptimizable" code at the start (like IO) and therefore the initial stored
pointer is unchanged after optimizations.
Oh yeah, it's worth mentioning that otherwise (if I don't put a bogus printf)
the first line of code of the function is a __builtin_memcpy which is probably
highly optimizable.

I'll try to come up with a short code example if I get the time later on.

Thank you
Guillaume

[Bug rtl-optimization/66207] Switch alpha to LRA

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Uroš Bizjak from comment #4)
> > Native bootstrap with alphaev68-linux-gnu (a BWX architecture) with the
> > patch from Comment #1 succeeded, the testresults are at [1]. Comparing to
> > non-LRA testsuite run, here is only one new test failure in the entire
> > testsuite:
> 
> No, this failure is not RA related.

-> PR66236.

So, LRA testresults are clean on alphaev68-linux-gnu.

[Bug c/66230] Using optimizations causes program to segfault

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
Another thing you might try is to use: -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations (as per http://gcc.gnu.org/bugs/)
and see if the issue goes away, too.

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
Firefox developers just fixed first half of problem seen by null sanitizer and
I would still wait for fixing the rest:
https://bugzilla.mozilla.org/show_bug.cgi?id=1167119.

Looks fixed issues are not sufficient to successfully run Firefox with LTO,
let's wait for fixing the rest.

Martin

[Bug libstdc++/63345] Multiple undefined behaviors (static_cast<>) in libstdc++-v3/include/bits

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Why does your patch need to touch operator* or operator-> for any of the
iterators? For any dereferenceable iterator the cast should be valid, so if
you're seeing invalid casts it suggests that you are dereferencing invalid
iterators.

[Bug rtl-optimization/66236] [6 Regression] FAIL: gcc.c-torture/execute/pr42691.c on alpha-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug middle-end/66221] [CHKP, 6 regression] lto1: error: type variant has different TYPE_ARG_TYPES

[ienkovich at gcc dot gnu.org]

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

--- Comment #3 from Ilya Enkovich  ---
Author: ienkovich
Date: Thu May 21 09:47:32 2015
New Revision: 223474

URL: https://gcc.gnu.org/viewcvs?rev=223474&root=gcc&view=rev
Log:
gcc/

Backport from mainline r223471
2015-05-21  Ilya Enkovich  

PR middle-end/66221
* ipa-chkp.c (chkp_copy_function_type_adding_bounds): Use
build_distinct_type_copy to copy bounds.

gcc/testsuite/

Backport from mainline r223471
2015-05-21  Ilya Enkovich  

PR middle-end/66221
* gcc.dg/lto/pr66221_0.c: New test.
* gcc.dg/lto/pr66221_1.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/lto/pr66221_0.c
branches/gcc-5-branch/gcc/testsuite/gcc.dg/lto/pr66221_1.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/ipa-chkp.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c/66230] Using optimizations causes program to segfault

[gpnuma at centaurean dot com]

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

--- Comment #4 from gpnuma at centaurean dot com ---
Sorry I meant gcc 4.9.2 / -O3 of course, 4.8 works fine.

[Bug ipa/66181] [6 Regression]: /usr/include/bits/types.h:134:16: ICE: verify_type failed

[clyon at gcc dot gnu.org]

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

--- Comment #9 from Christophe Lyon  ---
Jan, when do you plan to commit your patch?

So far it made it impossible for me to run validations on a subset of 29
commits related to ARM/AArch64 targets since the ICE was introduced.

[Bug c/66230] Using optimizations causes program to segfault

[gpnuma at centaurean dot com]

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

--- Comment #5 from gpnuma at centaurean dot com ---
Ok I did just try "-fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations" and the issue is still there.

If I add the printf("something"); at the top of the function, everything works
normally.

[Bug rtl-optimization/66236] [6 Regression] FAIL: gcc.c-torture/execute/pr42691.c on alpha-linux-gnu

[thopre01 at gcc dot gnu.org]

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

--- Comment #2 from Thomas Preud'homme  ---
Hi Uroš, I tried with a n alpha-linux-gnu GCC cross-compiler built from
revision 223280 but couldn't reproduce this. I configured it with just --prefix
and --target=alpha-linux-gnu and tried compiling the testcase with -S -O3
-fomit-frame-pointer -funroll-loops.

Is there something else I missed?

[Bug c/66230] Using optimizations causes program to segfault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Markus Trippelsdorf  ---
OK you got me interested, so I've downloaded and build the app.
With gcc-5 and -fsanitize=undefined I get many alignment errors:

 Pre-heating ...
../src/kernel_lion_encode.c:182:54: runtime error: store to misaligned address
0x7fa7274ed3d4 for type 'uint64_t', which requires 8 byte alignment
0x7fa7274ed3d4: note: pointer points here
  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00
00 00 00 00 00 00 00
  ^ 
../src/kernel_lion_encode.c:169:52: runtime error: load of misaligned address
0x7fa7273d5da8 for type '__int128 unsigned', which requires 16 byte alignment
0x7fa7273d5da8: note: pointer points here
 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00
00 00 00  00 00 00 00
  ^ 
../src/kernel_lion_encode.c:182:54: runtime error: store to misaligned address
0x7fa72758b204 for type 'uint64_t', which requires 8 byte alignment
0x7fa72758b204: note: pointer points here
  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00
00 00 00 00 00 00 00
  ^ 
../src/kernel_lion_encode.c:169:52: runtime error: load of misaligned address
0x7fa727415a98 for type '__int128 unsigned', which requires 16 byte alignment
0x7fa727415a98: note: pointer points here
 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00
00 00 00  00 00 00 00
  ^ 
../src/kernel_lion_encode.c:182:56: runtime error: load of misaligned address
0x7fa727504e9c for type 'uint64_t', which requires 8 byte alignment
0x7fa727504e9c: note: pointer points here
  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00
00 00 00 00 00 00 00
  ^ 
../src/kernel_lion_encode.c:182:56: runtime error: load of misaligned address
0x7fa72754de44 for type 'uint64_t', which requires 8 byte alignment
0x7fa72754de44: note: pointer points here
  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00
00 00 00 00 00 00 00
  ^ 
../src/kernel_lion_encode.c:182:56: runtime error: load of misaligned address
0x7fa72751446c for type 'uint64_t', which requires 8 byte alignment
0x7fa72751446c: note: pointer points here
  00 00 00 00 32 20 33 20  33 20 34 0a 32 20 33 20  00 00 00 00 00 00 00 00  00
00 00 00 00 00 00 00
  ^ 
../src/kernel_lion_encode.c:169:52: runtime error: load of misaligned address
0x7fa7273b128c for type '__int128 unsigned', which requires 16 byte alignment
0x7fa7273b128c: note: pointer points here
  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  66
66 65 72 00 00 00 00
  ^ 
../src/kernel_lion_encode.c:182:54: runtime error: store to misaligned address
0x7fa727571c5c for type 'uint64_t', which requires 8 byte alignment
0x7fa727571c5c: note: pointer points here
  23 20 32 33 23 20 31 39  65 78 74 65 00 00 00 00  00 00 00 00 00 00 00 00  00
00 00 00 00 00 00 00
  ^ 
../src/buffer.c:38:55: runtime error: load of misaligned address 0x020fd8cc
for type 'uint_fast64_t', which requires 8 byte alignment
0x020fd8cc: note: pointer points here
  00 00 00 00 b5 98 00 00  00 00 00 00 43 3c 00 00  00 00 00 00 03 00 00 00  03
00 00 00 03 00 00 00
  ^ 
../src/buffer.c:38:80: runtime error: load of misaligned address 0x020fd8d4
for type 'uint_fast64_t', which requires 8 byte alignment
0x020fd8d4: note: pointer points here
  00 00 00 00 43 3c 00 00  00 00 00 00 03 00 00 00  03 00 00 00 03 00 00 00  00
00 00 00 b5 98 00 00
  ^ 
../src/kernel_lion_decode.c:84:50: runtime error: store to misaligned address
0x0223dd54 for type 'uint64_t', which requires 8 byte alignment
0x0223dd54: note: pointer points here
  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00
00 00 00 00 00 00 00
  ^ 
../src/kernel_lion_decode.c:90:28: runtime error: load of misaligned address
0x02126728 for type '__int128 unsigned', which requires 16 byte alignment
0x02126728: note: pointer points here
 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00
00 00 00  00 00 00 00
  ^ 
../src/kernel_lion_decode.c:84:50: runtime error: store to misaligned address
0x02259b94 for type 'uint64_t', which requires 8 byte alignment
0x02259b94: note: pointer points here
  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00
00 00 00 00 00 00 00
  ^ 
../src/kernel_lion_decode.c:84:52: runtime error: load of misaligned address
0x0225581c for type 'uint64_t', which requires 8 byte alignment
0x0225581c: note:

[Bug fortran/66238] New: C/Fortran interoperability broken with -flto

[dominiq at lps dot ens.fr]

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

Bug ID: 66238
   Summary: C/Fortran interoperability broken with -flto
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---

When running the gfortran test suite with -flto, I get the following new
failures since r223288

FAIL: gfortran.dg/bind_c_usage_16.f03   -g -flto  (test for excess errors)
FAIL: gfortran.dg/bind_c_usage_17.f90   -g -flto  (test for excess errors)
FAIL: gfortran.dg/c_char_tests.f03   -g -flto  (test for excess errors)
FAIL: gfortran.dg/proc_ptr_7.f90   -g -flto  (test for excess errors)

The errors are

/opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_16_c.c:8:6: warning:
type of 'returnA' does not match original declaration [-Wlto-type-mismatch]
 char returnA(char *);
  ^
lto1: note: return value type mismatch
lto1: note: type 'unsigned char' should match type 'char'
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_16.f03:12:0: note: 'bar'
was previously declared here
   function bar(x)  bind(c, name="returnA")
^
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_16_c.c:9:6: warning:
type of 'returnB' does not match original declaration [-Wlto-type-mismatch]
 char returnB(void);
  ^
lto1: note: return value type mismatch
lto1: note: type 'unsigned char' should match type 'char'
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_16.f03:17:0: note: 'foo'
was previously declared here
   function foo()  bind(c, name="returnB")
^

/opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_17.f90:24:0: warning:
type of 'cdir' does not match original declaration [-Wlto-type-mismatch]
   str1 = cdir()
^
lto1: note: return value type mismatch
lto1: note: type 'char' should match type 'unsigned char'
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_17_c.c:4:6: note: 'cdir'
was previously declared here
 char cdir(void){return '/';}
  ^

/opt/gcc/_clean/gcc/testsuite/gfortran.dg/c_char_driver.c:1:6: warning: type of
'param_test' does not match original declaration [-Wlto-type-mismatch]
 void param_test(char my_char, char my_char_2);
  ^
lto1: note: type mismatch in parameter 1
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/c_char_tests.f03:10:0: note:
'param_test' was previously declared here
   subroutine param_test(my_char, my_char_2) bind(c)
^

and

/opt/gcc/_clean/gcc/testsuite/gfortran.dg/proc_ptr_7.f90:22:0: warning: type of
'assignf' does not match original declaration [-Wlto-type-mismatch]
   call assignF(ptr)
^
lto1: note: type mismatch in parameter 1
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/proc_ptr_7.c:8:6: note: 'assignf_'
was previously declared here
 void assignf_(int(**ptr)(void)) {
  ^

The first two failures can be fixed by replacing 'char' with 'unsigned char' in
the C files. I don't know how to fix the two other ones.

[Bug c/66230] Using optimizations causes program to segfault

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709 for a similar bug
in LZ4.

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

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

--- Comment #20 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #19)
> Could you guys please test this patch?  Actually, now it looks quite obvious
> I think.

gen_rtx_SET functions required SImode as their first argument.
Tests are running with that change on 5.1.0, though I agree
that it's an obvious fix.

[Bug libstdc++/66017] Undefined behaviour in std::set

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
I think this would solve it (I'm still trying to build a clang that will allow
me to reproduce the error):


--- a/libstdc++-v3/include/bits/stl_tree.h
+++ b/libstdc++-v3/include/bits/stl_tree.h
@@ -869,25 +869,32 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   iterator
   begin() _GLIBCXX_NOEXCEPT
   { 
+   if (_M_impl._M_header._M_left == &_M_impl._M_header)
+ return end();
return iterator(static_cast<_Link_type>
(this->_M_impl._M_header._M_left));
   }

   const_iterator
   begin() const _GLIBCXX_NOEXCEPT
-  { 
+  {
+   if (_M_impl._M_header._M_left == &_M_impl._M_header)
+ return end();
return const_iterator(static_cast<_Const_Link_type>
  (this->_M_impl._M_header._M_left));
   }

   iterator
   end() _GLIBCXX_NOEXCEPT
-  { return iterator(static_cast<_Link_type>(&this->_M_impl._M_header)); }
+  {
+   return iterator(reinterpret_cast<_Link_type>
+   (&this->_M_impl._M_header));
+  }

   const_iterator
   end() const _GLIBCXX_NOEXCEPT
   { 
-   return const_iterator(static_cast<_Const_Link_type>
+   return const_iterator(reinterpret_cast<_Const_Link_type>
  (&this->_M_impl._M_header));
   }


When the tree is empty begin() performs an invalid cast too, but I don't like
the branch this introduces.

[Bug c/66230] Using optimizations causes program to segfault

[gpnuma at centaurean dot com]

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

--- Comment #8 from gpnuma at centaurean dot com ---
Thanks Markus I didn't think these alignment issues were actually the problem,
it goes a long way.

By doing memmoves instead of pointer cast allocations I got rid of the
segfault, but of course things are much slower... this "undefined behaviour" is
really treacherous !!

Is there any way to ensure proper alignment so I don't fall into this trap and
still benefit from maximum speed ?

[Bug c/66230] Using optimizations causes program to segfault

[gpnuma at centaurean dot com]

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

--- Comment #9 from gpnuma at centaurean dot com ---
What I mean is the structs I was using the pointer casts allocations with are
instanciated by the program itself, so there could be a way to instanciate them
with the required alignment I suppose.

[Bug c/66220] -Wmisleading-indentation false/inconsistent warning

[sirl at gcc dot gnu.org]

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

--- Comment #4 from Franz Sirl  ---
Patch from #c3 works fine for our codebase, I couldn't spot any false positives
anymore.

[Bug rtl-optimization/66237] [6 regression] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE (internal compiler error)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|[6.0 regression] FAIL:  |[6 regression] FAIL:
   |gcc.dg/tree-prof/pr34999.c  |gcc.dg/tree-prof/pr34999.c
   |compilation,  -fprofile-use |compilation,  -fprofile-use
   |-D_PROFILE_USE (internal|-D_PROFILE_USE (internal
   |compiler error) |compiler error)

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[olegendo at gcc dot gnu.org]

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

--- Comment #21 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #20)
> (In reply to Oleg Endo from comment #19)
> > Could you guys please test this patch?  Actually, now it looks quite obvious
> > I think.
> 
> gen_rtx_SET functions required SImode as their first argument.
> Tests are running with that change on 5.1.0, though I agree
> that it's an obvious fix.

Please commit if it looks OK.

[Bug c++/66239] New: Unoptimized sqrt(float or double) returns wrong values for ARM Cortex-A8 -mfloat-abi=[soft,softfp]

[maciej.andrzejewski at data dot pl]

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

Bug ID: 66239
   Summary: Unoptimized sqrt(float or double) returns wrong values
for ARM Cortex-A8 -mfloat-abi=[soft,softfp]
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maciej.andrzejewski at data dot pl
  Target Milestone: ---

Tested both on GCC 4.9.1 (compiled toolchain using crosstool-ng) and 4.9.2
(compiled toolchain using buildroot).

Simple code:

-- CODE --
#include 
#include 
#include 


int main( void )
{
double sq3 = 9.1;
double ret3 = sqrtf(sq3);
printf("%f\n", ret3);

float sq4 = 9.1;
double ret4 = sqrtf(sq4);
printf("%f\n", ret4);

double sq1 = 9.1;
double ret1 = sqrt(sq1);
printf("%f\n", ret1);

float sq2 = 9.1;
double ret2 = sqrt(sq2);
printf("%f\n", ret2);

return 0;
}
-- CODE --

compiled with command:
g++ -mcpu=cortex-a8 -march=armv7-a -mtune=cortex-a8 -mfpu=neon
-mthumb-interwork -mfpu=neon -Wall -Wextra -mfloat-abi=softfp

or

g++ -mcpu=cortex-a8 -march=armv7-a -mtune=cortex-a8 -mfpu=neon 
-mthumb-interwork -mfpu=neon -Wall -Wextra -mfloat-abi=soft

prints output when run:
-- OUTPUT --
0.00
0.00
89884613882771507935772421602449274280826426490922860415370742828850803088708436568909338933268615382725731836148779976703521876921396883553861971381426763394584730974161643341227168116324626810241973964225774272233175406843466371141886318608237834273423597057507238373804952327520531541920130815989439791104.00
89884613882771507935772421602449274280826426490922860415370742828850803088708436568909338933268615382725731836148779976703521876921396883553861971381426763394584730974161643341227168116324626810241973964225774272233175406843466371141886318608237834273423597057507238373804952327520531541920130815989439791104.00
-- OUTPUT --

when compiled with added ANY optimization flag (O, O1, O2, O3, Og) prints
proper output:
-- OUTPUT 2 --
3.016621
3.016621
3.016621
3.016621
-- OUTPUT 2 --




*** Additional info ***

g++ --version:
arm-none-linux-gnueabi-g++ (Buildroot 2015.02) 4.9.2

readelf -a a.out:
-- READELF --
macieja@ubuntu:~/Projects/sqrtf$ readelf -a a.out
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class: ELF32
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  EXEC (Executable file)
  Machine:   ARM
  Version:   0x1
  Entry point address:   0x103d0
  Start of program headers:  52 (bytes into file)
  Start of section headers:  5012 (bytes into file)
  Flags: 0x5000202, has entry point, Version5 EABI,
soft-float ABI
  Size of this header:   52 (bytes)
  Size of program headers:   32 (bytes)
  Number of program headers: 8
  Size of section headers:   40 (bytes)
  Number of section headers: 29
  Section header string table index: 26

Section Headers:
  [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf
Al
  [ 0]   NULL 00 00 00  0   0 
0
  [ 1] .interp   PROGBITS00010134 000134 13 00   A  0   0 
1
  [ 2] .note.ABI-tag NOTE00010148 000148 20 00   A  0   0 
4
  [ 3] .hash HASH00010168 000168 38 04   A  4   0 
4
  [ 4] .dynsym   DYNSYM  000101a0 0001a0 90 10   A  5   1 
4
  [ 5] .dynstr   STRTAB  00010230 000230 d3 00   A  0   0 
1
  [ 6] .gnu.version  VERSYM  00010304 000304 12 02   A  4   0 
2
  [ 7] .gnu.version_rVERNEED 00010318 000318 40 00   A  5   2 
4
  [ 8] .rel.dyn  REL 00010358 000358 08 08   A  4   0 
4
  [ 9] .rel.plt  REL 00010360 000360 20 08  AI  4  11 
4
  [10] .init PROGBITS00010380 000380 0c 00  AX  0   0 
4
  [11] .plt  PROGBITS0001038c 00038c 44 04  AX  0   0 
4
  [12] .text PROGBITS000103d0 0003d0 0001f8 00  AX  0   0 
4
  [13] .fini PROGBITS000105c8 0005c8 08 00  AX  0   0 
4
  [14] .rodata   PROGBITS000105d0 0005d0 08 00   A  0   0 
4
  [15] .ARM.exidxARM_EXIDX   000105d8 0005d8 18 00  AL 12   0 
4
  [16] .eh_frame PROGBITS000105f0 0005f0 04 00   A  0   0 
4
  [17] .init_array   INIT_ARRAY  000205f4 0005f4 04 00  WA  0   0 
4
  [18] .fini_array   FINI_ARRAY  000205f8 0005f8 04 00  WA  0   0 
4
  [19] .jcr  PR

[Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Ok, then maybe the following could work (only lightly tested so far).  Arguably
static_init_p could be renamed to e.g. no_sanitize_p.

diff --git gcc/cp/cp-gimplify.c gcc/cp/cp-gimplify.c
index d5a64fc..a90c8b7 100644
--- gcc/cp/cp-gimplify.c
+++ gcc/cp/cp-gimplify.c
@@ -906,6 +906,7 @@ struct cp_genericize_data
   vec bind_expr_stack;
   struct cp_genericize_omp_taskreg *omp_ctx;
   tree try_block;
+  bool static_init_p;
 };

 /* Perform any pre-gimplification lowering of C++ front end trees to
@@ -1150,6 +1151,21 @@ cp_genericize_r (tree *stmt_p, int *walk_subtrees, void
*data)
   *stmt_p = build1 (NOP_EXPR, void_type_node, integer_zero_node);
   *walk_subtrees = 0;
 }
+  else if ((flag_sanitize
+   & (SANITIZE_NULL | SANITIZE_ALIGNMENT | SANITIZE_VPTR))
+  && TREE_CODE (stmt) == DECL_EXPR
+  && VAR_P (DECL_EXPR_DECL (stmt))
+  && TREE_STATIC (DECL_EXPR_DECL (stmt))
+  && DECL_INITIAL (DECL_EXPR_DECL (stmt)))
+{
+  *walk_subtrees = 0;
+  /* The point here is to not sanitize static initializers.  */
+  bool static_init_p = wtd->static_init_p;
+  wtd->static_init_p = true;
+  cp_walk_tree (&DECL_INITIAL (DECL_EXPR_DECL (stmt)), cp_genericize_r,
+   data, NULL);
+  wtd->static_init_p = static_init_p;
+}
   else if (TREE_CODE (stmt) == OMP_PARALLEL || TREE_CODE (stmt) == OMP_TASK)
 {
   struct cp_genericize_omp_taskreg omp_ctx;
@@ -1275,9 +1291,10 @@ cp_genericize_r (tree *stmt_p, int *walk_subtrees, void
*data)
   if (*stmt_p == error_mark_node)
*stmt_p = size_one_node;
   return NULL;
-}
-  else if (flag_sanitize
-  & (SANITIZE_NULL | SANITIZE_ALIGNMENT | SANITIZE_VPTR))
+}
+  else if ((flag_sanitize
+   & (SANITIZE_NULL | SANITIZE_ALIGNMENT | SANITIZE_VPTR))
+  && !wtd->static_init_p)
 {
   if ((flag_sanitize & (SANITIZE_NULL | SANITIZE_ALIGNMENT))
  && TREE_CODE (stmt) == NOP_EXPR
@@ -1319,6 +1336,7 @@ cp_genericize_tree (tree* t_p)
   wtd.bind_expr_stack.create (0);
   wtd.omp_ctx = NULL;
   wtd.try_block = NULL_TREE;
+  wtd.static_init_p = false;
   cp_walk_tree (t_p, cp_genericize_r, &wtd, NULL);
   delete wtd.p_set;
   wtd.bind_expr_stack.release ();

[Bug rtl-optimization/66236] [6 Regression] FAIL: gcc.c-torture/execute/pr42691.c on alpha-linux-gnu

[thopre01 at gcc dot gnu.org]

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

--- Comment #3 from Thomas Preud'homme  ---
Alternatively, you can try the patch proposed at [1] and see if it fixes the
issue you're facing since it seems to be the same one.

[1] https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01901.html

Best regards.

[Bug c/66230] Using optimizations causes program to segfault

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
(In reply to gpnuma from comment #8)
> Thanks Markus I didn't think these alignment issues were actually the
> problem, it goes a long way.
> 
> By doing memmoves instead of pointer cast allocations I got rid of the
> segfault, but of course things are much slower... this "undefined behaviour"
> is really treacherous !!
> 
> Is there any way to ensure proper alignment so I don't fall into this trap
> and still benefit from maximum speed ?

I'm afraid there is no general recipe that would ensure proper alignment.
But using memcpy hasn't necessary to be "much slower".
And trading undefined behavior for a little more speed isn't a good idea in
general.

[Bug rtl-optimization/66236] [6 Regression] FAIL: gcc.c-torture/execute/pr42691.c on alpha-linux-gnu

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Thomas Preud'homme from comment #3)
> Alternatively, you can try the patch proposed at [1] and see if it fixes the
> issue you're facing since it seems to be the same one.
> 
> [1] https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01901.html

Thomas,

yes the referred patch also fixes this issue.

Thanks!

[Bug c++/66239] Unoptimized sqrt(float or double) returns wrong values for ARM Cortex-A8 -mfloat-abi=[soft,softfp]

[maciej.andrzejewski at data dot pl]

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

--- Comment #1 from Maciej Andrzejewski  ---
It is getting even more interesting.

I have disassabled 4 binaries compiled with options:
1) -mfloat-abi=softfp
2) -mfloat-abi=softfp -O
3) -mfloat-abi=hard
4) -mfloat-abi=hard -O

and from what I understand if we turn ON the optimization the FPU is turned
OFF!
I dont see in assembler that FPU s** registers are used in those two cases
where optimization is turned on:

-- DISASSAMBLE OPTION 1 --
00010570 :
   10570:   e92d4800push{fp, lr}
   10574:   e28db004add fp, sp, #4
   10578:   e24dd040sub sp, sp, #64 ; 0x40
   1057c:   e3032333movwr2, #13107  ; 0x
   10580:   e3432333movtr2, #13107  ; 0x
   10584:   e303movwr3, #13107  ; 0x
   10588:   e3443022movtr3, #16418  ; 0x4022
   1058c:   e14b20fcstrdr2, [fp, #-12]
   10590:   ed5b0b03vldrd16, [fp, #-12]
   10594:   eef77be0vcvt.f32.f64s15, d16
   10598:   ee170a90vmovr0, s15
   1059c:   eba1bl  10428 
   105a0:   ee070a90vmovs15, r0
   105a4:   eef70ae7vcvt.f64.f32d16, s15
   105a8:   ed4b0b05vstrd16, [fp, #-20] ; 0xffec
   105ac:   e30006ccmovwr0, #1740   ; 0x6cc
   105b0:   e341movtr0, #1
   105b4:   e14b21d4ldrdr2, [fp, #-20]  ; 0xffec
   105b8:   eba0bl  10440 
   105bc:   e309399amovwr3, #39322  ; 0x999a
   105c0:   e3443111movtr3, #16657  ; 0x4111
   105c4:   e50b3018str r3, [fp, #-24]  ; 0xffe8
   105c8:   e51b0018ldr r0, [fp, #-24]  ; 0xffe8
   105cc:   eb95bl  10428 
   105d0:   ee070a90vmovs15, r0
   105d4:   eef70ae7vcvt.f64.f32d16, s15
   105d8:   ed4b0b09vstrd16, [fp, #-36] ; 0xffdc
   105dc:   e30006ccmovwr0, #1740   ; 0x6cc
   105e0:   e341movtr0, #1
   105e4:   e14b22d4ldrdr2, [fp, #-36]  ; 0xffdc
   105e8:   eb94bl  10440 
   105ec:   e3032333movwr2, #13107  ; 0x
   105f0:   e3432333movtr2, #13107  ; 0x
   105f4:   e303movwr3, #13107  ; 0x
   105f8:   e3443022movtr3, #16418  ; 0x4022
   105fc:   e14b22fcstrdr2, [fp, #-44]  ; 0xffd4
   10600:   e14b02dcldrdr0, [fp, #-44]  ; 0xffd4
   10604:   eb8abl  10434 
   10608:   e14b03f4strdr0, [fp, #-52]  ; 0xffcc
   1060c:   e30006ccmovwr0, #1740   ; 0x6cc
   10610:   e341movtr0, #1
   10614:   e14b23d4ldrdr2, [fp, #-52]  ; 0xffcc
   10618:   eb88bl  10440 
   1061c:   e309399amovwr3, #39322  ; 0x999a
   10620:   e3443111movtr3, #16657  ; 0x4111
   10624:   e50b3038str r3, [fp, #-56]  ; 0xffc8
   10628:   ed5b7a0evldrs15, [fp, #-56] ; 0xffc8
   1062c:   eef70ae7vcvt.f64.f32d16, s15
   10630:   ec510b30vmovr0, r1, d16
   10634:   eb7ebl  10434 
   10638:   e14b04f4strdr0, [fp, #-68]  ; 0xffbc
   1063c:   e30006ccmovwr0, #1740   ; 0x6cc
   10640:   e341movtr0, #1
   10644:   e14b24d4ldrdr2, [fp, #-68]  ; 0xffbc
   10648:   eb7cbl  10440 
   1064c:   e3a03000mov r3, #0
   10650:   e1a3mov r0, r3
   10654:   e24bd004sub sp, fp, #4
   10658:   e8bd8800pop {fp, pc}
-- DISASSAMBLE OPTION 1 --



-- DISASSAMBLE OPTION 2 --
000104f4 :
   104f4:   e92d40d0push{r4, r6, r7, lr}
   104f8:   e30045d4movwr4, #1492   ; 0x5d4
   104fc:   e3404001movtr4, #1
   10500:   e3a06000mov r6, #0
   10504:   e302720amovwr7, #8714   ; 0x220a
   10508:   e3447008movtr7, #16392  ; 0x4008
   1050c:   e1a4mov r0, r4
   10510:   e1a02006mov r2, r6
   10514:   e1a03007mov r3, r7
   10518:   eba9bl  103c4 
   1051c:   e1a4mov r0, r4
   10520:   e1a02006mov r2, r6
   10524:   e1a03007mov r3, r7
   10528:   eba5bl  103c4 
   1052c:   e1a4mov r0, r4
   10530:   e30f2d38movwr2, #64824  ; 0xfd38
   10534:   e34f2ea1movtr2, #65185  ; 0xfea1
   10538:   e3023209movwr3, #8713   ; 0x2209
   

[Bug c/66240] New: RFE: extend -falign-xyz syntax

[vda.linux at googlemail dot com]

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

Bug ID: 66240
   Summary: RFE: extend -falign-xyz syntax
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vda.linux at googlemail dot com
  Target Milestone: ---

Experimentally, compilation with
-O2 -falign-functions=17 -falign-loops=17 -falign-jumps=17 -falign-labels=17
results in the following:
- functions are aligned using ".p2align 5,,16" asm directive
- loops/jumps/labels are aligned using ".p2align 5"

-Os -falign-functions=17 -falign-loops=17 -falign-jumps=17 -falign-labels=17
results in the following:
- functions are not aligned
- loops/jumps/labels are aligned using ".p2align 5"

Can this be improved so that in all cases, ".p2align 5,,16" is used? Shouldn't
be that hard...


Next step (what this RFE is all about). -falign-functions=N is too simplistic.
Ingo Molnar ran some tests and it looks on latest x86 CPUs, 64-byte alignment
runs fastest (he tried many other possibilites).

However, developers are less than thrilled by the idea of a slam-dunk 64-byte
aligning everything. Too much waste:
On 05/20/2015 02:47 AM, Linus Torvalds wrote:
> At the same time, I have to admit that I abhor a 64-byte function
> alignment, when we have a fair number of functions that are (much)
> smaller than that.
> 
> Is there some way to get gcc to take the size of the function into
> account? Because aligning a 16-byte or 32-byte function on a 64-byte
> alignment is just criminally nasty and wasteful.

I propose the following: align function to 64-byte boundaries *IF* this does
not introduce huge amount of padding.

GNU as already has support for this:

.align N1,FILL,N3

"The third expression is also absolute, and is also optional.
If it is present, it is the maximum number of bytes that should
be skipped by this alignment directive."

So, what we want is to put something like ".align 64,,7"
before every function. 98% of functions in typical linux kernel have first
instruction 7 or fewer bytes long. Thus, with ".align 64,,7", calling any
function will at a minimum be able to fetch one insn in one L1 read, not two.
And this would be acheved with only ~3.5 bytes per function wasted to padding
on average, whereas ".align 64" would waste 31 byte on average.

Please extend -falign-foo=N syntax to, say, -falign-foo=N,M, which generates
".align M,,N-1" or equivalent.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2015-05-21
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #11 from Marek Polacek  ---
Suspending until then.

[Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima  changed:

   What|Removed |Added

Summary|Multiple issues in  |[4.9/5/6 Regression] [SH]
   |conftest.c prevent build on |Wrong code is generated
   |sh4-linux-gnu   |with stage1 compiler

--- Comment #22 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #21)

OK, I'll commit your patch when all tests are done.
BTW, I'd like to change the summary of the PR to clarify that this is
a 4.9/5/6 regression.

[Bug target/66232] -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
Created attachment 35585
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35585&action=edit
A patch

I am testing this.

[Bug c/29358] Warning issued two times with snprintf

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #7 from Marek Polacek  ---
Note that my patch 
also fixes this issue.

[Bug target/54236] [SH] Improve addc and subc insn utilization

[olegendo at gcc dot gnu.org]

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

--- Comment #14 from Oleg Endo  ---
Author: olegendo
Date: Thu May 21 12:36:35 2015
New Revision: 223479

URL: https://gcc.gnu.org/viewcvs?rev=223479&root=gcc&view=rev
Log:
gcc/
PR target/54236
* config/sh/sh.md (*round_int_even): Reject pattern if operands[0] and
operands[1] are the same.

gcc/testsuite/
PR target/54236
* gcc.target/sh/pr54236-2.c: Fix typo in comment.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/sh/pr54236-2.c

[Bug middle-end/66241] New: ICE: verify_type failed while building libstdc++ (dwarfout.c: gen_type_die_with_usage())

[vp at gcc dot gnu.org]

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

Bug ID: 66241
   Summary: ICE: verify_type failed while building libstdc++
(dwarfout.c: gen_type_die_with_usage())
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vp at gcc dot gnu.org
  Target Milestone: ---

I'm seeing this while building arm-none-linux-gnueabi/gnueabihf at the stage of
building libstdc++

[...]arm-none-linux-gnueabi/libc/usr/include/bits/types.h:134:30: internal
compiler error: verify_type failed
0xf3eb05 verify_type(tree_node const*)
/work/ws/fsf-trunk/src/gcc/gcc/tree.c:13257
0x942ab4 gen_type_die_with_usage
/work/ws/fsf-trunk/src/gcc/gcc/dwarf2out.c:20250
0x9414be gen_decl_die
/work/ws/fsf-trunk/src/gcc/gcc/dwarf2out.c:20987
0x93faf3 gen_member_die
/work/ws/fsf-trunk/src/gcc/gcc/dwarf2out.c:19945
0x93faf3 gen_struct_or_union_type_die
/work/ws/fsf-trunk/src/gcc/gcc/dwarf2out.c:20038
0x93faf3 gen_tagged_type_die
/work/ws/fsf-trunk/src/gcc/gcc/dwarf2out.c:20227
0x9432c9 gen_type_die_with_usage
/work/ws/fsf-trunk/src/gcc/gcc/dwarf2out.c:20381
0x9414be gen_decl_die
/work/ws/fsf-trunk/src/gcc/gcc/dwarf2out.c:20987

This looks similar to bug 66214 but not sure if it's the same. Attaching a
preprocessed file that reproduces this with g++ -g -O0

[Bug middle-end/66241] ICE: verify_type failed while building libstdc++ (dwarfout.c: gen_type_die_with_usage())

[vp at gcc dot gnu.org]

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

--- Comment #1 from Vidya Praveen  ---
Created attachment 35586
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35586&action=edit
preprocessed file to reproduce ICE

[Bug ada/66242] New: Front-end error if exception propagation disabled

[simon at pushface dot org]

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

Bug ID: 66242
   Summary: Front-end error if exception propagation disabled
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
  Target Milestone: ---

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

First detected in GCC 4.9.1 built for arm-eabi on
x86_64-apple-darwin13 (Mac OS X Mavericks) with these pragmas on
System:

   pragma Profile (Ravenscar);
   pragma Restrictions (No_Enumeration_Maps);
   pragma Restrictions (No_Exception_Propagation);
   pragma Restrictions (No_Recursion);

Also observed with GCC 5.1.0, same build.

The demonstrators use

   pragma Restrictions (No_Exception_Propagation);
   with Ada.Finalization;
   package Fin is
  type F is new Ada.Finalization.Controlled with null record;
   end Fin;

and show the problem with the hosted compiler. There are two, because
only the first such error is detected.

(1) Unchecked deallocation

   with Ada.Finalization;
   with Ada.Unchecked_Deallocation;
   with Fin; use Fin;
   procedure Fin_Deallocation is

  type F_P is access F;
  procedure Delete
is new Ada.Unchecked_Deallocation (F, F_P);

  procedure Check_Heap_1 is
 An_F_P : F_P :=
   new F'(Ada.Finalization.Controlled with null record);
  begin
 Delete (An_F_P);
  end Check_Heap_1;

   begin
  Check_Heap_1;
   end Fin_Deallocation;

results in

17.procedure Check_Heap_1 is
18.   An_F_P : F_P :=
19. new F'(Ada.Finalization.Controlled with null record);
20.begin
21.   Delete (An_F_P);
  |
>>> "" is undefined

22.end Check_Heap_1;

The end of the -gnatdg output for Check_Heap_1 is

   begin
  if an_f_p /= null then
 B22b : begin
system__soft_links__abort_defer.all;
B23b : begin
   [constraint_error when
 an_f_p = null
 "access check failed"]
   [type T24b is procedure (object : in out fin__TfC)]
   [subtype T25b is access T24b]
   T25b!(fin__fH!(fin__TfC!(an_f_p.all)._tag).all (2)).all
 (fin__TfC!(an_f_p.all));
exception
   when others =>
  any id := true;<<<
end B23b;
 at end
system__standard_library__abort_undefer_direct;
 end B22b;
 free an_f_p;
 an_f_p := null;
 if  then
[program_error "finalize raised exception"]  <<<
 end if;
  end if;
   end check_heap_1;

which I take to mean that the compiler has tried to generate an
exception handler which is incompatible with pragma Restrictions
(No_Exception_Propagation).

I've traced this to exp_intr.adb, and written a patch which resolves
this problem.

(2) Returning a controlled type

I see also that in exp_ch7.adb all the cases where an exception
handler like this one might be generated are protected by a check for
No_Exception_Propagation, except for one at line 4751 in
Process_Transient_Objects. To demonstrate this,

   with Ada.Finalization;
   with Fin; use Fin;
   procedure Fin_Return_Controlled is
  type R is record
 A, B : F;
  end record;
  function Get_F return R is
  begin
 return (A => F'(Ada.Finalization.Controlled with null record),
 B => F'(Ada.Finalization.Controlled with null record));
  end Get_F;
  An_F : R;
   begin
  An_F := Get_F;
   end Fin_Return_Controlled;

fails as

 8. with Ada.Finalization;
 9. with Fin; use Fin;
10. procedure Fin_Return_Controlled is
11.type R is record
12.   A, B : F;
13.end record;
14.function Get_F return R is
15.begin
16.   return (A => F'(Ada.Finalization.Controlled with null record),
17.   B => F'(Ada.Finalization.Controlled with null record));
18.end Get_F;
19.An_F : R;
20. begin
21.An_F := Get_F;
   |
>>> "" is undefined

22. end Fin_Return_Controlled;

and the corresponding part of the -gnatdg output is

  B26b : declare
  begin
 B27b : begin
T25b := null;
fin_return_controlled__rDF (R18b.all, f => true);
 exception
when others =>
   any id := true;
 end B27b;
 if  then
[program_error "finalize raised exception"]
 end if;
  end B26b;

with the same symptoms.

I have a patch for this too.

The patches apply (with considerable offsets) to GCC 5.1.0, but I
haven't tested them yet (indeed, I've only tested in the arm-eabi
build).

[Bug ada/66242] Front-end error if exception propagation disabled

[simon at pushface dot org]

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

--- Comment #1 from simon at pushface dot org ---
Created attachment 35588
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35588&action=edit
Suggested patch

[Bug c++/66211] [5 Regression] Rvalue conversion in ternary operator causes internal compiler error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0
Summary|[5/6 Regression] Rvalue |[5 Regression] Rvalue
   |conversion in ternary   |conversion in ternary
   |operator causes internal|operator causes internal
   |compiler error  |compiler error
  Known to fail||5.1.0

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

[Bug target/65283] [SH] lds fpscr not put in delay slot

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-21
 Ever confirmed|0   |1

--- Comment #1 from Oleg Endo  ---
BTW, the SH4A fpchg insn has the same problem.

[Bug c++/66211] [5 Regression] Rvalue conversion in ternary operator causes internal compiler error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0
Summary|[5/6 Regression] Rvalue |[5 Regression] Rvalue
   |conversion in ternary   |conversion in ternary
   |operator causes internal|operator causes internal
   |compiler error  |compiler error
  Known to fail||5.1.0

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Thu May 21 13:23:41 2015
New Revision: 223483

URL: https://gcc.gnu.org/viewcvs?rev=223483&root=gcc&view=rev
Log:
2015-05-21  Richard Biener  

PR c++/66211
* match.pd: Guard pattern optimzing (int)(float)int
conversions to apply only on GIMPLE.

* g++.dg/conversion/pr66211.C: New testcase.
* gcc.dg/tree-ssa/forwprop-18.c: Adjust.

Added:
trunk/gcc/testsuite/g++.dg/conversion/pr66211.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-18.c

[Bug c/66219] The gcc generated section start/stop pointers become undefined when option -flto is used

[dscao999 at hotmail dot com]

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

--- Comment #2 from Cao Da Shi  ---
This issue poped up when cross compiling systemd-219. It is confirmed that the
missed section has the __attribute__((used)) declared. But still the link will
only pass without "-flto", with all other options exactly the same. The files
are too large to be sent. The link command is as follows:
arm-elf-linux-gnueabi-gcc -shared -Wl,-Map=/tmp/mymap.txt -fPIC -DPIC
pam_systemd_la-pam_systemd.o -Wl,--whole-archive libsystemd-internal.a
libsystemd-shared.a -Wl,--no-whole-archive -Wl,-rpath -lrt -lcap -lm
libpam_misc.so libpam.so -ldl -flto -O2 -Wl,--as-needed -Wl,--no-undefined
-Wl,--gc-sections -Wl,-z -Wl,relro -Wl,-z -Wl,now
-Wl,--version-script=pam_systemd.sym -pthread -Wl,-soname -Wl,pam_systemd.so -o
/tmp/pam_systemd.so

$ arm-elf-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-elf-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/opt/cxpkg/cxarm/libexec/gcc/arm-elf-linux-gnueabi/4.8.4/lto-wrapper
Target: arm-elf-linux-gnueabi
Configured with: /home/dscao/build/native/gcc/gcc-4.8.4/configure
--prefix=/opt/cxpkg/cxarm --target=arm-elf-linux-gnueabi
--host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu
--with-tune=cortex-a8 --with-arch=armv7-a -with-mode=arm --with-float=hard
--with-fpu=vfp3 --disable-nls --with-system-zlib
--with-sysroot=/var/opt/cxroots/armroot --enable-languages=c,c++
--enable-checking=release --enable-threads=posix --enable-shared
Thread model: posix
gcc version 4.8.4 (GCC)

[Bug c++/66243] New: enum class value is allowed to be initialized by value from other enum class

[Predelnik at gmail dot com]

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

Bug ID: 66243
   Summary: enum class value is allowed to be initialized by value
from other enum class
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Predelnik at gmail dot com
  Target Milestone: ---

>From my understanding enum class values could be initialized by integer
constant expression (and thus by its own already defined values since they are
implicitly convertible to int in its scope). However g++ compiles the following
code where this value is taken from other completely unrelated enum class and
thus shouldn't be implicitly convertible to integer type in its scope.

enum class A
{
  X
};

enum class B
{
  X = A::X,
};

int main()
{
}

[Bug fortran/66238] C/Fortran interoperability broken with -flto

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #1 from Mikael Morin  ---
(In reply to Dominique d'Humieres from comment #0)
> When running the gfortran test suite with -flto, I get the following new
> failures since r223288
> 
I don't have updated to that revision, so that I can't check by myself, but
here are a few possible problems:

For proc_ptr_7, the procedure pointer argument has a variadic number of
arguments on the fortran side, and no argument on the C side.

For c_char_tests, a possible problem is the declaration of arguments as
  character(c_char), value :: foo
This declares a character of len c_char and default kind as far as I know.
According to
https://gcc.gnu.org/onlinedocs/gfortran/Interoperable-Subroutines-and-Functions.html
the canonical declaration is rather:
  character(kind=c_char) :: foo(*)
With the value attribute, I don't know how it should be handled though.

[Bug target/65283] [SH] lds fpscr not put in delay slot

[chrbr at gcc dot gnu.org]

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

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 CC||chrbr at gcc dot gnu.org

--- Comment #2 from chrbr at gcc dot gnu.org ---
this is a conservative limitation to avoid a ds schedule problem. 

this is because
(define_attr "in_delay_slot" "yes,no"
 (eq_attr "type" "fpscr_toggle") (const_string "no")

an old analysis (for reference) and regression test:
https://gcc.gnu.org/ml/gcc-patches/2007-01/msg00746.html

[Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[kkojima at gcc dot gnu.org]

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

--- Comment #23 from Kazumoto Kojima  ---
Ouch.  The peephole in problem was added at gcc-5 not at 4.9.  The above
patch should fix the original conftest.c issue, but debien 4.9-16 problem
would be an another issue.  Sorry for my confusion.

[Bug target/65283] [SH] lds fpscr not put in delay slot

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  ---
Thanks for the pointer.

Still, if this
(define_attr "in_delay_slot" "yes,no"
 (eq_attr "type" "fpscr_toggle") (const_string "no")

is changed to "yes", the delay-branch will not consider multiple-set insns. 
The "toggle_pr" insn used to be a single set, but now is a multiple-set.

[Bug target/65283] [SH] lds fpscr not put in delay slot

[chrbr at gcc dot gnu.org]

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

--- Comment #4 from chrbr at gcc dot gnu.org ---
yes it's only for the SH4A fpchg case

[Bug target/65283] [SH] lds fpscr not put in delay slot

[chrbr at gcc dot gnu.org]

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

--- Comment #5 from chrbr at gcc dot gnu.org ---
ah I see, I was on the 4.8 where toggle_pr was indeed a single pattern.

[Bug rtl-optimization/66237] [6 regression] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE (internal compiler error)

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-05-21
   Assignee|unassigned at gcc dot gnu.org  |miyuki at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Mikhail Maltsev  ---
I could reproduce this ICE in somewhat "unnatural" conditions: profile is
generated by an x86_64 executable and used by aarch64 cross-compiler, but the
backtraces match, so I can start fixing it (and setting up QEMU...). If
possible, could you provide the actual profile (.gcda file) generated after
pr34999.x01 invocation? Does it differ from pristine build?

[Bug rtl-optimization/66237] [6 regression] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE (internal compiler error)

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

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

--- Comment #2 from Andreas Schwab  ---
Created attachment 35589
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35589&action=edit
pr34999.gcda

[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved

[vehre at gcc dot gnu.org]

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

--- Comment #5 from vehre at gcc dot gnu.org ---
Let's have a look at the standard (F2008, 12.8.2, last sentence):

In the array case, the values of the elements, if any, of the result are
the same as would have been obtained if the scalar function had been applied
separately, in array element order, to corresponding elements of each array
actual argument.

How is this to be interpreted?

This way (pseudo-notation):

(c(i)= plus(c(1), b(i)), i = 1, size(c))

If like above, then the output would be

20, 27, 27, 27, 27

which is what is emitted, when the patch of comment #1 is not applied.

Or like this?

t = c(1)
(c(i) = plus(t, b(i)), i = 1, size(c))

which emits

20, 20, 20, 20, 20

But why is the second version expected, when one formulates this kind of
rhs/lhs dependency? I think the first example is covered by the standard, but I
am not happy with it, because it is not what I would expect, when writing the
code. 

So what do you think?
A third approach could be to add a warning for this kind of lhs/rhs dependency.
How hard would the analysis be?

[Bug rtl-optimization/66237] [6 regression] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE (internal compiler error)

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

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

--- Comment #3 from Andreas Schwab  ---
The profile files differ in a few bytes.

  9  17 ^O   265 M-5
 10 217 M-^O  44 $
 11 323 M-S  301 M-A
 12 166 v165 u
 21 146 f376 M-~
 22 213 M-^K 233 M-^[
 23 166 v 32 ^Z
 24  14 ^L   107 G

[Bug fortran/66244] New: ICE in lhd_set_decl_assembler_name

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

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

Bug ID: 66244
   Summary: ICE in lhd_set_decl_assembler_name
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This code snippet ...
   program p
  integer, target :: a(3)
  integer, pointer :: z => a(3)
  z = 0
  print *, z
   end

yields (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit)
f951: internal compiler error: in lhd_set_decl_assembler_name, at
langhooks.c:179

[Bug c++/66243] enum class value is allowed to be initialized by value from other enum class

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-21
 Ever confirmed|0   |1

[Bug fortran/66245] New: ICE on select type with empty type spec

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

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

Bug ID: 66245
   Summary: ICE on select type with empty type spec
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This test case with an empty type selector (type is) ...
   program p
  type t; end type
  class(t), allocatable :: x
  call s
   contains
  subroutine s
 select type ( x )
 type is ( )
 end select
  end
   end

and this variation (class is) ...
   program p
  type t; end type
  class(t), allocatable :: x
  call s
   contains
  subroutine s
 select type ( x )
 class is ( )
 end select
  end
   end

yields (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit)
f951: internal compiler error: gfc_get_default_type(): Bad symbol
'__tmp_UNKNOWN_0'

[Bug target/51726] LTO and attribute 'selectany'

[jacek at codeweavers dot com]

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

Jacek Caban  changed:

   What|Removed |Added

 CC||jacek at codeweavers dot com

--- Comment #5 from Jacek Caban  ---
It seems like selectany is not supported at all in LTO:

$ cat selectany.c 
__attribute__((selectany)) int i = 0;

$ i686-w64-mingw32-gcc selectany.c selectany.c -flto -shared
/tmp/cchTGZVt.o (symbol from plugin):(.text+0x0): multiple definition of `i'
/tmp/ccAy2OzL.o (symbol from plugin):(.text+0x0): first defined here
collect2: error: ld returned 1 exit status

$ i686-w64-mingw32-gcc --version
i686-w64-mingw32-gcc (GCC) 5.1.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Should I file separated bug?

[Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #24 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #23)
> Ouch.  The peephole in problem was added at gcc-5 not at 4.9.  The above
> patch should fix the original conftest.c issue, but debien 4.9-16 problem
> would be an another issue.  Sorry for my confusion.

I am partially to be blamed for that. I initially reported the gcc-5 issue
here, then saw gcc-4.9 failed to build as well and then assumed both were the
same problem.

But in any case, I am super happy you guys are fixing this. I will be back in
Japan in October, so if I have a chance to meet either of you, I owe you some
beer/sake/wine etc :).

Thanks!

[Bug libgcc/66212] Exception handling broken on powerpc

[andri.yngvason at marel dot com]

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

Andri Yngvason  changed:

   What|Removed |Added

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

--- Comment #4 from Andri Yngvason  ---
I downloaded everything again and started from scratch. I've no idea what was
wrong but now the problem is gone. Mea culpa.

[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved

[mikael at gcc dot gnu.org]

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

--- Comment #6 from Mikael Morin  ---
(In reply to vehre from comment #5)

For the interpretation of (intrinsic) assignment, you have to look at
7.2.1.3:

> The execution of the assignment shall have the same effect as if the
> evaluation of expr and the evaluation of all expressions in variable
> occurred before any portion of the variable is defined by the assignment

This, together with what you already quoted:

> Let's have a look at the standard (F2008, 12.8.2, last sentence):
> 
> In the array case, the values of the elements, if any, of the result are
> the same as would have been obtained if the scalar function had been applied
> separately, in array element order, to corresponding elements of each array
> actual argument.
> 

gives as interpretation:

((i)= plus(c(1), b(i)), i = 1, size(c))
(c(i) = (i), i=1,size(c))

which gives the same result as your second interpretation.

[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved

[vehre at gcc dot gnu.org]

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

--- Comment #7 from vehre at gcc dot gnu.org ---
Ah, ok, which opens the question why that isn't done?

[Bug preprocessor/66246] New: PCH breaks preprocessor

[kai-bugs at cats dot ms]

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

Bug ID: 66246
   Summary: PCH breaks preprocessor
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kai-bugs at cats dot ms
  Target Milestone: ---

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

Test consists of:
- make sure we have no PCH
- compile the source w/o PCH
- compile the PCH
- compile the source w/PCH

As far as I can tell, the reason for the problems is that macros no longer get
expanded

If it matters, this is from the MinGW packaged with Qt 5.4.

$ cat t.sh
#! /bin/bash -x

gcc --version
rm th.hh.gch
g++ -Winvalid-pch -c -save-temps test.cc
g++ -x c++-header -c -save-temps th.hh
g++ -Winvalid-pch -c -save-temps test.cc

$ ./t.sh
+ gcc --version
gcc.exe (i686-posix-dwarf-rev2, Built by MinGW-W64 project) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

+ rm th.hh.gch
+ g++ -Winvalid-pch -c -save-temps test.cc
+ g++ -x c++-header -c -save-temps th.hh
+ g++ -Winvalid-pch -c -save-temps test.cc
In file included from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/_mingw.h:13:0,
 from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:10,
 from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/assert.h:15,
 from test.cc:4:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/_mingw_secapi.h:51:10: error:
redefinition of 'struct __if_array'
   struct __if_array  {
  ^
In file included from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/_mingw.h:13:0,
 from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:10,
 from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/assert.h:15,
 from th.hh:1:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/_mingw_secapi.h:51:10: error:
previous definition of 'struct __if_array'
   struct __if_array  {
  ^
In file included from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:10:0,
 from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/assert.h:15,
 from test.cc:4:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/_mingw.h: In function 'void
__debugbreak()':
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/_mingw.h:657:101: error:
redefinition of 'void __debugbreak()'
 __MINGW_INTRIN_INLINE void __cdecl __debugbreak(void)
   
 ^
In file included from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:10:0,
 from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/assert.h:15,
 from th.hh:1:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/_mingw.h:657:101: note: 'void
__debugbreak()' previously defined here
 __MINGW_INTRIN_INLINE void __cdecl __debugbreak(void)
   
 ^
In file included from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/assert.h:15:0,
 from test.cc:4:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h: At global scope:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:159:16: error:
redefinition of 'struct localeinfo_struct'
 typedef struct localeinfo_struct {
^
In file included from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/assert.h:15:0,
 from th.hh:1:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:159:16: error:
previous definition of 'struct localeinfo_struct'
 typedef struct localeinfo_struct {
^
In file included from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/assert.h:15:0,
 from test.cc:4:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:162:18: error:
invalid type in declaration before ',' token
 } _locale_tstruct,*_locale_t;
  ^
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:162:18: error:
conflicting declaration 'typedef int _locale_tstruct'
In file included from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/assert.h:15:0,
 from th.hh:1:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:162:3: note:
previous declaration as 'typedef struct localeinfo_struct _locale_tstruct'
 } _locale_tstruct,*_locale_t;
   ^
In file included from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/assert.h:15:0,
 from test.cc:4:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:162:20: error:
conflicting declaration 'typedef int* _locale_t'
 } _locale_tstruct,*_locale_t;
^
In 

[Bug c++/66239] Unoptimized sqrt(float or double) returns wrong values for ARM Cortex-A8 -mfloat-abi=[soft,softfp]

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #2 from Ramana Radhakrishnan  ---
(In reply to Maciej Andrzejewski from comment #1)
> It is getting even more interesting.
> 
> I have disassabled 4 binaries compiled with options:
> 1) -mfloat-abi=softfp
> 2) -mfloat-abi=softfp -O
> 3) -mfloat-abi=hard
> 4) -mfloat-abi=hard -O
> 
> and from what I understand if we turn ON the optimization the FPU is turned
> OFF!
> I dont see in assembler that FPU s** registers are used in those two cases
> where optimization is turned on:

Yeah it's called constant folding in the compiler. Why make the cpu do more
work at run time when the compiler can statically tell you the value for sqrt
of a floating point value. The cycles spent in compiling with -O have to give
you some value surely ... :)

I have no idea why your -O0 case fails though, offhand.

Ramana


> 
> -- DISASSAMBLE OPTION 1 --
> 00010570 :
>10570: e92d4800push{fp, lr}
>10574: e28db004add fp, sp, #4
>10578: e24dd040sub sp, sp, #64 ; 0x40
>1057c: e3032333movwr2, #13107  ; 0x
>10580: e3432333movtr2, #13107  ; 0x
>10584: e303movwr3, #13107  ; 0x
>10588: e3443022movtr3, #16418  ; 0x4022
>1058c: e14b20fcstrdr2, [fp, #-12]
>10590: ed5b0b03vldrd16, [fp, #-12]
>10594: eef77be0vcvt.f32.f64s15, d16
>10598: ee170a90vmovr0, s15
>1059c: eba1bl  10428 
>105a0: ee070a90vmovs15, r0
>105a4: eef70ae7vcvt.f64.f32d16, s15
>105a8: ed4b0b05vstrd16, [fp, #-20] ; 0xffec
>105ac: e30006ccmovwr0, #1740   ; 0x6cc
>105b0: e341movtr0, #1
>105b4: e14b21d4ldrdr2, [fp, #-20]  ; 0xffec
>105b8: eba0bl  10440 
>105bc: e309399amovwr3, #39322  ; 0x999a
>105c0: e3443111movtr3, #16657  ; 0x4111
>105c4: e50b3018str r3, [fp, #-24]  ; 0xffe8
>105c8: e51b0018ldr r0, [fp, #-24]  ; 0xffe8
>105cc: eb95bl  10428 
>105d0: ee070a90vmovs15, r0
>105d4: eef70ae7vcvt.f64.f32d16, s15
>105d8: ed4b0b09vstrd16, [fp, #-36] ; 0xffdc
>105dc: e30006ccmovwr0, #1740   ; 0x6cc
>105e0: e341movtr0, #1
>105e4: e14b22d4ldrdr2, [fp, #-36]  ; 0xffdc
>105e8: eb94bl  10440 
>105ec: e3032333movwr2, #13107  ; 0x
>105f0: e3432333movtr2, #13107  ; 0x
>105f4: e303movwr3, #13107  ; 0x
>105f8: e3443022movtr3, #16418  ; 0x4022
>105fc: e14b22fcstrdr2, [fp, #-44]  ; 0xffd4
>10600: e14b02dcldrdr0, [fp, #-44]  ; 0xffd4
>10604: eb8abl  10434 
>10608: e14b03f4strdr0, [fp, #-52]  ; 0xffcc
>1060c: e30006ccmovwr0, #1740   ; 0x6cc
>10610: e341movtr0, #1
>10614: e14b23d4ldrdr2, [fp, #-52]  ; 0xffcc
>10618: eb88bl  10440 
>1061c: e309399amovwr3, #39322  ; 0x999a
>10620: e3443111movtr3, #16657  ; 0x4111
>10624: e50b3038str r3, [fp, #-56]  ; 0xffc8
>10628: ed5b7a0evldrs15, [fp, #-56] ; 0xffc8
>1062c: eef70ae7vcvt.f64.f32d16, s15
>10630: ec510b30vmovr0, r1, d16
>10634: eb7ebl  10434 
>10638: e14b04f4strdr0, [fp, #-68]  ; 0xffbc
>1063c: e30006ccmovwr0, #1740   ; 0x6cc
>10640: e341movtr0, #1
>10644: e14b24d4ldrdr2, [fp, #-68]  ; 0xffbc
>10648: eb7cbl  10440 
>1064c: e3a03000mov r3, #0
>10650: e1a3mov r0, r3
>10654: e24bd004sub sp, fp, #4
>10658: e8bd8800pop {fp, pc}
> -- DISASSAMBLE OPTION 1 --
> 
> 
> 
> -- DISASSAMBLE OPTION 2 --
> 000104f4 :
>104f4: e92d40d0push{r4, r6, r7, lr}
>104f8: e30045d4movwr4, #1492   ; 0x5d4
>104fc: e3404001movtr4, #1
>10500: e3a06000mov r6, #0
>10504: e302720amovwr7, #8714   ; 0x220a
>10508: e3447008

[Bug preprocessor/66246] PCH breaks preprocessor

[kai-bugs at cats dot ms]

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

--- Comment #1 from kai-bugs at cats dot ms ---
Created attachment 35591
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35591&action=edit
Source

[Bug target/66232] -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
(In reply to H.J. Lu from comment #2)
> Created attachment 35585 [details]
> A patch
> 
> I am testing this.

It failed this:

[hjl@gnu-6 pr66232]$ cat x.c
extern void (*bar) (void);
void
foo (int n)
{
  int i;
  for (i = 0; i < n; i++)
{
  if (!bar)
continue;
  (*bar) ();
}
}
[hjl@gnu-6 pr66232]$ make
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc -fPIC -O -mx32 -S -o x.s x.c
x.c: In function ‘foo’:
x.c:12:1: error: unable to generate reloads for:
 }
 ^
(call_insn 17 15 18 5 (call (mem:QI (zero_extend:DI (reg/f:SI 87 [ D.1845 ]))
[0 *_6 S1 A8])
(const_int 0 [0])) x.c:10 651 {*call_x32}
 (expr_list:REG_DEAD (reg/f:SI 87 [ D.1845 ])
(nil))
(nil))
x.c:12:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:3488
0xcf0c1e _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/export/gnu/import/git/sources/gcc/gcc/rtl-error.c:110
0xbc6dec curr_insn_transform
/export/gnu/import/git/sources/gcc/gcc/lra-constraints.c:3488
0xbc9c6c lra_constraints(bool)
/export/gnu/import/git/sources/gcc/gcc/lra-constraints.c:4436
0xbb6074 lra(_IO_FILE*)
/export/gnu/import/git/sources/gcc/gcc/lra.c:2317
0xb64a10 do_reload
/export/gnu/import/git/sources/gcc/gcc/ira.c:5412
0xb64dbe execute
/export/gnu/import/git/sources/gcc/gcc/ira.c:5583
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [x.s] Error 1
[hjl@gnu-6 pr66232]$

[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved

[mikael at gcc dot gnu.org]

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

--- Comment #8 from Mikael Morin  ---
(In reply to vehre from comment #7)
> Ah, ok, which opens the question why that isn't done?

Performance, for (very) big arrays.