[Bug target/59385] gcc 4.9 fails to use fma with __attribute__((target("fma")))

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59385

Uroš Bizjak  changed:

   What|Removed |Added

 CC||tmsriram at google dot com

--- Comment #2 from Uroš Bizjak  ---
Adding CC.

[Bug target/59390] presence of __attribute__((target("fma"))) declaration breaks __builtin_fma

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59390

Uroš Bizjak  changed:

   What|Removed |Added

 CC||tmsriram at google dot com

--- Comment #1 from Uroš Bizjak  ---
Adding CC.

[Bug c/47435] [4.7 Regression] ICE: SIGSEGV in c_finish_case (c-typeck.c:8859) on invalid code

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47435

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
Version|4.6.0   |4.7.3
Summary|[4.7/4.8/4.9 Regression]|[4.7 Regression] ICE:
   |ICE: SIGSEGV in |SIGSEGV in c_finish_case
   |c_finish_case   |(c-typeck.c:8859) on
   |(c-typeck.c:8859) on|invalid code
   |invalid code|

--- Comment #9 from Marek Polacek  ---
This doesn't seem to ICE anymore with 4.8/trunk.

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379

--- Comment #8 from H.J. Lu  ---
(In reply to H.J. Lu from comment #7)
> r202807 can bootstrap.  But r202811 failed with
> 
> The only difference in GCC source is:
> 
> diff --git a/gcc/DATESTAMP b/gcc/DATESTAMP
> index 0f54f2b..b7c5255 100644
> --- a/gcc/DATESTAMP
> +++ b/gcc/DATESTAMP
> @@ -1 +1 @@
> -20130920
> +20130921

This may not be related to this bug.

[Bug target/59222] [4.9 Regression] gcc.c-torture/compile/20050622-1.c ICEs at -O1 and above for aarch64-elf ILP32

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59222

Andrew Pinski  changed:

   What|Removed |Added

Summary|[4.9 Regression]|[4.9 Regression]
   |gcc.c-torture/compile/20050 |gcc.c-torture/compile/20050
   |622-1.c ICEs at -O1 and |622-1.c ICEs at -O1 and
   |abiove for aarch64-elf  |above for aarch64-elf ILP32
   |ILP32   |

--- Comment #3 from Andrew Pinski  ---
(gdb) p icode
$1 = CODE_FOR_addsi3
(gdb) p debug_rtx(x)
(reg:SI 86)
$2 = void
(gdb) p debug_rtx(y)
(const_int 75497488 [0x4800010])

[Bug target/59375] internal compiler error: in expand_shift_1, at expmed.c:2245

[iwamatsu at nigauri dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59375

--- Comment #4 from Nobuhiro Iwamatsu  ---
Oleg and Kojima-san, thanks for your work.

Yes, I was building on SH native.
And I am using gcc 4.6.3 version in the host.

[Bug target/59393] New: [4.8/4.9 regression] mips16 code size

[sandra at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393

Bug ID: 59393
   Summary: [4.8/4.9 regression] mips16 code size
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at codesourcery dot com

Created attachment 31383
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31383&action=edit
bf_enc.i

The attached test case (part of blowfish) is compiled for MIPS16 with

-Os -DNDEBUG -fno-schedule-insns2  -mno-check-zero-division -fno-common 
-fsection-anchors -fno-shrink-wrap -ffunction-sections -mips16

In GCC 4.7, this produced 2152 bytes of code.

In GCC 4.8, it produces 2396 bytes.  On mainline head, it's 2384.  In both
cases, the code growth is coming from reload blowing up.

I tracked the 4.8 regression down to two distinct changes:

(1) This patch for PR54109
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00617.html
removed forward-propagation of constant offsets into address expressions.  No
subsequent pass is making that optimization so the code requires one extra
register that is live essentially through the whole function by the time it
gets to reload.

(2) The hoist pass seems to be significantly underestimating register pressure
and adds 9 more pseudos with long lifetimes.  (This might be a red herring, but
why is it only considering GR_REGS as a pressure class and not M16_REGS?)

By reverting the above patch and disabling the hoist pass, I was able to get
the same code size on 4.8 as 4.7.  On mainline head, there's something else
going on as well, as this brought the code size down only halfway, to 2280
bytes.  I haven't yet analyzed where the remaining bad code is coming from, but
if I had to make a wild stab in the dark, I'd guess that if the register
pressure calculation is wrong in hoist it may be wrong in other places as well.

In any case, reverting a patch that fixes a correctness bug and disabling the
hoist pass is clearly not an acceptable solution.  Any suggestions on the
"right" way to fix the two already-identified problems?

[Bug fortran/40756] Cleanup TREE_BLOCK

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40756

Bug 40756 depends on bug 37132, which changed state.

Bug 37132 Summary: Debug: No DW_TAG_namelist emitted for NAMELISTS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37132

   What|Removed |Added

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

[Bug fortran/24546] [meta-bug] gfortran debugging problems

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546

Bug 24546 depends on bug 37132, which changed state.

Bug 37132 Summary: Debug: No DW_TAG_namelist emitted for NAMELISTS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37132

   What|Removed |Added

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

[Bug debug/37132] Debug: No DW_TAG_namelist emitted for NAMELISTS

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37132

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #7 from Tobias Burnus  ---
FIXED on the 4.9 trunk.

[Bug middle-end/58809] [4.7/4.8/4.9 Regression] ICE with complex variable in OpenMP reduction clause

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58809

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #7 from Tobias Burnus  ---
[second test case]
(In reply to Volker Reichelt from comment #0)
> A similar code snippet triggers an ICE in a different position on trunk:

Reduced example:

void foo()
{
  _Complex int j;
#pragma omp parallel reduction (&:j)
  ;
}


I wonder whether it is valid as the following is rejected with "error: invalid
operands to binary & (have 'complex int' and 'complex int')":

_Complex int foo(_Complex int j)
{
  _Complex int k = -1;
  j &=  k;
}

[Bug target/59222] [4.9 Regression] gcc.c-torture/compile/20050622-1.c ICEs at -O1 and abiove for aarch64-elf ILP32

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59222

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0
Summary|gcc.c-torture/compile/20050 |[4.9 Regression]
   |622-1.c ICEs at -O1 and |gcc.c-torture/compile/20050
   |abiove for aarch64-elf  |622-1.c ICEs at -O1 and
   |ILP32   |abiove for aarch64-elf
   ||ILP32

--- Comment #2 from Andrew Pinski  ---
Full backtrace:
(gdb) bt
#0  fancy_abort (file=0xe48128
"/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/optabs.c",
line=4716, function=0xe48c0a "gen_add2_insn")
at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/diagnostic.c:1182
#1  0x007b44ce in gen_add2_insn (x=0x77e50ca0, y=0x77e49800) at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/optabs.c:4716
#2  0x00755b53 in emit_add2_insn (x=0x77e50ca0, y=0x77e49800)
at /data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/lra.c:277
#3  0x00758db5 in lra_emit_add (x=0x77e50ca0, y=0x77a69108,
z=0x77e49800) at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/lra.c:354
#4  0x00768922 in curr_insn_transform () at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/lra-constraints.c:3507
#5  0x0076a215 in lra_constraints (first_p=) at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/lra-constraints.c:4049
#6  0x00757e86 in lra (f=) at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/lra.c:2331
#7  0x0071cc27 in do_reload (this=) at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/ira.c:5451
#8  rest_of_handle_reload (this=) at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/ira.c:5580
#9  execute (this=) at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/ira.c:5609
#10 0x007d499a in execute_one_pass (pass=0x13c19e0) at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/passes.c:2215
#11 0x007d4c26 in execute_pass_list (pass=0x13c19e0) at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/passes.c:2268
#12 0x007d4c38 in execute_pass_list (pass=0x13c0900) at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/passes.c:2269
#13 0x0055fe39 in expand_function (node=0x77c667b0) at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/cgraphunit.c:1763
#14 0x00561ce1 in expand_all_functions () at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/cgraphunit.c:1868
#15 compile () at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/cgraphunit.c:2203
#16 0x0056338a in finalize_compilation_unit () at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/cgraphunit.c:2280
#17 0x004143a3 in c_write_global_declarations () at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/c/c-decl.c:10399
#18 0x0087463d in compile_file () at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/toplev.c:561
#19 0x00875816 in do_compile (argc=4, argv=0x7fffe0f8) at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/toplev.c:1887
#20 toplev_main (argc=4, argv=0x7fffe0f8) at
/data1/src/gcc-cavium/toolchain-thunder/scripts/../src/gcc/toplev.c:1963
#21 0x00d51fee in __libc_start_main ()
#22 0x00400349 in _start ()

So this is a LRA related failure.

[Bug libstdc++/59392] crash on throw from "unexpected exception" handler with ARM EABI unwinder

[mseaborn at chromium dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59392

Mark Seaborn  changed:

   What|Removed |Added

 CC||mseaborn at chromium dot org

--- Comment #1 from Mark Seaborn  ---
Instead of:

  if (catch_type->__do_catch(&bad_exc, NULL, 1))

I think this should be:

  // We don't have a thrown object to compare against, but since
  // bad_exception doesn't have virtual bases, that's OK; just pass 0.
  void *obj = NULL;
  if (catch_type->__do_catch(&bad_exc, &obj, 1))

or to avoid the comment, just:

  std::bad_exception ex;
  void *obj = &ex;
  if (catch_type->__do_catch(&typeid(ex), &obj, 1))

The non-EABI equivalent is the second check_exception_spec() call in
__cxa_call_unexpected() in eh_personality.cc.

[Bug target/59375] internal compiler error: in expand_shift_1, at expmed.c:2245

[kkojima at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59375

--- Comment #3 from Kazumoto Kojima  ---
All my 4.8 cross compilers including 4.8.2 and 4.8.3 don't fail
with ccFujO37.out.  Maybe a host compiler's problem.
Iwamatsu-san, which host compiler did you use?
Perhaps SH native one?

[Bug libstdc++/59392] New: crash on throw from "unexpected exception" handler with ARM EABI unwinder

[roland at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59392

Bug ID: 59392
   Summary: crash on throw from "unexpected exception" handler
with ARM EABI unwinder
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland at gnu dot org
Target: arm-linux-gnueabihf

Created attachment 31382
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31382&action=edit
test case

I've observed this on trunk and on 4.6.3, but I think the bug has been there
since the introduction of ARM EABI unwinding in 4.2.

The attached test case crashes with a null pointer dereference (producing no
output) on ARM/EABI targets.  On other targets (I only tested
x86_64-linux-gnu), it correctly crashes via abort after emitting a message
(i.e. std::terminate runs).  The original case was more complex and used
std::set_terminate to set a handler that used longjmp, avoiding the abort.  For
the test suite, it's probably most convenient to do that (or just exit with an
expected code in the terminate handler) rather than to detect that the default
std::terminate crash happened correctly vs a different crash.

The bug comes about in an obvious and straightforward way.  But I don't know
the libsupc++ internals well enough to suggest an appropriate fix off hand. 
What happens is that libstdc++-v3/libsupc++/eh_call.cc:__cxa_call_unexpected
does:
  if (catch_type->__do_catch(&bad_exc, 0, 1))
i.e., passes a null pointer as the second argument to the __do_catch method.
libstdc++-v3/libsupc++/class_type_info.cc:__do_catch passes this argument on as
the second argument to __do_upcast.
In libstdc++-v3/libsupc++/class_type_info.cc:__do_upcast there is:
  __do_upcast (dst_type, *obj_ptr, result);
i.e., unconditionally dereferencing OBJ_PTR (the second argument).

I'd like to see this get fixed on the trunk and 4.8 at least.
I'd be glad to pursue the fix myself if I had any idea what it should be.

[Bug c++/58567] [4.8/4.9 Regression] ICE with invalid loop variable in template using openmp

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58567

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #3 from Tobias Burnus  ---
Lightly tested patch:

--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -13037,2 +13037,6 @@ tsubst_omp_for_iterator (tree t, int i, tree declv,
   decl = RECUR (decl);
+
+  if (decl == error_mark_node)
+return;
+
   if (init_decl)

[Bug tree-optimization/59388] [4.7/4.8/4.9 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59388

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|[4.9 Regression] ICE on |[4.7/4.8/4.9 Regression]
   |valid code at -O1 and above |ICE on valid code at -O1
   |on x86_64-linux-gnu |and above on
   ||x86_64-linux-gnu

--- Comment #2 from Jakub Jelinek  ---
Likely introduced in r179388.

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379

--- Comment #7 from H.J. Lu  ---
r202807 can bootstrap.  But r202811 failed with

[hjl@gnu-mic-2 libgcc]$
/export/build/gnu/gcc-lto-fdo/build-x86_64-linux/./gcc/xgcc
-B/export/build/gnu/gcc-lto-fdo/build-x86_64-linux/./gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include-g -O2 -m32 -O2  -g -O2
-DIN_GCC   -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fpic -mlong-double-80 -I. -I. -I../../.././gcc
-I/export/gnu/import/git/gcc/libgcc -I/export/gnu/import/git/gcc/libgcc/.
-I/export/gnu/import/git/gcc/libgcc/../gcc
-I/export/gnu/import/git/gcc/libgcc/../include
-I/export/gnu/import/git/gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS  -DUSE_TLS -o unwind-dw2-fde-dip.o -MT unwind-dw2-fde-dip.o -MD
-MP -MF unwind-dw2-fde-dip.dep -fexceptions -c
/export/gnu/import/git/gcc/libgcc/unwind-dw2-fde-dip.c -fvisibility=hidden
-DHIDE_EXPORTS
In file included from
/export/gnu/import/git/gcc/libgcc/unwind-dw2-fde-dip.c:89:0:
/export/gnu/import/git/gcc/libgcc/unwind-dw2-fde.c: In function
‘classify_object_over_fdes’:
/export/gnu/import/git/gcc/libgcc/unwind-dw2-fde.c:660:1: internal compiler
error: Segmentation fault
 }
 ^
0x5eb5ce crash_signal
/export/gnu/import/git/gcc/gcc/toplev.c:335
0x931cb3 htab_find_slot_with_hash
/export/gnu/import/git/gcc/libiberty/hashtab.c:655
0x931cb3 gen_rtx_CONST_INT
/export/gnu/import/git/gcc/gcc/emit-rtl.c:410
0x931cb3 gen_int_mode
/export/gnu/import/git/gcc/gcc/emit-rtl.c:420
0x931cb3 get_mode_bounds(machine_mode, int, machine_mode, rtx_def**, rtx_def**)
/export/gnu/import/git/gcc/gcc/stor-layout.c:2840
0x95245e simplify_const_relational_operation(rtx_code, machine_mode, rtx_def*,
rtx_def*)
/export/gnu/import/git/gcc/gcc/simplify-rtx.c:5151
0x9525ab simplify_const_relational_operation(rtx_code, machine_mode, rtx_def*,
rtx_def*)
/export/gnu/import/git/gcc/gcc/simplify-rtx.c:5006
0x95b364 simplify_relational_operation(rtx_code, machine_mode, machine_mode,
rtx_def*, rtx_def*)
/export/gnu/import/git/gcc/gcc/simplify-rtx.c:4602
0x7a6dd2 fold_rtx
/export/gnu/import/git/gcc/gcc/cse.c:3378
0x7a7046 fold_rtx
/export/gnu/import/git/gcc/gcc/cse.c:3209
0x7aa6aa cse_insn
/export/gnu/import/git/gcc/gcc/cse.c:4578
0x7af736 cse_extended_basic_block
/export/gnu/import/git/gcc/gcc/cse.c:6410
0x7af736 cse_main(rtx_def*, int) [clone .isra.18]
/export/gnu/import/git/gcc/gcc/cse.c:6588
0xf5394b rest_of_handle_cse
/export/gnu/import/git/gcc/gcc/cse.c:7438
0xf5394b (anonymous namespace)::pass_cse::execute() [clone .lto_priv.9491]
/export/gnu/import/git/gcc/gcc/cse.c:7484
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The only difference in GCC source is:

diff --git a/gcc/DATESTAMP b/gcc/DATESTAMP
index 0f54f2b..b7c5255 100644
--- a/gcc/DATESTAMP
+++ b/gcc/DATESTAMP
@@ -1 +1 @@
-20130920
+20130921

[Bug tree-optimization/59388] [4.9 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59388

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/59222] gcc.c-torture/compile/20050622-1.c ICEs at -O1 and abiove for aarch64-elf ILP32

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59222

Andrew Pinski  changed:

   What|Removed |Added

Summary|gcc.c-torture/compile/20050 |gcc.c-torture/compile/20050
   |622-1.c ICEs at -O1 and |622-1.c ICEs at -O1 and
   |abiove for aarch64-elf  |abiove for aarch64-elf
   ||ILP32

--- Comment #1 from Andrew Pinski  ---
This only happens with ILP32, I had originally misconfigured my compiler to
default to ILP32.

[Bug c/52023] [C11] _Alignof (double) yields wrong value on x86

[jsm28 at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

Joseph S. Myers  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug libstdc++/59391] std::sort will go out of std::vector bounds and crash

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59391

--- Comment #2 from Andrew Pinski  ---
Works for me in gcc version 4.9.0 20131026 (experimental) [trunk revision
204095] (GCC) 


Can you try a newer version as 4.4 is no longer supported.

[Bug c/52023] [C11] _Alignof (double) yields wrong value on x86

[jsm28 at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #14 from Joseph S. Myers  ---
Fixed for 4.9.  The semantics of __alignof__ and C++11 alignof remain,
deliberately, the alignment used outside structures.

[Bug c/52023] [C11] _Alignof (double) yields wrong value on x86

[jsm28 at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

--- Comment #13 from Joseph S. Myers  ---
Author: jsm28
Date: Wed Dec  4 22:57:20 2013
New Revision: 205685

URL: http://gcc.gnu.org/viewcvs?rev=205685&root=gcc&view=rev
Log:
PR c/52023
c-family:
* c-common.c (c_sizeof_or_alignof_type): Add parameter min_alignof
and check field alignment if set.
* c-common.h (c_sizeof_or_alignof_type): Update prototype.
(c_sizeof, c_alignof): Update calls to c_sizeof_or_alignof_type.

c:
* c-parser.c (c_parser_alignas_specifier): Use
c_sizeof_or_alignof_type instead of c_alignof.
(c_parser_alignof_expression): Likewise, with min_alignof
parameter depending on alignof spelling used.

cp:
* typeck.c (cxx_sizeof_or_alignof_type): Update call to
c_sizeof_or_alignof_type.

objc:
* objc-act.c (objc_synthesize_getter): Update calls to
c_sizeof_or_alignof_type.

testsuite:
* gcc.dg/c11-align-6.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/c11-align-6.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/objc/ChangeLog
trunk/gcc/objc/objc-act.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/59391] std::sort will go out of std::vector bounds and crash

[awwafa at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59391

--- Comment #1 from Ahmed Wafa  ---
// The following is shortest array that will reproduce that problem
const int int_array[] = {1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2};

[Bug libstdc++/59391] New: std::sort will go out of std::vector bounds and crash

[awwafa at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59391

Bug ID: 59391
   Summary: std::sort will go out of std::vector bounds and crash
   Product: gcc
   Version: 4.4.6
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: awwafa at gmail dot com

$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC)

--- gcc switches used -
g++  -o sort_test.o  -c sort_test.cxx
g++  -o sort_test  sort_test.o

 sort_test.cxx-
#include 
#include 

bool compare_val(int* a, int* b) {
   if (*a <= *b) return true;
   return false;
}
int main (void) {

  const int int_array[] = {12, 13, 2, 2, 6, 7, 12, 2, 10, 11, 16, 5, 5, 2, 16,
7, 6, 16, 14, 5, 10, 9, 14, 3, 7, 15, 14, 6, 2, 1, 11, 13, 14, 12, 15, 4, 3,
11, 5, 12, 5, 5, 1, 9, 6, 16, 15, 11, 16, 13, 15, 10, 6, 13, 13, 12, 11, 10, 1,
13, 11, 11, 10, 9, 7, 8, 12, 10, 2};

   std::vector my_vec;
   int length = sizeof(int_array)/sizeof(int);
   for(int i=0; i < length; ++i) {
  int *int_ptr =new int;
  *int_ptr = int_array[i];
  my_vec.push_back(int_ptr);
   }
   std::sort(my_vec.begin(), my_vec.end(), compare_val);
}
 sort_test.cxx-


 Valgrind output -
==20061== Memcheck, a memory error detector
==20061== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==20061== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==20061== Command: ./sort_test
==20061== 
==20061== Invalid read of size 8
==20061==at 0x40159E: __gnu_cxx::__normal_iterator > >
std::__unguarded_partition<__gnu_cxx::__normal_iterator > >, int*, bool (*)(int*,
int*)>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, int*, bool (*)(int*, int*)) (in
/home/awafa/tmp/std_sort_crash/sort_test)
==20061==by 0x4010B8: void
std::__introsort_loop<__gnu_cxx::__normal_iterator > >, long, bool (*)(int*,
int*)>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, long, bool (*)(int*, int*)) (in
/home/awafa/tmp/std_sort_crash/sort_test)
==20061==by 0x400B08: void std::sort<__gnu_cxx::__normal_iterator > >, bool (*)(int*,
int*)>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, bool (*)(int*, int*)) (in
/home/awafa/tmp/std_sort_crash/sort_test)
==20061==by 0x40092A: main (in /home/awafa/tmp/std_sort_crash/sort_test)
==20061==  Address 0x4a33a48 is 8 bytes before a block of size 1,024 alloc'd
==20061==at 0x490459B: operator new(unsigned long)
(vg_replace_malloc.c:220)
==20061==by 0x401844: __gnu_cxx::new_allocator::allocate(unsigned
long, void const*) (in /home/awafa/tmp/std_sort_crash/sort_test)
==20061==by 0x4012C9: std::_Vector_base
>::_M_allocate(unsigned long) (in /home/awafa/tmp/std_sort_crash/sort_test)
==20061==by 0x400D5A: std::vector
>::_M_insert_aux(__gnu_cxx::__normal_iterator > >, int* const&) (in
/home/awafa/tmp/std_sort_crash/sort_test)
==20061==by 0x400A73: std::vector
>::push_back(int* const&) (in /home/awafa/tmp/std_sort_crash/sort_test)
==20061==by 0x4008E1: main (in /home/awafa/tmp/std_sort_crash/sort_test)

[Bug c++/59389] [C++11] bogus error: call of overloaded ‘Foo()’ is ambiguous

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59389

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  ---
Even in the first case the diagnostic is quite poor compared with clang's
(location info included).

[Bug ada/59382] gnatmake is not able to compile libraries

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59382

Eric Botcazou  changed:

   What|Removed |Added

 Target||arm-linux
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
Summary|gnatmake is not able to |gnatmake is not able to
   |compile libraries on ARM|compile libraries
   |(native)|

--- Comment #4 from Eric Botcazou  ---
Thanks for reporting the problem.

[Bug ada/59382] gnatmake is not able to compile libraries on ARM (native)

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59382

--- Comment #3 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Dec  4 21:28:21 2013
New Revision: 205682

URL: http://gcc.gnu.org/viewcvs?rev=205682&root=gcc&view=rev
Log:
PR ada/59382
gnattools/
* configure.ac (target parameterization): Rewrite.
* configure: Regenerate.
gcc/ada/
* indepsw-darwin.adb: New file.

Added:
branches/gcc-4_8-branch/gcc/ada/indepsw-darwin.adb
  - copied unchanged from r205681, trunk/gcc/ada/indepsw-darwin.adb
Modified:
branches/gcc-4_8-branch/gcc/ada/ChangeLog
branches/gcc-4_8-branch/gnattools/ChangeLog
branches/gcc-4_8-branch/gnattools/configure
branches/gcc-4_8-branch/gnattools/configure.ac

[Bug ada/59382] gnatmake is not able to compile libraries on ARM (native)

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59382

--- Comment #2 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Dec  4 21:25:11 2013
New Revision: 205681

URL: http://gcc.gnu.org/viewcvs?rev=205681&root=gcc&view=rev
Log:
PR ada/59382
gnattools/
* configure.ac (target parameterization): Rewrite.
* configure: Regenerate.
gcc/ada/
* indepsw-darwin.adb: New file.

Added:
trunk/gcc/ada/indepsw-darwin.adb
Modified:
trunk/gcc/ada/ChangeLog
trunk/gnattools/ChangeLog
trunk/gnattools/configure
trunk/gnattools/configure.ac

[Bug c/54113] -Wmissing-prototypes produces false alarms for C99 inline functions

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54113

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed on trunk.

[Bug c/54113] -Wmissing-prototypes produces false alarms for C99 inline functions

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54113

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Wed Dec  4 21:15:31 2013
New Revision: 205680

URL: http://gcc.gnu.org/viewcvs?rev=205680&root=gcc&view=rev
Log:
PR c/54113
c/
* c-decl.c (start_function): Don't warn for missing prototype for
inline functions.
testsuite/
* gcc.dg/pr54113.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr54113.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706

[octoploid at yandex dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||octoploid at yandex dot com

--- Comment #2 from Markus Trippelsdorf  ---
(In reply to David Kredba from comment #1)
> I can reproduce this with Gentoo gcc-4.8.2 and new KDE's kig package 4.11.4.
> 
> How to debug this please?

http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction

[Bug target/59390] New: presence of __attribute__((target("fma"))) declaration breaks __builtin_fma

[jtaylor.debian at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59390

Bug ID: 59390
   Summary: presence of  __attribute__((target("fma")))
declaration breaks __builtin_fma
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jtaylor.debian at googlemail dot com

compiling this code leads to a compilation error on -O3:


#include "math.h"
void fun() __attribute__((target("fma")));

void 
other_fun(double *restrict out, double * restrict a, double * restrict b,
double * restrict c, int n)
{
int i;
for (i = 0; i < n; i++) {
out[i] = fma(a[i], b[i], c[i]);
}   
}

$ cc-4.9 fma.c -c -std=c99 -O3
fma.c: In function ‘other_fun’:
fma.c:9:21: error: ‘__builtin_ia32_vfmaddpd’ needs isa option -m32 -mfma4 -mfma
 out[i] = fma(a[i], b[i], c[i]);
 ^

removing the attribute from the unused declaration fixes it, as does using
-fno-builtin or a lower optimization level.

$ gcc-4.9 -v
Using built-in specs.
COLLECT_GCC=/home/jtaylor/tmp/gcc-local/bin/../bin/gcc
COLLECT_LTO_WRAPPER=/home/jtaylor/tmp/gcc-local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/jtaylor/tmp/gcc/configure
--enable-languages=c,c++,fortran --enable-tls
--prefix=/home/jtaylor/tmp/gcc-local --with-gmp=/usr --with-mpfr=/usr
--with-mpc=/usr --with-cloog=/usr --with-ppl=/usr --with-isl=/usr
Thread model: posix
gcc version 4.9.0 20131204 (experimental) (GCC)

also affects gcc 4.8.1

[Bug target/59375] internal compiler error: in expand_shift_1, at expmed.c:2245

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59375

Oleg Endo  changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu.org

--- Comment #2 from Oleg Endo  ---
I have tried this with 4.8.3 r205675 and my newlib cross config with the
following options:
-m4 -mb|-ml -O2 -g -fbuilding-libgcc -fno-stack-protector -fpic
-fvisibility=hidden -frandom-seed=0

and some other minor variations, but could not reproduce it.
Kaz, could you please also try it in your config?

[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706

[nheghathivhistha at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251

David Kredba  changed:

   What|Removed |Added

 CC||nheghathivhistha at gmail dot 
com

--- Comment #1 from David Kredba  ---
I can reproduce this with Gentoo gcc-4.8.2 and new KDE's kig package 4.11.4.

How to debug this please?

[Bug debug/37132] Debug: No DW_TAG_namelist emitted for NAMELISTS

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37132

--- Comment #6 from Tobias Burnus  ---
Author: burnus
Date: Wed Dec  4 19:59:42 2013
New Revision: 205679

URL: http://gcc.gnu.org/viewcvs?rev=205679&root=gcc&view=rev
Log:
gcc/
2013-12-04  Tobias Burnus  

PR debug/37132
* lto-streamer.h (LTO_tags): Add LTO_namelist_decl_ref.
* tree.def (NAMELIST_DECL): Add.
* tree.h (NAMELIST_DECL_ASSOCIATED_DECL): New macro.
* tree.c (initialize_tree_contains_struct): Add asserts for it.
* dwarf2out.c (gen_namelist_decl): New function.
(gen_decl_die, dwarf2out_decl): Call it.
(dwarf2out_imported_module_or_decl_1): Handle NAMELIST_DECL.
* lto-streamer-in.c (lto_input_tree_ref): Handle NAMELIST_DECL.
(lto_input_tree_ref, lto_input_tree_1): Update lto_tag_check_range
call.
* lto-streamer-out.c (lto_output_tree_ref): Handle
* NAMELIST_DECL.

gcc/fortran
2013-12-04  Tobias Burnus  

PR debug/37132
* trans-decl.c (generate_namelist_decl, create_module_nml_decl):
New static functions.
(gfc_generate_module_vars, generate_local_vars): Call them.
(gfc_trans_use_stmts): Handle namelists for debug genertion.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/lto-streamer-in.c
trunk/gcc/lto-streamer-out.c
trunk/gcc/lto-streamer.h
trunk/gcc/tree.c
trunk/gcc/tree.def
trunk/gcc/tree.h

[Bug c++/59389] [C++11] bogus error: call of overloaded ‘Foo()’ is ambiguous

[ppluzhnikov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59389

Paul Pluzhnikov  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #2 from Paul Pluzhnikov  ---
Here is the test that compiles with Clang but not GCC (added explicit to
Foo::Foo):

#include 
#include 
#include 

struct Foo {
  explicit Foo(const std::map>&
machines);
};

int main()
{
  Foo foo2({{"abc", {"aaa", "bbb"}}});  // OK
  Foo foo1({{"abc", {"aaa"}}}); // Error.
}

[Bug c++/59389] [C++11] bogus error: call of overloaded ‘Foo()’ is ambiguous

[ppluzhnikov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59389

Paul Pluzhnikov  changed:

   What|Removed |Added

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

--- Comment #1 from Paul Pluzhnikov  ---
Hmm, Clang also rejects this test:

t.cc:12:7: error: call to constructor of 'Foo' is ambiguous
  Foo foo1({{"abc", {"aaa"}}}); // Error.
  ^~~
t.cc:5:8: note: candidate is the implicit move constructor
struct Foo {
   ^
t.cc:5:8: note: candidate is the implicit copy constructor
t.cc:6:3: note: candidate constructor
  Foo(const std::map>&);
  ^
1 error generated.


I must have over-reduced the original.

[Bug c++/59389] New: [C++11] bogus error: call of overloaded ‘Foo()’ is ambiguous

[ppluzhnikov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59389

Bug ID: 59389
   Summary: [C++11] bogus error: call of overloaded
‘Foo()’ is ambiguous
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com

Google ref: b/11997192

Using current trunk:
g++ (GCC) 4.9.0 20131204 (experimental)

// --- cut ---
#include 
#include 
#include 

struct Foo {
  Foo(const std::map>&);
};

int main()
{
  Foo foo2({{"abc", {"aaa", "bbb"}}});  // OK
  Foo foo1({{"abc", {"aaa"}}}); // Error.
}
// --- cut ---

g++ -c -std=c++11 t.cc

t.cc: In function 'int main()':
t.cc:12:30: error: call of overloaded 'Foo()'
is ambiguous
   Foo foo1({{"abc", {"aaa"}}}); // Error.
  ^
t.cc:12:30: note: candidates are:
t.cc:6:3: note: Foo::Foo(const std::map,
std::vector > >&)
   Foo(const std::map>&);
   ^
t.cc:5:8: note: constexpr Foo::Foo(const Foo&)
 struct Foo {
^
t.cc:5:8: note: constexpr Foo::Foo(Foo&&)

[Bug tree-optimization/59388] [4.9 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59388

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-04
 CC||mpolacek at gcc dot gnu.org
  Known to work||4.8.2
   Target Milestone|--- |4.9.0
Summary|ICE on valid code at -O1|[4.9 Regression] ICE on
   |and above on|valid code at -O1 and above
   |x86_64-linux-gnu|on x86_64-linux-gnu
 Ever confirmed|0   |1
  Known to fail||4.9.0

--- Comment #1 from Marek Polacek  ---
Confirmed, -fno-tree-reassoc makes the ICE go away.

[Bug tree-optimization/59388] New: ICE on valid code at -O1 and above on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59388

Bug ID: 59388
   Summary: ICE on valid code at -O1 and above on x86_64-linux-gnu
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

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

It is a regression from 4.8.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.9.0 20131204 (experimental) [trunk revision 205673] (GCC) 
$ 
$ gcc-trunk -O0 small.c; a.out
$ gcc-4.8 -O1 small.c; a.out
$ 
$ gcc-trunk -O1 small.c
small.c: In function ‘main’:
small.c:9:1: error: definition in block 2 follows the use
 main () 
 ^
for SSA_NAME: _2 in statement:
_8 = _2;
small.c:9:1: internal compiler error: verify_ssa failed
0xb56fcc verify_ssa(bool)
../../gcc-trunk/gcc/tree-ssa.c:1096
0x8fa8be execute_function_todo
../../gcc-trunk/gcc/passes.c:1844
0x8fb2b3 execute_todo
../../gcc-trunk/gcc/passes.c:1877
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 





int a;

struct
{
  unsigned int f:1;
} b;

int 
main () 
{ 
  a = (0 < b.f) | b.f; 
  return a; 
}

[Bug tree-optimization/59387] New: wrong code (hangs) at -Os on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59387

Bug ID: 59387
   Summary: wrong code (hangs) at -Os on x86_64-linux-gnu
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The current gcc trunk miscompiles the following code on x86_64-linux at -Os
(but not at the other optimization levels) in both 32-bit and 64-bit modes. 

This is a regression from 4.8.x.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.9.0 20131204 (experimental) [trunk revision 205673] (GCC) 
$ 
$ gcc-trunk -O1 small.c; a.out
$ gcc-trunk -O2 small.c; a.out
$ gcc-4.8 -Os small.c; a.out
$ 
$ gcc-trunk -Os small.c
$ a.out
^C
$ 


-


int a, *d, **e = &d, f;
char c;

struct
{
  int f1;
} b;

int
main ()
{
  for (a = -19; a; a++)
{
  for (b.f1 = 0; b.f1 < 24; b.f1++)
c--; 
  *e = &f;
  if (!d)
return 0;
}
  return 0;
}

[Bug tree-optimization/57315] LTO and/or vectorizer performance regression on salsa20 core, 4.7->4.8

[vmakarov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57315

--- Comment #4 from Vladimir Makarov  ---
  Zack, thanks for reporting this.  Crypto algorithms are very interesting
cases for RA.  A lot of performance improvements were done for RA during
gcc-4.9 development.  Now on Intel Haswell I have

bash-4.2$ /home/cygnus/vmakarov/build/comparison/4.7-64/bin/gcc -std=c99 -O2
-march=native salsa-test.c && ./a.out
 779.132 keys/s
bash-4.2$ /home/cygnus/vmakarov/build/comparison/4.8-64/bin/gcc -std=c99 -O2
-march=native salsa-test.c && ./a.out
 778.976 keys/s
bash-4.2$ /home/cygnus/vmakarov/build1/trunk5/64r/bin/gcc -std=c99 -O2
-march=native salsa-test.c && ./a.out
1392.555 keys/s
bash-4.2$ /home/cygnus/vmakarov/build/comparison/4.7-64/bin/gcc -std=c99 -O3
-fwhole-program -march=native salsa-test.c && ./a.out
1375.610 keys/s
bash-4.2$ /home/cygnus/vmakarov/build/comparison/4.8-64/bin/gcc -std=c99 -O3
-fwhole-program -march=native salsa-test.c && ./a.out
1224.177 keys/s
bash-4.2$ /home/cygnus/vmakarov/build1/trunk5/64r/bin/gcc -std=c99 -O3
-fwhole-program -march=native salsa-test.c && ./a.out
1436.539 keys/s

Here, trunk5 is today GCC trunk.

Unfortunately, the changes in RA are too big and can not be ported to gcc-4.8.

[Bug tree-optimization/59386] [4.9 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu in 64-bit mode

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59386

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-04
 CC||mpolacek at gcc dot gnu.org
  Known to work||4.8.2
   Target Milestone|--- |4.9.0
Summary|ICE on valid code at -O2|[4.9 Regression] ICE on
   |and -O3 on x86_64-linux-gnu |valid code at -O2 and -O3
   |in 64-bit mode  |on x86_64-linux-gnu in
   ||64-bit mode
 Ever confirmed|0   |1
  Known to fail||4.9.0

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/59268] [4.7/4.8/4.9 Regression] [c++11] ICE with constexpr in a virtual function

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59268

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed for 4.8.3+, though with --enable-checking=release it doesn't ICE and just
works (because then tsubst_copy just passes it through unmodified, which is
sufficient here).
So IMHO not work doing anything for 4.7.x.

[Bug c++/59268] [4.7/4.8/4.9 Regression] [c++11] ICE with constexpr in a virtual function

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59268

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec  4 18:14:01 2013
New Revision: 205675

URL: http://gcc.gnu.org/viewcvs?rev=205675&root=gcc&view=rev
Log:
PR c++/59268
* pt.c (tsubst_copy_and_build): Handle POINTER_PLUS_EXPR.

* g++.dg/cpp0x/constexpr-template6.C: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-template6.C
Modified:
branches/gcc-4_8-branch/gcc/cp/ChangeLog
branches/gcc-4_8-branch/gcc/cp/pt.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555

--- Comment #13 from Jan Hubicka  ---
I see, we should just short citcuit case when caller_freq
is 0.  I will test patch.

[Bug c++/59268] [4.7/4.8/4.9 Regression] [c++11] ICE with constexpr in a virtual function

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59268

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec  4 18:00:28 2013
New Revision: 205674

URL: http://gcc.gnu.org/viewcvs?rev=205674&root=gcc&view=rev
Log:
PR c++/59268
* pt.c (tsubst_copy_and_build): Handle POINTER_PLUS_EXPR.

* g++.dg/cpp0x/constexpr-template6.C: New test.

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

[Bug tree-optimization/59386] New: ICE on valid code at -O2 and -O3 on x86_64-linux-gnu in 64-bit mode

[su at cs dot ucdavis.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59386

Bug ID: 59386
   Summary: ICE on valid code at -O2 and -O3 on x86_64-linux-gnu
in 64-bit mode
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The following code causes an ICE when compiled with the current gcc trunk at
-O2 and -O3 on x86_64-linux-gnu in 64-bit mode (but not in 32-bit mode). 

It is a regression from 4.8.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.9.0 20131204 (experimental) [trunk revision 205660] (GCC) 
$ 
$ gcc-trunk -m64 -Os -c small.c   
$ gcc-4.8 -m64 -O2 -c small.c
$ gcc-trunk -m32 -O2 -c small.c
$ 
$ gcc-trunk -m64 -O2 -c small.c
small.c: In function ‘fn2’:
small.c:31:1: error: incorrect sharing of tree nodes
 }
 ^
a.f2
# .MEM_11 = VDEF <.MEM_10>
a.f2 = D.1782;
small.c:31:1: internal compiler error: verify_gimple failed
0x9d3821 verify_gimple_in_cfg(function*)
../../gcc-trunk/gcc/tree-cfg.c:4848
0x8fa874 execute_function_todo
../../gcc-trunk/gcc/passes.c:1843
0x8fb273 execute_todo
../../gcc-trunk/gcc/passes.c:1877
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


---


struct S0
{
  int f0;
};

struct S1
{
  int f1;
  struct S0 f2;
} c;

int b;

struct S0
fn1 ()
{
  struct S1 d;
  if (b) 
for (; c.f1;)
  ;
  else
return d.f2; 
}

struct S0
fn2 ()
{
  struct S1 a;
  a.f2 = fn1 ();
  return a.f2; 
}

[Bug c/58943] [4.7/4.8/4.9 Regression] wrong calculation of indirect structure member arithmetic via function call

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58943

--- Comment #6 from joseph at codesourcery dot com  ---
Yes, something like that.

[Bug c/54113] -Wmissing-prototypes produces false alarms for C99 inline functions

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54113

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-12-04
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
I have a patch for disabling the diagnostic  for inline functions in C99 mode.

[Bug c/59385] New: gcc 4.9 fails to use fma with __attribute__((target("fma")))

[jtaylor.debian at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59385

Bug ID: 59385
   Summary: gcc 4.9 fails to use fma with
__attribute__((target("fma")))
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jtaylor.debian at googlemail dot com

attached code does not emit fma instructions in gcc 4.9 while it did in gcc-4.8
(ffast-math is enabled):

$ gcc -v
COLLECT_GCC=/scratch/jtaylor/gcc/local-trunk/bin//gcc
COLLECT_LTO_WRAPPER=/scratch/jtaylor/gcc/local-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /media/jtaylor/external1/buildacc/gcc-trunk/configure
--enable-languages=c,c++,fortran --enable-tls
--prefix=/scratch/jtaylor/gcc/local-trunk --with-gmp=/usr --with-mpfr=/usr
--with-mpc=/usr --with-cloog=/usr --with-ppl=/usr --with-isl=/usr
Thread model: posix
gcc version 4.9.0 20131204 (experimental) (GCC) 

$ gcc-4.9 -Wall fma-attribute.c -c -std=c99 -O2 && objdump -d fma-attribute.o 

fma-attribute.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:c5 fb 10 06  vmovsd (%rsi),%xmm0
   4:c5 fb 59 02  vmulsd (%rdx),%xmm0,%xmm0
   8:c5 fb 58 01  vaddsd (%rcx),%xmm0,%xmm0
   c:c5 fb 11 07  vmovsd %xmm0,(%rdi)
  10:c3   retq   

whereas gcc 4.8.1 does:

COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.8.1-10ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9) 

$ gcc-4.8 -Wall fma-attribute.c -c -std=c99 -O2 && objdump -d fma-attribute.o 

 :
   0:c5 fb 10 06  vmovsd (%rsi),%xmm0
   4:c5 fb 10 09  vmovsd (%rcx),%xmm1
   8:c4 e2 f1 99 02   vfmadd132sd (%rdx),%xmm1,%xmm0
   d:c5 fb 11 07  vmovsd %xmm0,(%rdi)
  11:c3   retq   
  12:66 66 66 66 66 2e 0f data32 data32 data32 data32 nopw
%cs:0x0(%rax,%rax,1)
  19:1f 84 00 00 00 00 00 


another weirdness is that gcc 4.8 and 4.9 it uses fma/avx also for the function
marked target("sse"), this can be fixed by only setting it in the declaration
and not the definition. Is that intentional?

[Bug c/59385] gcc 4.9 fails to use fma with __attribute__((target("fma")))

[jtaylor.debian at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59385

--- Comment #1 from Julian Taylor  ---
Created attachment 31381
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31381&action=edit
code reproducing the issue

[Bug ada/59382] gnatmake is not able to compile libraries on ARM (native)

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59382

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-04
 CC||ebotcazou at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org
   Target Milestone|--- |4.8.3
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
Looking into it.

[Bug rtl-optimization/59317] [4.9 Regression] [LRA,MIPS] ICE: in check_rtl, at lra.c (insn does not satisfy constraints)

[vmakarov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59317

--- Comment #3 from Vladimir Makarov  ---
(In reply to Robert Suchanek from comment #2)
> The latest patches do not seem to resolve the issue.
> 
> Although the newly generated pseudos get ALL_REGS class assigned, the class
> change does not happen later. As the class is not changed, hard regs are
> found basing on the class, and hence, wrong hard reg(s) are assigned and it
> is found by the coherency check.
> 
> If I'm right, there are least two opportunities where the class can be
> changed in the constraint pass. One fails as the constraints cannot
> influence the classes of the new pseudos (for reload insns) and another one
> when it tries to narrow the class for input pseudos.

Sorry, I can not reproduce this. I built cc1 from yesterday trunk on x86-64
using --target=mips16-linux and then I use -O2 -mips32 -mips16 to compile the
test.  It was ok.

I used the below patch.  You can send me the LRA dump.  May be it will give me
a hint what is going on.

Index: gcc/config/mips/constraints.md
===
--- gcc/config/mips/constraints.md  (revision 205647)
+++ gcc/config/mips/constraints.md  (working copy)
@@ -19,7 +19,7 @@

 ;; Register constraints

-(define_register_constraint "d" "BASE_REG_CLASS"
+(define_register_constraint "d" "ADDR_REG_CLASS"
   "An address register.  This is equivalent to @code{r} unless
generating MIPS16 code.")

Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c  (revision 205647)
+++ gcc/config/mips/mips.c  (working copy)
@@ -2157,7 +2157,7 @@
  All in all, it seems more consistent to only enforce this restriction
  during and after reload.  */
   if (TARGET_MIPS16 && regno == STACK_POINTER_REGNUM)
-return !strict_p || GET_MODE_SIZE (mode) == 4 || GET_MODE_SIZE (mode) ==
8;
+return  GET_MODE_SIZE (mode) == 4 || GET_MODE_SIZE (mode) == 8;

   return TARGET_MIPS16 ? M16_REG_P (regno) : GP_REG_P (regno);
 }
@@ -17301,7 +17301,7 @@
   fixed_regs[26] = call_used_regs[26] = 1;
   fixed_regs[27] = call_used_regs[27] = 1;
   fixed_regs[30] = call_used_regs[30] = 1;
-  if (optimize_size)
+  if (optimize_size && !targetm.lra_p())
{
  fixed_regs[8] = call_used_regs[8] = 1;
  fixed_regs[9] = call_used_regs[9] = 1;
@@ -18699,6 +18699,21 @@
   else
 return default_case_values_threshold ();
 }
+
+static reg_class_t
+mips_spill_class (reg_class_t rclass, enum machine_mode mode)
+{
+  if (TARGET_MIPS16)
+   return SPILL_REGS;
+  return NO_REGS;
+}
+
+static bool
+mips_lra_p (void)
+{
+  return !TARGET_RELOAD;
+}
+
 ^L
 /* Initialize the GCC target structure.  */
 #undef TARGET_ASM_ALIGNED_HI_OP
@@ -18933,6 +18948,15 @@
 #undef TARGET_CASE_VALUES_THRESHOLD
 #define TARGET_CASE_VALUES_THRESHOLD mips_case_values_threshold

+#undef TARGET_SPILL_CLASS
+#define TARGET_SPILL_CLASS mips_spill_class
+
+#undef TARGET_LRA_P
+#define TARGET_LRA_P mips_lra_p
+
+#undef TARGET_DIFFERENT_ADDR_DISPLACEMENT_P
+#define TARGET_DIFFERENT_ADDR_DISPLACEMENT_P hook_bool_void_true
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 ^L
 #include "gt-mips.h"
Index: gcc/config/mips/mips.h
===
--- gcc/config/mips/mips.h  (revision 205647)
+++ gcc/config/mips/mips.h  (working copy)
@@ -1874,10 +1874,12 @@
 {
   NO_REGS, /* no registers in set */
   M16_REGS,/* mips16 directly accessible registers */
+  M16F_REGS,   /* mips16 + frame */
   T_REG,   /* mips16 T register ($24) */
   M16_T_REGS,  /* mips16 registers plus T register */
   PIC_FN_ADDR_REG, /* SVR4 PIC function address register */
   V1_REG,  /* Register $v1 ($3) used for TLS access.  */
+  SPILL_REGS,  /* All but $sp and call preserved regs are in
here */
   LEA_REGS,/* Every GPR except $25 */
   GR_REGS, /* integer registers */
   FP_REGS, /* floating point registers */
@@ -1911,10 +1913,12 @@
 {  \
   "NO_REGS",   \
   "M16_REGS",  \
+  "M16F_REGS", \
   "T_REG", \
   "M16_T_REGS",   
\
   "PIC_FN_ADDR_REG",   \
   "V1_REG",\
+  "SPILL_REGS",   
\
   "LEA_REGS",  \
 

[Bug libstdc++/53984] iostream operation throwing exception when exceptions not enabled

[tom at kera dot name]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53984

Tomalak Geret'kal  changed:

   What|Removed |Added

 CC||tom at kera dot name

--- Comment #3 from Tomalak Geret'kal  ---
Another testcase was proposed under the following Stack Overflow question:

  http://stackoverflow.com/q/20371956/560648

The answer to that question was a link to this bug.

[Bug rtl-optimization/59086] [4.9 Regression] error: ‘asm’ operand has impossible constraints

[vmakarov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086

--- Comment #9 from Vladimir Makarov  ---
(In reply to Jan Hubicka from comment #8)
> > Do we have any documentation that states how many registers can be used in
> > inline assembler for a particular arch and optset? "almost all" is not good
> > enough for that.
> 
> It is somewhat difficult question.  Basically you are not supposed to use
> any "fixed"
> registers where fixed set of registers depends on compilation flags. For
> example ESP is
> always fixed, EBP is fixed depending on frame pointer elimination.
> With PIC you need also EBP for GOT pointer and for DRAP you need another
> register.
> You need to leave enough registers so reload can load all additional operand
> and addresses.
> Things may have also changes with IRA - last time I looked into this was
> with old reload.
> 
> Vladimir, do you have idea about more precise description?

It is very difficult to formulate this for all cases.

For one alternative, I would say for any given class the number of allocatable
hard regs of given class should be not less than max (non-output operands with
a constraint register class intersecting given class, analogous for non-input
operands).  Early clobber operands are considered non-input and non-output. 
Operand modes should be taken into account too, e.g. an operand needs 2 regs.

We cannot assume that a pseudo has an equivalent unallocatable hard reg
expression.

Still this description might not work when we have a subreg of bigger pseudo
requiring at least 2 hard regs as sometimes we need to reload all pseudo.

Also this formulation can be too strict when there are register and
non-register constraint, e.g. memory.  Several alternative can complicate the
situation even more.

As algorithms behind reload/LRA are too complicated and has a lot of details,
the formulation will be too long.  The simple formulation for all possible
cases would be too constrained and not practical.  Therefore nobody tried to
write it down and we just have a fatal message 'can not reload'.


> > 
> > If the user code that worked in 4.8 correctly is now broken for 4.9, we 
> > better
> > need to respect the user and document it properly.
> 
> Well, the problem is that precise set of constraints is exremely tied to
> compiler internals (and it also changes from release to release, indeed).  It
> is overall problem of ASM statement extension in GCC, sadly.
> 
>

[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p

[octoploid at yandex dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555

--- Comment #12 from Markus Trippelsdorf  ---
(In reply to Jakub Jelinek from comment #11)
> Can't reproduce this, with various snapshots from around the date of
> comments, or current trunk, neither on the larger nor shorter testcase.

Strange.
Just double checked and it still ICEs for me:
  % ../gcc/configure --disable-bootstrap --disable-libvtv --disable-libitm
--disable-libcilkrts --disable-libssp --disable-libgomp --disable-werror
--disable-multilib --enable-languages=c,c++
  % make -j4 && make DESTDIR=/var/tmp/gcc_test install
  % /var/tmp/gcc_test/usr/local/bin/g++ -O3 -c test.ii
test.ii:113:35: internal compiler error: Floating point exception
 void addServer() { I(new P); }
   ^
0xb44e9f crash_signal
../../gcc/gcc/toplev.c:336
0x53c863 want_inline_self_recursive_call_p
../../gcc/gcc/ipa-inline.c:708
0x1023819 inline_small_functions
../../gcc/gcc/ipa-inline.c:1767
0x1023819 ipa_inline
../../gcc/gcc/ipa-inline.c:2020
0x1023819 execute
../../gcc/gcc/ipa-inline.c:2390
Please submit a full bug report,
with preprocessed source if appro

[Bug rtl-optimization/58726] [4.7 Regression] wrong code at -Os on x86_64-linux-gnu (affecting trunk/4.7/4.6, but not 4.8)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58726

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Known to work||4.8.3, 4.9.0
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
Summary|[4.7/4.8/4.9 Regression]|[4.7 Regression] wrong code
   |wrong code at -Os on|at -Os on x86_64-linux-gnu
   |x86_64-linux-gnu (affecting |(affecting trunk/4.7/4.6,
   |trunk/4.7/4.6, but not 4.8) |but not 4.8)
  Known to fail|4.9.0   |

--- Comment #7 from Jakub Jelinek  ---
Fixed for 4.8.3+ so far.

[Bug target/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163

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

[Bug c/59351] ICE on empty compound literal with -pedantic

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59351

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Wed Dec  4 15:54:48 2013
New Revision: 205673

URL: http://gcc.gnu.org/viewcvs?rev=205673&root=gcc&view=rev
Log:
PR c/59351
testsuite/
* gcc.dg/pr59351.c: Use -pedantic instead of -Wpedantic.

Modified:
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr59351.c

[Bug ipa/59008] [4.9 Regression] ICEs in try_make_edge_direct_simple_call / propagate_controlled_uses

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59008

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

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

[Bug target/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163

--- Comment #21 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec  4 15:50:02 2013
New Revision: 205671

URL: http://gcc.gnu.org/viewcvs?rev=205671&root=gcc&view=rev
Log:
PR target/59163
* config/i386/i386.c (ix86_legitimate_combined_insn): If for
!TARGET_AVX there is misaligned MEM operand with vector mode
and get_attr_ssememalign is 0, return false.
(ix86_expand_special_args_builtin): Add get_pointer_alignment
computed alignment and for non-temporal loads/stores also
at least GET_MODE_ALIGNMENT as MEM_ALIGN.
* config/i386/sse.md
(_loadu,
_storeu,
_loaddqu,
_storedqu, _lddqu,
sse_vmrcpv4sf2, sse_vmrsqrtv4sf2, sse2_cvtdq2pd, sse_movhlps,
sse_movlhps, sse_storehps, sse_loadhps, sse_loadlps,
*vec_interleave_highv2df, *vec_interleave_lowv2df,
*vec_extractv2df_1_sse, sse2_loadhpd, sse2_loadlpd, sse2_movsd,
sse4_1_v8qiv8hi2, sse4_1_v4qiv4si2,
sse4_1_v4hiv4si2, sse4_1_v2qiv2di2,
sse4_1_v2hiv2di2, sse4_1_v2siv2di2, sse4_2_pcmpestr,
*sse4_2_pcmpestr_unaligned, sse4_2_pcmpestri, sse4_2_pcmpestrm,
sse4_2_pcmpestr_cconly, sse4_2_pcmpistr, *sse4_2_pcmpistr_unaligned,
sse4_2_pcmpistri, sse4_2_pcmpistrm, sse4_2_pcmpistr_cconly): Add
ssememalign attribute.
* config/i386/i386.md (ssememalign): New define_attr.

* g++.dg/torture/pr59163.C: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/torture/pr59163.C
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/i386/i386.c
branches/gcc-4_8-branch/gcc/config/i386/i386.md
branches/gcc-4_8-branch/gcc/config/i386/sse.md
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/58726] [4.7/4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu (affecting trunk/4.7/4.6, but not 4.8)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58726

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec  4 15:51:02 2013
New Revision: 205672

URL: http://gcc.gnu.org/viewcvs?rev=205672&root=gcc&view=rev
Log:
PR rtl-optimization/58726
* combine.c (force_to_mode): Fix comment typo.  Don't destructively
modify x for ROTATE, ROTATERT and IF_THEN_ELSE.

* gcc.c-torture/execute/pr58726.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr58726.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/combine.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug c/59351] ICE on empty compound literal with -pedantic

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59351

--- Comment #7 from Marek Polacek  ---
Ugh, of course, will fix it immediately.

[Bug c/59351] ICE on empty compound literal with -pedantic

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59351

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #6 from Eric Botcazou  ---
I have this in my logs on the 4.7 branch:

output is:
xgcc: error: unrecognized command line option '-Wpedantic'

FAIL: gcc.dg/pr59351.c  (test for warnings, line 7)
FAIL: gcc.dg/pr59351.c (test for excess errors)
Excess errors:
xgcc: error: unrecognized command line option '-Wpedantic'

[Bug gcov-profile/58682] Profiling directed optimization doesn't play well with indirect inlining

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58682

H.J. Lu  changed:

   What|Removed |Added

 CC||evstupac at gmail dot com

--- Comment #5 from H.J. Lu  ---
*** Bug 58279 has been marked as a duplicate of this bug. ***

[Bug ipa/58279] Interanl compiler error while pgo compilation at ipa-inline.c:902

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58279

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #10 from H.J. Lu  ---
I closed it as dup of PR 58682.  If PR 58682 is a regression
on 4.8, please reopen PR 58682 and request the backport.

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

[Bug other/59384] New: Cilk Plus array notation with for loop after segfaults

[nick.tomlinson at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59384

Bug ID: 59384
   Summary: Cilk Plus array notation with for loop after segfaults
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nick.tomlinson at arm dot com
CC: bviyer at gcc dot gnu.org

Created attachment 31380
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31380&action=edit
Minimal reproducer

When I compile the attached file, GCC segfaults. This appears to be a result of
having a Cilk Plus array notation assignment followed by a for loop using the
array assigned to.

The attached file is a minimal (un-preprocessed to preserve comments; there are
no includes or preprocessor macros) reproducer. The comments include
observations about what triggers the bug, a stack trace from GCC, the output of
gcc -v, and the command line used to compile it.

[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827

[octoploid at yandex dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733

--- Comment #8 from Markus Trippelsdorf  ---
(In reply to Jakub Jelinek from comment #7)
> So, with r205392 now in, can this still be reproduced?

Unfortunately, yes.

[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
Can't reproduce this, with various snapshots from around the date of comments,
or current trunk, neither on the larger nor shorter testcase.

[Bug middle-end/58290] [4.9 Regression] error: virtual definition of statement not up-to-date

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58290

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
By r204399 in particular.  Richard, does that sound like a real fix or just
something that made the issue latent?  If the former, then we just want the
testcase into testsuite.

[Bug ipa/58279] Interanl compiler error while pgo compilation at ipa-inline.c:902

[evstupac at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58279

--- Comment #9 from Stupachenko Evgeny  ---
r203897 | pmatos | 2013-10-21 19:41:46 +0400 (Mon, 21 Oct 2013) | 4 lines

* ipa-inline.c (edge_badness): Cap edge->count at max_count for badness
calculations.

fixes the issue in trunk.

To be consistent we should apply the patch (attached) to 4.8 GCC as well.
However I believe we should update max_count when adding new edges, but not
edge_count.

[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
So, with r205392 now in, can this still be reproduced?

[Bug ipa/58279] Interanl compiler error while pgo compilation at ipa-inline.c:902

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58279

--- Comment #8 from H.J. Lu  ---
(In reply to Stupachenko Evgeny from comment #7)
> Created attachment 31379 [details]
> patch to ipa-inline.c for 4.8

Is this a backport from trunk? If yes, please identify which
checkin on trunk fixes it.

[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[rmansfield at qnx dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350

Ryan Mansfield  changed:

   What|Removed |Added

 CC||rmansfield at qnx dot com

--- Comment #1 from Ryan Mansfield  ---
Also seen on an armeabi target.

[Bug ipa/58279] Interanl compiler error while pgo compilation at ipa-inline.c:902

[evstupac at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58279

--- Comment #7 from Stupachenko Evgeny  ---
Created attachment 31379
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31379&action=edit
patch to ipa-inline.c for 4.8

[Bug middle-end/58903] [4.9 Regression] ICE: SIGSEGV in hash_table::find_slot_with_hash() with -O -fdevirtualize-speculatively

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58903

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Jakub Jelinek  ---
Should be fixed by r205656.

[Bug rtl-optimization/59086] [4.9 Regression] error: ‘asm’ operand has impossible constraints

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086

--- Comment #8 from Jan Hubicka  ---
> Do we have any documentation that states how many registers can be used in
> inline assembler for a particular arch and optset? "almost all" is not good
> enough for that.

It is somewhat difficult question.  Basically you are not supposed to use any
"fixed"
registers where fixed set of registers depends on compilation flags. For
example ESP is
always fixed, EBP is fixed depending on frame pointer elimination.
With PIC you need also EBP for GOT pointer and for DRAP you need another
register.
You need to leave enough registers so reload can load all additional operand
and addresses.
Things may have also changes with IRA - last time I looked into this was with
old reload.

Vladimir, do you have idea about more precise description?
> 
> If the user code that worked in 4.8 correctly is now broken for 4.9, we better
> need to respect the user and document it properly.

Well, the problem is that precise set of constraints is exremely tied to
compiler internals (and it also changes from release to release, indeed).  It
is overall problem of ASM statement extension in GCC, sadly.

Honza

[Bug rtl-optimization/58960] [4.9 regression] ICE in bmp_iter_set_init

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58960

Marek Polacek  changed:

   What|Removed |Added

   Priority|P1  |P2
 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
I also wondered why is this P1.  Decreasing to P2...

[Bug rtl-optimization/58960] [4.9 regression] ICE in bmp_iter_set_init

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58960

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
ia64-*-* is neither primary nor secondary target, why is this P1?

[Bug target/58964] [4.9 Regression] Bogus message: error: -mpreferred-stack-boundary=0 is not between 2 and 12

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58964

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed by r205616.

[Bug rtl-optimization/59086] [4.9 Regression] error: ‘asm’ operand has impossible constraints

[aivchenk at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086

--- Comment #7 from Alexander Ivchenko  ---
Do we have any documentation that states how many registers can be used in
inline assembler for a particular arch and optset? "almost all" is not good
enough for that.

If the user code that worked in 4.8 correctly is now broken for 4.9, we better
need to respect the user and document it properly.

[Bug rtl-optimization/59086] [4.9 Regression] error: ‘asm’ operand has impossible constraints

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
(In reply to Alexander Ivchenko from comment #5)
> I understand the technical reasons of the complexity of the correct and
> efficient register allocation here, but what I don't understand is this:
> 
> $> gcc_4.7 test.c -c -fPIC -mstackrealign -march=core-avx2 -m32
> $> gcc_4.8 test.c -c -fPIC -mstackrealign -march=core-avx2 -m32
> $> gcc_4.9 test.c -c -fPIC -mstackrealign -march=core-avx2 -m32
> test.c: In function 'testFunc':
> test.c:7:3: error: 'asm' operand has impossible constraints
>__asm__(
>^
> 
> How can we allow to break the user code with the release version of the
> compiler here..?

If it does something wrong, and using almost all or all available registers in
an asm is always wrong, then why not.  Just compile it with
-maccumulate-outgoing-args or without -mstackrealign or better rework either to
need fewer registers (pass some more arguments in memory or even better some
memory structure, so that they can all be loaded/saved from there using fewer
registers).

I'd say this should be closed NOTABUG (or WONTFIX?).

[Bug tree-optimization/59355] [4.9 Regression] ICE: SIGSEGV in hash_table::find_slot_with_hash() with -fno-devirtualize

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59355

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/58651] [4.7/4.8/4.9 Regression] ICE with invalid initializer list

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58651

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
A CONSTRUCTOR with init_list_type_node TREE_TYPE makes it all the way through
to gimplification, which expectedly ICEs on it.

[Bug c++/59383] New: typedef propagation with template base class using the same name is wrong

[gmarkhor at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59383

Bug ID: 59383
   Summary: typedef propagation with template base class using the
same name is wrong
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gmarkhor at gmail dot com

I am using g++ 4.8.1. Consider the following code (compiled as g++ -std=c++11
-c test.cc):

#include 

template 
struct TypePair {
  typedef F First;
  typedef S Second;
};

template 
class Base {
 public:
  typedef TypePair Family;
  typedef Base ParentType;
};

template 
class Derived : public Base {
 public:
  typedef TypePair Family;
  typedef typename Family::Second ParentType;
};

static_assert(std::is_same, Derived<1>::ParentType>::value, "Error");




The static assertion is failed. Clang ver. 3.2 and 3.3 and 3.4 compiles this
code well.

If you remove the template from Base:




#include 

template 
struct TypePair {
  typedef F First;
  typedef S Second;
};

class Base {
 public:
  typedef TypePair Family;
  typedef Base ParentType;
};

template 
class Derived : public Base {
 public:
  typedef TypePair Family;
  typedef typename Family::Second ParentType;
};

static_assert(std::is_same::ParentType>::value, "Error");




then everything becomes OK. The other way to make it work is to remove template
from Derived and inherit from an explicit Base<1>:





#include 

template 
struct TypePair {
  typedef F First;
  typedef S Second;
};

template 
class Base {
 public:
  typedef TypePair Family;
  typedef Base ParentType;
};

class Derived : public Base<1> {
 public:
  typedef TypePair Family;
  typedef typename Family::Second ParentType;
};

static_assert(std::is_same, Derived::ParentType>::value, "Error");



I am not sure what standard says about this, but it seems a bug.

[Bug target/59003] [4.9 Regression] profiledbootstrap miscompiles gcc during stagefeedback --with-tune=amdfam10

[octoploid at yandex dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003

--- Comment #7 from Markus Trippelsdorf  ---
Created attachment 31378
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31378&action=edit
disassemled get_or_alloc_expr_for_name(tree_node*) bad

I've attached the disassembly of get_or_alloc_expr_for_name()
Good: misaligned_move_string_pro_epilogues off
Bad: misaligned_move_string_pro_epilogues on

[Bug target/59003] [4.9 Regression] profiledbootstrap miscompiles gcc during stagefeedback --with-tune=amdfam10

[octoploid at yandex dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003

--- Comment #6 from Markus Trippelsdorf  ---
Created attachment 31377
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31377&action=edit
disassemled get_or_alloc_expr_for_name(tree_node*) good

[Bug target/59003] [4.9 Regression] profiledbootstrap miscompiles gcc during stagefeedback --with-tune=amdfam10

[octoploid at yandex dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003

--- Comment #5 from Markus Trippelsdorf  ---
Looks like gcc/tree-ssa-pre.c gets miscompiled:

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 8327]
0x00d156d3 in get_or_alloc_expr_for_name(tree_node*) [clone
.lto_priv.4065] ()
(gdb) bt
#0  0x00d156d3 in get_or_alloc_expr_for_name(tree_node*) [clone
.lto_priv.4065] ()
#1  0x00f47468 in compute_avail() ()
#2  0x011068cf in (anonymous namespace)::pass_pre::execute() [clone
.lto_priv.5361] ()
#3  0x00c8f3a2 in execute_one_pass(opt_pass*) ()
#4  0x00c9065b in execute_pass_list(opt_pass*) ()
#5  0x00e405f5 in expand_function(cgraph_node*) [clone .lto_priv.5292]
()
#6  0x010ed32b in compile() ()
#7  0x010ed8da in finalize_compilation_unit() ()
#8  0x00ffe208 in c_write_global_declarations() ()
#9  0x010b0c5f in compile_file() ()
#10 0x010b2d14 in toplev_main(int, char**) ()
#11 0x77756f90 in __libc_start_main () from /lib/libc.so.6
#12 0x0104d236 in _start ()

Is it possible to somehow disassemble slim object files?

[Bug rtl-optimization/59317] [4.9 Regression] [LRA,MIPS] ICE: in check_rtl, at lra.c (insn does not satisfy constraints)

[robert.suchanek at imgtec dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59317

--- Comment #2 from Robert Suchanek  ---
The latest patches do not seem to resolve the issue.

Although the newly generated pseudos get ALL_REGS class assigned, the class
change does not happen later. As the class is not changed, hard regs are found
basing on the class, and hence, wrong hard reg(s) are assigned and it is found
by the coherency check.

If I'm right, there are least two opportunities where the class can be changed
in the constraint pass. One fails as the constraints cannot influence the
classes of the new pseudos (for reload insns) and another one when it tries to
narrow the class for input pseudos.

[Bug ada/59382] New: gnatmake is not able to compile libraries on ARM (native)

[pavel at zhukoff dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59382

Bug ID: 59382
   Summary: gnatmake is not able to compile libraries on ARM
(native)
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pavel at zhukoff dot net

Created attachment 31376
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31376&action=edit
suggested patch

gnatmake is not able to build libraries (both static or dynamic) on arm
platform natively.

gcc-gnat-4.8.2-2.fc20.armv7hl

# gnatmake -P testso.gpr -f
testso.gpr:4:22: warning: libraries are not supported on this platform
gcc -c -I- -gnatA /root/testsolib/test.adb

== testso.gpr == 

library project testso is 
for source_dirs use (".");
for library_kind use "relocatable";
for Library_Name use "noname";
for Library_Dir use "lib/";
end testso;

== test.ad? == 
any package; 


Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7hl-redhat-linux-gnueabi/4.8.2/lto-wrapper
Target: armv7hl-redhat-linux-gnueabi
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/home/max/rpm/BUILD/gcc-4.8.2-20131017/obj-armv7hl-redhat-linux-gnueabi/isl-install
--with-cloog=/home/max/rpm/BUILD/gcc-4.8.2-20131017/obj-armv7hl-redhat-linux-gnueabi/cloog-install
--disable-sjlj-exceptions --with-cpu=cortex-a8 --with-tune=cortex-a8
--with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16
--with-abi=aapcs-linux --build=armv7hl-redhat-linux-gnueabi
Thread model: posix
gcc version 4.8.2 20131017 (Red Hat 4.8.2-2) (GCC) 

# gnatmake --version
GNATMAKE 4.8.2 20131017 (Red Hat 4.8.2-2)
Copyright (C) 1995-2013, 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.

[Bug libstdc++/58638] libstdc++ builds as non-PIC when --with-pic is specified

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58638

H.J. Lu  changed:

   What|Removed |Added

 CC||cnstar9988 at gmail dot com

--- Comment #2 from H.J. Lu  ---
*** Bug 59380 has been marked as a duplicate of this bug. ***

[Bug c++/59380] libstdc++.a: could not read symbols: Bad value

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59380

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from H.J. Lu  ---
Dup.

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

[Bug c++/59380] libstdc++.a: could not read symbols: Bad value

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59380

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-12-04
 Ever confirmed|0   |1

--- Comment #3 from H.J. Lu  ---
Where is your libstdc++.so? Why can't linker find it?

[Bug rtl-optimization/58726] [4.7/4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu (affecting trunk/4.7/4.6, but not 4.8)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58726

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec  4 11:25:06 2013
New Revision: 205664

URL: http://gcc.gnu.org/viewcvs?rev=205664&root=gcc&view=rev
Log:
PR rtl-optimization/58726
* combine.c (force_to_mode): Fix comment typo.  Don't destructively
modify x for ROTATE, ROTATERT and IF_THEN_ELSE.

* gcc.c-torture/execute/pr58726.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr58726.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/56787] [4.8 Regression] Vectorization fails because of CLOBBER statements

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56787

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #8 from ktkachov at gcc dot gnu.org ---
Also fails on arm-* btw.

[Bug target/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163

--- Comment #19 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec  4 11:11:24 2013
New Revision: 205661

URL: http://gcc.gnu.org/viewcvs?rev=205661&root=gcc&view=rev
Log:
PR target/59163
* config/i386/i386.c (ix86_legitimate_combined_insn): If for
!TARGET_AVX there is misaligned MEM operand with vector mode
and get_attr_ssememalign is 0, return false.
(ix86_expand_special_args_builtin): Add get_pointer_alignment
computed alignment and for non-temporal loads/stores also
at least GET_MODE_ALIGNMENT as MEM_ALIGN.
* config/i386/sse.md
(_loadu,
_storeu,
_loaddqu,
_storedqu, _lddqu,
sse_vmrcpv4sf2, sse_vmrsqrtv4sf2, sse2_cvtdq2pd, sse_movhlps,
sse_movlhps, sse_storehps, sse_loadhps, sse_loadlps,
*vec_interleave_highv2df, *vec_interleave_lowv2df,
*vec_extractv2df_1_sse, sse2_movsd, sse4_1_v8qiv8hi2,
sse4_1_v4qiv4si2, sse4_1_v4hiv4si2,
sse4_1_v2qiv2di2, sse4_1_v2hiv2di2,
sse4_1_v2siv2di2, sse4_2_pcmpestr, *sse4_2_pcmpestr_unaligned,
sse4_2_pcmpestri, sse4_2_pcmpestrm, sse4_2_pcmpestr_cconly,
sse4_2_pcmpistr, *sse4_2_pcmpistr_unaligned, sse4_2_pcmpistri,
sse4_2_pcmpistrm, sse4_2_pcmpistr_cconly): Add ssememalign attribute.
* config/i386/i386.md (ssememalign): New define_attr.

* g++.dg/torture/pr59163.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr59163.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug target/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163

--- Comment #20 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec  4 11:12:04 2013
New Revision: 205663

URL: http://gcc.gnu.org/viewcvs?rev=205663&root=gcc&view=rev
Log:
PR target/59163
* config/i386/i386.c (ix86_legitimate_combined_insn): If for
!TARGET_AVX there is misaligned MEM operand with vector mode
and get_attr_ssememalign is 0, return false.
(ix86_expand_special_args_builtin): Add get_pointer_alignment
computed alignment and for non-temporal loads/stores also
at least GET_MODE_ALIGNMENT as MEM_ALIGN.
* config/i386/sse.md
(_loadu,
_storeu,
_loaddqu,
_storedqu, _lddqu,
sse_vmrcpv4sf2, sse_vmrsqrtv4sf2, sse2_cvtdq2pd, sse_movhlps,
sse_movlhps, sse_storehps, sse_loadhps, sse_loadlps,
*vec_interleave_highv2df, *vec_interleave_lowv2df,
*vec_extractv2df_1_sse, sse2_movsd, sse4_1_v8qiv8hi2,
sse4_1_v4qiv4si2, sse4_1_v4hiv4si2,
sse4_1_v2qiv2di2, sse4_1_v2hiv2di2,
sse4_1_v2siv2di2, sse4_2_pcmpestr, *sse4_2_pcmpestr_unaligned,
sse4_2_pcmpestri, sse4_2_pcmpestrm, sse4_2_pcmpestr_cconly,
sse4_2_pcmpistr, *sse4_2_pcmpistr_unaligned, sse4_2_pcmpistri,
sse4_2_pcmpistrm, sse4_2_pcmpistr_cconly): Add ssememalign attribute.
* config/i386/i386.md (ssememalign): New define_attr.

* g++.dg/torture/pr59163.C: New test.

Modified:
trunk/gcc/config/i386/i386.c