[Bug rtl-optimization/59019] [4.9 regression] ICE in advance_target_bb, at sched-rgn.c:3561

[ebotcazou at gcc dot gnu.org]

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

--- Comment #2 from Eric Botcazou  ---
> Now insn 24 is an unconditional trap and is considered a control flow
> altering insn (see Eric's change for PR29841).  Since we have a control flow
> altering insn in the middle of a block, we trip the checking failure.
> 
> This seems like a pretty fundamental problem.   I can't think of any other
> case where we allow optimizations to turn an insn which does not alter flow
> control into a flow control altering insn (obviously we allow the opposite
> and it's good).

Yet the comment I added should have made it clear that I didn't invent this,
look at the CALL_INSN case just above.  For example, turning a conditional
no-return call into an unconditional one will have the same effect.

> This means that every pass which might potentially turn a conditional trap
> into an unconditional trap would have to run DCE afterwards or otherwise
> cleanup the code after the trap to avoid this problem.  Not good.
> 
> Or we would have to force each optimizer which might potentially turn a
> conditional trap into an unconditional trap run find_many_sub_basic_blocks. 

Yes, that's a generic issue with passes making things unconditional, the CFG
must be updated.

[Bug c++/57520] alias template substitution/deduction failure

[potswa at mac dot com]

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

David Krauss  changed:

   What|Removed |Added

 CC||potswa at mac dot com

--- Comment #3 from David Krauss  ---
To summarize the above, template template argument deduction finds an alias
template used to declare an object instead of the template type the alias
resolved to. This is wrong because alias template specializations are not
distinct types.

The f1/g1 examples are extraneous. f2 matches the alias (wrong) and g2 matches
the type generated by the alias (correct).

One workaround is to simply add a typedef, this fixes overload resolution of
both functions.

   typedef Vec vit;
   vit v;

I still reproduce this in a 4.9 trunk build from mid October.

[Bug rtl-optimization/59019] [4.9 regression] ICE in advance_target_bb, at sched-rgn.c:3561

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-07
 CC||ebotcazou at gcc dot gnu.org,
   ||law at redhat dot com
 Ever confirmed|0   |1

--- Comment #1 from Jeffrey A. Law  ---
This is a latent bug that the path isolation code happens to expose.

The fundamental problem is prior to combine we have the following RTL:

(insn 25 3 6 2 (set (reg/v:SI 340 [ new_i ])
(const_int 0 [0])) j.c:225 -1
 (nil))
(insn 6 25 24 2 (set (reg:BI 343)
(eq:BI (reg/v:SI 340 [ new_i ])
(const_int -1 [0x]))) j.c:225 309 {*cmpsi_normal}
 (expr_list:REG_DEAD (reg/v:SI 340 [ new_i ])
(nil)))
(insn 24 6 15 2 (trap_if (eq (reg:BI 343)
(const_int 0 [0]))
(const_int 0 [0])) -1
 (expr_list:REG_DEAD (reg:BI 343)
(nil)))
(insn 15 24 16 2 (clobber (reg/i:SI 8 r8)) j.c:231 -1
 (expr_list:REG_UNUSED (reg/i:SI 8 r8)
(nil)))


At this stage insn 24 is not considered a control flow altering insn -- it's a
conditional trap.



Combine does its thing and we end with:

(insn 24 6 15 2 (trap_if (const_int 1 [0x1])
(const_int 0 [0])) 363 {*trap}
 (nil))
(insn 15 24 16 2 (clobber (reg/i:SI 8 r8)) j.c:231 -1
 (expr_list:REG_UNUSED (reg/i:SI 8 r8)
(nil)))

Now insn 24 is an unconditional trap and is considered a control flow altering
insn (see Eric's change for PR29841).  Since we have a control flow altering
insn in the middle of a block, we trip the checking failure.

This seems like a pretty fundamental problem.   I can't think of any other case
where we allow optimizations to turn an insn which does not alter flow control
into a flow control altering insn (obviously we allow the opposite and it's
good).

This means that every pass which might potentially turn a conditional trap into
an unconditional trap would have to run DCE afterwards or otherwise cleanup the
code after the trap to avoid this problem.  Not good.

Or we would have to force each optimizer which might potentially turn a
conditional trap into an unconditional trap run find_many_sub_basic_blocks. 
Also not good.

Or we could hack the ia64 port in some horrid way to avoid this problem.  Even
worse.

I'm open to suggestions.

[Bug sanitizer/59029] ICE with builtin function and -fsanitize=address

[y.gribov at samsung dot com]

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

Yury Gribov  changed:

   What|Removed |Added

 CC||y.gribov at samsung dot com

--- Comment #2 from Yury Gribov  ---
Created attachment 31177
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31177&action=edit
Draft patch

Aha, looks like the ICE is caused by destination address being INTEGER_CST
instead of ADDR_EXPR. Attached patch seems to fix this (tested on x86_64).

@Volker: could you add your testcase to Asan testsuite?

-Y

[Bug c++/56710] Using reserved double underscore variable name in a lambda causes internal compiler error

[allan at archlinux dot org]

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

Allan McRae  changed:

   What|Removed |Added

 CC||allan at archlinux dot org

--- Comment #2 from Allan McRae  ---
I had a user report an ICE in gcc-4.8 that is fixed with this change [1].  Is
it possible to get this backported?


[1] https://bugs.archlinux.org/task/35803

[Bug plugins/59028] gengtype 4.7 fails with operator inside GTY-ed struct

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Andrew Pinski  ---
New feature in 4.7 so closing as won't fix. Note c++ support was less supported
in 4.7 which is why it does not work.

[Bug plugins/59028] gengtype 4.7 fails with operator inside GTY-ed struct

[bstarynk at gcc dot gnu.org]

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

--- Comment #2 from Basile Starynkevitch  ---
At least MELT 1.0 for GCC 4.8 did not requires the ugly workarounds in MELT
1.0.1 needed by GCC 4.7

[Bug fortran/58189] Color diagnostics for gfortran

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org
 Depends on||44054, 53552

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Tobias Burnus from comment #1)
> See also PR44054 about re-using the middle-end infrastructure

It is not really middle-end, but yes re-using common infrastructure (instead of
duplicating it) would be nice.

See also:  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53552#c2

This case is slightly harder from PR44054, since the latter only requires that
Fortran diagnostics pass through diagnostics.c but it can go back to Fortran
functions as a fake pretty-printer. In this case, however, the colors are
implemented in the pretty-printer, so Fortran would need to re-implement its
diagnostic printing functions as a pretty printer. Or duplicate the code.

[Bug c++/59030] [4.9 Regression] Caret diagnostic always points to the first line

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
It would be nice to have a few silly tests for caret diagnostics in the
testsuite, but I think dejagnu was making this far from trivial. Perhaps things
have improved since then.

[Bug c/59022] Bogus "warning: conversion to 'short int' from 'int' may alter its value [-Wconversion]"

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  ---
There is a bug report open somewhere about not warning when all operands and
destination have the same type. I seem to remember that I even submitted a
patch, but it got rejected. I think Wconversion is quite noisy otherwise: int +
int can also overflow, but we don't warn about that. Clang doesn't warn either
and they are normally much more noisy than GCC.

[Bug sanitizer/59018] [4.9 Regression] libsanitizer doesn't build for x32

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #13 from H.J. Lu  ---
Fixed.

[Bug target/59034] [4.9 Regression] FAIL gcc.c-torture/compile/20031208-1.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-06
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

[Bug target/59034] [4.9 Regression] FAIL gcc.c-torture/compile/20031208-1.c

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
The fix is obvious:

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index c7ec0c1..a2c81e5 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -1669,7 +1669,7 @@
   split_double_mode (DImode, &operands[1], 1, &operands[2], &operands[3]);

   operands[1] = gen_lowpart (DImode, operands[2]);
-  operands[2] = gen_rtx_MEM (SImode, gen_rtx_PLUS (DImode, stack_pointer_rtx,
+  operands[2] = gen_rtx_MEM (SImode, gen_rtx_PLUS (Pmode, stack_pointer_rtx,
GEN_INT (4)));
 })

@@ -1686,7 +1686,7 @@
   split_double_mode (DImode, &operands[1], 1, &operands[2], &operands[3]);

   operands[1] = gen_lowpart (DImode, operands[2]);
-  operands[2] = gen_rtx_MEM (SImode, gen_rtx_PLUS (DImode, stack_pointer_rtx,
+  operands[2] = gen_rtx_MEM (SImode, gen_rtx_PLUS (Pmode, stack_pointer_rtx,
GEN_INT (4)));
 })

I am testing it now.

[Bug target/59034] [4.9 Regression] FAIL gcc.c-torture/compile/20031208-1.c

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
split2 generates

(insn 26 25 8 2 (set (mem:SI (plus:DI (reg/f:SI 7 sp) 
(const_int 4 [0x4])) [0 S4 A8])
(const_int -1766711296 [0x96b22000])) x.i:4 86
{*movsi_internal} (nil))

DI looks wrong here.

[Bug target/59034] New: [4.9 Regression] FAIL gcc.c-torture/compile/20031208-1.c

[hjl.tools at gmail dot com]

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

Bug ID: 59034
   Summary: [4.9 Regression] FAIL
gcc.c-torture/compile/20031208-1.c
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com

On x86-64, r203247 gave

# ./xgcc -B./ -fno-diagnostics-show-caret -fdiagnostics-color=never -O1 -w -S
/export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/compile/20031208-1.c
-march=corei7 -mx32
/export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/compile/20031208-1.c: In
function ‘bar’:
/export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/compile/20031208-1.c:6:1:
internal compiler error: in plus_constant, at explow.c:86
0x7a4cf2 plus_constant(machine_mode, rtx_def*, long)
/export/gnu/import/git/gcc/gcc/explow.c:86
0x113757d record_store
/export/gnu/import/git/gcc/gcc/dse.c:1547
0x1139fec scan_insn
/export/gnu/import/git/gcc/gcc/dse.c:2620
0x113a34a dse_step1
/export/gnu/import/git/gcc/gcc/dse.c:2735
0x113c4bc rest_of_handle_dse
/export/gnu/import/git/gcc/gcc/dse.c:3697
0x113c6ba execute
/export/gnu/import/git/gcc/gcc/dse.c:3797
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

It may be latent before and shows up with x86 tuning change in
r203171/r203172.

[Bug sanitizer/59018] [4.9 Regression] libsanitizer doesn't build for x32

[hjl at gcc dot gnu.org]

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

--- Comment #12 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Nov  6 21:52:29 2013
New Revision: 204483

URL: http://gcc.gnu.org/viewcvs?rev=204483&root=gcc&view=rev
Log:
Check __x86_64__ for FPU state

PR sanitizer/59018
* sanitizer_common/sanitizer_platform_limits_posix.cc
(struct_user_fpxregs_struct_sz): Initialize to 0 if __x86_64__ is
defined.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc

[Bug sanitizer/59018] [4.9 Regression] libsanitizer doesn't build for x32

[hjl at gcc dot gnu.org]

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

--- Comment #11 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Nov  6 21:51:41 2013
New Revision: 204482

URL: http://gcc.gnu.org/viewcvs?rev=204482&root=gcc&view=rev
Log:
Use 64-bit system types for x86-64

PR sanitizer/59018
* sanitizer_common/sanitizer_platform_limits_linux.cc
(struct_kernel_stat64_sz): Initialize to 0 if __x86_64__ is
defined.
* sanitizer_common/sanitizer_platform_limits_posix.h
(__sanitizer_dirent): Use 64-bit d_ino/d_off if __x86_64__ is
defined.
(__sanitizer___kernel_uid_t): Typedef as unsigned if __x86_64__
is defined.
(__sanitizer___kernel_gid_t): Likewise.
(__sanitizer___kernel_off_t): Typedef as long long if __x86_64__
is defined.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc
trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h

[Bug sanitizer/59018] [4.9 Regression] libsanitizer doesn't build for x32

[hjl at gcc dot gnu.org]

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

--- Comment #10 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Nov  6 21:50:42 2013
New Revision: 204481

URL: http://gcc.gnu.org/viewcvs?rev=204481&root=gcc&view=rev
Log:
Fix internal_clone for x32

PR sanitizer/59018
* sanitizer_common/sanitizer_linux.cc (internal_clone): Allocate
2 64-bit integers to save and restore fn and arg.  Properly load
newtls/child_tidptr into r8/r10.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc

[Bug sanitizer/59018] [4.9 Regression] libsanitizer doesn't build for x32

[hjl at gcc dot gnu.org]

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

--- Comment #9 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Nov  6 21:49:36 2013
New Revision: 204480

URL: http://gcc.gnu.org/viewcvs?rev=204480&root=gcc&view=rev
Log:
Cast pointers to uptr for 64-bit syscalls

PR sanitizer/59018
* sanitizer_common/sanitizer_linux.cc (internal_mmap,
internal_munmap, internal_open, internal_read, internal_write,
internal_stat, internal_lstat, internal_fstat, internal_readlink,
internal_unlink, internal_execve, NanoTime, BlockingMutex::Lock,
BlockingMutex::Unlock, internal_ptrace, internal_getdents,
internal_sigaltstack): Cast pointers to uptr for 64-bit syscalls.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc

[Bug fortran/59023] [4.9 regression] ICE in gfc_search_interface with BIND(C)

[fxcoudert at gcc dot gnu.org]

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

--- Comment #1 from Francois-Xavier Coudert  ---
Using an intermediate variable works around the bug. If you replace:

toto = t(helper())

with

i = helper()
toto = t(i)

where i is an integer variable, you don't have the ICE anymore.

[Bug tree-optimization/59014] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
(In reply to Marek Polacek from comment #4)
> Why does it think that a.1_5 must be 0?

That's because VRP is innocent here after all, it's the forwprop1 what does

-  _6 = a.1_5 & 1;
-  _7 = (_Bool) _6;
+  _7 = (_Bool) a.1_5;

More (hopefully) tomorrow...

[Bug plugins/59028] gengtype 4.7 fails with operator inside GTY-ed struct

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-11-06
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Is this a bug in 4.8 and above?  If not then we should close this as won't fix
as 4.7 is not getting any new features.

[Bug rtl-optimization/30807] postreload bug (might be generic in trunk)

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #14 from Oleg Endo  ---
Test case added to 4.9.  Closed.

[Bug c++/59033] New: cannot control inherited constructors visibility

[akim.demaille at gmail dot com]

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

Bug ID: 59033
   Summary: cannot control inherited constructors visibility
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akim.demaille at gmail dot com

Hi,

Again, I have found no clear wording in the draft of the standard that I have,
however, consistency in the language would expect that "using" to import
constructors should provide them with the _current_ public/protected/private
visibility, not the one of the original constructor.

The following example shows that the "using" on types and "using" on
constructors are not treated the same way.

akim@padam /tmp $ cat foo.cc
struct base
{
protected:
  using type = int;
  base(type, type) {}
};

struct derived: public base
{
public:
  using base::base;
  using base::type;
};

int main()
{
  derived::type i;
  derived b(i,i);
}
akim@padam /tmp $ g++-mp-4.9 -Wall -std=c++11 foo.cc
foo.cc: In function 'int main()':
foo.cc:11:15: error: 'derived::derived(base::type, base::type)' is protected
   using base::base;
   ^
foo.cc:18:16: error: within this context
   derived b(i,i);
^
akim@padam /tmp $ g++-mp-4.9 --version
g++-mp-4.9 (MacPorts gcc49 4.9-20130915_0) 4.9.0 20130915 (experimental)
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.

Same with 4.8.

[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux

[eugeni.stepanov at gmail dot com]

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

--- Comment #2 from Evgeniy Stepanov  ---
As discussed in a email thread on gcc-patches, we will probably move away from
including kernel headers and just define all the types in our code.

[Bug fortran/59026] ELEMENTAL procedure with VALUE arguments emits wrong code

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-06
 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Paul Thomas  ---
Created attachment 31176
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31176&action=edit
Fixes the PR

This is regtesting right now - I'll prepare the testcase and submit, as soon as
it is done.

Best regards

Paul

[Bug c/59022] Bogus "warning: conversion to 'short int' from 'int' may alter its value [-Wconversion]"

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
Reference for completeness: C99, 6.3.1.1, paragraph 2.

[Bug c++/59032] [4.8/4.9 Regression] ICE incrementing vector type

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||ice-on-invalid-code
  Known to work||4.1.0
  Known to fail||4.8.0, 4.9.0

--- Comment #1 from Volker Reichelt  ---
The error message is broken since GCC 4.1.0.
With GCC 4.0.0 I get a decent message:

bug.cc: In function 'void foo()':
bug.cc:4: error: no pre-increment operator for type

[Bug c++/59032] New: [4.8/4.9 Regression] ICE incrementing vector type

[reichelt at gcc dot gnu.org]

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

Bug ID: 59032
   Summary: [4.8/4.9 Regression] ICE incrementing vector type
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following invalid code snippet triggers an ICE since GCC 4.8.0:


void foo()
{
  float v __attribute__((vector_size(8)));
  ++v;
}


bug.cc: In function 'void foo()':
bug.cc:4:5: error: can't convert between vector values of different size
   ++v;
 ^
bug.cc:4:6: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in fold_binary_loc, at fold-const.c:10381
   ++v;
  ^
0xd356c6 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9472
0x91bc32 tree_class_check
../../gcc/gcc/tree.h:2815
0x91bc32 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/gcc/fold-const.c:10381
0x925a2a fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/gcc/fold-const.c:15048
0x90389d fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/gcc/fold-const.c:10035
0x925a2a fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/gcc/fold-const.c:15048
0x98dde6 gimplify_self_mod_expr(tree_node**, gimple_statement_d**,
gimple_statement_d**, bool, tree_node*)
../../gcc/gcc/gimplify.c:2400
0x9872aa gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7665
0x98b956 gimplify_stmt(tree_node**, gimple_statement_d**)
../../gcc/gcc/gimplify.c:5657
0x9884cf gimplify_cleanup_point_expr
../../gcc/gcc/gimplify.c:5433
0x9884cf gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:8088
0x98b956 gimplify_stmt(tree_node**, gimple_statement_d**)
../../gcc/gcc/gimplify.c:5657
0x987f1b gimplify_statement_list
../../gcc/gcc/gimplify.c:1548
0x987f1b gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:8140
0x98b956 gimplify_stmt(tree_node**, gimple_statement_d**)
../../gcc/gcc/gimplify.c:5657
0x98c7e5 gimplify_bind_expr
../../gcc/gcc/gimplify.c:1229
0x9883ac gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7922
0x98b956 gimplify_stmt(tree_node**, gimple_statement_d**)
../../gcc/gcc/gimplify.c:5657
0x98d0ce gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:8832
0x98d626 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:8970
Please submit a full bug report, [etc.]

Btw, the error message seems to be bogus, too. The C-frontend gives a better
diagnostic (and doesn't crash):

bug.c: In function 'foo':
bug.c:4:3: error: wrong type argument to increment
   ++v;

[Bug rtl-optimization/30807] postreload bug (might be generic in trunk)

[olegendo at gcc dot gnu.org]

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

--- Comment #13 from Oleg Endo  ---
Author: olegendo
Date: Wed Nov  6 20:26:35 2013
New Revision: 204473

URL: http://gcc.gnu.org/viewcvs?rev=204473&root=gcc&view=rev
Log:
PR target/30807
* gcc.target/sh/torture/pr30807.c: New.


Added:
trunk/gcc/testsuite/gcc.target/sh/torture/pr30807.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/59031] New: vtable lookup not optimized away

[eraman at google dot com]

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

Bug ID: 59031
   Summary: vtable lookup not optimized away
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eraman at google dot com
CC: jason at redhat dot com

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

The fix to PR c++/11750 at r193504 caused a regression in the following code at
-O0:

class B {
 public:
  virtual int add (int a, int b) {return a+ b;}
};

class D : public B {
};

int foo (int a, int b) {
  D d;
  return d.add(a, b);
}

The call d.add(a, b) used to generate a direct call to B::add, but now
generates an indirect call. At -O2, FRE could devirtualize this in some
situations but not always. The attached patch fixes this case and bootstraps
fine. Is this a reasonable fix?

[Bug c++/59030] [4.9 Regression] Caret diagnostic always points to the first line

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   Target Milestone|--- |4.9.0

[Bug c++/11468] Deriving from CNI class java::lang::Object causing an ICE

[paolo.carlini at oracle dot com]

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

Bug 11468 depends on bug 11006, which changed state.

Bug 11006 Summary: [CNI] ICE with use of __java_boolean
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11006

   What|Removed |Added

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

[Bug java/4439] CNI: would be nice to be able to create Java array with 'new'

[paolo.carlini at oracle dot com]

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

Bug 4439 depends on bug 11006, which changed state.

Bug 11006 Summary: [CNI] ICE with use of __java_boolean
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11006

   What|Removed |Added

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

[Bug c++/11006] [CNI] ICE with use of __java_boolean

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|gcc-bugs at gcc dot gnu.org|
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

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

[Bug c++/11006] [CNI] ICE with use of __java_boolean

[paolo at gcc dot gnu.org]

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

--- Comment #9 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Nov  6 20:19:10 2013
New Revision: 204469

URL: http://gcc.gnu.org/viewcvs?rev=204469&root=gcc&view=rev
Log:
/cp
2013-11-06  Paolo Carlini  

PR c++/11006
* init.c (build_new_1): Don't call build_java_class_ref on non-class
types.

/testsuite
2013-11-06  Paolo Carlini  

PR c++/11006
* g++.dg/other/java3.C: New.

Added:
trunk/gcc/testsuite/g++.dg/other/java3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/59030] [4.9 Regression] Caret diagnostic always points to the first line

[reichelt at gcc dot gnu.org]

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

--- Comment #1 from Volker Reichelt  ---
With yesterday's build I got a correct diagnostic:


bug.cc:5:9: error: expected primary-expression before ';' token
 int j = ;
 ^

[Bug c++/59030] New: [4.9 Regression] Caret diagnostic always points to the first line

[reichelt at gcc dot gnu.org]

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

Bug ID: 59030
   Summary: [4.9 Regression] Caret diagnostic always points to the
first line
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

With today's trunk (4.9.0 20131106) the caret diagnostic always points to the
first line, although the line number is correct. 

==
// First line

int i = 0;

int j = ;
==

The above invalid code snippet produces the error message:


bug.cc:5:9: error: expected primary-expression before ';' token
 // First line
 ^

[Bug sanitizer/59029] ICE with builtin function and -fsanitize=address

[reichelt at gcc dot gnu.org]

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

--- Comment #1 from Volker Reichelt  ---
The broken caret diagnostic seems to be a general problem of today's build.
I'll open a separate bug report for this.

[Bug libstdc++/59027] New: std::is_signed does not include check for is_arithmetic

[marc.mutz at kdab dot com]

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

Bug ID: 59027
   Summary: std::is_signed does not include check for
is_arithmetic
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com

According to N3797 Table 49, both is_signed and is_unsigned should evaluate to
true_type only if the argument is_arithmetic, too. is_unsigned honours this,
but is_signed doesn't:

  template::value>
struct __is_signed_helper
: public false_type { };

  template
struct __is_signed_helper<_Tp, true>
: public integral_constant
{ };

  /// is_signed
  template
struct is_signed
: public __is_signed_helper<_Tp>::type
{ };

  /// is_unsigned
  template
struct is_unsigned
: public __and_, __not_>>::type
{ };

[Bug sanitizer/59029] New: ICE with builtin function and -fsanitize=address

[reichelt at gcc dot gnu.org]

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

Bug ID: 59029
   Summary: ICE with builtin function and -fsanitize=address
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

The following code snippet compiled with "-fsanitize=address -O" triggers an
ICE
since GCC 4.8.0 (when the address-sanitizer was introduced):


inline int foo(int* p)
{
  return __sync_fetch_and_add(p, 1);
}

void bar()
{
  foo(0);
}


bug.c: In function 'bar':
bug.c:6:6: internal compiler error: in get_mem_refs_of_builtin_call, at
asan.c:722
 inline int foo(int* p)
  ^
0x987d46 get_mem_refs_of_builtin_call
../../gcc/gcc/asan.c:722
0x98adb5 has_stmt_been_instrumented_p
../../gcc/gcc/asan.c:801
0x98adb5 transform_statements
../../gcc/gcc/asan.c:1919
0x98be62 asan_instrument
../../gcc/gcc/asan.c:2271
0x98be62 execute
../../gcc/gcc/asan.c:2311
Please submit a full bug report, [etc.]

In addition, the error location of the ICE is broken: the caret points to the
first line of the file whereas the reported line number is 6.

[Bug plugins/59028] New: gengtype 4.7 fails with operator inside GTY-ed struct

[bstarynk at gcc dot gnu.org]

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

Bug ID: 59028
   Summary: gengtype 4.7 fails with operator inside GTY-ed struct
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: plugins
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bstarynk at gcc dot gnu.org

Created attachment 31174
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31174&action=edit
testopgty.h uses the operator keyword inside a GTY-ed struct.

The attached file testopgty.h when run with 

/usr/lib/gcc/x86_64-linux-gnu/4.7.3/gengtype \
   -r /usr/lib/gcc/x86_64-linux-gnu/4.7.3/plugin/gtype.state \
   -P gt-baobab.h testopgty.h

fails with the error:

   testopgty.h:4: unidentified type `operator'

(this is on Debian/Sid, and also on GGC 4.7.3 FSF) 

Addenda:

Actually this bug was first discovered with MELT 1.0 plugin for 4.7 & 4.8 (see
http://gcc-melt.org/ for more about MELT). The MELT bug is
https://sourceforge.net/p/gcc-melt/tickets/6/

A disgusting workaround (for the MELT plugin) is available as MELT 1.0.1 (or
MELT 1.0.1 rc1) - it involves running unifdef to remove "faulty" code - bug the
bug really is in gengtype.

[Bug fortran/56806] make: *** [spher_harm.o] Error 1

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |WORKSFORME

[Bug fortran/59026] New: ELEMENTAL procedure with VALUE arguments emits wrong code

[fxcoudert at gcc dot gnu.org]

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

Bug ID: 59026
   Summary: ELEMENTAL procedure with VALUE arguments emits wrong
code
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org

The following source is compiled into wrong code:

interface
  elemental integer function foo(x)
integer, intent(in), value :: x
  end function
end interface

  print *, foo(42)
  print *, foo([0,1])
end

For all versions of gfortran starting from 4.3 (and up to current trunk), the
second call to FOO is miscompiled. Looking at the generated code
(-fdump-tree-original), the first call is, as expected, by value:

  D.1882 = foo (42);
  _gfortran_transfer_integer_write (&dt_parm.0, &D.1882, 4);

while the second call is by-reference:

  D.1887 = A.2[S.3];
  D.1888 = foo (&D.1887);
  _gfortran_transfer_integer_write (&dt_parm.1, &D.1888, 4);

This can be confirmed by adding an actual FOO function such as:

elemental integer function foo(x)
  integer, intent(in), value :: x
  foo = x - 1
end function

Running the complete program then yields:

  41
  1370438451  1370438451

[Bug target/59021] [4.9 regression] new vzeroupper instructions generated with -mavx

[uros at gcc dot gnu.org]

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

--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Nov  6 19:37:12 2013
New Revision: 204464

URL: http://gcc.gnu.org/viewcvs?rev=204464&root=gcc&view=rev
Log:
PR target/59021
* config/i386/i386.c (ix86_avx_u128_mode_needed): Require
AVX_U128_DIRTY mode for call_insn RTXes that use AVX256 registers.
(ix86_avx_u128_mode_needed): Return AVX_U128_DIRTY mode for call_insn
RTXes that return in AVX256 register.

testsuite/ChangeLog:

PR target/59021
* gcc.target/i386/pr59021.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr59021.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/59025] Revision 203979 causes failure in CPU2006 benchmark 435.gromacs

[pthaugen at gcc dot gnu.org]

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

--- Comment #2 from Pat Haugen  ---
Yes, this still fails with r204348.

I did discover that adding -mrecip=rsqrt allows the benchmark to succeed.

[Bug ada/55946] wrong tools used for build of gnattools [native-cross]

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-06
 CC||ebotcazou at gcc dot gnu.org
Summary|Wrong GNAT tools used on|wrong tools used for build
   |build of gnattools  |of gnattools [native-cross]
   |[native-cross]  |
 Ever confirmed|0   |1

--- Comment #2 from Eric Botcazou  ---
Related work done at http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00146.html

[Bug sanitizer/59018] [4.9 Regression] libsanitizer doesn't build for x32

[kcc at gcc dot gnu.org]

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

--- Comment #8 from Kostya Serebryany  ---
>> I will submit my patches to GCC now.
Ok!

[Bug sanitizer/59018] [4.9 Regression] libsanitizer doesn't build for x32

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
(In reply to Kostya Serebryany from comment #5)
> > Can you try
> > 
> >   register void *r8 __asm__ ("r8") = newtls;
> >   register int *r10 __asm__ ("r10") = child_tidptr;
> Yep, works! 
> 
> > But you need to enable x32 first on your OS, which requires
> > 
> > 1. x32 enabled kernel, Linux kernel >= 3.4.0.
> > 2. x32 glibc.
> 
> This does not match my system. :( 
> Do you have a VM image (e.g. for VMWare player) with such a system? 

I can create an x32 VirtualBox image.  Do you have
a place I can upload it for you?

> > 
> > > 
> > > 2. Is there any chance to test x32 off the clang tree, so that we keep the
> > > upstream tree x32-clean all the time?
> > 
> > There was x32 port of llvm/clang last year.  But only parts
> > of the x32 patches have been merged with llvm.
> 
> Do you need help with this?

Yes, please.  I'd like to work with something to get
x32 support into llvm/clang.


> I'll be on the LLVM dev meeting today and tomorrow, may at least ask around.

[Bug sanitizer/59018] [4.9 Regression] libsanitizer doesn't build for x32

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
(In reply to Kostya Serebryany from comment #4)
> the patches look good and pass our testing on x86_64 and i386. 
> Thanks! 
> committed as
> http://llvm.org/viewvc/llvm-project?view=revision&revision=194155
> (fixed 4 small lint warnings there)
> 
> We have few options: 
> 1. I do another full merge, but most likely next week
> 2. You submit these patches directly to gcc now (this may cause a very minor
> headache at the next merge)

My current build has been failing. I'd like to get it fixed as soon
as possible. I will submit my patches to GCC now.

[Bug sanitizer/59018] [4.9 Regression] libsanitizer doesn't build for x32

[kcc at gcc dot gnu.org]

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

--- Comment #5 from Kostya Serebryany  ---

> Can you try
> 
>   register void *r8 __asm__ ("r8") = newtls;
>   register int *r10 __asm__ ("r10") = child_tidptr;
Yep, works! 

> But you need to enable x32 first on your OS, which requires
> 
> 1. x32 enabled kernel, Linux kernel >= 3.4.0.
> 2. x32 glibc.

This does not match my system. :( 
Do you have a VM image (e.g. for VMWare player) with such a system? 

> 
> > 
> > 2. Is there any chance to test x32 off the clang tree, so that we keep the
> > upstream tree x32-clean all the time?
> 
> There was x32 port of llvm/clang last year.  But only parts
> of the x32 patches have been merged with llvm.

Do you need help with this? 
I'll be on the LLVM dev meeting today and tomorrow, may at least ask around.

[Bug sanitizer/59018] [4.9 Regression] libsanitizer doesn't build for x32

[kcc at gcc dot gnu.org]

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

--- Comment #4 from Kostya Serebryany  ---
the patches look good and pass our testing on x86_64 and i386. 
Thanks! 
committed as http://llvm.org/viewvc/llvm-project?view=revision&revision=194155
(fixed 4 small lint warnings there)

We have few options: 
1. I do another full merge, but most likely next week
2. You submit these patches directly to gcc now (this may cause a very minor
headache at the next merge)

[Bug sanitizer/59018] [4.9 Regression] libsanitizer doesn't build for x32

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
(In reply to Kostya Serebryany from comment #1)
> At least one of these patches does not build with clang:
> 
> /home/kcc/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:
> 807:21: error: ignored asm label 'r8' on automatic variable [-Werror]
>   void *r8 __asm__ ("r8") = newtls;
> ^
> /home/kcc/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:
> 808:21: error: ignored asm label 'r10' on automatic variable [-Werror]
>   int *r10 __asm__ ("r10") = child_tidptr;
> ^
> 
> is this some kind of gcc-specific syntax? 
> (forgive my ignorance here)

Can you try

  register void *r8 __asm__ ("r8") = newtls;
  register int *r10 __asm__ ("r10") = child_tidptr;

as suggested by Jakub?

> Two general questions: 
> 
> 1. Before doing the merge I test the patch like this: 
> rm -rf */{*/,}libsanitizer && make -j 50  && make -C gcc check-g{cc,++} 
> RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp'
> 
> What should I add to this line to also test x32? 

I am using:

RUNTESTFLAGS='--target_board=unix\{-mx32,-m32,-m64\} asan.exp'

But you need to enable x32 first on your OS, which requires

1. x32 enabled kernel, Linux kernel >= 3.4.0.
2. x32 glibc.

> 
> 2. Is there any chance to test x32 off the clang tree, so that we keep the
> upstream tree x32-clean all the time?

There was x32 port of llvm/clang last year.  But only parts
of the x32 patches have been merged with llvm.

[Bug target/59021] [4.9 regression] new vzeroupper instructions generated with -mavx

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #3)
> I have patch in testing.

The call_insn RTX should always define its mode. Previously, the state was
switched to DIRTY by an eventual move to a 256bit function argument register
(even when the move was useless) in front of the call_insn. Nowadays, this is
not true anymore, so call_insn should switch the state to DIRTY mode on its
own.

[Bug sanitizer/59018] [4.9 Regression] libsanitizer doesn't build for x32

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
(In reply to Kostya Serebryany from comment #1)
> At least one of these patches does not build with clang:
> 
> /home/kcc/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:
> 807:21: error: ignored asm label 'r8' on automatic variable [-Werror]
>   void *r8 __asm__ ("r8") = newtls;
> ^
> /home/kcc/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:
> 808:21: error: ignored asm label 'r10' on automatic variable [-Werror]
>   int *r10 __asm__ ("r10") = child_tidptr;
> ^
> 
> is this some kind of gcc-specific syntax? 

There is missing register keyword of course for both.
So
  register void *r8 __asm__ ("r8") = newtls;
  register int *r10 __asm__ ("r10") = child_tidptr;

[Bug sanitizer/59018] [4.9 Regression] libsanitizer doesn't build for x32

[kcc at gcc dot gnu.org]

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

--- Comment #1 from Kostya Serebryany  ---
At least one of these patches does not build with clang:

/home/kcc/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:807:21:
error: ignored asm label 'r8' on automatic variable [-Werror]
  void *r8 __asm__ ("r8") = newtls;
^
/home/kcc/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:808:21:
error: ignored asm label 'r10' on automatic variable [-Werror]
  int *r10 __asm__ ("r10") = child_tidptr;
^

is this some kind of gcc-specific syntax? 
(forgive my ignorance here)

Two general questions: 

1. Before doing the merge I test the patch like this: 
rm -rf */{*/,}libsanitizer && make -j 50  && make -C gcc check-g{cc,++} 
RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp'

What should I add to this line to also test x32? 

2. Is there any chance to test x32 off the clang tree, so that we keep the
upstream tree x32-clean all the time?

[Bug target/59021] [4.9 regression] new vzeroupper instructions generated with -mavx

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-11-06
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Ever confirmed|0   |1

--- Comment #3 from Uroš Bizjak  ---
I have patch in testing.

--cut here--
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 204459)
+++ config/i386/i386.c  (working copy)
@@ -15708,7 +15708,7 @@ ix86_avx_u128_mode_needed (rtx insn)
  rtx arg = XEXP (XEXP (link, 0), 0);

  if (ix86_check_avx256_register (&arg, NULL))
-   return AVX_U128_ANY;
+   return AVX_U128_DIRTY;
}
}

--cut here--

[Bug preprocessor/58580] [4.8 Regression] preprocessor goes OOM with warning for zero literals

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Wed, 6 Nov 2013, dodji at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58580
> 
> Dodji Seketeli  changed:
> 
>What|Removed |Added
> 
>  Status|ASSIGNED|RESOLVED
>  Resolution|--- |FIXED
> 
> --- Comment #7 from Dodji Seketeli  ---
> This should be fixed in trunk for 4.9 by commit
> http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=fc3eff8854861fcd70d33d26095b17fe456fae31
> 
> 
> I'll give it some testing time, and if it turns out to work OK, I'll consider
> backporting the change to 4.8.
> 
> What do you think, Richi?

Yes, backporting would be nice - it affects a few packages for us.

[Bug tree-optimization/59006] [4.9 Regression] internal compiler error: in vect_transform_stmt, at tree-vect-stmts.c:5963

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.8.2
   Last reconfirmed||2013-11-06
  Component|c   |tree-optimization
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|internal compiler error: in |[4.9 Regression] internal
   |vect_transform_stmt, at |compiler error: in
   |tree-vect-stmts.c:5963  |vect_transform_stmt, at
   ||tree-vect-stmts.c:5963
   Target Milestone|--- |4.9.0
  Known to fail||4.9.0

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

[Bug tree-optimization/59025] Revision 203979 causes failure in CPU2006 benchmark 435.gromacs

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Was this before r204348, or can you reproduce it also after that follow-up fix?

[Bug regression/58985] [4.9 Regression]: gcc.dg/pr57518.c scan-rtl-dump-not ira REG_EQUIV...

[wmi at gcc dot gnu.org]

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

--- Comment #7 from wmi at gcc dot gnu.org ---
Author: wmi
Date: Wed Nov  6 17:06:46 2013
New Revision: 204461

URL: http://gcc.gnu.org/viewcvs?rev=204461&root=gcc&view=rev
Log:
2013-11-06  Wei Mi  

PR regression/58985
* testsuite/gcc.dg/pr57518.c: Add subreg in regexp pattern.

Modified:
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr57518.c

[Bug tree-optimization/59025] New: Revision 203979 causes failure in CPU2006 benchmark 435.gromacs

[pthaugen at gcc dot gnu.org]

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

Bug ID: 59025
   Summary: Revision 203979 causes failure in CPU2006 benchmark
435.gromacs
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, jakub at gcc dot gnu.org
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux

435.gromacs started miscomparing on PowerPC with r203979. Compiler options used
are -O3 -m64 -mcpu=power6 -ffast-math. Currently trying to track down an
individual file that is miscompiled so I can provide more detail.

[Bug fortran/59024] New: ICE: after printing certain error messages, the compiler seg faults.

[kimwooyoung at gmail dot com]

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

Bug ID: 59024
   Summary: ICE: after printing certain error messages, the
compiler seg faults.
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kimwooyoung at gmail dot com

This reproducer causes the compiler to seg fault.
The compiler exits normally with the commented-out version.
The reproducer is not a legal fortran program, but the compiler should not die 
with a seg fault.


MODULE mtc
  USE ISO_C_BINDING
  PRIVATE
  PUBLIC :: tc, not_present1, &

  TYPE tc
  END TYPE tc
  INTERFACE tc
MODULE PROCEDURE tc_ctor
  END INTERFACE tc
CONTAINS
!  TYPE(tc) FUNCTION tc_ctor() result(t)
!  END FUNCTION tc_ctor
  FUNCTION tc_ctor() result(t)
TYPE(tc) t
  END FUNCTION tc_ctor
END MODULE mtc



===


gfortran -c gf_reprod.F90
gf_reprod.F90:6.6:

  TYPE tc
  1
Error: Syntax error in PUBLIC statement at (1)
gf_reprod.F90:7.5:

  END TYPE tc
 1
Error: Expecting END MODULE statement at (1)
gf_reprod.F90:15.12:

TYPE(tc) t
1
Error: Derived type 'tc' at (1) is being used before it is defined
f951: internal compiler error: Segmentation fault
0x869cbf crash_signal
../../gcc-4.8.2/gcc/toplev.c:332
0x50b3fb show_locus
../../gcc-4.8.2/gcc/fortran/error.c:310
0x50bc90 show_loci
../../gcc-4.8.2/gcc/fortran/error.c:434
0x50bc90 error_print
../../gcc-4.8.2/gcc/fortran/error.c:666
0x50c778 gfc_error(char const*, ...)
../../gcc-4.8.2/gcc/fortran/error.c:961
0x5144f7 check_interface0
../../gcc-4.8.2/gcc/fortran/interface.c:1477
0x516dd4 check_sym_interfaces
../../gcc-4.8.2/gcc/fortran/interface.c:1589
0x57e693 do_traverse_symtree
../../gcc-4.8.2/gcc/fortran/symbol.c:3575
0x516ebc gfc_check_interfaces(gfc_namespace*)
../../gcc-4.8.2/gcc/fortran/interface.c:1699
0x55d51e resolve_types
../../gcc-4.8.2/gcc/fortran/resolve.c:14989
0x55dda0 gfc_resolve
../../gcc-4.8.2/gcc/fortran/resolve.c:15073
0x552486 gfc_parse_file()
../../gcc-4.8.2/gcc/fortran/parse.c:4614
0x58e365 gfc_be_parse_file
../../gcc-4.8.2/gcc/fortran/f95-lang.c:189
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/59006] internal compiler error: in vect_transform_stmt, at tree-vect-stmts.c:5963

[regehr at cs dot utah.edu]

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

--- Comment #1 from John Regehr  ---
Simpler test case:

$ cat small.c
int a[10], b;
int main() {
  for (; b <= 0; b++)
a[b] = a[0] || b;
}

$ gcc -O3 small.c
small.c: In function ‘main’:
small.c:2:5: internal compiler error: in vect_transform_stmt, at
tree-vect-stmts.c:5963
 int main() {
 ^
0xb333d7 vect_transform_stmt(gimple_statement_d*, gimple_stmt_iterator_d*,
bool*, _slp_tree*, _slp_instance*)
/home/regehr/z/compiler-source/gcc/gcc/tree-vect-stmts.c:5963
0xb363d1 vect_transform_loop(_loop_vec_info*)
/home/regehr/z/compiler-source/gcc/gcc/tree-vect-loop.c:5882
0xb5352f vectorize_loops()
/home/regehr/z/compiler-source/gcc/gcc/tree-vectorizer.c:373
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/59023] [4.9 regression] ICE in gfc_search_interface with BIND(C)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |4.9.0

[Bug tree-optimization/58653] [4.7/4.8 Regression] wrong code (segfaults) at -O3 on x86_64-linux-gnu in 64-bit mode (affecting gcc 4.6 to trunk)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.9.0
Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] wrong
   |wrong code (segfaults) at   |code (segfaults) at -O3 on
   |-O3 on x86_64-linux-gnu in  |x86_64-linux-gnu in 64-bit
   |64-bit mode (affecting gcc  |mode (affecting gcc 4.6 to
   |4.6 to trunk)   |trunk)
  Known to fail||4.8.2

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

[Bug tree-optimization/58653] [4.7/4.8/4.9 Regression] wrong code (segfaults) at -O3 on x86_64-linux-gnu in 64-bit mode (affecting gcc 4.6 to trunk)

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Wed Nov  6 15:00:16 2013
New Revision: 204458

URL: http://gcc.gnu.org/viewcvs?rev=204458&root=gcc&view=rev
Log:
2013-11-06  Richard Biener  

PR tree-optimization/58653
* tree-predcom.c (ref_at_iteration): Rewrite to generate
a MEM_REF.
(prepare_initializers_chain): Adjust.

* gcc.dg/tree-ssa/predcom-6.c: New testcase.
* gcc.dg/tree-ssa/predcom-7.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/predcom-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/predcom-7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-predcom.c

[Bug middle-end/59011] [4.7/4.8/4.9 Regression] ICE in make_decl_rtl, at varasm.c:1147

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Known to work|4.3.6   |4.4.0

--- Comment #3 from H.J. Lu  ---
It is caused by r148198.

[Bug tree-optimization/58653] [4.7/4.8/4.9 Regression] wrong code (segfaults) at -O3 on x86_64-linux-gnu in 64-bit mode (affecting gcc 4.6 to trunk)

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
*** Bug 58697 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/58697] [4.8/4.9 Regression] wrong code (segfaults) at -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #9 from Richard Biener  ---
It's a dup.

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

[Bug target/59021] [4.9 regression] new vzeroupper instructions generated with -mavx

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
Isn't the argument list a bit strange for call insn?

(call_insn 20 19 21 2 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:DI ("foo") [flags 0x41]  ) [0 foo S1 A8])
(const_int 16 [0x10]))) pr59021.c:15 660 {*call_value}
 (nil)
(expr_list:V4DF (use (reg:V4DF 21 xmm0))
(expr_list:REG_BR_PRED (use (reg:SI 5 di))
(expr_list:REG_BR_PRED (use (reg:SI 4 si))
(expr_list:REG_BR_PRED (use (reg:SI 1 dx))
(expr_list:REG_BR_PRED (use (reg:SI 2 cx))
(expr_list:REG_BR_PRED (use (reg:SI 37 r8))
(expr_list:REG_DEAD (use (mem:BLK (reg/f:DI 7 sp)
[0 S12 A64]))
(nil)


These should be (expr_list:REG_DEP_TRUE (use (...))

[Bug fortran/59023] New: [4.9 regression] ICE in gfc_search_interface with BIND(C)

[fxcoudert at gcc dot gnu.org]

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

Bug ID: 59023
   Summary: [4.9 regression] ICE in gfc_search_interface with
BIND(C)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org

The code below triggers an ICE on current trunk (on x86_64-apple-darwin13, but
I don't suppose it matters much). It works with gfortran 4.8.0 and 4.8.2, as
well as all other versions since 4.3 at least.

!
module foo
  type t
integer hidden
  end type
contains
  subroutine bar
type(t) :: toto
interface
  integer function helper() bind(c)
  end function
end interface
toto = t(helper())
  end subroutine
end module
!


It is somewhat frustrating, because this bug is triggered in my current
(tentative) implementation of IEEE_ARITHMETIC's IEEE_CLASS routine.

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[jan.sm...@alcatel-lucent.com]

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

--- Comment #28 from Jan Smets  ---
Can this be backported to 4.8 please.
Thanks

[Bug c/59022] Bogus "warning: conversion to 'short int' from 'int' may alter its value [-Wconversion]"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
The warning is correct, short + short may overflow when computed in 'int' and
thus may get truncated with the conversion to short.  -original shows the
code after some (premature) optimization.

[Bug preprocessor/58580] [4.8 Regression] preprocessor goes OOM with warning for zero literals

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
  Known to work||4.9.0
 Resolution|FIXED   |---
Summary|[4.8/4.9 Regression]|[4.8 Regression]
   |preprocessor goes OOM with  |preprocessor goes OOM with
   |warning for zero literals   |warning for zero literals
  Known to fail||4.8.2

--- Comment #8 from Richard Biener  ---
Yeah.  Re-opening, fixed on trunk only sofar.

[Bug target/59021] [4.9 regression] new vzeroupper instructions generated with -mavx

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||kyukhin at gcc dot gnu.org

--- Comment #1 from Uroš Bizjak  ---
Kirill, can please someone from your team comment on the testcase?

[Bug c/59022] New: Bogus "warning: conversion to 'short int' from 'int' may alter its value [-Wconversion]"

[burnus at gcc dot gnu.org]

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

Bug ID: 59022
   Summary: Bogus "warning: conversion to 'short int' from 'int'
may alter its value [-Wconversion]"
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

The following code gives with C (cc1) and C++ (cc1plus) and -Wconversion the
bogus warning:

test3.c:2:31: warning: conversion to 'short int' from 'int' may alter its value
[-Wconversion]
   coordtmp[0] = coordexist[0] + coordexist[1];
   ^



void SetBins(short *coordexist, short *coordtmp) {
  coordtmp[0] = coordexist[0] + coordexist[1];
}


The -fdump-tree-original dump looks as follows:

  *coordtmp = (short int) ((unsigned short) *coordexist + (unsigned short)
*(coordexist + 2));

[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 #3 from octoploid at yandex dot com ---
The issue only happens when I use the 'gold' linker,
ld.bfd is fine. So maybe a binutils bug?
Honza?

[Bug tree-optimization/58653] [4.7/4.8/4.9 Regression] wrong code (segfaults) at -O3 on x86_64-linux-gnu in 64-bit mode (affecting gcc 4.6 to trunk)

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
The issue is that predcom treats

  e[c + 3][d] and e[c + 4][d]

as having distance '2', but that's in a dimension that is not evolving.
Later we adjust the evolving dimension index with an adjusted value
which obviously breaks as it gets out-of-bounds.  That will later
confuse data-ref analysis as well, so the "fix" using signed arithmetic
doesn't fix the underlying issue.

I'm not sure why the issue with tree_could_trap_p exists, tree_could_trap_p
is very conservative and we can arrange for constant offsets to appear
in a single MEM_REF.

Trying a patch doing that.

[Bug preprocessor/58580] [4.8/4.9 Regression] preprocessor goes OOM with warning for zero literals

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

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

--- Comment #7 from Dodji Seketeli  ---
This should be fixed in trunk for 4.9 by commit
http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=fc3eff8854861fcd70d33d26095b17fe456fae31


I'll give it some testing time, and if it turns out to work OK, I'll consider
backporting the change to 4.8.

What do you think, Richi?

[Bug libfortran/58020] Code for handling IEEE exceptions

[fxcoudert at gcc dot gnu.org]

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

--- Comment #23 from Francois-Xavier Coudert  ---
(In reply to Tobias Burnus from comment #16)
> I want to mention that there is now some additional support for IEEE in
> libgfortran/config. None of those functions is exported, yet - that permits
> to tweak their ABI. All work on x86 hardware, glibc, sysv (= Solaris,
> FreeBSD), AIX - which should cover most systems.

Yes. After thinking about it some more, we'll need to add two "save/restore FPU
state" functions.

[Bug tree-optimization/59014] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
It seems we create wrong ASSERT_EXPR:

  a.1_5 = a;
  _7 = (_Bool) a.1_5;
  _8 = _4 | _7; 
  if (_8 != 0)
goto ; 
  else
goto ; 

  : 
  a.1_15 = ASSERT_EXPR ;

Why does it think that a.1_5 must be 0?

[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
   Priority|P3  |P1

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |4.9.0

[Bug middle-end/59011] [4.7/4.8/4.9 Regression] ICE in make_decl_rtl, at varasm.c:1147

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||4.3.6
  Known to fail||4.5.3

[Bug tree-optimization/59014] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c/59017] Infinite loop introduced in program with -O2 or -O3 on Mageia Linux x86-64 Cauldron with gcc-4.8.2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
-fno-aggressive-loop-optimizations fixes this.  On trunk I get

t.c: In function 'main':
t.c:59:29: warning: iteration 20u invokes undefined behavior
[-Waggressive-loop-optimizations]
 x_count += c5_counts[LIM_min_x-1]-c5_counts[x+1];
 ^
t.c:35:5: note: containing loop
 for(int x = 0; x <= LIM; x++)
 ^

clearly x+1 is out-of bounds for x == LIM.

[Bug target/59021] [4.9 regression] new vzeroupper instructions generated with -mavx

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
   Target Milestone|--- |4.9.0

[Bug rtl-optimization/59019] [4.9 regression] ICE in advance_target_bb, at sched-rgn.c:3561

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug rtl-optimization/59020] [4.9 Regression] internal compiler error: in maybe_add_or_update_dep_1, at sched-deps.c:933

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
   Target Milestone|--- |4.9.0

[Bug target/59021] New: [4.9 regression] new vzeroupper instructions generated with -mavx

[ebotcazou at gcc dot gnu.org]

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

Bug ID: 59021
   Summary: [4.9 regression] new vzeroupper instructions generated
with -mavx
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ebotcazou at gcc dot gnu.org

Created attachment 31173
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31173&action=edit
Testcase

It's not clear to me whether this is a real bug or not, but new vzeroupper
instructions started to be generated with -mavx very recently because of:

2013-11-04  Vladimir Makarov  

PR rtl-optimization/58968
* lra-spills.c (return_regno_p): New function.
(lra_final_code_change): Use it.

For the attached testcase compiled with -O2 -mavx:

--- t.s.0   2013-11-06 12:17:49.080691443 +0100
+++ t.s 2013-11-06 12:17:55.005691730 +0100
@@ -23,12 +23,14 @@
callfoo
testl   %eax, %eax
jne .L6
+   vzeroupper
leave
.cfi_remember_state
.cfi_def_cfa 7, 8
ret
 .L6:
.cfi_restore_state
+   vzeroupper
callabort
.cfi_endproc
 .LFE0:

[Bug tree-optimization/59014] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
And, it's not related to -Os; the bug triggers exactly when VRP is run.

[Bug rtl-optimization/59020] [4.9 Regression] internal compiler error: in maybe_add_or_update_dep_1, at sched-deps.c:933

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #1 from Joost VandeVondele  
---
output from -v 

> gfortran  -c -O2 -march=native -fmodulo-sched -ffast-math -ffree-form 
> -fno-inline  -v bug.f90
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/data/vjoost/gnu/gcc_trunk/install
--enable-languages=c,c++,fortran --disable-multilib --enable-plugins
--enable-lto --disable-bootstrap
Thread model: posix
gcc version 4.9.0 20131106 (experimental) [trunk revision 204433] (GCC) 
COLLECT_GCC_OPTIONS='-c' '-O2' '-march=native' '-fmodulo-sched' '-ffast-math'
'-ffree-form' '-fno-inline' '-v'

/data/vjoost/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/f951
bug.f90 -march=corei7 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a
-mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mno-abm -mno-lwp
-mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2
-msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c
-mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt
-mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf --param l1-cache-size=32
--param l1-cache-line-size=64 --param l2-cache-size=24576 -mtune=corei7 -quiet
-dumpbase bug.f90 -auxbase bug -O2 -version -fmodulo-sched -ffast-math
-ffree-form -fno-inline -fintrinsic-modules-path
/data/vjoost/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/finclude
-o /tmp/ccJiZWVg.s
GNU Fortran (GCC) version 4.9.0 20131106 (experimental) [trunk revision 204433]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.2 20120816 (prerelease) [gcc-4_7-branch
revision 190437], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.9.0 20131106 (experimental) [trunk revision 204433]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.2 20120816 (prerelease) [gcc-4_7-branch
revision 190437], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
bug.f90: In function ‘write_forces’:
bug.f90:98:0: internal compiler error: in maybe_add_or_update_dep_1, at
sched-deps.c:933

[Bug rtl-optimization/59020] New: [4.9 Regression] internal compiler error: in maybe_add_or_update_dep_1, at sched-deps.c:933

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 59020
   Summary: [4.9 Regression] internal compiler error: in
maybe_add_or_update_dep_1, at sched-deps.c:933
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch

Created attachment 31172
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31172&action=edit
reduced testcase.

The attached testcase compiled with current trunk fails as

gfortran  -c -O2 -march=native -fmodulo-sched -ffast-math -ffree-form
-fno-inline  bug.f90

bug.f90:98:0: internal compiler error: in maybe_add_or_update_dep_1, at
sched-deps.c:933
   END SUBROUTINE write_forces
 ^
0xf3e498 maybe_add_or_update_dep_1
../../gcc/gcc/sched-deps.c:933
0xf3e498 maybe_add_or_update_dep_1
../../gcc/gcc/sched-deps.c:928
0xf3e5fc haifa_note_dep
../../gcc/gcc/sched-deps.c:1866
0xf35e52 note_dep
../../gcc/gcc/sched-deps.c:1901
0xf35e52 add_dependence_1
../../gcc/gcc/sched-deps.c:4175
0xf389d1 add_dependence(rtx_def*, rtx_def*, reg_note)
../../gcc/gcc/sched-deps.c:1557
0xf3c0f5 chain_to_prev_insn
../../gcc/gcc/sched-deps.c:1693
0xf3c0f5 deps_analyze_insn(deps_desc*, rtx_def*)
../../gcc/gcc/sched-deps.c:3697
0xf3c6f2 sched_analyze(deps_desc*, rtx_def*, rtx_def*)
../../gcc/gcc/sched-deps.c:3739
0x9b1dd5 compute_block_dependences
../../gcc/gcc/sched-rgn.c:2721
0x9b1dd5 sched_rgn_compute_dependencies(int)
../../gcc/gcc/sched-rgn.c:3234
0x9b4621 schedule_region

This is a recent failure introduced between r204343 and r204377

[Bug tree-optimization/59014] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
I'd say this is .vrp1.  In .mergephi2, we have

  : 
  a.1_11 = a.1_5;
  d = a.1_11;
  return 0;

but in .vrp1:

  : 
  a.1_13 = 0;
  a.1_11 = 0;
  d = 0;
  return 0;

And yeah, the bug goes away with -fno-tree-vrp.

[Bug rtl-optimization/59019] New: [4.9 regression] ICE in advance_target_bb, at sched-rgn.c:3561

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

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

Bug ID: 59019
   Summary: [4.9 regression] ICE in advance_target_bb, at
sched-rgn.c:3561
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: law at gcc dot gnu.org
Target: ia64-*-*

Broken by r204414.

$ gcc/xgcc -B gcc/ ../gcc/testsuite/gcc.dg/20050629-1.c -O2 -S -w
../gcc/testsuite/gcc.dg/20050629-1.c: In function ‘finalize_ssa_v_may_def_ops’:
../gcc/testsuite/gcc.dg/20050629-1.c:238:2: internal compiler error: in
advance_target_bb, at sched-rgn.c:3561
  }
  ^
0x4095d1cf advance_target_bb
../../gcc/sched-rgn.c:3560
0x410da62f commit_schedule
../../gcc/haifa-sched.c:5628
0x410f348f schedule_block(basic_block_def**, void*)
../../gcc/haifa-sched.c:6424
0x4096c60f schedule_region
../../gcc/sched-rgn.c:3057
0x4096c60f schedule_insns
../../gcc/sched-rgn.c:3393
0x4096cf1f schedule_insns
../../gcc/sched-rgn.c:3378
0x4096cf1f rest_of_handle_sched
../../gcc/sched-rgn.c:3586
0x4096cf1f execute
../../gcc/sched-rgn.c:3650

[Bug tree-optimization/59014] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-06
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.9.0
Summary|wrong code at -Os and above |[4.9 Regression] wrong code
   |on x86_64-linux-gnu |at -Os and above on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1

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

[Bug sanitizer/59018] [4.9 Regression] libsanitizer doesn't build for x32

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-06
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

[Bug regression/58985] [4.9 Regression]: gcc.dg/pr57518.c scan-rtl-dump-not ira REG_EQUIV...

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

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

--- Comment #6 from Hans-Peter Nilsson  ---
Confirmed fixed.  Thanks.

[Bug sanitizer/59018] New: [4.9 Regression] libsanitizer doesn't build for x32

[hjl.tools at gmail dot com]

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

Bug ID: 59018
   Summary: [4.9 Regression] libsanitizer doesn't build for x32
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

r204368 breaks x32.  There are 4 problems:

1. internal_syscall casts pointers to uint64.  It doesn't work for
x32 since 32-bit pointers are signed extended to int64. They should
be casted to uptr first.  A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00403.html

2. internal_clone needs to allocate 2 int64 to restore 2 pointers
by pop which only pops 64-bit integer into 64-bit register. Also
"movq   %6,%%r8\n" can't be used to load 32-bit pointer into 64-bit
r8.  We should let compiler handle it.  A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00405.html

3. x32 uses the same file system calls as x86-64. The types
used in those system calls must be the same for x32 and x86-64.
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00407.html

4. X32 uses the same FPU state as x86-64.  We should check
__x86_64 instead of __WORDSIZE == 64.  A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00408.html

All patches are tested on x32, x86-64 and x86.