[Bug c/37428] GNU VLA-in-structure extension is undocumented

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/60664] New: bool / out of range int comparison warning failure

[dcb314 at hotmail dot com]

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

Bug ID: 60664
   Summary: bool / out of range int comparison warning failure
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

Consider the following code:

extern bool f(int n);

void
g(int a, int b)
{
if (f(a) == 2)
f(b);
}

gcc says nothing

$ g++ -c -O2 -Wall -Wextra -ansi -pedantic mar26b.cc

clang has more to say
$ clang++ -c !$
clang++ -c mar26b.cc
mar26b.cc:7:11: warning: comparison of constant 2 with expression of type
'bool'
  is always false [-Wtautological-constant-out-of-range-compare]
if (f(a) == 2)
 ^  ~
1 warning generated.

I've just built gcc trunk with clang and it looks as if producing
a similar warning to clang will flush out five bugs in gcc trunk.

[Bug c/57452] FAIL: c-c++-common/cilk-plus/AN/if_test.c

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Looking at gcc-testresults, this seems to be fixed.

[Bug c++/60664] bool / out of range int comparison warning failure

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-26
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  The same for the C FE.

[Bug c/56724] sub-optimal location in error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-26
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Marek Polacek  ---
Confirmed.  I though about tweaking this, too.  I may look at it in next
stage1, but not assigning right now.

[Bug c/18637] pragma handler interfaces should be merged

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
I guess c_register_pragma_with_data and
c_register_pragma_with_expansion_and_data should be merged as well.

[Bug rtl-optimization/60452] [4.8/4.9 Regression] wrong code at -O1 with large offsets in the frame

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Mar 26 07:38:30 2014
New Revision: 208837

URL: http://gcc.gnu.org/viewcvs?rev=208837&root=gcc&view=rev
Log:
PR rtl-optimization/60452
* rtlanal.c (rtx_addr_can_trap_p_1): Fix head comment.
: Return 1 for invalid offsets from the frame pointer.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20140326-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/rtlanal.c
trunk/gcc/testsuite/ChangeLog

[Bug c/60665] New: gcc/ipa-devirt.c:1510:7: warning: variable 'can_refer' is used uninitialized whenever '?:' condition is false

[dcb314 at hotmail dot com]

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

Bug ID: 60665
   Summary: gcc/ipa-devirt.c:1510:7: warning: variable 'can_refer'
is used uninitialized whenever '?:' condition is false
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

I just tried to compile gcc trunk with clang and the
above warning message appears.

It looks as if it would be prudent to initialise local
variable can_refer, declared around line 1423 of gcc/ipa-devirt.c,
to some sensible default value.

[Bug c/59749] unused warning not emited for unused static struct unles -save-temps is used

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Actually I think this is a dup.

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

[Bug c/57201] Using --save-temps affects whether warning is printed

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||martin at netbsd dot org

--- Comment #12 from Marek Polacek  ---
*** Bug 59749 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/60452] [4.8/4.9 Regression] wrong code at -O1 with large offsets in the frame

[ebotcazou at gcc dot gnu.org]

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

--- Comment #14 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Mar 26 07:42:30 2014
New Revision: 208838

URL: http://gcc.gnu.org/viewcvs?rev=208838&root=gcc&view=rev
Log:
PR rtl-optimization/60452
* rtlanal.c (rtx_addr_can_trap_p_1): Fix head comment.
: Return 1 for invalid offsets from the frame pointer.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/20140326-1.c
  - copied unchanged from r208837,
trunk/gcc/testsuite/gcc.c-torture/execute/20140326-1.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/rtlanal.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/60452] [4.8/4.9 Regression] wrong code at -O1 with large offsets in the frame

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

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

[Bug c/60666] New: sese.c:536:11: warning: variable 'stmts' is used uninitialized whenever '||' condition is true

[dcb314 at hotmail dot com]

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

Bug ID: 60666
   Summary: sese.c:536:11: warning: variable 'stmts' is used
uninitialized whenever '||' condition is true
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

It might be a wise idea to make sure that local variable
stmts, declared at line 489, is initialised to some
sensible default value, under all possible execution paths.

I found this possible problem by bootstrapping gcc trunk
with clang.

[Bug c/56467] gcc fails to link binaries with unknown reference complaint

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Marek Polacek  ---
Feedback not coming.

[Bug c/52903] cppopts.texi, invoke.texi @itemx without @item

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Seems to be fixed in r192887.

[Bug c/52632] GCC compfail on O0

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #8 from Marek Polacek  ---
Then this looks as invalid.

[Bug c/48777] duplicate pointers to empty structs passed as arguments to function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #3 from Marek Polacek  ---
Thus closing.

[Bug java/60667] New: Undefined behavior in Java FE

[jakub at gcc dot gnu.org]

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

Bug ID: 60667
   Summary: Undefined behavior in Java FE
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: aph at gcc dot gnu.org

Undefined behavior in java FE.

In --with-build-config=bootstrap-ubsan i686 trunk bootstrap I'm getting
several:
../../gcc/double-int.c:1064:33: runtime error: shift exponent -65 is negative
errors (and similar), e.g. on:
/usr/src/gcc/obj985a/./gcc/gcj
-B/usr/src/gcc/obj985a/i686-pc-linux-gnu/libjava/ -B/usr/src/gcc/obj985a/./gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include -isystem
/usr/local/i686-pc-linux-gnu/sys-include -ffloat-store -fomit-frame-pointer
-Usun -fclasspath= -fbootclasspath=../../../libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c
-fsource-filename=/usr/src/gcc/obj985a/i686-pc-linux-gnu/libjava/classpath/lib/classes
-MT gnu/java/awt.lo -MD -MP -MF gnu/java/awt.deps @gnu/java/awt.list -fPIC -o
gnu/java/.libs/awt.o

This happens on:
#0  double_int::set_bit (this=0xc920, bitpos=4294967295) at
../../gcc/double-int.c:1064
#1  0x08258b8a in mark_reference_fields (field=0xf79c1844, mask=, pointer_after_end=0xc920, all_bits_set=0x8258e06, 
last_set_index=0xc90c, last_view_index=0xc910, ubit=32) at
../../gcc/java/boehm.c:110

p int_byte_position (field)
$12 = 128
p ubit
$13 = 32
p int_size_in_bytes (field->typed.type)
$17 = 4
Thus count is 32, ubit 32, size_words 1 and ubit - count - i - 1 is -1,
thus
*mask = (*mask).set_bit (ubit - count - i - 1);
is set_bit (0x) and attempts to shift up by (int) (0x - 64).

p debug_tree (field)
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0xf79b1ba0 fields

pointer_to_this  chain >
unsigned SI size 
unit size 
align 32 symtab 0 alias set -1 canonical type 0xf79b1c00
pointer_to_this >
unsigned decl_5 SI file
/usr/src/gcc/libjava/classpath/java/awt/Component.java line 0 col 0 size
 unit size 
align 32 offset_align 128
offset 
constant 128>
bit offset  constant 0> context 
chain >
$18 = void


Can you please fix this, I have no idea what this code tries to do and why.

[Bug java/60667] Undefined behavior in Java FE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
CCing also Tom as he is listed as author.

[Bug ipa/60315] [4.8/4.9 Regression] template constructor switch optimization

[rguenther at suse dot de]

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

--- Comment #15 from rguenther at suse dot de  ---
On Wed, 26 Mar 2014, hubicka at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
> 
> --- Comment #14 from Jan Hubicka  ---
> The compile time hog issue is fixed now.  We still fix the predicates for
> switch statement (to get pass NOP_EXPR) since it seems very common pattern. 
> Richard: I suppose we can't fold away the NOP_EXPR easily earlier?

forwprop would do that, but the enum is unsigned int while the
switch value is int and thus simplify_gimple_switch bails out
because the conversion is not value-preserving.

So the frontend would need to be changed here or we need to
"complicate" the transform by not looking at the type of
the existing switch argument but instead by looking at the
actual switch label values to see if their value would be
preserved.  But yes, that enum -> int conversion asked for
by the C++ standard seems to be common that this should be
worth the trouble.

[Bug c/60668] New: simplify-rtx.c:1676: minor tidyup in if ... else chain

[dcb314 at hotmail dot com]

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

Bug ID: 60668
   Summary: simplify-rtx.c:1676: minor tidyup in if ... else chain
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

Source code is

  if (arg0 == 0)
val = GET_MODE_PRECISION (mode) - 1;
  else if (arg0 >= 0)
val = GET_MODE_PRECISION (mode) - floor_log2 (arg0) - 2;
  else if (arg0 < 0)
