[Bug rtl-optimization/56129] Seg fault on 256.bzip2 from spec2000 with -lto and pre-reload scheduler for x86 Atom

[ubizjak at gmail dot com]

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



--- Comment #1 from Uros Bizjak  2013-01-29 07:14:37 
UTC ---

(In reply to comment #0)



> Please, let me know if we are needed any additional info.



Yes, we need all relevant files to recreate the failure. If possible, please

create a minimal executable testcase that exposes the problem.



Please follow the instructions in http://gcc.gnu.org/bugs/#report. Hopefully

someone will add a section on how to handle LTO compiles.

[Bug pending/55996] [meta-bug] GCC 4.9 pending patches

[ubizjak at gmail dot com]

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



--- Comment #2 from Uros Bizjak  2013-01-29 07:01:24 
UTC ---

[4.9 PATCH, alpha]: Switch alpha to LRA



http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01357.html

[Bug c++/56137] New: std::initializer_list accepts invalid designated initializers

[andersk at mit dot edu]

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



 Bug #: 56137

   Summary: std::initializer_list accepts invalid designated

initializers

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ande...@mit.edu





The following initializers are incorrectly accepted by g++ -std=c++11

(4.7.2-19ubuntu1 and 4.8.0 20130121-0ubuntu1):



#include 

std::vector v = {.ignored_name = 1, .also_ignored_name = 2};



#include 

std::initializer_list l = {.ignored_name = 1, .also_ignored_name = 2};

[Bug fortran/56136] New: Compiler fails when code contains lhs-reallocation of an object with overloaded (elemental) Assignment operator

[alipasha.celeris at gmail dot com]

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

 Bug #: 56136
   Summary: Compiler fails when code contains lhs-reallocation of
an object with overloaded (elemental) Assignment
operator
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: alipasha.cele...@gmail.com


Created attachment 29299
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29299
The code that causes compiler crash

Upon compiling the following code using GNU Fortran (GCC) 4.8.0 20130128
(experimental):

  MODULE A_TEST_M
TYPE :: A_TYPE
  CONTAINS
  GENERIC :: ASSIGNMENT (=) => ASGN_A
  PROCEDURE, PRIVATE :: ASGN_A
END TYPE

CONTAINS

ELEMENTAL SUBROUTINE ASGN_A (A, B)
  CLASS (A_TYPE), INTENT (INOUT) :: A
  CLASS (A_TYPE), INTENT (IN) :: B
END SUBROUTINE
  END MODULE A_TEST_M

  PROGRAM ASGN_REALLOC_TEST
USE A_TEST_M
TYPE (A_TYPE), ALLOCATABLE :: A(:)

ALLOCATE (A(100))
A(1:50) = A(51:100)
A = A(1:50)
  END PROGRAM

placed in file "asgn_realloc_test.f" with compile call:

  user@machine:~/../quicktest$ gfortran asgn_realloc_test.f

causes compiler to crash with the following messages: 

asgn_realloc_test.f: In function ‘test’:
asgn_realloc_test.f:22:0: internal compiler error: in gfc_conv_variable, at
fortran/trans-expr.c:1658
 A = A(1:50)
 ^
0x5db000 gfc_conv_variable
../.././gcc/fortran/trans-expr.c:1658
0x5d75ca gfc_conv_expr(gfc_se*, gfc_expr*)
../.././gcc/fortran/trans-expr.c:6263
0x5dbef3 gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../.././gcc/fortran/trans-expr.c:6357
0x5dc2fa gfc_conv_derived_to_class(gfc_se*, gfc_expr*, gfc_typespec,
tree_node*, bool, bool)
../.././gcc/fortran/trans-expr.c:305
0x5d426a gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../.././gcc/fortran/trans-expr.c:4087
0x5ff84c gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
../.././gcc/fortran/trans-stmt.c:491
0x5a4663 trans_code
../.././gcc/fortran/trans.c:1511
0x5cb57e gfc_generate_function_code(gfc_namespace*)
../.././gcc/fortran/trans-decl.c:5390
0x564390 translate_all_program_units
../.././gcc/fortran/parse.c:4463
0x564390 gfc_parse_file()
../.././gcc/fortran/parse.c:4677
0x59fe75 gfc_be_parse_file
../.././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 <http://gcc.gnu.org/bugs.html> for instructions.

Note that the line before the reallocating assignment (A(1:50) = A(51:100))
will not cause errors.

Compiler was configured using:

  sudo LIBRARY_PATH=/usr/lib/x86_64-linux-gnu ./configure
--enable-languages=c,c++,fortran --enable-libgomp --enable-lto --enable-gold
--with-plugin-ld=/usr/bin/gold

on Ubuntu:

  Release 12.04 (precise) 64-bit
  Kernel Linux 3.2.0-36-generic

[Bug c++/56135] New: [c++11] this incorrectly captured as null in template member function

[arnetheduck at gmail dot com]

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



 Bug #: 56135

   Summary: [c++11] this incorrectly captured as null in template

member function

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: arnethed...@gmail.com





Created attachment 29298

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29298

Test case showing broken capture of this



When creating a lambda function in a template member function, when capturing

this using [=], this is not captured correctly when the lambda only calls

another template member function reusing the outer template argument.



Qualifying the call with this or not passing on the outer template argument

solves the issue.



In the attached code, I expect this to be captured in all 4 cases, but the

"broken" captures null resulting in the print out:



./test

(nil)

0x7fff1354f2af

0x7fff1354f2af

0x7fff1354f2af



GDB shows the same - this has been captured but with null as value.



clang 3.2 captures this as expected.

[Bug c++/56134] ICE: alias attribute on c++ static class member;

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



  Known to fail||4.3.5, 4.4.5, 4.8.0



--- Comment #2 from Andrew Pinski  2013-01-29 
01:08:23 UTC ---

Confirmed:

t.cc:4:45: internal compiler error: in make_rtl_for_nonlocal_decl, at

cp/decl.c:5803

   static char q __attribute__ ((alias ("a")));

 ^

0x51579a make_rtl_for_nonlocal_decl

../../gcc/cp/decl.c:5803

0x53a780 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)

../../gcc/cp/decl.c:6420

0x5d844e grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,

bool, tree_node*, tree_node*)

../../gcc/cp/decl2.c:981

0x5f7462 cp_parser_member_declaration

../../gcc/cp/parser.c:19435

0x5f82e6 cp_parser_member_specification_opt

../../gcc/cp/parser.c:18986

0x5f82e6 cp_parser_class_specifier_1

../../gcc/cp/parser.c:18239

0x5f82e6 cp_parser_class_specifier

../../gcc/cp/parser.c:18455

0x5f82e6 cp_parser_type_specifier

../../gcc/cp/parser.c:13570

0x60f48d cp_parser_decl_specifier_seq

../../gcc/cp/parser.c:10895

0x612ea9 cp_parser_simple_declaration

../../gcc/cp/parser.c:10494

0x614e20 cp_parser_block_declaration

../../gcc/cp/parser.c:10443

0x61da0b cp_parser_declaration

../../gcc/cp/parser.c:10340

0x61c6dd cp_parser_declaration_seq_opt

../../gcc/cp/parser.c:10226

0x61df82 cp_parser_translation_unit

../../gcc/cp/parser.c:3808

[Bug c++/56134] ICE: alias attribute on c++ static class member;

[tristan.wibberley at gmail dot com]

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

--- Comment #1 from Tristan Wibberley  
2013-01-29 01:00:44 UTC ---
$ g++ --version
g++-4.7.real (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
Copyright © 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c++/56134] New: ICE: alias attribute on c++ static class member;

[tristan.wibberley at gmail dot com]

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



 Bug #: 56134

   Summary: ICE: alias attribute on c++ static class member;

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: tristan.wibber...@gmail.com





Created attachment 29297

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29297

preprocessed source that causes an ICE



src.cc:4:45: internal compiler error: in make_rtl_for_nonlocal_decl, at

cp/decl.c:5697

[Bug regression/56131] [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux

[vries at gcc dot gnu.org]

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



--- Comment #3 from vries at gcc dot gnu.org 2013-01-29 00:28:38 UTC ---

Using NOTE_BASIC_BLOCK instead of BLOCK_FOR_INSN on bb_note allows us to get

the bb.



This tentative patch:

...

Index: cfgrtl.c

===

--- cfgrtl.c (revision 195240)

+++ cfgrtl.c (working copy)

@@ -144,9 +144,11 @@ delete_insn (rtx insn)

   NOTE_DELETED_LABEL_NAME (insn) = name;



   if (bb_note != NULL_RTX && NOTE_INSN_BASIC_BLOCK_P (bb_note)

-  && BLOCK_FOR_INSN (bb_note) == bb)

+  && (bb == NULL

+  || NOTE_BASIC_BLOCK (bb_note) == bb))

 {

   reorder_insns_nobb (insn, insn, bb_note);

+  bb = NOTE_BASIC_BLOCK (bb_note);

   BB_HEAD (bb) = bb_note;

   if (BB_END (bb) == bb_note)

 BB_END (bb) = insn;

...



gives the following result:

...

(note 23 221 22 [bb 3] NOTE_INSN_BASIC_BLOCK)

(note 22 23 67 ("lbl1") NOTE_INSN_DELETED_LABEL 3)

...

[Bug middle-end/56113] out of memory when compiling a function with many goto labels (50k > )

[steven at gcc dot gnu.org]

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



--- Comment #9 from Steven Bosscher  2013-01-28 
23:34:36 UTC ---

(In reply to comment #7)



With the patch from comment #7:



n=1000 6.18user 254976k maxresident

n=2000 16.76user 509184k maxresident

n=4000 54.23user 1432576l maxresident

n=8000 201.31user 1343296k maxresident



Without:

n=1000 6.45user 255616k maxresident

n=2000 17.65user 572096k maxresident

n=4000 55.10user 1485184k maxresident

n=8000 199.49user 1456000k maxresident



So there appears to be some small effect on memory footprint but

nothing to get excited about, and no effect on compile time.

[Bug regression/56131] [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux

[vries at gcc dot gnu.org]

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



vries at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-28

 Ever Confirmed|0   |1



--- Comment #2 from vries at gcc dot gnu.org 2013-01-28 23:15:32 UTC ---

I can reproduce this on a x86_64-linux to sparc-linux cross-compiler.



The segv is due to bb being null and dereferenced:

...

Program received signal SIGSEGV, Segmentation fault.

0x0066145b in delete_insn (insn=0x76b1a480) at gcc/cfgrtl.c:150

150  BB_HEAD (bb) = bb_note;

(gdb) p bb

$4 = (basic_block) 0x0

...



the bb var is set here:

...

138  basic_block bb = BLOCK_FOR_INSN (insn);

...



with insn being:

...

(gdb) call debug_rtx (insn)

(code_label 22 21 23 3 ("lbl1") [0 uses])

...

[Bug libstdc++/56112] [4.8 Regression] cannot create unordered_map from range of types convertible to value_type

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #9 from Jonathan Wakely  2013-01-28 
23:09:06 UTC ---

fixed

[Bug libstdc++/56112] [4.8 Regression] cannot create unordered_map from range of types convertible to value_type

[redi at gcc dot gnu.org]

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



--- Comment #8 from Jonathan Wakely  2013-01-28 
23:07:59 UTC ---

Author: redi

Date: Mon Jan 28 23:07:35 2013

New Revision: 195520



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

Log:

PR libstdc++/56112

* include/bits/hashtable_policy.h (insert(_Pair&&)): Use _M_emplace

to construct value_type explicitly before trying to extract the key.

* testsuite/23_containers/unordered_map/cons/56112.cc: New.



Added:

trunk/libstdc++-v3/testsuite/23_containers/unordered_map/cons/56112.cc

Modified:

trunk/libstdc++-v3/ChangeLog

trunk/libstdc++-v3/include/bits/hashtable_policy.h

[Bug fortran/54107] [4.8 Regression] [F03] Memory hog with abstract interface

[janus at gcc dot gnu.org]

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



--- Comment #27 from janus at gcc dot gnu.org 2013-01-28 22:42:48 UTC ---

(In reply to comment #26)

> There is one case that remains to be handled.  I suppose it is valid if the

> other are valid.

> 

>   function foo () result(bar)

> procedure(foo), pointer :: bar 

>   end function



Yes, in principle proc-ptr valued functions are allowed. I don't see why it

wouldn't be valid.



This ICEs for me with 4.6, 4.7 and trunk (with the current patches for this

PR).

[Bug regression/56131] [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux

[mikpe at it dot uu.se]

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



Mikael Pettersson  changed:



   What|Removed |Added



 CC||vries at gcc dot gnu.org



--- Comment #1 from Mikael Pettersson  2013-01-28 
21:58:49 UTC ---

Started with Tom de Vries' "Remove dead labels to increase superblock scope"

patch in r186451:

http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00875.html

http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00402.html

[Bug target/56133] New: [x86] align_loops, align_jumps and align_functions are ignored

[hjl.tools at gmail dot com]

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



 Bug #: 56133

   Summary: [x86] align_loops, align_jumps and align_functions

are ignored

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: hjl.to...@gmail.com





i386.c has



  /* Default align_* from the processor table.  */

  if (align_loops == 0)

{

  align_loops = processor_target_table[ix86_tune].align_loop;

  align_loops_max_skip =

processor_target_table[ix86_tune].align_loop_max_skip;

}

  if (align_jumps == 0)

{

  align_jumps = processor_target_table[ix86_tune].align_jump;

  align_jumps_max_skip =

processor_target_table[ix86_tune].align_jump_max_skip;

}

  if (align_functions == 0)

{

  align_functions = processor_target_table[ix86_tune].align_func;

}



However, opts.c has



{ OPT_LEVELS_2_PLUS, OPT_falign_loops, NULL, 1 },

{ OPT_LEVELS_2_PLUS, OPT_falign_jumps, NULL, 1 },

{ OPT_LEVELS_2_PLUS, OPT_falign_labels, NULL, 1 },

{ OPT_LEVELS_2_PLUS, OPT_falign_functions, NULL, 1 },





Those variables aren't zero unless they are set at command-line.  I think

they should be initialized to -1, which is handled by init_alignments:



/* Default the align_* variables to 1 if they're still unset, and

   set up the align_*_log variables.  */

static void 

init_alignments (void)

{



and i386.c should check <= 0, instead of == 0.

[Bug target/52480] SH Target: SH4A movua.l does not work for big endian

[olegendo at gcc dot gnu.org]

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



--- Comment #7 from Oleg Endo  2013-01-28 20:44:03 
UTC ---

(In reply to comment #6)

> As of rev 195493 the test case for this PR is failing again.



In fact, now it doesn't work for little and big endian.

[Bug target/52480] SH Target: SH4A movua.l does not work for big endian

[olegendo at gcc dot gnu.org]

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



Oleg Endo  changed:



   What|Removed |Added



 Status|RESOLVED|REOPENED

 Resolution|FIXED   |



--- Comment #6 from Oleg Endo  2013-01-28 20:21:00 
UTC ---

As of rev 195493 the test case for this PR is failing again.

[Bug lto/56088] [4.8 Regression] LTO error: error: inlining failed in call to always_inline ‘vswprintf’: recursive inlining

[vhaisman at gmail dot com]

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

--- Comment #8 from Václav Zeman  2013-01-28 
20:12:49 UTC ---
(In reply to comment #7)
> What linker are you using?  It seems to work for me with GNU ld 2.23.1.
> 
> Using
> 
> > ./xg++ -B. t2.ii -r -nostdlib -flto -std=c++11 -march=amdfam10 -mfxsr -fPIC 
> > -O3 -flto-partition=none -fuse-linker-plugin
> 
> and preprocessed source.  Did you use the same flags compiling timehelper.o?
I am seeing this when I add -Wl,-v to command line:

/usr/bin/ld.gold -plugin
/home/wilx/gcc48/libexec/gcc/x86_64-linux-gnu/4.8.0/liblto_plugin.so
-plugin-opt=/home/wilx/gcc48/libexec/gcc/x86_64-linux-gnu/4.8.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/cchgMTW0.res --sysroot=/ --eh-frame-hdr -m
elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o out.so -r
-L/home/wilx/gcc48/lib/gcc/x86_64-linux-gnu/4.8.0
-L/home/wilx/gcc48/lib/gcc/x86_64-linux-gnu/4.8.0/../../../../lib64
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/usr/lib/../lib64 -L/home/wilx/gcc48/lib/gcc/x86_64-linux-gnu/4.8.0/../../..
-v ./timehelper.o
GNU gold (GNU Binutils for Ubuntu 2.22.90.20120924) 1.11 g++-4.8
@/tmp/cc2L4QqZ.args

[Bug fortran/53537] [4.6/4.7/4.8 Regression] Explicit IMPORT of renamed USE-associated symbol fails

[dominiq at lps dot ens.fr]

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



--- Comment #8 from Dominique d'Humieres  2013-01-28 
20:08:50 UTC ---

After revision 195506, the test in pr44830 compiles without error.

[Bug debug/55059] [4.8 Regression] DWARF missing concrete class definition

[tromey at gcc dot gnu.org]

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



--- Comment #5 from Tom Tromey  2013-01-28 20:08:11 
UTC ---

(In reply to comment #4)

> (In reply to comment #3)

> > If we change gdb to cope with this, I think the effect will be to undo what

> > the patches here were attempting to accomplish.

> 

> I believe the patch was trying to avoid treating a partial definition as a 
> full

> definition when there's a full definition of the class in another CU.  If

> there's only the partial definition, the best we can do is to use that.  That

> seems better to me than the situation we had before.



That isn't what gdb does, though.



I've been thinking about this today and have a list of objections -



I couldn't find support in the DWARF standard for this approach.

I realize DWARF is "anything goes" -- but if this approach is taken

then I think at least a bug report to all the known DWARF consumers is

in order.  I imagine several of them will need fixes.



Fixing this in gdb seems a bit expensive.  I think we will have to track

all partial definitions of a type and then replace them with the real

definition, if one is found.  It is unclear how much DWARF we'll have to

read to dig up the real definition when using the .gdb_index.  Basically

this is a new, non-local property of DWARF with zero connections between

the declaration and definition.  It seems like there can be many obscure

bad scenarios.



If the motivation for this feature in GCC is space savings in the DWARF,

then it seems like it should be on one of the various -f options, not

the default.  For .debug_types at least I think it is better to always

emit the full information.  This may be true of dwz as well, though I suppose

dwz could also be taught this convention.



IIUC this approach relies on ODR for C++ (and presumably just can't be

used for other languages).  However, I think this presumes too much.

It may be that the ODR is violated in a program, and the debuginfo can

be used to help determine this.  But this rule makes it harder to

discover differences between CUs.



Finally, the original thread discusses gdb a fair amount and by my reading

was contingent on "gdb doing the right thing".  But this is not the case.

[Bug fortran/44830] Function return-type declaration with specification expression rejected for renamed derived types

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-28

 CC||bur...@net-b.de, mikael at

   ||gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Dominique d'Humieres  2013-01-28 
20:07:56 UTC ---

The code compiles without error after revision 195506.

If the code is valid as I think, this PR can be closed as fixed with pr53537.

If it is not valid, somebody will have to explain why.

[Bug other/54814] [4.8 Regression] ICE: unable to find a register to spill in class 'R0_REG'

[gjl at gcc dot gnu.org]

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



Georg-Johann Lay  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #16 from Georg-Johann Lay  2013-01-28 
20:05:29 UTC ---

Fixed for the milestone.

[Bug other/54814] [4.8 Regression] ICE: unable to find a register to spill in class 'R0_REG'

[gjl at gcc dot gnu.org]

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



--- Comment #15 from Georg-Johann Lay  2013-01-28 
20:03:34 UTC ---

Author: gjl

Date: Mon Jan 28 20:03:26 2013

New Revision: 195515



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

Log:

PR other/54814

* reload.c (find_valid_class_1): Use in_hard_reg_set_p instead of

TEST_HARD_REG_BIT.





Modified:

trunk/gcc/ChangeLog

trunk/gcc/reload.c

[Bug fortran/54107] [4.8 Regression] [F03] Memory hog with abstract interface

[mikael at gcc dot gnu.org]

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



--- Comment #26 from Mikael Morin  2013-01-28 
19:46:01 UTC ---

Thanks for testing.

There is one case that remains to be handled.  I suppose it is valid if the

other are valid.



  function foo () result(bar)

procedure(foo), pointer :: bar 

  end function

[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'

[hubicka at ucw dot cz]

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



--- Comment #28 from Jan Hubicka  2013-01-28 19:05:40 
UTC ---

> > 1) Just add the check.  We will then miss all devirtualization oppurtunities

> >through the construction vtable.

> 

> The front end does devirtualization itself for calls within constructors, so

> the impact of this isn't likely to be too bad.



Does it cover all the cases we can potentially handle by middle-end? Or does it

stop

i.e. at function boundary?

On the other hand I would say that calls close to consturction are those that

are

likely to be devirtualized, so we should not ignore thoe.



> >what happens on targets not supporting visibility?

> 

> I think that setting DECL_VISIBILITY should do the trick even if it isn't

> reflected in the assembly output.  I added the DECL_ARTIFICIAL check to

> default_assemble_visibility so that this wouldn't cause warnings.



Yes, that seem like way to go.

> 

> > 3) Perhaps we can use DECL_VALUE_EXPR or somethin similar to keep track of

> >the canonical way to reffer into tthe construction vtable? (i.e. by

> > reference

> >to vtable) We can then lower all direct references to the indirect

> >references late, i.e. in expansion?

> 

> Hmm, that makes sense.



OK, if you help me with C++ bits, I can give this a try.



Honza

[Bug rtl-optimization/55342] [4.8 Regression] [LRA,x86] Non-optimal code for simple loop with LRA

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



   Priority|P1  |P2

 CC||jakub at gcc dot gnu.org



--- Comment #3 from Jakub Jelinek  2013-01-28 
18:53:25 UTC ---

I'm downgrading this to P2, it is unfortunate we generate slightly worse code

on this testcase, but it is more important how LRA vs. reload behaves on

average on various benchmarks etc.  This doesn't mean this isn't important to

look at, but I think it isn't a release blocker at this point.

[Bug fortran/56132] New: Lengths incorrect on assignment to an allocatable character scalar.

[jtappin at gmail dot com]

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



 Bug #: 56132

   Summary: Lengths incorrect on assignment to an allocatable

character scalar.

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: jtap...@gmail.com





Created attachment 29296

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29296

Code demonstrating the problem



When I run the attached program with gfortran (4.7.2), the length appears to be

that of the previous assignment, e.g.:

./a.out 

String :_

   0 

   0 

String :_

   0 

   4 

String :_77

   4 

   4 77  

String :_why does this happen

   4 77  

   2 wh

[Bug middle-end/53073] [4.8 Regression] 464.h264ref in SPEC CPU 2006 miscompiled

[sje at gcc dot gnu.org]

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



Steve Ellcey  changed:



   What|Removed |Added



 CC||sje at gcc dot gnu.org



--- Comment #9 from Steve Ellcey  2013-01-28 18:50:42 
UTC ---

FYI: I reported this issue to SPEC to make sure they were aware of it.

their reply is at:



http://www.spec.org/cpu2006/Docs/faq.html#Run.05



They do not intend to offer alternative sources.

[Bug c++/55951] ICE in check_array_designated_initializer, at cp/decl.c:4785

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-28

 Ever Confirmed|0   |1

[Bug regression/56131] New: [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux

[mikpe at it dot uu.se]

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



 Bug #: 56131

   Summary: [4.8 regression] gcc.dg/pr56035.c ICEs gcc on

sparc-linux

Classification: Unclassified

   Product: gcc

   Version: 4.7.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: regression

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: mi...@it.uu.se





The recently added gcc.dg/pr56035.c test case fails on sparc-linux:



+FAIL: gcc.dg/pr56035.c (internal compiler error)

+FAIL: gcc.dg/pr56035.c (test for excess errors)



Compiling it with an x86_64-linux to sparc-linux cross-compiler shows:



> /tmp/objdir/gcc/xgcc -B/tmp/objdir/gcc/ -O1 -ftree-vectorize 
> -fcse-follow-jumps -fstrict-overflow -S pr56035.c 

pr56035.c: In function 'f':

pr56035.c:35:1: internal compiler error: Segmentation fault

 }

 ^

0x70fa9f crash_signal

/tmp/gcc-4.8-20130127/gcc/toplev.c:332

0x4cdc96 delete_insn(rtx_def*)

/tmp/gcc-4.8-20130127/gcc/cfgrtl.c:151

0x6210a8 delete_related_insns(rtx_def*)

/tmp/gcc-4.8-20130127/gcc/jump.c:1243

0x6215e7 redirect_jump_2(rtx_def*, rtx_def*, rtx_def*, int, int)

/tmp/gcc-4.8-20130127/gcc/jump.c:1574

0x6216b2 redirect_jump(rtx_def*, rtx_def*, int)

/tmp/gcc-4.8-20130127/gcc/jump.c:1533

0x6c4464 dbr_schedule(rtx_def*)

/tmp/gcc-4.8-20130127/gcc/reorg.c:3722

0x6c52bf rest_of_handle_delay_slots

/tmp/gcc-4.8-20130127/gcc/reorg.c:3891

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.



This ICE is different from the one in PR56035.



Reverting the PR56035 fix in r195462 makes no difference.



gcc-4.7 does not ICE on this test case.

[Bug rtl-optimization/55221] [regression] gcc-4.6-20121102/gcc/rtl.h:2105: error: 'FIRST_PSEUDO_REGISTER' undeclared here (not in a fnction)

[thierry at FreeBSD dot org]

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

Thierry Thomas  changed:

   What|Removed |Added

 CC||thierry at FreeBSD dot org

--- Comment #4 from Thierry Thomas  2013-01-28 
17:19:12 UTC ---
Same error on FreeBSD 9.1-RELEASE #0 r243826 i386 and gcc-4.6-20130125:

cc -c   -O2 -pipe -march=prescott -I/usr/local/include -fno-strict-aliasing
-DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition
-Wc++-compat   -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
-I.././../gcc-4.6-20130125/gcc -I.././../gcc-4.6-20130125/gcc/build
-I.././../gcc-4.6-20130125/gcc/../include
-I.././../gcc-4.6-20130125/gcc/../libcpp/include -I/usr/local/include 
-I.././../gcc-4.6-20130125/gcc/../libdecnumber
-I.././../gcc-4.6-20130125/gcc/../libdecnumber/dpd -I../libdecnumber  
-I/usr/local/include \
-o build/vec.o .././../gcc-4.6-20130125/gcc/vec.c
In file included from .././../gcc-4.6-20130125/gcc/genflags.c:29:
.././../gcc-4.6-20130125/gcc/rtl.h:1989: warning: ISO C forbids forward
references to 'enum' types
.././../gcc-4.6-20130125/gcc/rtl.h:1990: warning: ISO C forbids forward
references to 'enum' types
.././../gcc-4.6-20130125/gcc/rtl.h:1991: warning: ISO C forbids forward
references to 'enum' types
.././../gcc-4.6-20130125/gcc/rtl.h:1992: warning: ISO C forbids forward
references to 'enum' types
.././../gcc-4.6-20130125/gcc/rtl.h:1992: warning: ISO C forbids forward
references to 'enum' types
.././../gcc-4.6-20130125/gcc/rtl.h:1993: warning: ISO C forbids forward
references to 'enum' types
.././../gcc-4.6-20130125/gcc/rtl.h:2105: error: 'FIRST_PSEUDO_REGISTER'
undeclared here (not in a function)
.././../gcc-4.6-20130125/gcc/rtl.h:2456: warning: ISO C forbids forward
references to 'enum' types
gmake[2]: *** [build/genflags.o] Erreur 1
gmake[2]: *** Attente des tâches non terminées
In file included from .././../gcc-4.6-20130125/gcc/read-rtl.c:31:
.././../gcc-4.6-20130125/gcc/rtl.h:1989: warning: ISO C forbids forward
references to 'enum' types
.././../gcc-4.6-20130125/gcc/rtl.h:1990: warning: ISO C forbids forward
references to 'enum' types
.././../gcc-4.6-20130125/gcc/rtl.h:1991: warning: ISO C forbids forward
references to 'enum' types
.././../gcc-4.6-20130125/gcc/rtl.h:1992: warning: ISO C forbids forward
references to 'enum' types
.././../gcc-4.6-20130125/gcc/rtl.h:1992: warning: ISO C forbids forward
references to 'enum' types
.././../gcc-4.6-20130125/gcc/rtl.h:1993: warning: ISO C forbids forward
references to 'enum' types
.././../gcc-4.6-20130125/gcc/rtl.h:2105: error: 'FIRST_PSEUDO_REGISTER'
undeclared here (not in a function)
.././../gcc-4.6-20130125/gcc/rtl.h:2456: warning: ISO C forbids forward
references to 'enum' types
gmake[2]: *** [build/read-rtl.o] Erreur 1
In file included from .././../gcc-4.6-20130125/gcc/rtl.c:34:
.././../gcc-4.6-20130125/gcc/rtl.h:1989: warning: ISO C forbids forward
references to 'enum' types
.././../gcc-4.6-20130125/gcc/rtl.h:1990: warning: ISO C forbids forward
references to 'enum' types
.././../gcc-4.6-20130125/gcc/rtl.h:1991: warning: ISO C forbids forward
references to 'enum' types
.././../gcc-4.6-20130125/gcc/rtl.h:1992: warning: ISO C forbids forward
references to 'enum' types
.././../gcc-4.6-20130125/gcc/rtl.h:1992: warning: ISO C forbids forward
references to 'enum' types
.././../gcc-4.6-20130125/gcc/rtl.h:1993: warning: ISO C forbids forward
references to 'enum' types
.././../gcc-4.6-20130125/gcc/rtl.h:2105: error: 'FIRST_PSEUDO_REGISTER'
undeclared here (not in a function)
.././../gcc-4.6-20130125/gcc/rtl.h:2456: warning: ISO C forbids forward
references to 'enum' types
gmake[2]: *** [build/rtl.o] Erreur 1

[Bug rtl-optimization/56117] [4.8 Regression] ICE: in cselib_subst_to_values, at cselib.c:1853 with -O2 -fsched2-use-superblocks and __builtin_prefetch()

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #4 from Jakub Jelinek  2013-01-28 
16:52:26 UTC ---

Fixed.

[Bug rtl-optimization/56117] [4.8 Regression] ICE: in cselib_subst_to_values, at cselib.c:1853 with -O2 -fsched2-use-superblocks and __builtin_prefetch()

[jakub at gcc dot gnu.org]

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



--- Comment #3 from Jakub Jelinek  2013-01-28 
16:50:39 UTC ---

Author: jakub

Date: Mon Jan 28 16:50:22 2013

New Revision: 195513



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

Log:

PR rtl-optimization/56117

* sched-deps.c (sched_analyze_2) : For use_cselib

call cselib_lookup_from_insn on the MEM before calling

add_insn_mem_dependence.



* gcc.dg/pr56117.c: New test.



Added:

trunk/gcc/testsuite/gcc.dg/pr56117.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/sched-deps.c

trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/55270] [4.8 Regression] ICE in get_loop_body, at cfgloop.c:823

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  2013-01-28 
16:43:31 UTC ---
Unfortunately this patch causes a few FAILs, e.g.:

/home/polacek/src/gcc/gcc/testsuite/gcc.c-torture/compile/20020604-1.c: In
function ‘foo’:
/home/polacek/src/gcc/gcc/testsuite/gcc.c-torture/compile/20020604-1.c:15:1:
internal compiler error: in calc_dfs_tree, at dominance.c:397
 foo (unsigned int n, int x, int y, unsigned char *z)
 ^
0x63c87b calc_dfs_tree
/home/polacek/src/gcc/gcc/dominance.c:397
0x63ca66 calculate_dominance_info(cdi_direction)
/home/polacek/src/gcc/gcc/dominance.c:658
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I can take a look (but probably only tomorrow).

[Bug fortran/54107] [4.8 Regression] [F03] Memory hog with abstract interface

[janus at gcc dot gnu.org]

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



--- Comment #25 from janus at gcc dot gnu.org 2013-01-28 16:04:14 UTC ---

(In reply to comment #24)

> > Draft patch for comment #4, to be tested.

> 

> Thanks! Seems to work on comment 4 at least. I'll try a regtest.



Regtest went through cleanly, and it also works well for an 'indirect' case

like this:





contains



  subroutine s1 (arg1)

procedure(s2) :: arg1

  end subroutine



  subroutine s2 (arg2)

procedure(s1) :: arg2

  end subroutine



end

[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'

[jason at gcc dot gnu.org]

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



--- Comment #27 from Jason Merrill  2013-01-28 
15:42:57 UTC ---

(In reply to comment #26)

> 1) Just add the check.  We will then miss all devirtualization oppurtunities

>through the construction vtable.



The front end does devirtualization itself for calls within constructors, so

the impact of this isn't likely to be too bad.



>what happens on targets not supporting visibility?



I think that setting DECL_VISIBILITY should do the trick even if it isn't

reflected in the assembly output.  I added the DECL_ARTIFICIAL check to

default_assemble_visibility so that this wouldn't cause warnings.



> 3) Perhaps we can use DECL_VALUE_EXPR or somethin similar to keep track of

>the canonical way to reffer into tthe construction vtable? (i.e. by

> reference

>to vtable) We can then lower all direct references to the indirect

>references late, i.e. in expansion?



Hmm, that makes sense.

[Bug target/35294] iwmmxt intrinsics, internal compiler error

[nickc at redhat dot com]

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



Nick Clifton  changed:



   What|Removed |Added



 CC||nickc at redhat dot com



--- Comment #18 from Nick Clifton  2013-01-28 15:09:52 
UTC ---

I have checked in a modified version of serowk's patch to the 4.7 branch.  The

modification was to produce an error message in the cases where the modes do

not match, and to allow for the automatic forcing of constants into registers

for those builtins that do not accept immediates as their third operand.



Cheers

  Nick

[Bug target/35294] iwmmxt intrinsics, internal compiler error

[nickc at gcc dot gnu.org]

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



--- Comment #17 from Nick Clifton  2013-01-28 
15:07:48 UTC ---

Author: nickc

Date: Mon Jan 28 15:07:41 2013

New Revision: 195510



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

Log:

PR target/35294

* config/arm/arm.c (arm_expand_binop_builtin): Add new parameter.

Fix mode checks to allow for the passing of constants in the

second parameter.

(arm_expand_builtin): Adjust calls to arm_expand_binop_builtin.

Add entries in the switch statement for builtin iwmmxt vector

shift and rotate builtins.



Modified:

branches/gcc-4_7-branch/gcc/ChangeLog

branches/gcc-4_7-branch/gcc/config/arm/arm.c

[Bug tree-optimization/56125] [4.7 Regression] -O2 -ffast-math generates bad code when dividing a double by the square of another double.

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



Summary|[4.7/4.8 Regression] -O2|[4.7 Regression] -O2

   |-ffast-math generates bad   |-ffast-math generates bad

   |code when dividing a double |code when dividing a double

   |by the square of another|by the square of another

   |double. |double.



--- Comment #6 from Jakub Jelinek  2013-01-28 
15:07:24 UTC ---

Fixed on the trunk so far.

[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'

[hubicka at ucw dot cz]

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



--- Comment #26 from Jan Hubicka  2013-01-28 14:56:12 
UTC ---

> perhaps making them hidden whenever possible is really desirable.



Yes, this seems fine to me. Just to be sure I understand the problem fully.

I believe there is still problem with folding. When folding references through

external vtable I think we can still invent direct references to construction

vtable.



While doing so we go through logic in can_refer_decl_in_current_unit_p.

This is trying to validate the reference to the symbol referred only outside

of current unit.



I sort of hacked it together trying to work out what rules are.

This is all wrong for construction vtables where, if I understand it right,

we can not reffer them in any case because other file may be from other

compiler.

(with excetion of ltrans and LTO, also resolution data may tell us that the

symbol is defined?)



  /* We are folding reference from external vtable.  The vtable may reffer

 to a symbol keyed to other compilation unit.  The other compilation

 unit may be in separate DSO and the symbol may be hidden.  */

  if (DECL_VISIBILITY_SPECIFIED (decl)

  && DECL_EXTERNAL (decl)

  && (!(snode = symtab_get_node (decl)) ||

!snode->symbol.in_other_partition))

return false;

  /* When function is public, we always can introduce new reference.

 Exception are the COMDAT functions where introducing a direct

 reference imply need to include function body in the curren tunit.  */

  if (TREE_PUBLIC (decl) && !DECL_COMDAT (decl))

return true;

  /* We are not at ltrans stage; so don't worry about WHOPR.

 Also when still gimplifying all referred comdat functions will be

 produced.



 As observed in PR20991 for already optimized out comdat virtual functions

 it may be tempting to not necessarily give up because the copy will be

 output elsewhere when corresponding vtable is output.

 This is however not possible - ABI specify that COMDATs are output in

 units where they are used and when the other unit was compiled with LTO

 it is possible that vtable was kept public while the function itself

 was privatized. */

  if (!flag_ltrans && (!DECL_COMDAT (decl) || !cgraph_function_flags_ready))

return true;



  /* OK we are seeing either COMDAT or static variable.  In this case we must

 check that the definition is still around so we can refer it.  */

  if (TREE_CODE (decl) == FUNCTION_DECL)



  return true;



I guess we need to add check for construction vtables and disable references

There are options.



1) Just add the check.  We will then miss all devirtualization oppurtunities

   through the construction vtable.  I guess it is what we should do for 4.8

   and earlier.  Marking them hidden will prevent folders from using them, but 

   what happens on targets not supporting visibility?



2) We may teach all optimizers, like ccp/gvn and fold to only "jump across

them"

   and fold only when the reference to construction vtable is used by reference

   to method itself, but it is not how the optimizers are organized - they

   always do one folding at a time and expect that they can reffer to them.



3) Perhaps we can use DECL_VALUE_EXPR or somethin similar to keep track of

   the canonical way to reffer into tthe construction vtable? (i.e. by

reference

   to vtable) We can then lower all direct references to the indirect

   references late, i.e. in expansion?



I suppose 3) makes most sense in longer run.  Implementing 2) without missing

optimization oppurtunities would be hard.

Honza

[Bug tree-optimization/56034] [4.8 Regression] ICE: verify_gimple failed (invalid PHI argument) with -ftree-loop-distribution

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #8 from Richard Biener  2013-01-28 
14:46:59 UTC ---

Fixed.

[Bug tree-optimization/56034] [4.8 Regression] ICE: verify_gimple failed (invalid PHI argument) with -ftree-loop-distribution

[rguenth at gcc dot gnu.org]

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



--- Comment #7 from Richard Biener  2013-01-28 
14:45:50 UTC ---

Author: rguenth

Date: Mon Jan 28 14:45:46 2013

New Revision: 195508



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

Log:

2013-01-28  Richard Biener  



PR tree-optimization/56034

* tree-loop-distribution.c (enum partition_kind): Add

PKIND_REDUCTION.

(partition_builtin_p): Adjust.

(generate_code_for_partition): Handle PKIND_REDUCTION.  Assert

it is the last partition.

(rdg_flag_uses): Check SSA_NAME_IS_DEFAULT_DEF before looking

up the vertex for the definition.

(classify_partition): Classify whether a partition is a

PKIND_REDUCTION, thus has uses outside of the loop.

(ldist_gen): Inherit PKIND_REDUCTION when merging partitions.

Merge all PKIND_REDUCTION partitions into the last partition.

(tree_loop_distribution): Seed partitions from reductions as well.



* gcc.dg/torture/pr56034.c: New testcase.



Added:

trunk/gcc/testsuite/gcc.dg/torture/pr56034.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-loop-distribution.c

[Bug tree-optimization/56125] [4.7/4.8 Regression] -O2 -ffast-math generates bad code when dividing a double by the square of another double.

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2013-01-28 
14:43:07 UTC ---

Author: jakub

Date: Mon Jan 28 14:43:03 2013

New Revision: 195507



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

Log:

PR tree-optimization/56125

* tree-ssa-math-opts.c (gimple_expand_builtin_pow): Don't optimize

pow(x,c) into sqrt(x) * powi(x, n/2) or

1.0 / (sqrt(x) * powi(x, abs(n/2))) if c is an integer or when

optimizing for size.

Don't optimize pow(x,c) into powi(x, n/3) * powi(cbrt(x), n%3) or

1.0 / (powi(x, abs(n)/3) * powi(cbrt(x), abs(n)%3)) if 2c is an

integer.



* gcc.dg/pr56125.c: New test.



Added:

trunk/gcc/testsuite/gcc.dg/pr56125.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-ssa-math-opts.c

[Bug fortran/53537] [4.6/4.7/4.8 Regression] Explicit IMPORT of renamed USE-associated symbol fails

[mikael at gcc dot gnu.org]

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



--- Comment #7 from Mikael Morin  2013-01-28 
14:37:26 UTC ---

Author: mikael

Date: Mon Jan 28 14:37:20 2013

New Revision: 195506



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

Log:

2013-01-28  Tobias Burnus  

Mikael Morin  



PR fortran/53537

* symbol.c (gfc_find_sym_tree): Don't look for the symbol outside an

interface block.

(gfc_get_ha_symtree): Let gfc_find_sym_tree lookup the parent namespace.

* decl.c (gfc_match_data_decl): Ditto.

(variable_decl): Remove undeclared type error.

(gfc_match_import): Use renamed instead of original name.



2013-01-28  Tobias Burnus  

Mikael Morin  



PR fortran/53537

* gfortran.dg/import2.f90: Adjust undeclared type error messages.

* gfortran.dg/import8.f90: Likewise.

* gfortran.dg/interface_derived_type_1.f90: Likewise.

* gfortran.dg/import10.f90: New test.

* gfortran.dg/import11.f90: Likewise





Added:

trunk/gcc/testsuite/gfortran.dg/import10.f90

trunk/gcc/testsuite/gfortran.dg/import11.f90

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/decl.c

trunk/gcc/fortran/symbol.c

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/gfortran.dg/import2.f90

trunk/gcc/testsuite/gfortran.dg/import8.f90

trunk/gcc/testsuite/gfortran.dg/interface_derived_type_1.f90

[Bug lto/56061] [4.8 Regression] ICE in lto1 (in inline_call, at ipa-inline-transform.c:267)

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-28

 CC||hubicka at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-01-28 
14:35:29 UTC ---

Confirmed.  Compile-time -O1 vs. link/WPA-time -O0 (I don't think we

necessarily

want to support this fully... we do want to support compile-time -O0 vs.

link-time -O1)



Not sure why size estimates go wrong in this case though.

[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts

[jakub at gcc dot gnu.org]

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



--- Comment #17 from Jakub Jelinek  2013-01-28 
14:33:18 UTC ---

Should be fixed now on the trunk, but keeping the PR open, so that we don't

forget to revert and do a better fix instead.

[Bug testsuite/56053] FAIL: c-c++-common/asan/(global|stack)-overflow-1.c

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #9 from Jakub Jelinek  2013-01-28 
14:31:35 UTC ---

Should be fixed now.

[Bug lto/56088] [4.8 Regression] LTO error: error: inlining failed in call to always_inline ‘vswprintf’: recursive inlining

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed|2013-01-23 00:00:00 |2013-01-28

 Ever Confirmed|0   |1



--- Comment #7 from Richard Biener  2013-01-28 
14:30:43 UTC ---

What linker are you using?  It seems to work for me with GNU ld 2.23.1.



Using



> ./xg++ -B. t2.ii -r -nostdlib -flto -std=c++11 -march=amdfam10 -mfxsr -fPIC 
> -O3 -flto-partition=none -fuse-linker-plugin



and preprocessed source.  Did you use the same flags compiling timehelper.o?

[Bug testsuite/56053] FAIL: c-c++-common/asan/(global|stack)-overflow-1.c

[jakub at gcc dot gnu.org]

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



--- Comment #8 from Jakub Jelinek  2013-01-28 
14:28:24 UTC ---

Author: jakub

Date: Mon Jan 28 14:28:16 2013

New Revision: 195505



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

Log:

PR testsuite/56053

* c-c++-common/asan/heap-overflow-1.c: Don't include stdlib.h and

string.h.  Provide memset, malloc and free prototypes, adjust line

numbers in dg-output.

* c-c++-common/asan/stack-overflow-1.c: Don't include string.h.

Provide memset prototype and adjust line numbers in dg-output.

* c-c++-common/asan/global-overflow-1.c: Likewise.



Modified:

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/c-c++-common/asan/global-overflow-1.c

trunk/gcc/testsuite/c-c++-common/asan/heap-overflow-1.c

trunk/gcc/testsuite/c-c++-common/asan/stack-overflow-1.c

[Bug testsuite/56053] FAIL: c-c++-common/asan/(global|stack)-overflow-1.c

[dominiq at lps dot ens.fr]

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



--- Comment #7 from Dominique d'Humieres  2013-01-28 
14:06:35 UTC ---

> Created attachment 29295 [details]

> gcc48-pr56053.patch

>

> Untested fix.



On x86_64-apple-darwin10, with the patch

make -k check-gcc RUNTESTFLAGS="asan.exp --target_board=unix'{-m32,-m64}'"

gives



=== gcc Summary ===



# of expected passes516

# of unsupported tests76



and check-g++ gives



=== g++ Summary ===



# of expected passes810

# of unsupported tests138



So the patch fixes this PR at least on darwin.

[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts

[jakub at gcc dot gnu.org]

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



--- Comment #16 from Jakub Jelinek  2013-01-28 
14:05:48 UTC ---

Author: jakub

Date: Mon Jan 28 14:05:40 2013

New Revision: 195504



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

Log:

PR tree-optimization/56094

* gimplify.c (force_gimple_operand_1): Temporarily set input_location

to UNKNOWN_LOCATION while gimplifying expr.



* gcc.dg/pr56094.c: New test.



Added:

trunk/gcc/testsuite/gcc.dg/pr56094.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/gimplify.c

trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/55270] [4.8 Regression] ICE in get_loop_body, at cfgloop.c:823

[rguenth at gcc dot gnu.org]

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



--- Comment #9 from Richard Biener  2013-01-28 
14:03:18 UTC ---

When propagate_rhs_into_lhs alters the CFG from



   if ()

{

 if ()

  exit_loop;

}



to



   if ()

{

  exit_loop;

}



it fails to fixup loop structure:



  /* Propagation into these nodes may make certain edges in

 the CFG unexecutable.  We want to identify them as PHI nodes

 at the destination of those unexecutable edges may become

 degenerates.  */

  else if (gimple_code (use_stmt) == GIMPLE_COND

   || gimple_code (use_stmt) == GIMPLE_SWITCH

   || gimple_code (use_stmt) == GIMPLE_GOTO)

{

...



Now, for full propagation the edge wants marking as non-executable

(which is done by removing it here - somewhat premature, as CFG cleanup

is run afterwards anyway and that handles the situation correctly

by calling fix_loop_structure).



Index: gcc/tree-ssa-dom.c

===

--- gcc/tree-ssa-dom.c  (revision 195502)

+++ gcc/tree-ssa-dom.c  (working copy)

@@ -3006,7 +3006,14 @@ eliminate_degenerate_phis (void)

 }



   if (cfg_altered)

-free_dominance_info (CDI_DOMINATORS);

+{

+  free_dominance_info (CDI_DOMINATORS);

+  if (current_loops)

+   {

+ calculate_dominance_info (CDI_DOMINATORS);

+ fix_loop_structure (NULL);

+   }

+}



   /* Propagation of const and copies may make some EH edges dead.  Purge

  such edges from the CFG as needed.  */



fixes this (one more reason to fix loop structure at loop_optimizer_init

instead ...)

[Bug fortran/54107] [4.8 Regression] [F03] Memory hog with abstract interface

[janus at gcc dot gnu.org]

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



--- Comment #24 from janus at gcc dot gnu.org 2013-01-28 13:48:54 UTC ---

(In reply to comment #23)

> Created attachment 29294 [details]

> Draft patch for comment #4, to be tested.



Thanks! Seems to work on comment 4 at least. I'll try a regtest.

[Bug rtl-optimization/55270] [4.8 Regression] ICE in get_loop_body, at cfgloop.c:823

[rguenth at gcc dot gnu.org]

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



--- Comment #8 from Richard Biener  2013-01-28 
13:48:29 UTC ---

BB 12 does not belong to loop 1 but is marked so.  Broken by late phicprop.

[Bug rtl-optimization/55270] [4.8 Regression] ICE in get_loop_body, at cfgloop.c:823

[mpolacek at gcc dot gnu.org]

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



--- Comment #7 from Marek Polacek  2013-01-28 
13:42:51 UTC ---

Yeah, on the second thought, that is nonsense, sorry.

[Bug rtl-optimization/55270] [4.8 Regression] ICE in get_loop_body, at cfgloop.c:823

[rguenther at suse dot de]

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



--- Comment #6 from rguenther at suse dot de  
2013-01-28 13:39:28 UTC ---

On Mon, 28 Jan 2013, mpolacek at gcc dot gnu.org wrote:



> 

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

> 

> --- Comment #5 from Marek Polacek  2013-01-28 
> 13:35:15 UTC ---

> Maybe just remove the assert?  We know, that dfs_enumerate_from can sometimes

> return bogus number.



Huh?  Definitely not ...



Let me have a look here.

[Bug bootstrap/56128] [4.8 Regression] No way to disable build of libsanitizer

[bonzini at gnu dot org]

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



--- Comment #3 from Paolo Bonzini  2013-01-28 13:36:36 
UTC ---

--disable-target-libsanitizer should work:



# Handle --disable- generically.

for dir in $configdirs $build_configdirs $target_configdirs ; do

  dirname=`echo $dir | sed -e s/target-//g -e s/build-//g -e s/-/_/g`

  varname=`echo $dirname | sed -e s/+/_/g`

  if eval test x\${enable_${varname}} "=" xno ; then

noconfigdirs="$noconfigdirs $dir"

  fi

done

[Bug rtl-optimization/55270] [4.8 Regression] ICE in get_loop_body, at cfgloop.c:823

[mpolacek at gcc dot gnu.org]

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



--- Comment #5 from Marek Polacek  2013-01-28 
13:35:15 UTC ---

Maybe just remove the assert?  We know, that dfs_enumerate_from can sometimes

return bogus number.

[Bug rtl-optimization/55270] [4.8 Regression] ICE in get_loop_body, at cfgloop.c:823

[mpolacek at gcc dot gnu.org]

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



--- Comment #4 from Marek Polacek  2013-01-28 
13:33:47 UTC ---

The problem here is in dfs_enumerate_from, which wrongly detects the number of

BBs in a loop.  get_loop_body_with_size calls dfs_enumerate_from with reverse =

1, thus we go against direction of edges.  I.e., we start at the header, then

go through its predecessors and if the predecessor hasn't been visited yet and

is dominated by the header, we count it.  But, we don't count BB which only has

an exit edge--thus its successor is outside of the loop.  Moving in !reverse

direction doesn't seem to help.  I'm not exactly sure what to do here, I'm

afraid of touching dfs_enumerate_from algorithm ;).

[Bug c++/56130] __attribute__((deprecated)) does not affect C++ reference

[chen3feng at gmail dot com]

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



--- Comment #1 from chen3feng  2013-01-28 13:17:52 
UTC ---

Tested on gcc 4.1.2 4.5.3 4.6.3 4.7.2

[Bug c++/56130] New: __attribute__((deprecated)) does not affect C++ reference

[chen3feng at gmail dot com]

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



 Bug #: 56130

   Summary: __attribute__((deprecated)) does not affect C++

reference

Classification: Unclassified

   Product: gcc

   Version: 4.7.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: chen3f...@gmail.com





int g_nn;

int& g_n __attribute__((deprecated)) = g_nn;



int main()

{

g_n = 1;

}



Compile with -Wall

No any warning.

[Bug bootstrap/56128] [4.8 Regression] No way to disable build of libsanitizer

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-28

 CC||aoliva at gcc dot gnu.org,

   ||bonzini at gnu dot org,

   ||jakub at gcc dot gnu.org,

   ||kcc at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #2 from Jakub Jelinek  2013-01-28 
13:06:40 UTC ---

I think we should both avoid linux/futex.h includes (both in libsanitizer and

testsuite/g++.dg/asan/, both inherited from upstream), either by doing a

configure test for it and only including it if it works properly, or just do

what libgomp or libitm do, don't include  and instead define

FUTEX_{WAIT,WAKE} directly, and also have some --disable-libsanitizer configury

option, CCing some build maintainers for that on where and how should that be

done.

[Bug testsuite/56053] FAIL: c-c++-common/asan/(global|stack)-overflow-1.c

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org

   |gnu.org |



--- Comment #6 from Jakub Jelinek  2013-01-28 
13:00:00 UTC ---

Created attachment 29295

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29295

gcc48-pr56053.patch



Untested fix.

[Bug tree-optimization/56118] Piecewise vector / complex initialization from constants not combined

[glisse at gcc dot gnu.org]

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



--- Comment #3 from Marc Glisse  2013-01-28 12:40:21 
UTC ---

(In reply to comment #2)

> The original testcase is a dup of PR33562, it's a missed dead store

> elimination, not "constant propagation".



Ah, thanks, I am not very familiar with compiler terminology...



> Related testcases have this issue with _Complex and __real / __imag

> piecewise initializations.



I tried it with _Complex before submitting the PR, and there assigning to the

real part in C code actually shows up in gimple as constructing a complex from

that new value and the imaginary part of the old value, which is then easier to

handle (that reminds me of the vec_concat vs vec_merge discussion about the x86

backend with Uros and rth). But variants might exhibit this issue indeed.



> Thus, let's make this bug the failure to combine piecewise constant inits

> of vectors and complex.



ok.

[Bug tree-optimization/56053] FAIL: c-c++-common/asan/(global|stack)-overflow-1.c

[rguenth at gcc dot gnu.org]

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



--- Comment #5 from Richard Biener  2013-01-28 
12:34:15 UTC ---

Seems to fortify by default and thus expose a builtin anyway.

[Bug rtl-optimization/56129] New: Seg fault on 256.bzip2 from spec2000 with -lto and pre-reload scheduler for x86 Atom

[ysrumyan at gmail dot com]

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



 Bug #: 56129

   Summary: Seg fault on 256.bzip2 from spec2000 with -lto and

pre-reload scheduler for x86 Atom

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: rtl-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ysrum...@gmail.com





In a process of testing Atom with lto and pre-reload scheduler we got Seg Fault

on 256:



./bzip2 input.graphic 58

spec_init

Loading Input Data

Duplicating 6656364 bytes

Duplicating 13312728 bytes

Duplicating 26625456 bytes

Duplicating 7566496 bytes

Input data 60817408 bytes in length

Compressing Input Data, level 7

Compressed data 44249975 bytes in length

Uncompressing Data

Segmentation fault



If we turn off LRA test is passed.



We did the following investigation:



1. Both -lto and pre-reload scheduler (-fschedule-insns --param

sched-pressure-algorithm=1 -fsched-pressure) are required to exhibit the

failure.

2. We also used Atom specific options to compile:

-msse2 -mfpmath=sse -ffast-math -march=atom

and peak optset - -O3 -funroll loops

3. We found out that if we turn off pre-reload scheduler for 'main' the failure

disappears.

4. We also determined that if we turn off pre-reload shceduler in main for

regions > 575 test is passed but it failed if we increase upper threshold on 1,

i.e. if we skip scheduling all regions in main starting from 577.

5. Comparing good and bad objdumps (I don't know how to get assembly file with

-lto) we found out that possible reason of fail is non-correct offset for one

of spill:



in good case



fill:   804c205:8b 84 24 c0 00 00 00 mov0xc0(%esp),%eax 

spill:  804d1ed:89 84 24 c0 00 00 00 mov%eax,0xc0(%esp)



in bad case with restricted scheduling



fill:   804c205:8b 84 24 c0 00 00 00 mov0xc0(%esp),%eax

spill:  804d1ed:89 44 24 6c  mov%eax,0x6c(%esp)



in bzip2 built with standard pre-reload shceduler and lto



fill:   804c272:   8b 44 24 7c mov0x7c(%esp),%eax

spill:  804d1a9:   89 44 24 78 mov%eax,0x78(%esp)



i.e. we see the different offset for spill/fill of virtual register.



To reproduce the failure is is sufficient to run spec on any corei7 machine

with the pointed out options.

Please, let me know if we are needed any additional info.

[Bug fortran/54107] [4.8 Regression] [F03] Memory hog with abstract interface

[mikael at gcc dot gnu.org]

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



--- Comment #23 from Mikael Morin  2013-01-28 
12:31:19 UTC ---

Created attachment 29294

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29294

Draft patch for comment #4, to be tested.



As I said on @fortran, I don't think it's possible to create recursive

middle-end types.  With this patch the dummy procedure gets a variadic function

type, which is the best we can do in this case.

[Bug bootstrap/56128] [4.8 Regression] No way to disable build of libsanitizer

[rguenth at gcc dot gnu.org]

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



--- Comment #1 from Richard Biener  2013-01-28 
12:21:14 UTC ---

13:17 < jakub> richi: libgomp defines FUTEX_{WAIT,WAKE} on its own rather then 

   including linux/futex.h, guess the googlers could consider such 

   a change on libasan side too



is one way of avoiding to include a kernel header (the failing header is

from 2.6.18, __user is not properly cleaned from it).

[Bug tree-optimization/56053] FAIL: c-c++-common/asan/(global|stack)-overflow-1.c

[dominiq at lps dot ens.fr]

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



--- Comment #4 from Dominique d'Humieres  2013-01-28 
12:16:32 UTC ---

Created attachment 29293

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29293

preprocessed source for global-overflow-1.c



> Can you attach preprocessed source please?



Done for global-overflow-1.c.

[Bug bootstrap/56128] New: [4.8 Regression] No way to disable build of libsanitizer

[rguenth at gcc dot gnu.org]

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



 Bug #: 56128

   Summary: [4.8 Regression] No way to disable build of

libsanitizer

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: bootstrap

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: rgue...@gcc.gnu.org

Target: x86_64-linux





There is no way to disable libsanitizer on "supported" platforms.  So with

(broken) kernel headers build fails with



In file included from

/gcc/spec/sb-vangelis-head-64/gcc/libsanitizer/sanitizer_common/sanitizer_linux.cc:35:0:

/usr/include/linux/futex.h:34:21: error: field '__user' has incomplete type

  struct robust_list __user *next;

 ^

/usr/include/linux/futex.h:34:21: error: expected ';' at end of member

declaration

/usr/include/linux/futex.h:69:21: error: expected ';' at end of member

declaration

  struct robust_list __user *list_op_pending;

 ^

/usr/include/linux/futex.h:96:26: error: expected ',' or '...' before '*' token

 long do_futex(u32 __user *uaddr, int op, u32 val, unsigned long timeout,

  ^

/usr/include/linux/futex.h:100:31: error: expected ',' or '...' before '*'

token

 handle_futex_death(u32 __user *uaddr, struct task_struct *curr, int pi);

   ^

make[3]: *** [sanitizer_linux.lo] Error 1



with no way to fix up (I don't need asan/tsan here).

[Bug tree-optimization/56053] FAIL: c-c++-common/asan/(global|stack)-overflow-1.c

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #3 from Jakub Jelinek  2013-01-28 
12:10:57 UTC ---

Just guessing, perhaps Darwin headers define memset using __builtin_memset?

So, perhaps we should ditch #include  and define the prototypes

ourselves, then it isn't dependent on the target headers.

[Bug tree-optimization/56053] FAIL: c-c++-common/asan/(global|stack)-overflow-1.c

[rguenth at gcc dot gnu.org]

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



--- Comment #2 from Richard Biener  2013-01-28 
12:07:12 UTC ---

The optimization is sound without -fno-builtin-memset.  Otherwise not - why

would that not be in effect for darwin?  Can you attach preprocessed source

please?

[Bug tree-optimization/56034] [4.8 Regression] ICE: verify_gimple failed (invalid PHI argument) with -ftree-loop-distribution

[rguenth at gcc dot gnu.org]

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



--- Comment #6 from Richard Biener  2013-01-28 
11:57:25 UTC ---

We have the producer of the loop closed PHI use not in the last partition

as it is designed to happen.  I have a patch.

[Bug target/48659] Segmentation fault when using openMP and SSE

[daniel.f.starke at freenet dot de]

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



--- Comment #3 from Daniel Starke  
2013-01-28 11:53:14 UTC ---

I can confirm this bug for gcc 4.7.2 mingw64. The -mstackrealign command-line

flag can be used as workaround as described on

http://stackoverflow.com/questions/6716654/segmentation-fault-using-openmp-and-sse

until this bug is properly patched.

[Bug target/56127] Incorrect code with -O1, -O2, -O3

[trosenband at gmail dot com]

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



Till  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #4 from Till  2013-01-28 11:39:58 UTC 
---

Can't reproduce problem with non-vendor-modified GCC.

[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'

[jakub at gcc dot gnu.org]

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



--- Comment #25 from Jakub Jelinek  2013-01-28 
11:27:51 UTC ---

I meant the ABI checkers only.  Anyway, on the other side given comments like:

   This mangling isn't part of the ABI specification; in the ABI

   specification, the vtable group is dumped in the same COMDAT as the

   main vtable, and is referenced only from that vtable, so it doesn't

   need an external name.  For binary formats without COMDAT sections,

   though, we need external names for the vtable groups.

and

Construction virtual tables are not exported because

they cannot be referred to from other object files;

their name is not standardized by the ABI.



perhaps making them hidden whenever possible is really desirable.

[Bug target/56127] Incorrect code with -O1, -O2, -O3

[trosenband at gmail dot com]

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



--- Comment #3 from Till  2013-01-28 11:20:46 UTC 
---

Thank you for checking.  You are right, this seems to be a version-specific

problem for Sourcery CodeBench.  I don't see an obvious bug in the assembly

code produce by these compilers:



@ GNU C++ (Ubuntu/Linaro 4.6.3-8ubuntu1) version 4.6.3 20120624 (prerelease)

(arm-linux-gnueabi)



@ GNU C++ (Ubuntu/Linaro 4.7.2-1ubuntu1) version 4.7.2 (arm-linux-gnueabi)

[Bug tree-optimization/56118] Piecewise vector / complex initialization from constants not combined

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-28

Summary|No constant propagation in  |Piecewise vector / complex

   |vector field assignment |initialization from

   ||constants not combined

 Ever Confirmed|0   |1



--- Comment #2 from Richard Biener  2013-01-28 
10:44:34 UTC ---

The original testcase is a dup of PR33562, it's a missed dead store

elimination,

not "constant propagation".  The other issue is that we are not combining

adjacent stores (also for other types), we have a PR for that elsewhere, too.

Yes, basic-block vectorization could handle this, but it's probably not the

very best knife to do that job ;)



Related testcases have this issue with _Complex and __real / __imag

piecewise initializations.



Thus, let's make this bug the failure to combine piecewise constant inits

of vectors and complex.

[Bug target/56127] Incorrect code with -O1, -O2, -O3

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Target||arm-xilinx-eabi

  Component|c++ |target



--- Comment #2 from Richard Biener  2013-01-28 
10:36:16 UTC ---

@ GNU C++ (Sourcery CodeBench Lite 2012.03-83) version 4.6.3 (arm-xilinx-eabi)



please try a FSF compiler version.  Works ok for me with 4.6.3 on x86_64-linux,

thus not a frontend issue but at most a target one.

[Bug tree-optimization/56125] [4.7/4.8 Regression] -O2 -ffast-math generates bad code when dividing a double by the square of another double.

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org

   |gnu.org |



--- Comment #4 from Jakub Jelinek  2013-01-28 
10:27:19 UTC ---

Created attachment 29292

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29292

gcc48-pr56125.patch



The bug is that the last two optimizations of pow (where 2c resp. 3c is a

non-zero integer) silently assume that the earlier optimizations already

handled the cases where already c (or 2c for the last optimization) is an

integer.

But that doesn't have to be the case, as shown by the testcase, the integer

optimization is guarded by c in [-1,2] or optimization for speed.



The && optimize_function_for_speed_p () (or should that be

optimize_insn_for_speed_p?, the pow folding is inconsistent in that, and I

don't see e.g. rtl_profile_for_bb being called during this pass to make it

accurate)

is up for discussions, say on x86_64

__attribute__((cold)) double

foo (double x, double n)

{

  double u = __builtin_pow (x, -1.5);

  return u;

}

with it we get smaller code:

movsd   .LC0(%rip), %xmm1

jmp pow

compared to:

sqrtsd  %xmm0, %xmm1

mulsd   %xmm0, %xmm1

movsd   .LC0(%rip), %xmm0

divsd   %xmm1, %xmm0

without it, 7 bytes shorter.

[Bug c++/56127] Incorrect code with -O1, -O2, -O3

[trosenband at gmail dot com]

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



--- Comment #1 from Till  2013-01-28 10:20:48 UTC 
---

Created attachment 29291

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29291

exp_results.ii

[Bug c++/56127] New: Incorrect code with -O2

[trosenband at gmail dot com]

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



 Bug #: 56127

   Summary: Incorrect code with -O2

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: trosenb...@gmail.com





Created attachment 29290

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29290

main.ii



It seems like GCC 4.6.3 generates incorrect assembly for ARM Cortex-A9 from the

following C++ code when invoked with -O1, -O2 and -O3

The code just increments two variables 100 times and divides them.



Correct output is:

average = 1.000

PMTsum = 100  nValues = 100



but -O1 gives this:

average = 0.000

PMTsum = 100  nValues = 100



and -O2 and -O3 yield this:

average =   inf

PMTsum = 100  nValues = 100



This 3-file C++ project is the minimal configuration that shows this behavior. 

With everything in one file the problem vanishes.



Below the C++ code is the assembly language output, marked with *** where I

think the error may be (but I'm unfamiliar with assembly language).



Thanks to anyone who looks into this, and to everyone who has been developing

GCC!



//exp_results.h



class exp_results

{

public:

exp_results() :

PMTsum(0),

nValues(0)

{

}



unsigned increment();



double get_average()

{

if (nValues)

return ((double)PMTsum) / ((double)nValues);

else

return 0;

}



unsigned PMTsum;

unsigned nValues;

};





//exp_results.cpp



#include "exp_results.h"





unsigned exp_results::increment()

{

PMTsum++;

nValues++;



return 1;

}



//main.cc



#include 

#include "exp_results.h"



int main()

{

exp_results r;



for(unsigned i=0; i< 100; i++)

r.increment();



printf("average = %9.3f\n", r.get_average());

printf("PMTsum = %u  nValues = %u\n", r.PMTsum, r.nValues);

return 0;

}





// main.s



.cpu cortex-a9

.eabi_attribute 27, 3

.fpu neon-fp16

.eabi_attribute 20, 1

.eabi_attribute 21, 1

.eabi_attribute 23, 3

.eabi_attribute 24, 1

.eabi_attribute 25, 1

.eabi_attribute 26, 1

.eabi_attribute 30, 2

.eabi_attribute 34, 1

.eabi_attribute 18, 4

.file"main.cc"

@ GNU C++ (Sourcery CodeBench Lite 2012.03-83) version 4.6.3 (arm-xilinx-eabi)

@compiled by GNU C version 4.3.2, GMP version 4.3.2, MPFR version 3.0.1-p4,

MPC version 0.9

@ GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

@ options passed:  -fpreprocessed main.ii -mcpu=cortex-a9

@ -mfloat-abi=softfp -mfpu=neon-fp16 -auxbase-strip src/main.o -O2 -Wall

@ -fmessage-length=0 -fverbose-asm -fremove-local-statics

@ options enabled:  -fauto-inc-dec -fbranch-count-reg -fcaller-saves

@ -fcombine-stack-adjustments -fcommon -fcompare-elim -fcprop-registers

@ -fcrossjumping -fcse-follow-jumps -fdefer-pop

@ -fdelete-null-pointer-checks -fdevirtualize -fdwarf2-cfi-asm

@ -fearly-inlining -feliminate-unused-debug-types -fexceptions

@ -fexpensive-optimizations -fextension-elimination -fforward-propagate

@ -ffunction-cse -fgcse -fgcse-lm -fguess-branch-probability -fident

@ -fif-conversion -fif-conversion2 -findirect-inlining -finline

@ -finline-functions-called-once -finline-small-functions -fipa-cp

@ -fipa-profile -fipa-pure-const -fipa-reference -fipa-sra

@ -fira-share-save-slots -fira-share-spill-slots -fivopts

@ -fkeep-static-consts -fleading-underscore -fmath-errno -fmerge-constants

@ -fmerge-debug-strings -fmove-loop-invariants -fomit-frame-pointer

@ -foptimize-register-move -foptimize-sibling-calls -fpartial-inlining

@ -fpeephole -fpeephole2 -fprefetch-loop-arrays -fpromote-loop-indices

@ -freg-struct-return -fregmove -frename-registers -freorder-blocks

@ -freorder-functions -frerun-cse-after-loop

@ -fsched-critical-path-heuristic -fsched-dep-count-heuristic

@ -fsched-group-heuristic -fsched-interblock -fsched-last-insn-heuristic

@ -fsched-rank-heuristic -fsched-spec -fsched-spec-insn-heuristic

@ -fsched-stalled-insns-dep -fschedule-insns -fschedule-insns2

@ -fsection-anchors -fshow-column -fsigned-zeros -fsplit-ivs-in-unroller

@ -fsplit-wide-types -fstrict-aliasing -fstrict-overflow

@ -fstrict-volatile-bitfields -fthread-jumps -ftoplevel-reorder

@ -ftrapping-math -ftree-bit-ccp -ftree-builtin-call-dce -ftree-ccp

@ -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-cselim -ftree-dce

@ -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre

@ -ftree-if-to-switch-conversion -ftree-loop-if-convert -ftree-loop-im

@ -ftree-loop-ivcanon -ftree-loop-optimize -ftree-parallelize-loops=

@ -ftree-phiprop -ftree-pre -ftree-pta -ftree-reassoc -ftree-scev-cprop

@ -ftree-sink -ftree-slp-vectorize -ftree-sra -ftree-switch-conversion

@ -ftree-ter -ftree-vect-loop-version -ftree-vrp -funit-at-a-time

@ -funroll-l

[Bug middle-end/56113] out of memory when compiling a function with many goto labels (50k > )

[rguenth at gcc dot gnu.org]

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



--- Comment #8 from Richard Biener  2013-01-28 
10:04:46 UTC ---

Moving ->points_to to a separate obstack might also help (performing

label_visit

in topological order we could then free ->points_to once we have visited

all successors of a node).

[Bug middle-end/56113] out of memory when compiling a function with many goto labels (50k > )

[rguenth at gcc dot gnu.org]

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



--- Comment #7 from Richard Biener  2013-01-28 
09:45:06 UTC ---

label_visit () seems to collect recursively points_to bits over the predecessor

graph, thus using a quadratic amount of memory.  It does so to optimize

variables that point to the same stuff by assigning them the same

pointer_label.



"indirect" nodes seem to be special as far as I can see as they will never

share the same label with a previously visited node.  We should be able

to represent their points_to set by themselves and not miss any equivalences

nor create false ones by that.  Thus:



Index: gcc/tree-ssa-structalias.c

===

--- gcc/tree-ssa-structalias.c  (revision 195502)

+++ gcc/tree-ssa-structalias.c  (working copy)

@@ -2103,6 +2103,17 @@ label_visit (constraint_graph_t graph, s

   if (!graph->points_to[n])

 graph->points_to[n] = BITMAP_ALLOC (&predbitmap_obstack);



+  /* Indirect nodes get fresh variables.  Represent those by that

+ single fresh variable.  */

+  if (!bitmap_bit_p (graph->direct_nodes, n))

+{

+  bitmap_set_bit (graph->points_to[n], FIRST_REF_NODE + n);

+  graph->pointer_label[n] = pointer_equiv_class++;

+  equiv_class_add (pointer_equiv_class_table,

+  graph->pointer_label[n], graph->points_to[n]);

+  return;

+}

+

   /* Label and union our incoming edges's points to sets.  */

   EXECUTE_IF_IN_NONNULL_BITMAP (graph->preds[n], 0, i, bi)

 {

@@ -2117,9 +2128,6 @@ label_visit (constraint_graph_t graph, s

   if (graph->points_to[w])

bitmap_ior_into(graph->points_to[n], graph->points_to[w]);

 }

-  /* Indirect nodes get fresh variables.  */

-  if (!bitmap_bit_p (graph->direct_nodes, n))

-bitmap_set_bit (graph->points_to[n], FIRST_REF_NODE + n);



   if (!bitmap_empty_p (graph->points_to[n]))

 {



not sure if it helps in this case though.  Assigning pointer_labels is

an optimization, and could be completely short-cut if necessary (not

sure what the result would be for this testcase, or how we could up-front

detect if performing this equivalencing is worthwhile or not).

One may also think of using the pointer_labels of the incoming edges

to perform the unioning instead, thus cache by { set of pointer labels },

 { points-to set } instead of by expanded points-to set only.



The algorithm is definitely poor in its memory usage ...

[Bug tree-optimization/56125] [4.7/4.8 Regression] -O2 -ffast-math generates bad code when dividing a double by the square of another double.

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org

   Target Milestone|--- |4.7.3



--- Comment #3 from Jakub Jelinek  2013-01-28 
09:15:09 UTC ---

Regressed with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174446

Looking into it.

[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts

[rguenth at gcc dot gnu.org]

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



--- Comment #15 from Richard Biener  2013-01-28 
08:55:55 UTC ---

(In reply to comment #12)

> Created attachment 29272 [details]

> gcc48-pr56094.patch

> 

> input_location is used heavily in the gimplifier, gimplify_expr sets it from

> the expression being currently gimplified (if it has any), and for temporaries

> and their initializers that are created while gimplifying that stmt it is

> intentional to use the location of that expression.

> 

> I've bootstrapped/regtested this patch on i686-linux (no ada) so far, the 
> lex.c

> hunk is to avoid ICEs when e.g. tree-parloops.c calls the make_type langhook

> (but there are other callers of that) with input_location of UNKNOWN_LOCATION.

> I was surprised there weren't regressions, given that input_location is used

> implicitly e.g. by all error/warning calls, unless they supply their own

> location.



This patch looks like a good way forward to me (moving the input_location

logic to the single caller of expand_all_functions () would be even better

of course, at best up to finalize_compilation_unit - which also should not

need to save the old location but simply arrange it to be UNKNOWN_LOCATION.

That we need input_location during RTL expansion (and RTL opts even?) is

of course bad enough :/)



I'm not sure we want this kind of patch for stage4 though, eventually we

should simply go with setting input_location to UNKNOWN inside

force_gimple_operand and friends.

[Bug rtl-optimization/56117] [4.8 Regression] ICE: in cselib_subst_to_values, at cselib.c:1853 with -O2 -fsched2-use-superblocks and __builtin_prefetch()

[jakub at gcc dot gnu.org]

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



--- Comment #2 from Jakub Jelinek  2013-01-28 
08:51:39 UTC ---

Created attachment 29289

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29289

gcc48-pr56117.patch



Untested fix.  For MEMs, sched-deps.c is calling cselib_lookup_from_insn, but

for PREFETCH it wasn't doing that.  As this is before cselib_process_insn is

called, some REGs mentioned in the pattern might be never looked up yet at that

point.

[Bug rtl-optimization/56117] [4.8 Regression] ICE: in cselib_subst_to_values, at cselib.c:1853 with -O2 -fsched2-use-superblocks and __builtin_prefetch()

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-01-28

 CC||jakub at gcc dot gnu.org,

   ||vmakarov at gcc dot gnu.org

 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #1 from Jakub Jelinek  2013-01-28 
08:44:33 UTC ---

As expected, regressed with the

http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195211

change.

[Bug c/56086] when compiling C code with -std=gnu99 macro __STDC_UTF_16__ is defined

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org,

   ||jason at gcc dot gnu.org



--- Comment #5 from Jakub Jelinek  2013-01-28 
08:28:40 UTC ---

Let's CC Jason on this.

[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)

[jakub at gcc dot gnu.org]

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



--- Comment #15 from Jakub Jelinek  2013-01-28 
08:19:43 UTC ---

Because -gstabs etc. are still supported on most of the primary and secondary

targets, and (to my surprise) some projects are still using it (I believe e.g.

some Mozilla builds do as their bugreporting system only supports STABS, not

DWARF).  STABS hasn't been deprecated, so we can't just remove that support for

4.8 easily, yeah, we should probably deprecate it and remove later on.