val = GET_MODE_PRECISION (mode) - floor_log2 (~arg0) - 2;

Second if overlaps first and third if looks redundant.
Maybe better code might be

  if (arg0 == 0)
val = GET_MODE_PRECISION (mode) - 1;
  else if (arg0 > 0)
val = GET_MODE_PRECISION (mode) - floor_log2 (arg0) - 2;
  else
val = GET_MODE_PRECISION (mode) - floor_log2 (~arg0) - 2;

[Bug other/59545] Signed integer overflow issues

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ian at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
During bootstrap-ubsan, I'm still seeing tons of:
../../gcc/go/gofrontend/expressions.cc:3652:18: runtime error: load of value
196636864, which is not a valid value for type 'Operator'
and similar errors (something for Ian), plus PR60667, and in the testsuite e.g.
../../gcc/ira.c:2597:24: runtime error: signed integer overflow: -2144862208 +
-62586880 cannot be represented in type 'int'
../../gcc/tree-data-ref.c:2334:38: runtime error: signed integer overflow:
1073741824 + 1073741824 cannot be represented in type 'int'
../../gcc/tree-ssa-loop-ivopts.c:4148:24: runtime error: signed integer
overflow: -1 * -9223372036854775808 cannot be represented in type 'long long
int'
../../libiberty/cp-demangle.c:4039:40: runtime error: variable length array
bound evaluates to non-positive value 0
../../gcc/fortran/interface.c:2667:43: runtime error: load of value 1818451807,
which is not a valid value for type 'expr_t'
../../gcc/fortran/trans-array.c:2207:9: runtime error: load of value 100, which
is not a valid value for type 'bool'

just to name some unique ones for which I don't have a fix.

[Bug sanitizer/60636] ubsan doesn't instrument signed integer ABS_EXPR

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 26 09:18:26 2014
New Revision: 208841

URL: http://gcc.gnu.org/viewcvs?rev=208841&root=gcc&view=rev
Log:
PR sanitizer/60636
* ubsan.c (instrument_si_overflow): Instrument ABS_EXPR.

* c-c++-common/ubsan/pr60636.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr60636.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/ubsan.c

[Bug sanitizer/56781] boostrap-asan failure: fixincl fails to link (missing -lasan)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 26 09:19:44 2014
New Revision: 208842

URL: http://gcc.gnu.org/viewcvs?rev=208842&root=gcc&view=rev
Log:
PR sanitizer/56781
* Makefile.def: Set bootstrap=true; for host fixincludes.
* configure.ac: Don't bootstrap host fixincludes unless
--with-build-config=bootstrap-{a,ub}san.
* Makefile.in: Regenerated.
* configure: Regenerated.

Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in
trunk/configure
trunk/configure.ac

[Bug java/60667] Undefined behavior in Java FE

[aph at redhat dot com]

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

Andrew Haley  changed:

   What|Removed |Added

 CC||aph at redhat dot com

--- Comment #2 from Andrew Haley  ---
I can't investigate this with today's trunk, because it does not build with
ubsan:

i386 /scratch/gcc/configure --with-build-config=bootstrap-ubsan
--enable-languages=java


/scratch/gcc/obj-i686-pc-linux-gnu/./prev-gcc/xg++
-B/scratch/gcc/obj-i686-pc-linux-gnu/./prev-gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -nostdinc++
-B/scratch/gcc/obj-i686-pc-linux-gnu/prev-i686-pc-linux-gnu/libstdc++-v3/src/.libs
-B/scratch/gcc/obj-i686-pc-linux-gnu/prev-i686-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/scratch/gcc/obj-i686-pc-linux-gnu/prev-i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu

-I/scratch/gcc/obj-i686-pc-linux-gnu/prev-i686-pc-linux-gnu/libstdc++-v3/include
 -I/scratch/gcc/libstdc++-v3/libsupc++
-L/scratch/gcc/obj-i686-pc-linux-gnu/prev-i686-pc-linux-gnu/libstdc++-v3/src/.libs
-L/scratch/gcc/obj-i686-pc-linux-gnu/prev-i686-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-c   -g -O2 -fsanitize=undefined -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/scratch/gcc/gcc
-I/scratch/gcc/gcc/build -I/scratch/gcc/gcc/../include 
-I/scratch/gcc/gcc/../libcpp/include  \
-o build/read-rtl.o /scratch/gcc/gcc/read-rtl.c
/scratch/gcc/gcc/read-rtl.c: In function 'bool read_rtx(const char*,
rtx_def**)':
/scratch/gcc/gcc/read-rtl.c:1031:1: internal compiler error: Segmentation fault
 read_rtx (const char *rtx_name, rtx *x)
 ^
0xda18f2 crash_signal
/scratch/gcc/gcc/toplev.c:337
0x5ea774 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/scratch/gcc/gcc/tree.h:2826
0xd9282f place_field(record_layout_info_s*, tree_node*)
/scratch/gcc/gcc/stor-layout.c:1076
0xd98085 layout_type(tree_node*)
/scratch/gcc/gcc/stor-layout.c:2292
0xdc4480 ubsan_create_data(char const*, unsigned int, ubsan_mismatch_data
const*, ...)
/scratch/gcc/gcc/ubsan.c:465
0xdc4829 ubsan_instrument_unreachable(unsigned int)
/scratch/gcc/gcc/ubsan.c:517
0x92d8cb fold_builtin_0
/scratch/gcc/gcc/builtins.c:10306
0x93022c fold_builtin_n
/scratch/gcc/gcc/builtins.c:1
0x93a145 fold_call_stmt(gimple_statement_base*, bool)
/scratch/gcc/gcc/builtins.c:14251
0xb2690b gimple_fold_builtin(gimple_statement_base*)
/scratch/gcc/gcc/gimple-fold.c:888
0xb27967 gimple_fold_call
/scratch/gcc/gcc/gimple-fold.c:1179
0xb27d6d fold_stmt_1
/scratch/gcc/gcc/gimple-fold.c:1258
0xb282fb fold_stmt(gimple_stmt_iterator*)
/scratch/gcc/gcc/gimple-fold.c:1366
0xe2140c fold_marked_statements
/scratch/gcc/gcc/tree-inline.c:4497
0xe2188e optimize_inline_calls(tree_node*)
/scratch/gcc/gcc/tree-inline.c:4622
0x1492868 inline_transform(cgraph_node*)
/scratch/gcc/gcc/ipa-inline-transform.c:453
0xcb73f0 execute_one_ipa_transform_pass
/scratch/gcc/gcc/passes.c:2066
0xcb7557 execute_all_ipa_transforms()
/scratch/gcc/gcc/passes.c:2107
0x9951c4 expand_function
/scratch/gcc/gcc/cgraphunit.c:1767
0x9957e1 expand_all_functions
/scratch/gcc/gcc/cgraphunit.c:1908
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [build/read-rtl.o] Error 1
make[3]: Leaving directory `/scratch/gcc/obj-i686-pc-linux-gnu/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/scratch/gcc/obj-i686-pc-linux-gnu'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/scratch/gcc/obj-i686-pc-linux-gnu'
make: *** [all] Error 2

[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
As discussed yesterday with Ramana on IRC, my suggested fix for this for 4.9 is
something like:
--- gcc/dwarf2out.c2014-03-03 08:24:14.841895755 +0100
+++ gcc/dwarf2out.c2014-03-26 10:42:32.027508796 +0100
@@ -11326,7 +11326,12 @@ const_ok_for_output_1 (rtx *rtlp, void *
 }

   if (GET_CODE (rtl) != SYMBOL_REF)
-return 0;
+{
+  /* NOT is not handled by output_addr_const.  */
+  if (GET_CODE (rtl) == NOT)
+return 1;
+  return 0;
+}

   if (CONSTANT_POOL_ADDRESS_P (rtl))
 {

and for 5.0 we want to gather some statistics what we actually accept as CONST
operands in const_ok_for_output and then successfully emit it into debug info
and assemble that, and based on that adjust const_ok_for_output or it's
callers, so that for CONST expressions that have no chance of being assembled
we actually ignore the CONST around the expression and try to emit it as the
individual expressions.  So, say instead of trying to emit DW_OP_addr
(-1-symbol) in this case which won't assemble we emit it as DW_OP_const1s -1
DW_OP_addr (symbol) DW_OP_minus.

[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand

[ramrad01 at arm dot com]

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

--- Comment #6 from ramrad01 at arm dot com ---
On 03/26/14 09:46, jakub at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655
>
> Jakub Jelinek  changed:
>
> What|Removed |Added
> 
>   CC||jakub at gcc dot gnu.org
>
> --- Comment #5 from Jakub Jelinek  ---
> As discussed yesterday with Ramana on IRC, my suggested fix for this for 4.9 
> is
> something like:
> --- gcc/dwarf2out.c2014-03-03 08:24:14.841895755 +0100
> +++ gcc/dwarf2out.c2014-03-26 10:42:32.027508796 +0100
> @@ -11326,7 +11326,12 @@ const_ok_for_output_1 (rtx *rtlp, void *
>   }
>
> if (GET_CODE (rtl) != SYMBOL_REF)
> -return 0;
> +{
> +  /* NOT is not handled by output_addr_const.  */
> +  if (GET_CODE (rtl) == NOT)
> +return 1;
> +  return 0;
> +}


I have a very similar patch under testing only with a comment linking 
this to the bug report and bootstrapping and regression testing on 
aarch64, armhf and x86_64.

>
> if (CONSTANT_POOL_ADDRESS_P (rtl))
>   {
>
> and for 5.0 we want to gather some statistics what we actually accept as CONST
> operands in const_ok_for_output and then successfully emit it into debug info
> and assemble that, and based on that adjust const_ok_for_output or it's
> callers, so that for CONST expressions that have no chance of being assembled
> we actually ignore the CONST around the expression and try to emit it as the
> individual expressions.  So, say instead of trying to emit DW_OP_addr
> (-1-symbol) in this case which won't assemble we emit it as DW_OP_const1s -1
> DW_OP_addr (symbol) DW_OP_minus.

Agreed.


regards
Ramana



>

[Bug sanitizer/60649] [4.9 Regression][ASAN] Causes "'y' may be used uninitialized" warning (affects bootstrap-asan)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/59908] Incorrect uninit warning with -fsanitize=address caused by LIM

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
*** Bug 60649 has been marked as a duplicate of this bug. ***

[Bug c/51088] undefined label with statement expression and cond expression

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Reduced:
int
main ()
{
  void *L[] = { &&A };
  1 || ({ A: 0; });
}

[Bug java/60667] Undefined behavior in Java FE

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 32458
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32458&action=edit
gcc49-ubsan.patch

Ah, sounds like a very recent regression, most likely Honza's r208831.
Now, this patch makes ubsan more robust, so that it handles even stmts with
UNKNOWN_LOCATION properly, but the question remains if it is ok to change a
call to _ZN3vecIP7mapping7va_heap6vl_ptrE8truncateEj.part.3 (inserted during
fnsplit pass and why it doesn't set gimple_location for that call?) into
__builtin_unreachable ().

[Bug c++/60642] Unclear diagnostic with invalid use of abi_tag attribute on explicit instantiation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Jonathan Wakely  ---
(In reply to Luke Allardyce from comment #3)
> On further inspection it looks like vtable symbols for template classes are
> not being tagged

Let's ask Jason to take a look at that.

[Bug libstdc++/60662] simple use of call_once throws a system_error exception, but not if sleep_for is called beforehand

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
I can't reproduce this with 4.8.1 or later versions on Fedora, or 4.8.3 on
Debian, neither using your original source code nor your preprocessed source.

Please try debugging this yourself or report it to Ubuntu.

[Bug c/51088] undefined label with statement expression and cond expression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
The original testcase has undefined behavior, as documented:
"Jumping into a statement expression with a computed 'goto' (*note Labels as
Values::) has undefined behavior."
So, just don't do that.

[Bug sanitizer/60636] ubsan doesn't instrument signed integer ABS_EXPR

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug debug/28767] GCC should output DW_TAG_ptr_to_member for member functions

[mark at gcc dot gnu.org]

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

--- Comment #5 from Mark Wielaard  ---
Some discussion of the patch in comment #4 can be found here:
http://gcc.gnu.org/ml/gcc-patches/2011-05/threads.html#00225

[Bug tree-optimization/60669] New: VRP misses asserts for some already defined statements

[pinskia at gcc dot gnu.org]

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

Bug ID: 60669
   Summary: VRP misses asserts for some already defined statements
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org

Take (derived from gcc.dg/tree-ssa/vrp65.c):
extern void link_error (void);

void
f7 (int s)
{
  unsigned t = s;
  if ((s & 0x3cc0) == 0x3cc0)
{
  if (t <= 0x3cbf)
link_error ();
}
  else
{
  if (t + 64 <= 63)
link_error ();
}
}

--- CUT ---
Notice how VRP does not insert an assert for t in either side of the if
statement even though it could figure out its range.

This shows up when I was adding a pass which takes common code and hoists them
up.

[Bug target/60504] [4.9 regression] many Ada testsuite regressions on ARM/Linux

[mikpelinux at gmail dot com]

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

--- Comment #12 from Mikael Pettersson  ---
(In reply to Mikael Pettersson from comment #10)
> (In reply to Eric Botcazou from comment #9)
> > That's good news, thanks.  Did you do a testsuite run for all languages?
> 
> Sorry, didn't have time for that -- the repeated 4.9 builds and tests caused
> other build-and-test jobs to pile up and I need to get those done first.

I've now done full before-and-after bootstrap+testsuite runs with
--enable-languages=all,ada,go,obj-c++ on armv5tel-linux-gnueabi: Eric's patch
fixed all Ada regressions, and added no new regressions.

[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor

[dave.anglin at bell dot net]

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

--- Comment #41 from dave.anglin at bell dot net ---
On 25-Mar-14, at 11:14 AM, dominiq at lps dot ens.fr wrote:

> After r208780 (for 4.9, not backported yet to 4.8)?

Yes, it still fails on hppa2.0w-hp-hpux11.11.  Maybe list is shorter:

Unsupported rounding for real(16)
(en15.0)  9.E+03  expected:  10.E+03
(en15.0)  9.E+03  expected:  10.E+03
(en15.1) 9.9E+03  expected: 10.0E+03
(en15.1) 9.9E+03  expected: 10.0E+03
(en15.0) -9.E+03  expected: -10.E+03
(en15.0) -9.E+03  expected: -10.E+03
(en15.1)-9.9E+03  expected:-10.0E+03
(en15.1)-9.9E+03  expected:-10.0E+03
(en15.1)   987.3E+03  expected:987.4E+03
(en15.1)   987.3E+03  expected:987.4E+03
(en15.2)   98.77E+03  expected:98.76E+03
(en15.2)   98.77E+03  expected:98.76E+03
(en15.1)  -987.3E+03  expected:   -987.4E+03
(en15.1)  -987.3E+03  expected:   -987.4E+03
(en15.2)  -98.77E+03  expected:   -98.76E+03
(en15.2)  -98.77E+03  expected:   -98.76E+03

Dave
--
John David Anglindave.ang...@bell.net

[Bug tree-optimization/60669] VRP misses asserts for some already defined statements

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
because it's not used in the paths dominated by the conditional.

[Bug ipa/60659] [4.9 Regression] ICE in get_polymorphic_call_info, at ipa-devirt.c:1292

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor

[dominiq at lps dot ens.fr]

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

--- Comment #42 from Dominique d'Humieres  ---
> > After r208780 (for 4.9, not backported yet to 4.8)?
>
> Yes, it still fails on hppa2.0w-hp-hpux11.11.  Maybe list is shorter:
>
> Unsupported rounding for real(16)
> ...

So the line

! { dg-final { scan-file fmt_en.res "All kinds rounded to nearest" { xfail
i?86-*-solaris2.9* } } }

should be replaced with

! { dg-final { scan-file fmt_en.res "All kinds rounded to nearest" { xfail {
i?86-*-solaris2.9* hppa*-*-hpux11* } } } }

However I don't understand why you get the outputs, the corresponding tests are
supposed to be skipped if the rounding is not to nearest as detected.

Can you uncomment the line

!print *, n_tst, n_cnt

and post the corresponding output?

[Bug tree-optimization/59908] Incorrect uninit warning with -fsanitize=address caused by LIM

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
PR39612?

[Bug middle-end/60419] [4.8 Regression] ICE Segmentation fault

[jamborm at gcc dot gnu.org]

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

--- Comment #20 from Martin Jambor  ---
Author: jamborm
Date: Wed Mar 26 13:47:46 2014
New Revision: 208844

URL: http://gcc.gnu.org/viewcvs?rev=208844&root=gcc&view=rev
Log:
2014-03-26  Martin Jambor  

  PR ipa/60419
  * ipa.c (symtab_remove_unreachable_nodes): Clear thunk and
  alias flags of nodes in the border.

testsuite/
  * g++.dg/ipa/pr60419.C: New test.


Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/ipa/pr60419.C
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/ipa.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug ipa/60659] [4.9 Regression] ICE in get_polymorphic_call_info, at ipa-devirt.c:1292

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r205019.

[Bug middle-end/60419] [4.8 Regression] ICE Segmentation fault

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #21 from Martin Jambor  ---
Fixed on 4.8 as well.

[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor

[dave.anglin at bell dot net]

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

--- Comment #43 from dave.anglin at bell dot net ---
On 3/26/2014 8:51 AM, dominiq at lps dot ens.fr wrote:
> Can you uncomment the line
>
>  !print *, n_tst, n_cnt
>
> and post the corresponding output?
(en15.2) -98.77E+03  expected:   -98.76E+03
  190  16

Infinite recursion in a function called memset

[Nick Clifton]

Hi Guys,

  Suppose a programmer creates a function called "memset" and then
  compiles it with gcc.  Eg:

% cat memset.c

void *
memset (void *s, int c, unsigned int n)
{
  char *v = s;

  while (n--)
 *v++ =  c;
   return s;
}

% gcc -O3 -S -fno-builtin memset.c
% cat memset.s

memset:
.LFB0:
.cfi_startproc
testl   %edx, %edx
je  .L6
subl$1, %edx
subq$8, %rsp
.cfi_def_cfa_offset 16
movsbl  %sil, %esi
addq$1, %rdx
callmemset
addq$8, %rsp
.cfi_def_cfa_offset 8
ret

  Note the infinite recursion.  Memset calls memset which calls memset
  and so on.  This is with an x86_64 compiler built from today's
  sources, but the problem exists for all targets.  The "-fno-builtin"
  is just to avoid the warning about the conflicting types of the memset
  function, but the "-O3" is necessary in order to make gcc detect the
  loop and decide to expand it via a library function.

  Now presumably the programmer knows that there is a library function
  called memset, but also presumably they have their own reasons for
  creating a memset function.  Perhaps they want to add some extra
  annotation or debugging.  It does not seem illegal though.  A program
  provided function should take precedence over a library provided one.

  Anyway it seems to me that gcc should not attempt to call a function
  called "memset" if it is compiling code inside a function called
  "memset".  The problem is, I cannot see an easy way of enforcing this.
  The memset builtin expander is called from several different places
  and I am not at all sure how, or if, they should be modified.  Any
  clues ?

Cheers
  Nick

[Bug libgomp/60670] New: omp.h may differ between multilibs

[ro at gcc dot gnu.org]

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

Bug ID: 60670
   Summary: omp.h may differ between multilibs
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Host: *-*-solaris2.*, x86_64-unknown-linux-gnu
Target: *-*-solaris2.*, x86_64-unknown-linux-gnu
 Build: *-*-solaris2.*, x86_64-unknown-linux-gnu

It has been noticed that the libgomp omp.h header that is generated at build
time
may differ between different multilibs.  E.g. 

* i386-pc-solaris2.11:

--- omp.h   2014-03-21 14:27:34.522529041 +0100
+++ ../amd64/libgomp/omp.h  2014-03-21 14:27:56.903263206 +0100
@@ -34,13 +34,13 @@
 typedef struct
 {
   unsigned char _x[48] 
-__attribute__((__aligned__(4)));
+__attribute__((__aligned__(8)));
 } omp_lock_t;

 typedef struct
 {
-  unsigned char _x[56] 
-__attribute__((__aligned__(4)));
+  unsigned char _x[64] 
+__attribute__((__aligned__(8)));
 } omp_nest_lock_t;
 #endif

* sparc-sun-solaris2.11:

--- omp.h   2014-03-21 15:26:13.738263000 +0100
+++ ../sparcv9/libgomp/omp.h2014-03-21 15:26:49.743545700 +0100
@@ -39,7 +39,7 @@

 typedef struct
 {
-  unsigned char _x[56] 
+  unsigned char _x[64] 
 __attribute__((__aligned__(8)));
 } omp_nest_lock_t;
 #endif

* x86_64-unknown-linux-gnu:

--- omp.h   2014-03-21 19:02:19.351059178 +0100
+++ ../32/libgomp/omp.h 2014-03-21 19:02:30.432588699 +0100
@@ -39,8 +39,8 @@

 typedef struct
 {
-  unsigned char _x[16] 
-__attribute__((__aligned__(8)));
+  unsigned char _x[12] 
+__attribute__((__aligned__(4)));
 } omp_nest_lock_t;
 #endif

Unfortunately, only the version for the default multilib is installed.  Given
that variables of those types can be allocated by user code and size and/or
alignment can differ between different multilibs, this can lead to all sorts
of errors when the allocations performed are smaller than what libgomp assumes.

It seems like different per-multilib headers need to be installed into separate
hierarchies to handle this.

  Rainer

[Bug target/60606] ICE [ARM] error: insn does not satisfy its constraints

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Richard Earnshaw  ---
>register unsigned long pc asm("pc");

I think it's a mistake to permit this sort of construct.  

What does:

  a = pc;
  b = a+pc;

generate for b?  Is it exactly twice a (the compiler doesn't see pc changing,
so is free to assume that it doesn't), just more than twice a (how much more?)
or just less than twice a (different scheduling)?  What happens if the user
writes

  pc = 3; // ???

The point is that while it might be valid to use pc in assembly instructions,
the constructs you get in high-level languages are essentially meaningless.

As has been pointed out, in the few cases where you really need to extract the
program counter you can write an inline assembly statement that explicitly
references the PC.

[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor

[dominiq at lps dot ens.fr]

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

--- Comment #44 from Dominique d'Humieres  ---
What is the output of

  use ISO_FORTRAN_ENV
  print *, REAL_KINDS
end

?

[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor

[dave.anglin at bell dot net]

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

--- Comment #45 from dave.anglin at bell dot net ---
On 3/26/2014 11:09 AM, dominiq at lps dot ens.fr wrote:
> What is the output of
>
>use ISO_FORTRAN_ENV
>print *, REAL_KINDS
> end
>
> ?
4 8  16

[Bug testsuite/60671] New: FAIL: g++.dg/pr49718.C -std=gnu++98 scan-assembler-times __cyg_profile_func_enter 1

[danglin at gcc dot gnu.org]

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

Bug ID: 60671
   Summary: FAIL: g++.dg/pr49718.C -std=gnu++98
scan-assembler-times __cyg_profile_func_enter 1
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/test/gnu
/gcc/objdir/gcc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/pr49
718.C  -fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/tes
t/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.1
1 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/
gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
 -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++98
 -O2 -finstrument-functions  -S  -o pr49718.s(timeout = 300)
spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/test/gnu/gcc/objdir/g
cc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/pr49718.C
-fno-di
agnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/test/gnu/gcc/objdi
r/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/g
cc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc/libstdc
++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gc
c/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -O2
-finstrume
nt-functions -S -o pr49718.s
PASS: g++.dg/pr49718.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/pr49718.C -std=gnu++98  scan-assembler-times
__cyg_profile_func_enter 1

There are two instances in assembler file:
bl __cyg_profile_func_enter,%r2
.IMPORT __cyg_profile_func_enter,CODE


Similar fail:
FAIL: g++.dg/pr49718.C -std=gnu++11  scan-assembler-times
__cyg_profile_func_enter 1

[Bug testsuite/60672] New: FAIL: g++.dg/cpp1y/auto-fn25.C -std=gnu++1y (test for errors, line 7)

[danglin at gcc dot gnu.org]

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

Bug ID: 60672
   Summary: FAIL: g++.dg/cpp1y/auto-fn25.C -std=gnu++1y  (test for
errors, line 7)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/test/gnu
/gcc/objdir/gcc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp1
y/auto-fn25.C  -fno-diagnostics-show-caret -fdiagnostics-color=never 
-nostdinc+
+
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-
hpux11.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/t
est/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/
backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0
-std
=gnu++1y -flto  -S  -o auto-fn25.s(timeout = 300)
spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/test/gnu/gcc/objdir/g
cc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp1y/auto-fn25.C
 -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/test/gnu/g
cc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/te
st/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc
/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/tes
t/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++1y -flto
-S -o auto-fn25.s
cc1plus: error: LTO support has not been enabled in this configuration
compiler exited with status 1
output is:
cc1plus: error: LTO support has not been enabled in this configuration

FAIL: g++.dg/cpp1y/auto-fn25.C -std=gnu++1y  (test for errors, line 7)
FAIL: g++.dg/cpp1y/auto-fn25.C -std=gnu++1y (test for excess errors)

[Bug target/60504] [4.9 regression] many Ada testsuite regressions on ARM/Linux

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  ---
> I've now done full before-and-after bootstrap+testsuite runs with
> --enable-languages=all,ada,go,obj-c++ on armv5tel-linux-gnueabi: Eric's
> patch fixed all Ada regressions, and added no new regressions.

Many thanks to both of you for the testing, hopefully the patch will be OKed.

[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor

[dominiq at lps dot ens.fr]

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

--- Comment #46 from Dominique d'Humieres  ---
AFAICT on hppa*-*-hpux11* the E format does not round to nearest for tie. What
is the output of the following test

#include "stdio.h"
int main() {
printf("%.1e %.1e\n", 9950.0, 9750.0);
return 0;
}

? On x86_64-apple-darwin13, I get '1.0e+04 9.8e+03'.

[Bug c++/60673] New: c++11 static thread_local members may cause a segfault when accessed via 'this->'

[michael at ensslin dot cc]

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

Bug ID: 60673
   Summary: c++11 static thread_local members may cause a segfault
when accessed via 'this->'
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michael at ensslin dot cc

In the following minimal example, f() causes a segfault in the compiled
program, while g() and h() don't.
Note that the error also occurs in clang++.

mic@mic-nb $ cat test.cpp
#include 

struct A{
static thread_local std::string s;

void f() {
this->s = "segv";
}

void g() {
A::s ="no segv";
}

void h() {
s =   "no segv";
}
};

thread_local std::string A::s;

int main() {
A{}.f();
return 0;
}

mic@mic-nb $ g++ -std=c++11 -lpthread test.cpp 
mic@mic-nb $ ./a.out 
[1]11729 segmentation fault (core dumped)  ./a.out
mic@mic-nb $ clang++ -std=c++11 -lpthread test.cpp
mic@mic-nb $ ./a.out 
[1]11764 segmentation fault (core dumped)  ./a.out

Precise versions of installed software:

mic@mic-nb $ g++ --version
g++ (GCC) 4.8.2 20140206 (prerelease)
Copyright (C) 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.
mic@mic-nb $ clang++ --version
clang version 3.4 (tags/RELEASE_34/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
mic@mic-nb $ uname -a
Linux mic-nb 3.13.6-1-ARCH #1 SMP PREEMPT Fri Mar 7 22:47:48 CET 2014 x86_64
GNU/Linux

[Bug ipa/60674] New: missed devirtualization in function called by destructor

[jason at gcc dot gnu.org]

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

Bug ID: 60674
   Summary: missed devirtualization in function called by
destructor
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org

My recent patch for 60566 caused us to stop referring to destructors from
construction vtables; as a result, devirt-21.C and devirt-23.C started failing.

The fails aren't a new bug; we are no longer seeing the devirtualization
because we remove the path to wrap() through a virtual call to ~MultiTermDocs
that it occurred along.  But it seems odd to me that it isn't happening on path
through a non-virtual call to ~MultiTermDocs.  -fdump-ipa-cp before my patch
includes

  Jump functions of caller  virtual MultiTermDocs::~MultiTermDocs()/6:
callsite  virtual MultiTermDocs::~MultiTermDocs()/6 -> void
MultiTermDocs::wrap()/3 : 
   param 0: KNOWN TYPE: base  struct MultiTermDocs, offset 0, component
struct MultiTermDocs
 Aggregate passed by reference:
   offset: 0, cst: &MEM[(void *)&_ZTV13MultiTermDocs + 24B]
  Jump functions of caller  MultiTermDocs::~MultiTermDocs()/5:
callsite  MultiTermDocs::~MultiTermDocs()/5 -> void MultiTermDocs::wrap()/3
: 
   param 0: PASS THROUGH: 0, op nop_expr

Why isn't the second callsite also considered KNOWN TYPE, since it's a call
from a 'structor?  The gimple looks like

  iftmp.6_4 = *__vtt_parm_3(D);
  this_5(D)->_vptr.MultiTermDocs = iftmp.6_4;
  MultiTermDocs::wrap (this_5(D));

so we know that the vtable pointer has just been updated.  I've xfailed the
tests for now.

[Bug c++/60566] [4.9 Regression] r208573 omits needed thunks

[jason at gcc dot gnu.org]

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

--- Comment #14 from Jason Merrill  ---
Author: jason
Date: Wed Mar 26 16:50:26 2014
New Revision: 208845

URL: http://gcc.gnu.org/viewcvs?rev=208845&root=gcc&view=rev
Log:
PR c++/60566
PR c++/58678
* class.c (build_vtbl_initializer): Handle abstract dtors here.
* search.c (get_pure_virtuals): Not here.

Added:
trunk/gcc/testsuite/g++.dg/abi/thunk6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/cp/search.c
trunk/gcc/ipa-devirt.c
trunk/gcc/testsuite/g++.dg/ipa/devirt-21.C
trunk/gcc/testsuite/g++.dg/ipa/devirt-23.C

[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)

[jason at gcc dot gnu.org]

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

--- Comment #55 from Jason Merrill  ---
Author: jason
Date: Wed Mar 26 16:50:26 2014
New Revision: 208845

URL: http://gcc.gnu.org/viewcvs?rev=208845&root=gcc&view=rev
Log:
PR c++/60566
PR c++/58678
* class.c (build_vtbl_initializer): Handle abstract dtors here.
* search.c (get_pure_virtuals): Not here.

Added:
trunk/gcc/testsuite/g++.dg/abi/thunk6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/cp/search.c
trunk/gcc/ipa-devirt.c
trunk/gcc/testsuite/g++.dg/ipa/devirt-21.C
trunk/gcc/testsuite/g++.dg/ipa/devirt-23.C

[Bug c++/60675] New: [4.9 regression][aarch64] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[david.abdurachmanov at gmail dot com]

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

Bug ID: 60675
   Summary: [4.9 regression][aarch64] internal compiler error:
Max. number of generated reload insns per insn is
achieved (90)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com

$ rpm --eval "%{_build}"
aarch64-redhat-linux-gnu

Compiles fine with system GCC (gcc version 4.8.1 20130920 (Red Hat 4.8.1-10)
(GCC)).

Fails with pre-4.9.0 (tested 208693 and trunk [208843]).

Compiles fine with trunk on x86_64.

Compiles fine on aarch64 is `-fPIC` is removed from compilation line.

Attaching minimized pre-processed file.

## COMPILE ##

g++ -std=c++11 -O2 -fPIC -o G4ErrorFreeTrajState.cc.o -c
G4ErrorFreeTrajState2.ii

## ICE ##

G4ErrorFreeTrajState2.ii: In member function 'virtual G4int
G4ErrorFreeTrajState::PropagateError(const G4Track*)':
G4ErrorFreeTrajState2.ii:35892:1: internal compiler error: Max. number of
generated reload insns per insn is achieved (90)

 }
 ^

[Bug c++/60675] [4.9 regression][aarch64] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[david.abdurachmanov at gmail dot com]

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

--- Comment #1 from David Abdurachmanov  
---
Seems the testcase is too large. Trimming it more usually causes it not to ICE,
but will try to trim more.

[Bug c++/60675] [4.9 regression][aarch64] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Can you try compiling the testcase with -mno-lra?
Seems like something that could be related to LRA.

[Bug c++/60566] [4.9 Regression] r208573 omits needed thunks

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug ipa/60674] missed devirtualization in function called by destructor

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60674
Bug 60674 depends on bug 60566, which changed state.

Bug 60566 Summary: [4.9 Regression] r208573 omits needed thunks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566

   What|Removed |Added

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

[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand

[ramana at gcc dot gnu.org]

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

--- Comment #7 from Ramana Radhakrishnan  ---
(In reply to Jakub Jelinek from comment #5)
> As discussed yesterday with Ramana on IRC, my suggested fix for this for 4.9
> is something like:
> --- gcc/dwarf2out.c   2014-03-03 08:24:14.841895755 +0100
> +++ gcc/dwarf2out.c   2014-03-26 10:42:32.027508796 +0100
> @@ -11326,7 +11326,12 @@ const_ok_for_output_1 (rtx *rtlp, void *
>  }
>  
>if (GET_CODE (rtl) != SYMBOL_REF)
> -return 0;
> +{
> +  /* NOT is not handled by output_addr_const.  */
> +  if (GET_CODE (rtl) == NOT)
> + return 1;
> +  return 0;
> +}
>  

In addition looks like we need to handle 

(minus (const_int) (sym_ref))  because with the reduced testcase with -g and
removing the -fdata-sections I get an error with 

const ( minus (323) (sym_ref)) and gas won't grok that because there is no
relocation that will deal with this. 


(note 220 219 221 5 (var_location r2 (plus:SI (plus:SI (reg:SI 3 r3 [orig:192
ivtmp.37 ] [192])
(symbol_ref:SI ("*.LANCHOR0") [flags 0x182]))
(const:SI (minus:SI (const_int 323 [0x143])
(symbol_ref:SI ("*.LANCHOR0") [flags 0x182])
NOTE_INSN_VAR_LOCATION)

Uggh this is proving to be more ugly.

[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor

[dave.anglin at bell dot net]

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

--- Comment #47 from dave.anglin at bell dot net ---
On 3/26/2014 12:34 PM, dominiq at lps dot ens.fr wrote:
> AFAICT on hppa*-*-hpux11* the E format does not round to nearest for tie. What
> is the output of the following test
>
> #include "stdio.h"
> int main() {
>  printf("%.1e %.1e\n", 9950.0, 9750.0);
>  return 0;
> }
>
> ? On x86_64-apple-darwin13, I get '1.0e+04 9.8e+03'.
You are correct:
9.9e+03 9.7e+03

[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor

[dominiq at lps dot ens.fr]

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

--- Comment #48 from Dominique d'Humieres  ---
> > AFAICT on hppa*-*-hpux11* the E format does not round to nearest for tie. 
> > What
> > is the output of the following test
> >
> > ...
> >
> > ? On x86_64-apple-darwin13, I get '1.0e+04 9.8e+03'.
> You are correct:
> 9.9e+03 9.7e+03

OK! Unless someone beats me, I'll split the test in two, one for the main
issue, the other one for the round to even on tie.

[Bug middle-end/60640] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor  ---
Created attachment 32459
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32459&action=edit
Possible fix

The problem is that IPA-CP skips thunks when it redirects edges to the
new clones it produces.

I am currently testing this patch which duplicates thunks when
redirecting edges.  It is quite possible it will have issues.  In any
event, Honza, do you have any comments?

[Bug target/60545] Please support the 64-bit Windows/EFI calling convention on x86-64 Linux/ELF

[josh at joshtriplett dot org]

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

--- Comment #2 from Josh Triplett  ---
(In reply to Andrew Pinski from comment #1)
> The attribute is ms_abi.  It is documented in 4.4.0 and above.
> 
> From GCC 4.5.0 docuemtnation:
> http://gcc.gnu.org/onlinedocs/gcc-4.45.0/gcc/Function-Attributes.
> html#Function-Attributes
> 
> ms_abi/sysv_abi
> On 64-bit x86_64-*-* targets, you can use an ABI attribute to indicate which
> calling convention should be used for a function. The ms_abi attribute tells
> the compiler to use the Microsoft ABI, while the sysv_abi attribute tells
> the compiler to use the ABI used on GNU/Linux and other systems. The default
> is to use the Microsoft ABI when targeting Windows. On all other systems,
> the default is the AMD ABI.
> Note, the ms_abi attribute for Windows targets currently requires the
> -maccumulate-outgoing-args option.

Thanks for the clarification.

[Bug c++/60675] [4.9 regression][aarch64] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[david.abdurachmanov at gmail dot com]

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

--- Comment #3 from David Abdurachmanov  
---
With `-mno-lra` compiles fine.

[Bug c++/60675] [4.9 regression][aarch64] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to David Abdurachmanov from comment #1)
> Seems the testcase is too large. Trimming it more usually causes it not to
> ICE, but will try to trim more.

Does compressing it help with the size to attach it?

[Bug target/60675] [4.9 regression][aarch64] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||aarch64-none-linux-gnu
  Component|c++ |target
   Target Milestone|--- |4.9.0

[Bug target/60675] [4.9 regression][aarch64] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[david.abdurachmanov at gmail dot com]

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

--- Comment #5 from David Abdurachmanov  
---
Created attachment 32460
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32460&action=edit
Minimized pre-processed file

[Bug target/60676] New: Add vec_xxsldi, vec_xxpermdi to altivec.h

[meissner at gcc dot gnu.org]

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

Bug ID: 60676
   Summary: Add vec_xxsldi, vec_xxpermdi to altivec.h
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org

When the original ISA 2.06 changes where done, the builtins to do the xxsldi
and xxpermdi instructions were not documented, and the overloaded builtin used
__builtin_vsx_xxsldi and __builtin_vsx_xxpermdi instead of the more normal
__builtin_vec_xxsldi and __builtin_vec_xxpermdi.  The include file altivec.h
should export vec_xxsldi and vec_xxpermdi, no matter what the internal name
used by the compiler.

[Bug c++/60673] c++11 static thread_local members may cause a segfault when accessed via 'this->'

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-26
 Ever confirmed|0   |1

[Bug fortran/59093] Segfault in gfc_trans_pointer_assignment

[matthew.thompson at nasa dot gov]

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

--- Comment #5 from Matt Thompson  ---
An additional thought. You have a reduced test case which dies in Comment #3
(which fails for gfortran 4.9). However, you can make something similar which
succeeds:

program main

implicit none

type :: MAPL_LocStream
  type(MAPL_LocStreamType), pointer :: Ptr
end type

type MAPL_Tiling
   integer :: IM
end type

type MAPL_LocStreamType
   type(MAPL_Tiling), pointer  :: Tiling(:)
end type

contains

  subroutine MAPL_LocStreamGet (GRIDIM)
type(MAPL_LocStream) :: LocStream
integer, pointer :: GRIDIM(:)

integer, pointer :: LP(:)

LP => LocStream%Ptr%Tiling(:)%IM

  end subroutine

end program main


So, it's not that gfortran/gcc can't do the pointer, it's that it can't do it
to a pointer passed through the interface. Note that this still fails:


program main

implicit none

type :: MAPL_LocStream
  type(MAPL_LocStreamType), pointer :: Ptr
end type

type MAPL_Tiling
   integer :: IM
end type

type MAPL_LocStreamType
   type(MAPL_Tiling), pointer  :: Tiling(:)
end type

contains

  subroutine MAPL_LocStreamGet (GRIDIM)
type(MAPL_LocStream) :: LocStream
integer, pointer :: GRIDIM(:)

integer, pointer :: LP(:)

LP => LocStream%Ptr%Tiling(:)%IM
GRIDIM => LP

  end subroutine

end program main

with:
$ gfortran --version
GNU Fortran (GCC) 4.9.0 20140105 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

$ gfortran test.fix.F90
test.fix.F90: In function ‘mapl_locstreamget’:
test.fix.F90:26:0: internal compiler error: Segmentation fault
 GRIDIM => LP
 ^
0x50ff58 ???
../sysdeps/x86_64/elf/start.S:113
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/59296] [c++11] ref-qualified member function is ambiguous

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||paul at preney dot ca

--- Comment #1 from Jonathan Wakely  ---
*** Bug 60631 has been marked as a duplicate of this bug. ***

[Bug c++/60631] [c++11] rvalue this member functions are ambiguous

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
definitely a dup

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

[Bug c++/59296] [c++11] ref-qualified member function is ambiguous

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
reduced:

struct Type
{
  void get() const& { }
  void get() const&& { }
};

int main()
{
  Type{}.get();
}

The ambiguity happens when both overloads are const-qualified and *this is an
rvalue

[Bug target/60675] [4.9 regression][aarch64] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
I can reproduce it, I am trying to reduce it.  Note using -mcpu=cortex-a57 also
causes the internal error to go away.  So I think the scheduler before the
register allocator is causing some differences.

[Bug other/59545] Signed integer overflow issues

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 26 19:32:40 2014
New Revision: 208848

URL: http://gcc.gnu.org/viewcvs?rev=208848&root=gcc&view=rev
Log:
PR other/59545
* real.c (real_to_integer2): Change type of low to UHWI.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/real.c

[Bug libstdc++/59548] [4.7/4.8 Regression] Abort after copying std::unordered_map in debug mode

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Wed Mar 26 19:41:16 2014
New Revision: 208850

URL: http://gcc.gnu.org/viewcvs?rev=208850&root=gcc&view=rev
Log:
PR libstdc++/59548
* include/debug/safe_unordered_base.h (_Safe_unordered_container_base):
Define copy and move constructors that handle iterators correctly.
* testsuite/23_containers/unordered_map/59548.cc: New.

Added:
   
branches/gcc-4_8-branch/libstdc++-v3/testsuite/23_containers/unordered_map/59548.cc
Modified:
branches/gcc-4_8-branch/libstdc++-v3/ChangeLog
branches/gcc-4_8-branch/libstdc++-v3/include/debug/safe_unordered_base.h

[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor

[dave.anglin at bell dot net]

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

--- Comment #49 from dave.anglin at bell dot net ---
On 3/26/2014 2:07 PM, dominiq at lps dot ens.fr wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
>
> --- Comment #48 from Dominique d'Humieres  ---
>>> AFAICT on hppa*-*-hpux11* the E format does not round to nearest for tie. 
>>> What
>>> is the output of the following test
>>>
>>> ...
>>>
>>> ? On x86_64-apple-darwin13, I get '1.0e+04 9.8e+03'.
>> You are correct:
>> 9.9e+03 9.7e+03
> OK! Unless someone beats me, I'll split the test in two, one for the main
> issue, the other one for the round to even on tie.

It looks like hppa rounds toward zero on tie.  I couldn't find any 
documentation on the
subject.  For ia64, HP states that the rounding is according to C99.

[Bug libstdc++/59548] [4.7 Regression] Abort after copying std::unordered_map in debug mode

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.8.3
 Resolution|--- |FIXED
   Target Milestone|--- |4.8.3
Summary|[4.7/4.8 Regression] Abort  |[4.7 Regression] Abort
   |after copying   |after copying
   |std::unordered_map in debug |std::unordered_map in debug
   |mode|mode
  Known to fail||4.7.3, 4.8.2

--- Comment #9 from Jonathan Wakely  ---
Now also fixed for 4.8.3

I don't plan to fix this on the 4.7 branch.

[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor

[dave.anglin at bell dot net]

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

--- Comment #50 from dave.anglin at bell dot net ---
On 3/26/2014 3:43 PM, dave.anglin at bell dot net wrote:
> It looks like hppa rounds toward zero on tie.

This is what the HP-UX Floating-Point Guide says:

If two representable values are equally close to
the true value, choose the one whose least significant
bit is 0.

[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor

[dominiq at lps dot ens.fr]

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

--- Comment #51 from Dominique d'Humieres  ---
> This is what the HP-UX Floating-Point Guide says:
>
> If two representable values are equally close to
> the true value, choose the one whose least significant
> bit is 0.

This is round to even on tie, isn't it?

[Bug tree-optimization/57199] [4.8/4.9 Regression] Bogus warning: iteration NNNN invokes undefined behavior -Waggressive-loop-optimizations

[dichlofos-mv at yandex dot ru]

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

Mikhail Veltishchev  changed:

   What|Removed |Added

 CC||dichlofos-mv at yandex dot ru

--- Comment #7 from Mikhail Veltishchev  ---
(In reply to Paul Pluzhnikov from comment #6)
> > perhaps some __builtin_unreachable assert that size isn't (size_t) -1?
> 
> That works. Thanks for the suggestion.
Please, can you explain how you fixed this? We have almost the same problem.

[Bug fortran/34928] Extension: volatile common blocks

[dominiq at gcc dot gnu.org]

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

--- Comment #11 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Wed Mar 26 20:39:42 2014
New Revision: 208852

URL: http://gcc.gnu.org/viewcvs?rev=208852&root=gcc&view=rev
Log:

PR fortran/34928
* fortran.texi: Document Volatile COMMON as not supported.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.texi

[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor

[dave.anglin at bell dot net]

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

--- Comment #52 from dave.anglin at bell dot net ---
On 3/26/2014 4:20 PM, dominiq at lps dot ens.fr wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
>
> --- Comment #51 from Dominique d'Humieres  ---
>> This is what the HP-UX Floating-Point Guide says:
>>
>> If two representable values are equally close to
>> the true value, choose the one whose least significant
>> bit is 0.
> This is round to even on tie, isn't it?
I'm not sure. The hex representations for 9900.0 (9.9e+3) and 1.0 
(1.0e+4)
are 40c35600 and 40c38800, respectively.  It seems both 
have a
zero least significant bit.  So, something more is needed to break tie 
in this case.

Dave

[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Note the code isn't invalid, just has undefined behavior.

[Bug fortran/60677] New: [4.9 Regression] FAIL: gfortran.dg/ichar_3.f90 -O (test for excess errors)

[hjl.tools at gmail dot com]

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

Bug ID: 60677
   Summary: [4.9 Regression] FAIL: gfortran.dg/ichar_3.f90  -O
(test for excess errors)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com

spawn -ignore SIGHUP
/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/testsuite/gfortran4/../../gfortran
-B/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/testsuite/gfortran4/../../
-B/export/build/gnu/gcc-asan/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libgfortran/
/export/gnu/import/git/gcc/gcc/testsuite/gfortran.dg/ichar_3.f90
-fno-diagnostics-show-caret -fdiagnostics-color=never -O -pedantic-errors -S -o
ichar_3.s
=
==31523==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fffa6562b40 at pc 0x88f360 bp 0x7fffa65628f0 sp 0x7fffa65628e8
WRITE of size 8 at 0x7fffa6562b40 thread T0
#0 0x88f35f in gfc_conv_intrinsic_function_args
/export/gnu/import/git/gcc/gcc/fortran/trans-intrinsic.c:244
#1 0x8b5f34 in gfc_conv_intrinsic_ichar
/export/gnu/import/git/gcc/gcc/fortran/trans-intrinsic.c:4694
#2 0x8b5f34 in gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
/export/gnu/import/git/gcc/gcc/fortran/trans-intrinsic.c:6822
#3 0x86f2a1 in gfc_conv_function_expr
/export/gnu/import/git/gcc/gcc/fortran/trans-expr.c:5559
#4 0x87019a in gfc_conv_expr(gfc_se*, gfc_expr*)
/export/gnu/import/git/gcc/gcc/fortran/trans-expr.c:6310
#5 0x878977 in gfc_conv_expr_val(gfc_se*, gfc_expr*)
/export/gnu/import/git/gcc/gcc/fortran/trans-expr.c:6363
#6 0x88f0d9 in gfc_conv_intrinsic_function_args
/export/gnu/import/git/gcc/gcc/fortran/trans-intrinsic.c:232
#7 0x890b2c in gfc_conv_intrinsic_conversion
/export/gnu/import/git/gcc/gcc/fortran/trans-intrinsic.c:290
#8 0x8b629d in gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
/export/gnu/import/git/gcc/gcc/fortran/trans-intrinsic.c:6711
#9 0x86f2a1 in gfc_conv_function_expr
/export/gnu/import/git/gcc/gcc/fortran/trans-expr.c:5559
#10 0x87019a in gfc_conv_expr(gfc_se*, gfc_expr*)
/export/gnu/import/git/gcc/gcc/fortran/trans-expr.c:6310
#11 0x880346 in gfc_trans_assignment_1
/export/gnu/import/git/gcc/gcc/fortran/trans-expr.c:8000
#12 0x7d9954 in trans_code
/export/gnu/import/git/gcc/gcc/fortran/trans.c:1639
#13 0x84dc30 in gfc_generate_function_code(gfc_namespace*)
/export/gnu/import/git/gcc/gcc/fortran/trans-decl.c:5610
#14 0x735673 in translate_all_program_units
/export/gnu/import/git/gcc/gcc/fortran/parse.c:4535
#15 0x735673 in gfc_parse_file()
/export/gnu/import/git/gcc/gcc/fortran/parse.c:4732
#16 0x7c9719 in gfc_be_parse_file
/export/gnu/import/git/gcc/gcc/fortran/f95-lang.c:188
#17 0x1371cc1 in compile_file /export/gnu/import/git/gcc/gcc/toplev.c:548
#18 0x1376c2b in do_compile /export/gnu/import/git/gcc/gcc/toplev.c:1914
#19 0x1376c2b in toplev_main(int, char**)
/export/gnu/import/git/gcc/gcc/toplev.c:1990
#20 0x3cdda21b44 in __libc_start_main (/lib64/libc.so.6+0x3cdda21b44)
#21 0x5d2de0
(/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/f951+0x5d2de0)

Address 0x7fffa6562b40 is located in stack of thread T0 at offset 176 in frame
#0 0x8b551f in gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
/export/gnu/import/git/gcc/gcc/fortran/trans-intrinsic.c:6527

  This frame has 7 object(s):
[32, 40) 'append_args'
[96, 104) 'len'
[160, 176) 'args' <== Memory access at offset 176 overflows this variable
[224, 248) 'args'
[288, 328) 'ts'
[384, 464) 'se1'
[512, 592) 'argse'
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow
/export/gnu/import/git/gcc/gcc/fortran/trans-intrinsic.c:244
gfc_conv_intrinsic_function_args
Shadow bytes around the buggy address:
  0x100074ca4510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100074ca4520: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00
  0x100074ca4530: 00 00 00 00 00 00 f4 f4 f3 f3 f3 f3 00 00 00 00
  0x100074ca4540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100074ca4550: 00 00 f1 f1 f1 f1 00 f4 f4 f4 f2 f2 f2 f2 00 f4
=>0x100074ca4560: f4 f4 f2 f2 f2 f2 00 00[f4]f4 f2 f2 f2 f2 00 00
  0x100074ca4570: 00 f4 f2 f2 f2 f2 00 00 00 00 00 f4 f4 f4 f2 f2
  0x100074ca4580: f2 f2 00 00 00 00 00 00 00 00 00 00 f4 f4 f2 f2
  0x100074ca4590: f2 f2 00 00 00 00 00 00 00 00 00 00 f4 f4 f3 f3
  0x100074ca45a0: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100074ca45b0: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 

[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Reduced testcase -O2 -march=armv7-a:
void foo (void);

void
bar (int x, int y)
{
  y = ;
  if (x & (1 << y))
foo ();
}

[Bug fortran/60678] New: [4.9 Regression] FAIL: gfortran.dg/intrinsics_kind_argument_1.f90 -O (test for excess errors)

[hjl.tools at gmail dot com]

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

Bug ID: 60678
   Summary: [4.9 Regression] FAIL:
gfortran.dg/intrinsics_kind_argument_1.f90  -O  (test
for excess errors)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com

spawn -ignore SIGHUP
/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/testsuite/gfortran4/../../gfortran
-B/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/testsuite/gfortran4/../../
-B/export/build/gnu/gcc-asan/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libgfortran/
/export/gnu/import/git/gcc/gcc/testsuite/gfortran.dg/intrinsics_kind_argument_1.f90
-fno-diagnostics-show-caret -fdiagnostics-color=never -O -pedantic-errors -S -o
intrinsics_kind_argument_1.s
=
==9199==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fffdb25aff0 at pc 0x88f360 bp 0x7fffdb25ada0 sp 0x7fffdb25ad98
WRITE of size 8 at 0x7fffdb25aff0 thread T0
#0 0x88f35f in gfc_conv_intrinsic_function_args
/export/gnu/import/git/gcc/gcc/fortran/trans-intrinsic.c:244
#1 0x8b5f34 in gfc_conv_intrinsic_ichar
/export/gnu/import/git/gcc/gcc/fortran/trans-intrinsic.c:4694
#2 0x8b5f34 in gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
/export/gnu/import/git/gcc/gcc/fortran/trans-intrinsic.c:6822
#3 0x86f2a1 in gfc_conv_function_expr
/export/gnu/import/git/gcc/gcc/fortran/trans-expr.c:5559
#4 0x87019a in gfc_conv_expr(gfc_se*, gfc_expr*)
/export/gnu/import/git/gcc/gcc/fortran/trans-expr.c:6310
#5 0x87d41b in gfc_conv_expr_reference(gfc_se*, gfc_expr*)
/export/gnu/import/git/gcc/gcc/fortran/trans-expr.c:6445
#6 0x864d40 in gfc_conv_procedure_call(gfc_se*, gfc_symbol*,
gfc_actual_arglist*, gfc_expr*, vec*)
/export/gnu/import/git/gcc/gcc/fortran/trans-expr.c:4242
#7 0x8e1d6c in gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*,
bool) /export/gnu/import/git/gcc/gcc/fortran/trans-stmt.c:408
#8 0x7d9b43 in trans_code
/export/gnu/import/git/gcc/gcc/fortran/trans.c:1717
#9 0x84dc30 in gfc_generate_function_code(gfc_namespace*)
/export/gnu/import/git/gcc/gcc/fortran/trans-decl.c:5610
#10 0x735673 in translate_all_program_units
/export/gnu/import/git/gcc/gcc/fortran/parse.c:4535
#11 0x735673 in gfc_parse_file()
/export/gnu/import/git/gcc/gcc/fortran/parse.c:4732
#12 0x7c9719 in gfc_be_parse_file
/export/gnu/import/git/gcc/gcc/fortran/f95-lang.c:188
#13 0x1371cc1 in compile_file /export/gnu/import/git/gcc/gcc/toplev.c:548
#14 0x1376c2b in do_compile /export/gnu/import/git/gcc/gcc/toplev.c:1914
#15 0x1376c2b in toplev_main(int, char**)
/export/gnu/import/git/gcc/gcc/toplev.c:1990
#16 0x3cdda21b44 in __libc_start_main (/lib64/libc.so.6+0x3cdda21b44)
#17 0x5d2de0
(/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/f951+0x5d2de0)

Address 0x7fffdb25aff0 is located in stack of thread T0 at offset 176 in frame
#0 0x8b551f in gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
/export/gnu/import/git/gcc/gcc/fortran/trans-intrinsic.c:6527

  This frame has 7 object(s):
[32, 40) 'append_args'
[96, 104) 'len'
[160, 176) 'args' <== Memory access at offset 176 overflows this variable
[224, 248) 'args'
[288, 328) 'ts'
[384, 464) 'se1'
[512, 592) 'argse'
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow
/export/gnu/import/git/gcc/gcc/fortran/trans-intrinsic.c:244
gfc_conv_intrinsic_function_args
Shadow bytes around the buggy address:
  0x10007b6435a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007b6435b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
  0x10007b6435c0: f1 f1 00 00 00 00 00 00 00 00 00 00 f4 f4 f3 f3
  0x10007b6435d0: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007b6435e0: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f4 f4 f4
=>0x10007b6435f0: f2 f2 f2 f2 00 f4 f4 f4 f2 f2 f2 f2 00 00[f4]f4
  0x10007b643600: f2 f2 f2 f2 00 00 00 f4 f2 f2 f2 f2 00 00 00 00
  0x10007b643610: 00 f4 f4 f4 f2 f2 f2 f2 00 00 00 00 00 00 00 00
  0x10007b643620: 00 00 f4 f4 f2 f2 f2 f2 00 00 00 00 00 00 00 00
  0x10007b643630: 00 00 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00
  0x10007b643640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global r

[Bug tree-optimization/57199] [4.8/4.9 Regression] Bogus warning: iteration NNNN invokes undefined behavior -Waggressive-loop-optimizations

[ppluzhnikov at google dot com]

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

--- Comment #8 from Paul Pluzhnikov  ---
(In reply to Mikhail Veltishchev from comment #7)

> Please, can you explain how you fixed this? We have almost the same problem.

Here is the fix we deployed (test case from comment#2):

$ diff -u pr57199.cc pr57199a.cc
--- pr57199.cc  2014-03-26 13:50:25.682351842 -0700
+++ pr57199a.cc 2014-03-26 13:54:12.880279926 -0700
@@ -18,6 +18,9 @@
   DestroyElements(mutable_array() + n, s - n);
   }
   static void DestroyElements(T* ptr, size_t num) {
+if (__builtin_expect (num == (size_t) -1, 0)) {
+  __builtin_unreachable();
+}
 for (size_t i = 0; i < num; i++) {
   ptr[i].~T();
 }

[Bug fortran/60576] [4.8/4.9 Regression] FAIL: gfortran.dg/assumed_rank_7.f90

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
H.J. just filed a separate PR about the ichar_3.f90 failure in PR60678.

[Bug fortran/60678] [4.9 Regression] FAIL: gfortran.dg/intrinsics_kind_argument_1.f90 -O (test for excess errors)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576#c4

[Bug middle-end/39284] Computed gotos combined too aggressively

[timo.kreuzer at reactos dot org]

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

Timo Kreuzer  changed:

   What|Removed |Added

 CC||timo.kreuzer at reactos dot org

--- Comment #12 from Timo Kreuzer  ---
Any updates on this (after 5 years)? Or any workarounds?

I tried to do some optimization to my x86 instruction parser code by using
computed gotos. This post
(https://blogs.oracle.com/nike/entry/fast_interpreter_using_gcc_s) suggests
that it should give good speed improvements and the shown compilation results
looked promising.
But the results with newer GCC versions were so bad, I went back to a simple
switch()

The 2 major speed improvements (less instructions / improved branch prediction)
are completely killed by this bug.
Another thing, that I find suspicious (maybe this is some crazy optimization I
just don't understand) is that GCC doesn't generate a single JMP with a memory
operand anymore, but first loads the memory into a register and then does a
register based JMP, even when the load operation is exactly the same in all
cases.

>From the comments it looks like there is already a working patch. Why is it not
committed? I'd really appreaciate if you could fix this asap.

PS: It would be great if you could make this work for switch statements in a
loop as well! Normally people don't hassle with computed gotos, they use a
switch. If this is in a loop and cases go back directly to the switch
statement, the additional jump should be eliminated, possibly duplicating n
instructions from the top of the loop before the switch.