[Bug bootstrap/54688] [4.8 regression] violation of implicit restriction "No_Elaboration_Code" on a-ioexce.ads

[ebotcazou at gcc dot gnu.org]

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



--- Comment #13 from Eric Botcazou  2012-09-28 
07:55:19 UTC ---

> The offset range should not be an issue with the right constraints etc.; the

> port really ought to be changed.



Yes, in fact we already have the machinery to do it.



> In the meantime, please try this patch.



Thanks, it works for me, modulo the obvious thinko (mii->inc_constant --> cst).

[Bug rtl-optimization/52543] lower-subreg.c: code bloat of 300%-400% for multi-word memory splits

[gjl at gcc dot gnu.org]

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



--- Comment #15 from Georg-Johann Lay  2012-09-28 
08:21:19 UTC ---

Author: gjl

Date: Fri Sep 28 08:21:06 2012

New Revision: 191820



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

Log:

PR rtl-optimization/52543

* config/avr/avr.c (avr_mode_dependent_address_p): Return true for

all non-generic address spaces.

(TARGET_SECONDARY_RELOAD): New hook define to...

(avr_secondary_reload): ...this new static function.

* config/avr/avr.md (reload_in): New insns.

Undo r185605 (mostly):

* config/avr/avr-protos.h (avr_load_lpm): Remove.

* config/avr/avr.c (avr_load_libgcc_p): Don't restrict to __flash loads.

(avr_out_lpm): Also handle loads > 1 byte.

(avr_load_lpm): Remove.

(avr_find_unused_d_reg): New static function.

(avr_out_lpm_no_lpmx): New static function.

(adjust_insn_length): Remove ADJUST_LEN_LOAD_LPM.

* config/avr/avr.md (unspec): Remove UNSPEC_LPM.

(load__libgcc): Use MEM instead of UNSPEC_LPM.

(load_, load__clobber): Remove.

(mov): For multi-byte move from non-generic

16-bit address spaces: Expand to *mov again.

(load_libgcc): New expander.

(split-lpmx): Remove split.





Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/avr/avr-protos.h

trunk/gcc/config/avr/avr.c

trunk/gcc/config/avr/avr.md

[Bug bootstrap/54732] [4.8 regression] Installation failure: libbacktrace rebuilds upon install when built with "make bootstrap-lean"

[rguenth at gcc dot gnu.org]

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



Richard Guenther  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.0

[Bug tree-optimization/54713] [4.8 Regression] error: non-trivial conversion at assignment in gcc.c-torture/compile/pr53410-2.c

[rguenth at gcc dot gnu.org]

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



--- Comment #5 from Richard Guenther  2012-09-28 
08:36:28 UTC ---

(In reply to comment #4)

> Created attachment 28293 [details]

> gcc48-pr54713.patch

> 

> Updated patch.  I had to make the CONSTRUCTOR checking less strict, in

> particular there are CONSTRUCTORS with (consecutive) indexes as well as NULL

> indexes, there are CONSTRUCTORS with less than nunits elements even when the

> elements are scalar.



Ugh, less than nunits is probably ok for GENERIC but in GIMPLE we really

want trailing zeros explicit ... :/  Thus, if we need to "gimplify"

vector constructors we can as well clear their indexes?



> But even with all this I'm still getting gfortran.dg/loc_2.f90 -O3 ICEs,

> apparently SLP creates vector CONSTRUCTOR with type integer(kind=4) vector, 
> but

> elements logical(kind=4) (i.e. same TYPE_MODE, but INTEGER_TYPE vs.

> BOOLEAN_TYPE.  Shall I make the verification even less strict (check TYPE_MODE

> instead of useless_type_conversion?), or shall we fix the vectorizer?



The vectorizer needs to be fixed.  See the comment in

get_vectype_for_scalar_type_and_size:



  /* For vector types of elements whose mode precision doesn't

 match their types precision we use a element type of mode

 precision.  The vectorization routines will have to make sure

 they support the proper result truncation/extension.

 We also make sure to build vector types with INTEGER_TYPE

 component type only.  */



> Shouldn't I split the patch into the bugfixes + testcases and submit it before

> the verification, so that the latter can be done more slowly?



Yes, I think separate patches would be prefered.

[Bug lto/54095] Unnecessary static variable renaming

[rguenth at gcc dot gnu.org]

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



--- Comment #12 from Richard Guenther  2012-09-28 
08:37:56 UTC ---

Ok, I give up ;)  Honza, I think we should go with your patch to re-name

before LTO symtab merging as a first step, we can try improving later ...

[Bug bootstrap/54718] [4.8 regression] ICE in remap_gimple_stmt, at tree-inline.c:1468

[ro at gcc dot gnu.org]

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



Rainer Orth  changed:



   What|Removed |Added



 CC||iant at google dot com

 Depends on||54688



--- Comment #4 from Rainer Orth  2012-09-28 08:37:57 UTC 
---

The fix for PR bootstrap/54688 also fixed this one.  I can't say if there's

another

unrelated issue here, though.



There's one other problem (which is most likely different and has occured

before):



Since 20120919, go1 might run into an infinite loop compiling one or more

sparcv9

libgo modules:



pstack shows this stacktrace:



1653:/var/gcc/regression/trunk/11-gcc/build/./gcc/go1 fmt_test.go scan_test

 00229ec4 find_base_term(rtx_def*) (ba7c00, c, 27fb548, 33587b8, 94aef80,

e10dbf0) + 2a0

 00229d48 find_base_term(rtx_def*) (ba7c00, c, a6fc00, b43c00, 22a000, 201bbe0)

+ 124

 0022ac7c base_alias_check(rtx_def*, rtx_def*, machine_mode, machine_mode)

(eca9c840, ecac4080, c, 9, 22a000, 0) + 10

 0022c684 true_dependence_1(rtx_def const*, machine_mode, rtx_def*, rtx_def

const*, rtx_def*, bool) (1, 9, ecac4080, eca9c850, eca9c840, 1) + 150

 006a6500 drop_overlapping_mem_locs(void**, void*) (ba4400, ecac4080, 8604618,

8604608, eca9c850, 84878b0) + 1ac

 00887c24 htab_traverse_noresize (ff1180, 6a6354, ffbfc1bc, 0, 1bb1631c,

1bb04964) + 38

 0069ec30 clobber_overlapping_mems(dataflow_set_def*, rtx_def*) (e5c258,

ec1f6980, ffbfc224, 0, 1bb1631c, 1bb1631c) + 5c

 006a4870 val_store(dataflow_set_def*, rtx_def*, rtx_def*, rtx_def*, bool)

(e5c258, 107c898, ec1f6980, f6d97f68, 1, 107d7b8) + 240

 006a549c _ZL19compute_bb_dataflowP15basic_block_def.isra.55 (f7c66e48, e5c258,

107c898, ec1f69a0, f6d993d0, f6d97f68) + 6f8

 006a7a34 vt_find_locations() (cec5920, b52800, 10c58a8, f7c66e40, e5c0a8,

e5c0a0) + 3f0

 006b0858 variable_tracking_main() (6b07ec, b2f500, 1, 1, ba7e90, b52800) + 6c

 00443a54 execute_one_pass(opt_pass*) (1, b2f500, b52800, b72800, b9e800, 0) +

134

 00443f18 execute_pass_list(opt_pass*) (b2f500, b2d75c, b52800, b72800, b9e800,

0) + 14

 00443f3c execute_pass_list(opt_pass*) (b2d75c, b2d790, b52800, b72800, b9e800,

0) + 38

 00443f3c execute_pass_list(opt_pass*) (b2d790, b52800, b7292c, fb7ce8a0, 6,

b30334) + 38

 0028578c expand_function(cgraph_node*) (fb7ce8a0, b9e800, ba8800, fb48bd80,

b72800, b3d000) + bc

 00287ae0 compile() (ec0788, 78d, b3cc00, b3cc00, b3cc00, ec2f18) + c90

 00287eb0 finalize_compilation_unit() (1, 108, 1, ba8800, ba7e90, b9e800) + 80

 001ba404 Gogo::write_globals() (bcfaa8, ffbfc984, 0, d367c8, 0, ffbfc984) +

ac4

 004f385c compile_file() (2, 0, 7, b2b4c4, b9e800, ba7e90) + 88

 004f5368 toplev_main(int, char**) (ba8800, b9e800, b9e800, b2b4c4, b30400,

ba7e90) + aa8

 001823ec _start   (0, 0, 0, 0, 0, 0) + 5c



I'll hae to investigate more closely.



  Rainer

[Bug bootstrap/54718] [4.8 regression] ICE in remap_gimple_stmt, at tree-inline.c:1468

[ubizjak at gmail dot com]

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



--- Comment #5 from Uros Bizjak  2012-09-28 08:54:51 
UTC ---

(In reply to comment #4)

> The fix for PR bootstrap/54688 also fixed this one.  I can't say if there's

> another unrelated issue here, though.

> 

> There's one other problem (which is most likely different and has occured

> before):

> 

> Since 20120919, go1 might run into an infinite loop compiling one or more

> sparcv9 libgo modules:



Related to PR54507. You can try to compile with -fno-var-tracking-assignments.

[Bug lto/54705] ICE during custom LTO bootstrap with Ada enabled

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||WONTFIX



--- Comment #5 from Eric Botcazou  2012-09-28 
09:54:15 UTC ---

#2  0x005628db in output_die (die=0x7fffebb91460)

at /home/eric/svn/gcc-4_7-branch/gcc/dwarf2out.c:8469

8469  gcc_assert (AT_ref (a)->die_offset);

(gdb) p debug_dwarf_die(die)

DIE 360467: DW_TAG_GNU_call_site (0x7fffebb91460)

  abbrev id: 93 offset: 360467 mark: 1

  DW_AT_low_pc: label: *.LVL14079

  DW_AT_abstract_origin: die -> 0 (0x7fffeb8a6f00)



We have a cycle in the debug info:



(gdb) p a->dw_attr_val.v.val_die_ref.die

$25 = (dw_die_ref) 0x7fffeb8a6f00

(gdb) p a->dw_attr_val.v.val_die_ref.die->die_parent

$26 = (dw_die_ref) 0x7fffeb8c4820

(gdb) p a->dw_attr_val.v.val_die_ref.die->die_parent->die_parent

$27 = (dw_die_ref) 0x7fffeb8c4780

(gdb) p a->dw_attr_val.v.val_die_ref.die->die_parent->die_parent->die_parent

$28 = (dw_die_ref) 0x7fffeb8a6f00



(gdb) p *a->dw_attr_val.v.val_die_ref.die

$21 = {die_id = {die_symbol = 0x0, die_type_node = 0x0}, 

  die_attr = 0x7fffeb86dc60, die_parent = 0x7fffeb8c4820, 

  die_child = 0x7fffeb8c4d20, die_sib = 0x7fffeb8c48c0, die_definition = 0x0, 

  die_offset = 0, die_abbrev = 0, die_mark = 2, die_perennial_p = 0, 

  decl_id = 4952, die_tag = DW_TAG_subprogram}



(gdb) p *a->dw_attr_val.v.val_die_ref.die->die_parent

$22 = {die_id = {die_symbol = 0x0, die_type_node = 0x0}, 

  die_attr = 0x7fffeb8c1528, die_parent = 0x7fffeb8c4780, 

  die_child = 0x7fffeb8c4be0, die_sib = 0x7fffeb8c47d0, die_definition = 0x0, 

  die_offset = 0, die_abbrev = 0, die_mark = 2, die_perennial_p = 0, 

  decl_id = 0, die_tag = DW_TAG_lexical_block}



(gdb) p *a->dw_attr_val.v.val_die_ref.die->die_parent->die_parent

$23 = {die_id = {die_symbol = 0x0, die_type_node = 0x0}, 

  die_attr = 0x7fffeb8c6360, die_parent = 0x7fffeb8a6f00, 

  die_child = 0x7fffeb8c4820, die_sib = 0x7fffeb8c4d20, die_definition = 0x0, 

  die_offset = 0, die_abbrev = 0, die_mark = 2, die_perennial_p = 0, 

  decl_id = 0, die_tag = DW_TAG_inlined_subroutine}



(gdb) p *a->dw_attr_val.v.val_die_ref.die->die_parent->die_parent->die_parent

$24 = {die_id = {die_symbol = 0x0, die_type_node = 0x0}, 

  die_attr = 0x7fffeb86dc60, die_parent = 0x7fffeb8c4820, 

  die_child = 0x7fffeb8c4d20, die_sib = 0x7fffeb8c48c0, die_definition = 0x0, 

  die_offset = 0, die_abbrev = 0, die_mark = 2, die_perennial_p = 0, 

  decl_id = 4952, die_tag = DW_TAG_subprogram}



That's the usual mess with inlined nested subprograms, see

  http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00161.html

for a discussion and LTO further screws things up.



Sorting this out properly is probably impossible, so here are 2 workarounds:



 1.  This patchlet:



Index: dwarf2out.c

===

--- dwarf2out.c (revision 191561)

+++ dwarf2out.c (working copy)

@@ -17193,7 +17193,7 @@ gen_call_site_die (tree decl, dw_die_ref

   dw_die_ref tdie = lookup_decl_die (SYMBOL_REF_DECL

(ca_loc->symbol_ref));

   if (tdie)

add_AT_die_ref (die, DW_AT_abstract_origin, tdie);

-  else

+  else if (!in_lto_p)

add_AT_addr (die, DW_AT_abstract_origin, ca_loc->symbol_ref);

 }

   return die;



works around 3 different crashes with -flto -g for Ada programs I know of.

For some reason, the new DW_TAG_GNU_call_site stuff has made things worse.



 2. Do a canonical LTO bootstrap, i.e. add --with-build-config=bootstrap-lto to

the configure line and remove -flto from BOOT_CFLAGS.

[Bug libstdc++/54729] __compare_and_swap does not return on all paths

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #2 from Paolo Carlini  2012-09-28 
09:57:27 UTC ---

Closing then.

[Bug c++/54249] [C++11] No ::nullptr_t in header

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-09-28

  Component|libstdc++   |c++

 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot

   |gnu.org |com

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #12 from Paolo Carlini  2012-09-28 
10:00:36 UTC ---

On it.

[Bug c++/54249] [C++11] No ::nullptr_t in header

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

[Bug tree-optimization/54733] New: Missing opportunity to optimize endian independent load/store

[joey.ye at arm dot com]

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



 Bug #: 54733

   Summary: Missing opportunity to optimize endian independent

load/store

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: joey...@arm.com





This case tries to load from memory in little-endian way, no matter what

endianess current target is.



On trunk 4.8 little-endian target, two byte loads should be able to combined

into a single 16-byte load.



int read_aux(void *, int);



int read_le()

{ 

unsigned char data[2]; 

read_aux(data, 2); 

return data[0] | (data[1]<<8);

}



Current Tree (optimized):

  unsigned char data[2];



  read_aux (&data, 2);

  D.4064_1 = data[0];

  D.4065_2 = (int) D.4064_1;

  D.4066_3 = data[1];

  D.4067_4 = (int) D.4066_3;

  D.4068_5 = D.4067_4 << 8;

  D.4063_6 = D.4068_5 | D.4065_2;

  data ={v} {CLOBBER};

  return D.4063_6;



Expected Tree (optimized):

  unsigned char data[2];

  unsigned short *temp;

  unsigned in D.4064;



  read_aux (&data, 2);

  temp=&data;

  D.4064_1 = *temp;

  return D.4064_1;

[Bug fortran/54730] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1066

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #3 from Tobias Burnus  2012-09-28 
10:07:41 UTC ---

That seems to be a regression: No ICE with 4.1 and 4.3, while there is an ICE

with 4.4/4.5/4.6/4.7/4.8 (interestingly, g95 also ICEs).

[Bug fortran/54724] libgfortran does not respect --disable-werror

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #1 from Tobias Burnus  2012-09-28 
10:12:00 UTC ---

Well, libgfortran only uses -Werror for the Fortran code. I think it is

extremely unlikely to trigger there. (That part uses no system-specific code.)



Using -Werror for libgfortran's C code would be nice, but it fails too often.

(I tried it once.) Thus, libgfortran's C code is compiled without -Werror by

default - even without an explicit --disable-werror.



Thus, I think your issue is rather hypothetical and I don't think it makes

sense to fix it.

[Bug fortran/54730] [4.6/4.7/4.8 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1066

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



Summary|ICE in  |[4.6/4.7/4.8 Regression]

   |gfc_typenode_for_spec, at   |ICE in

   |fortran/trans-types.c:1066  |gfc_typenode_for_spec, at

   ||fortran/trans-types.c:1066



--- Comment #4 from Dominique d'Humieres  2012-09-28 
10:23:35 UTC ---

> That seems to be a regression: No ICE with 4.1 and 4.3 ...



Confirmed for 4.2.4 and 4.3.4 on powerpc-apple-darwin9, so marking as a

4.6/4.7/4.8 regression (4.5 and 4.6 being no longer supported).

[Bug debug/54734] New: Debug info for C++ and LTO misses types

[rguenth at gcc dot gnu.org]

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



 Bug #: 54734

   Summary: Debug info for C++ and LTO misses types

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: lto

  Severity: normal

  Priority: P3

 Component: debug

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

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





Consider the following reduced testcase (from standard library use):



template  class basic_string;

typedef basic_string sstring;



template 

class basic_string

{

public:

  typedef T type;

};



extern template class basic_string;



int main()

{

  sstring s;

  return sstring::type (0);

}



without LTO we have



 <1><130>: Abbrev Number: 2 (DW_TAG_typedef)

<131>   DW_AT_name: (indirect string, offset: 0x98): sstring

<135>   DW_AT_decl_file   : 1   

<136>   DW_AT_decl_line   : 2   

<137>   DW_AT_type: <0x13b> 

 <1><13b>: Abbrev Number: 3 (DW_TAG_class_type)

<13c>   DW_AT_name: (indirect string, offset: 0xa0):

basic_string 

<140>   DW_AT_byte_size   : 1   

<141>   DW_AT_decl_file   : 1   

<142>   DW_AT_decl_line   : 5   

<143>   DW_AT_sibling : <0x15a> 

 <2><147>: Abbrev Number: 2 (DW_TAG_typedef)

<148>   DW_AT_name: (indirect string, offset: 0x8e): type   

<14c>   DW_AT_decl_file   : 1   

<14d>   DW_AT_decl_line   : 8   

<14e>   DW_AT_type: <0x15a> 



while with LTO we get only



 <1><137>: Abbrev Number: 3 (DW_TAG_typedef)

<138>   DW_AT_name: (indirect string, offset: 0xf8): sstring

<13c>   DW_AT_decl_file   : 1   

<13d>   DW_AT_decl_line   : 11  

<13e>   DW_AT_type: <0x142> 

 <1><142>: Abbrev Number: 4 (DW_TAG_structure_type)

<143>   DW_AT_name: (indirect string, offset: 0xeb): basic_string   

<147>   DW_AT_declaration : 1   



which results from gen_struct_or_union_type_die on the type seeing

a TYPE_STUB_DECL with TYPE_DECL_SUPPRESS_DEBUG set.



Somehow the C++ frontend "manually" outputs the desired info and then for

later processing directs dwarf2out.c to not output anything?



This probably all boils down to LTO "ignoring" debug-hook calls from the

frontend, but is there a way to recover from that?  For example by

clearing TYPE_DECL_SUPPRESS_DEBUG for LTO?  Or is that used in "meaningful"

ways as well?

[Bug tree-optimization/54733] Missing opportunity to optimize endian independent load/store

[rguenth at gcc dot gnu.org]

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



Richard Guenther  changed:



   What|Removed |Added



   Keywords||missed-optimization

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-09-28

 Ever Confirmed|0   |1



--- Comment #1 from Richard Guenther  2012-09-28 
10:47:44 UTC ---

Confirmed.  The original idea was to leverage the byte-swap pass for this.

First you need to extend that to work on a memory source (which it currently

does not handle), then you, in addition to detecting bswap, emit a word

load and detect the "noop" pattern which then skips bswap.  (the byte-swap

pass was also supposed to utilize the vector shuffle engine for non-bswap

shuffles).

[Bug lto/47799] LTO debug info for early inlined functions missing

[rguenth at gcc dot gnu.org]

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



--- Comment #3 from Richard Guenther  2012-09-28 
11:07:22 UTC ---

Author: rguenth

Date: Fri Sep 28 11:07:17 2012

New Revision: 191824



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

Log:

2012-09-28  Richard Guenther  



PR lto/47799

* lto-streamer-out.c (tree_is_indexable): Make PARM_DECLs global.

(lto_output_tree_ref): Handle references to them.

(output_function): Do not output function arguments again.

* lto-streamer-in.c (input_function): Do not input arguments

again, nor overwrite them.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/lto-streamer-in.c

trunk/gcc/lto-streamer-out.c

[Bug tree-optimization/54713] [4.8 Regression] error: non-trivial conversion at assignment in gcc.c-torture/compile/pr53410-2.c

[jakub at gcc dot gnu.org]

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



--- Comment #6 from Jakub Jelinek  2012-09-28 
12:19:07 UTC ---

Author: jakub

Date: Fri Sep 28 12:18:57 2012

New Revision: 191826



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

Log:

PR tree-optimization/54713

* fold-const.c (vec_cst_ctor_to_array): Give up if vector CONSTRUCTOR

has vector elements.

(fold_ternary_loc) : Likewise.

* tree-vect-generic.c (vector_element): Don't rely on CONSTRUCTOR elts

indexes.  Use BIT_FIELD_REF if CONSTRUCTOR has vector elements.

(lower_vec_perm): Use NULL_TREE CONSTRUCTOR indexes.



* gcc.c-torture/compile/pr54713-1.c: New test.

* gcc.c-torture/compile/pr54713-2.c: New test.

* gcc.c-torture/compile/pr54713-3.c: New test.



Added:

trunk/gcc/testsuite/gcc.c-torture/compile/pr54713-1.c

trunk/gcc/testsuite/gcc.c-torture/compile/pr54713-2.c

trunk/gcc/testsuite/gcc.c-torture/compile/pr54713-3.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/fold-const.c

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-vect-generic.c

[Bug target/54716] Select best typed instruction for bitwise operations

[jakub at gcc dot gnu.org]

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



--- Comment #10 from Jakub Jelinek  2012-09-28 
12:21:01 UTC ---

Author: jakub

Date: Fri Sep 28 12:20:54 2012

New Revision: 191827



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

Log:

PR target/54716

* config/i386/predicates.md (nonimmediate_or_const_vector_operand):

New predicate.

* config/i386/i386.c (ix86_expand_vector_logical_operator): New

function.

* config/i386/i386-protos.h (ix86_expand_vector_logical_operator): New

prototype.

* config/i386/sse.md (3 VI logic): Use it.



* gcc.target/i386/xorps-sse2.c: Remove xfails.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/i386/i386-protos.h

trunk/gcc/config/i386/i386.c

trunk/gcc/config/i386/predicates.md

trunk/gcc/config/i386/sse.md

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/gcc.target/i386/xorps-sse2.c

[Bug c++/53551] -Wunused-local-typedefs misses uses

[dodji at gcc dot gnu.org]

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



--- Comment #5 from Dodji Seketeli  2012-09-28 
12:21:49 UTC ---

Author: dodji

Date: Fri Sep 28 12:21:33 2012

New Revision: 191828



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

Log:

PR c++/53551 - -Wunused-local-typedefs misses uses



We don't record the use of a typedef when it's used through a

typename.  Fixed thus.



Tested on x86_64-unknown-linux-gnu against trunk.



gcc/cp/



* decl.c (make_typename_type): Record the use of typedefs.



gcc/testsuite/



* g++.dg/warn/Wunused-local-typedefs-2.C: New test.



Added:

trunk/gcc/testsuite/g++.dg/warn/Wunused-local-typedefs-2.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/decl.c

trunk/gcc/testsuite/ChangeLog

[Bug c++/53551] -Wunused-local-typedefs misses uses

[dodji at gcc dot gnu.org]

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



Dodji Seketeli  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #6 from Dodji Seketeli  2012-09-28 
12:32:04 UTC ---

Fixed in trunk (4.8)

[Bug debug/54731] [4.8 regression] arm-elf/arm-eabisim crosses fails in make-check due to undefined LFE references: corrupt debug_line tables

[rearnsha at gcc dot gnu.org]

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



Richard Earnshaw  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-09-28

  Component|c++ |debug

Summary|arm-elf/arm-eabisim crosses |[4.8 regression]

   |fails in make-check due to  |arm-elf/arm-eabisim crosses

   |undefined LFE references|fails in make-check due to

   ||undefined LFE references:

   ||corrupt debug_line tables

 Ever Confirmed|0   |1



--- Comment #1 from Richard Earnshaw  2012-09-28 
12:49:59 UTC ---

This looks to be the debug line tables being corrupt somehow.  Objdump shows

the undef relocs to be in the .debug_line section

[Bug c++/29028] No warning about unused names introduced with using declarations

[dodji at gcc dot gnu.org]

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



--- Comment #4 from Dodji Seketeli  2012-09-28 
12:51:42 UTC ---

Author: dodji

Date: Fri Sep 28 12:51:30 2012

New Revision: 191829



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

Log:

PR c++/29028 - Missed unused warning on using declaration



In the example of the patch, g++ fails to warn that the variable N::i

(introduced via a using declaration) is unused.



This is because as we want to emit the warning in poplevel, when we

walk the local bindings returned by getdecls, we forget that a

VAR_DECL introduced by a using declaration is represented by a

TREE_LIST which TREE_VALUE is the VAR_DECL, and we wrongly look for a

bare VAR_DECL.



Fixed thus and tested on x86_64-unknown-linux-gnu against trunk.



gcc/cp/



* decl.c (poplevel): Do not forget that some local

bindings are represented by a TREE_LIST.



gcc/testsuite/



* g++.dg/warn/Wunused-var-18.C: New test.



Added:

trunk/gcc/testsuite/g++.dg/warn/Wunused-var-18.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/decl.c

trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/54735] New: [4.8 Regression] Segmentation fault in walk_aliased_vdefs_1

[markus at trippelsdorf dot de]

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



 Bug #: 54735

   Summary: [4.8 Regression] Segmentation fault in

walk_aliased_vdefs_1

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: mar...@trippelsdorf.de





The testcase from Bug 54146 segfaults on trunk (r191824):



% gdb g++

Reading symbols from /usr/bin/g++...(no debugging symbols found)...done.

(gdb) run slow.cc -c -w -O2

Starting program: /usr/bin/g++ slow.cc -frounding-math -c -w -O2

warning: no loadable sections found in added symbol-file system-supplied DSO at

0x77ffa000

process 2999 is executing new program:

/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0/g++

[New process 3002]

process 3002 is executing new program:

/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0/cc1plus



Program received signal SIGSEGV, Segmentation fault.

[Switching to process 3002]

0x008c3b58 in walk_aliased_vdefs_1(ao_ref_s*, tree_node*, bool

(*)(ao_ref_s*, tree_node*, void*), void*, bitmap_head_def**, unsigned int)

[clone .constprop.15] ()

(gdb) bt

#0  0x008c3b58 in walk_aliased_vdefs_1(ao_ref_s*, tree_node*, bool

(*)(ao_ref_s*, tree_node*, void*), void*, bitmap_head_def**, unsigned int)

[clone .constprop.15] ()

#1  0x008c459e in walk_aliased_vdefs(ao_ref_s*, tree_node*, bool

(*)(ao_ref_s*, tree_node*, void*), void*, bitmap_head_def**) ()

#2  0x008d0dee in propagate_necessity(edge_list*) () at

/home/markus/gcc/gcc/tree-ssa-dce.c:909

#3  0x008d1da2 in perform_tree_ssa_dce(bool) () at

/home/markus/gcc/gcc/tree-ssa-dce.c:1584

#4  0x007c86b2 in execute_one_pass(opt_pass*) () at

/home/markus/gcc/gcc/passes.c:2199

#5  0x007c8a15 in execute_pass_list(opt_pass*) () at

/home/markus/gcc/gcc/passes.c:2254

#6  0x007c8a27 in execute_pass_list(opt_pass*) () at

/home/markus/gcc/gcc/passes.c:2255

#7  0x0064f204 in expand_function(cgraph_node*) ()

#8  0x006506ba in compile() ()

#9  0x00650c25 in finalize_compilation_unit() ()

#10 0x005290b7 in cp_write_global_declarations() () at

/home/markus/gcc/gcc/cp/decl2.c:4024

#11 0x00858a05 in compile_file() ()

#12 0x0085a20a in toplev_main(int, char**) ()

[Bug c++/29028] No warning about unused names introduced with using declarations

[dodji at gcc dot gnu.org]

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



Dodji Seketeli  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #5 from Dodji Seketeli  2012-09-28 
13:01:56 UTC ---

Fixed in trunk (4.8)

[Bug tree-optimization/54345] jump threading leaks e->aux heap memory

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 CC||mpolacek at gcc dot gnu.org



--- Comment #5 from Marek Polacek  2012-09-28 
13:04:12 UTC ---

Sorry, I'm still not seeing the leak.  Tried testcase in PR46590 as well as in

some other memory-hog bugs, e.g. PR54489.

[Bug tree-optimization/54735] [4.8 Regression] Segmentation fault in walk_aliased_vdefs_1

[rguenth at gcc dot gnu.org]

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



Richard Guenther  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-09-28

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

   |gnu.org |

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from Richard Guenther  2012-09-28 
13:07:58 UTC ---

Mine.

[Bug lto/47799] LTO debug info for early inlined functions missing

[rguenth at gcc dot gnu.org]

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



Richard Guenther  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #4 from Richard Guenther  2012-09-28 
13:08:42 UTC ---

Mine.

[Bug fortran/54730] [4.6/4.7/4.8 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1066

[janus at gcc dot gnu.org]

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



--- Comment #5 from janus at gcc dot gnu.org 2012-09-28 13:11:16 UTC ---

Note that the error goes away when replacing the generic intrinsic REAL by a

specific one, e.g. FLOAT:



  implicit none

  intrinsic :: float

  real :: vec(1:2)

  vec = (/ float(a = 1), 1. /)

end

[Bug c++/54372] __attribute__((unused)) doesn't work with unused local typedef in template function.

[dodji at gcc dot gnu.org]

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



--- Comment #7 from Dodji Seketeli  2012-09-28 
13:32:52 UTC ---

Author: dodji

Date: Fri Sep 28 13:32:41 2012

New Revision: 191830



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

Log:

PR c++/54372 - unused attribute inactive on dependant entities



In the example of this patch, gcc/g++ invoked with

-Wunused-local-typedefs warns on dependant entities even when those

are decorated with the 'unused' attribute.



This is because in cplus_decl_attributes, save_template_attributes

makes so that the 'unused' attribute is applied to its appertaining

entity only at instantiation time.  But then at parsing time

maybe_warn_unused_local_typedefs checks for TREE_USED before warning.



This patch applies the 'unused' attribute at compilation time.



Tested on x86_64-unknown-linux-gnu against trunk.



gcc/cp/



* decl2.c (is_late_template_attribute): "unused" attribute is to

be applied at compile time.



gcc/testsuite/



* c-c++-common/Wunused-local-typedefs-2.c: New test.



Added:

trunk/gcc/testsuite/c-c++-common/Wunused-local-typedefs-2.c

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/decl2.c

trunk/gcc/testsuite/ChangeLog

[Bug c++/54372] __attribute__((unused)) doesn't work with unused local typedef in template function.

[dodji at gcc dot gnu.org]

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



Dodji Seketeli  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #8 from Dodji Seketeli  2012-09-28 
13:35:49 UTC ---

Fixed in trunk (4.8)

[Bug fortran/54725] cross gfortran always searches host paths (e.g. /usr/include)

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #4 from Tobias Burnus  2012-09-28 
14:16:37 UTC ---

Untested draft patch. As I don't build cross compilers, I would be happy if

someone could confirm that it works.



--- a/gcc/fortran/cpp.c

+++ b/gcc/fortran/cpp.c

@@ -269,3 +269,3 @@ gfc_cpp_init_options (unsigned int decoded_options_count,

   gfc_cpp_option.prefix = NULL;

-  gfc_cpp_option.sysroot = NULL;

+  gfc_cpp_option.sysroot = TARGET_SYSTEM_ROOT;

[Bug fortran/54725] cross gfortran always searches host paths (e.g. /usr/include)

[burnus at gcc dot gnu.org]

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



--- Comment #5 from Tobias Burnus  2012-09-28 
14:30:09 UTC ---

I forgot half of the patch - the second half is needed when no system root

exists. The patch is still untested.



--- a/gcc/fortran/cpp.c

+++ b/gcc/fortran/cpp.c

@@ -40,2 +40,6 @@ along with GCC; see the file COPYING3.  If not see



+#ifndef TARGET_SYSTEM_ROOT

+# define TARGET_SYSTEM_ROOT NULL

+#endif

+

 #ifndef TARGET_CPU_CPP_BUILTINS

@@ -269,3 +273,3 @@ gfc_cpp_init_options (unsigned int decoded_options_count,

   gfc_cpp_option.prefix = NULL;

-  gfc_cpp_option.sysroot = NULL;

+  gfc_cpp_option.sysroot = TARGET_SYSTEM_ROOT;

[Bug libstdc++/54448] many failures with /sbin/loader: Error: libstdc++.so.6: symbol "__pthread_mutex_init" unresolved

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC||jwakely.gcc at gmail dot

   ||com



--- Comment #3 from Paolo Carlini  2012-09-28 
15:00:04 UTC ---

Jon, can you have a look to this one? Thanks in advance..

[Bug libstdc++/54448] many failures with /sbin/loader: Error: libstdc++.so.6: symbol "__pthread_mutex_init" unresolved

[redi at gcc dot gnu.org]

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



--- Comment #4 from Jonathan Wakely  2012-09-28 
15:40:37 UTC ---

How is GCC configured?

[Bug c++/54401] Missing diagnostics about type-alias at class scope

[dodji at seketeli dot org]

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



--- Comment #1 from dodji at seketeli dot org  
2012-09-28 15:43:34 UTC ---

A candidate patch was sent to

http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01906.html

[Bug libstdc++/54448] many failures with /sbin/loader: Error: libstdc++.so.6: symbol "__pthread_mutex_init" unresolved

[htl10 at users dot sourceforge.net]

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



--- Comment #5 from Hin-Tak Leung  
2012-09-28 15:51:37 UTC ---

(In reply to comment #4)

> How is GCC configured?



Just "/where/source/is/configure" with no options. You can see it at the bottom

of :

http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg02452.html for 4.5.0

http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg02457.html for 4.5.1



all built with 4.3.3. 



(sorry the one for 4.5.0 has an extra --enable-obsolete - I must have copied it

blindly because 4.7.x for Tru64 needed it. But you can see the others on sept

25 

http://gcc.gnu.org/ml/gcc-testresults/2012-09/

- there are 20+ of them for various versions, and the 4.5.x and 4.6.x should be

without that).

[Bug libfortran/54736] New: GFORTRAN_CONVERT_UNIT causes malloc error on several platforms

[shart6 at utk dot edu]

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



 Bug #: 54736

   Summary: GFORTRAN_CONVERT_UNIT causes malloc error on several

platforms

Classification: Unclassified

   Product: gcc

   Version: 4.7.1

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: libfortran

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

ReportedBy: sha...@utk.edu





I have a code that has multiple large data files that are written in big 

endian format.  To deal with this on many platforms, a script was written 

that, among various other things, sets a few units to read as big endian 

by using GFORTRAN_CONVERT_UNIT='native;big_endian:60-70,80-89'.  However, 

when the Fortran program is called from the script I get:



scale: malloc.c:2368: sysmalloc: Assertion `(old_top == (((mbinptr) 

(((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct 

malloc_chunk, fd && old_size == 0) || 

((unsigned long) (old_size) >= (unsigned long)__builtin_offsetof 

(struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 

* (sizeof(size_t))) - 1))) && ((old_to

p)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.



This reliably happens on any Linux platform I've tested it on *except* 

Fedora/RHEL.



I've been able to reliably reproduce the problem on several 32-bit 

machines (Arch Linux (GCC 4.7.1), OpenSUSE 12.2, Ubuntu 12.10 Beta 1) by 

creating and running these two programs:



Write program:



[shane@shane-laptop ~/temp/testgfortran]$ cat test_write.f90

program test_write

implicit none



integer, parameter :: NUM = 10

integer :: i



open(unit=88,form='unformatted',convert='big_endian')

do i = 1,NUM

  write (88) i

end do



close(88)



end program test_write



Read Program:



[shane@shane-laptop ~/temp/testgfortran]$ cat test_read.f90

program test_write

implicit none



integer, parameter :: NUM = 10

integer :: readInt

integer :: i



open(unit=88,form='unformatted')

do i = 1,NUM

  read (88) readInt

  write (*,*) readInt

end do



close(88)



end program test_write



And testing:



[shane@shane-laptop ~/temp/testgfortran]$ ./test_write

[shane@shane-laptop ~/temp/testgfortran]$ ./test_read

16777216

At line 10 of file test_read.f90 (unit = 88, file = 'fort.88')

Fortran runtime error: End of file

[shane@shane-laptop ~/temp/testgfortran]$ 

GFORTRAN_CONVERT_UNIT='native;big_endian:88' ./test_read

test_read: malloc.c:2368: sysmalloc: Assertion `(old_top == (((mbinptr) 

(((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct 

malloc_chunk, fd && old_size == 0) || ((unsigned long) (old_size) >= 

(unsigned long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))

+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && 

((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' 

failed.

Aborted

[shane@shane-laptop ~/temp/testgfortran]$ 

GFORTRAN_CONVERT_UNIT='big_endian' ./test_read

   1

   2

   3

   4

   5

   6

   7

   8

   9

  10





Obviously the first invocation of test_read fails because the endianess 

is wrong, but the second one should work.  Running gdb yields:



Program received signal SIGABRT, Aborted.

0xb7fdd424 in __kernel_vsyscall ()



However, the above test program does work on all of the 64-bit machines 

I've tested.



I found that by commenting out the lines 582-583 in libgfortran/runtime/

environ.c I can get it to work.



I don't really know why it's accessing an element in the elist structure 

that hasn't been allocated yet.  This loop doesn't seem to do anything to 

me.  Since I don't know the reprocussions of just commenting out stuff 

willy nilly I'll leave the implementation details to someone with more 

knowledge, but this seems like a good place to start.

[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms

[tkoenig at gcc dot gnu.org]

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



Thomas Koenig  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-09-28

 CC||tkoenig at gcc dot gnu.org

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

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #1 from Thomas Koenig  2012-09-28 
18:38:13 UTC ---

Mine.

gcc-4.7.2 bug in Makefile.in and configure.ac

[Ernesto Fontenla]

Hello:

Building gcc-4.7.2 on Darwin 9.8.0 i386 with the options

Macintosh-85:gcc-build regular$ /usr/local/gcc-4.7.2/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-4.7.2/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.7.2/libexec/gcc/i386-apple-darwin9.8.0/4.7.2/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../gcc-4.7.2/configure --prefix=/usr/local/gcc-4.7.2 
--enable-languages=c,c++

Thread model: posix
gcc version 4.7.2 (GCC)

AND including mpc-1.0, gmp-5.0.5, mpfr-3.1.1 in the subdirectories mpc, 
gmp, mpfr, respectively, of the gcc source tree leads to the following 
error when the build reaches the mpc library:


checking for __gmpz_init in -lgmp... yes
checking for MPFR... no
configure: error: libmpfr not found or uses a different ABI (including 
static vs shared).

make[2]: *** [configure-stage1-mpc] Error 1
make[1]: *** [stage1-bubble] Error 2
make: *** [bootstrap] Error 2

The error is caused by the fact that the configure and Makefile don't 
properly point to the mpfr/src/.libs and mpfr/src directories for 
linking and includes (ditto mpc/src/.libs and mpc/src/).  The following 
changes fix the problem, permitting the compilation to correctly go 
through to completion (all three stages, and install):


Macintosh-85:gcc-4.7.2 regular$ diff Makefile.def.org Makefile.def
58c58
< host_modules= { module= mpfr; lib_path=.libs; bootstrap=true;
---
> host_modules= { module= mpfr; lib_path=src/.libs; bootstrap=true;
61c61
< host_modules= { module= mpc; lib_path=.libs; bootstrap=true;
---
> host_modules= { module= mpc; lib_path=src/.libs; bootstrap=true;
Macintosh-85:gcc-4.7.2 regular$ diff Makefile.in.org Makefile.in
653c653
< $$r/$(HOST_SUBDIR)/mpfr/.libs:$$r/$(HOST_SUBDIR)/prev-mpfr/.libs:
---
> $$r/$(HOST_SUBDIR)/mpfr/src/.libs:$$r/$(HOST_SUBDIR)/prev-mpfr/src/.libs:
658c658
< $$r/$(HOST_SUBDIR)/mpc/.libs:$$r/$(HOST_SUBDIR)/prev-mpc/.libs:
---
> $$r/$(HOST_SUBDIR)/mpc/src/.libs:$$r/$(HOST_SUBDIR)/prev-mpc/src/.libs:
Macintosh-85:gcc-4.7.2 regular$ diff configure.ac.org configure.ac
1251c1251
<   gmpinc='-I$$s/mpc/src '"$gmpinc"
---
>   gmpinc='-I$$r/$(HOST_SUBDIR)/mpc/src -I$$s/mpc/src '"$gmpinc"
1289,1291c1289,1291
<   gmplibs='-L$$r/$(HOST_SUBDIR)/mpfr/'"$lt_cv_objdir $gmplibs"
<   gmpinc='-I$$r/$(HOST_SUBDIR)/mpfr -I$$s/mpfr '"$gmpinc"
<   extra_mpc_mpfr_configure_flags='--with-mpfr-include=$$s/mpfr 
--with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/'"$lt_cv_objdir"

---
>   gmplibs='-L$$r/$(HOST_SUBDIR)/mpfr/src/'"$lt_cv_objdir $gmplibs"
>   gmpinc='-I$$r/$(HOST_SUBDIR)/mpfr/src -I$$s/mpfr/src '"$gmpinc"
> extra_mpc_mpfr_configure_flags='--with-mpfr-include=$$s/mpfr/src 
--with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/src/'"$lt_cv_objdir"

Macintosh-85:gcc-4.7.2 regular$ diff configure.org configure
5153c5153
<   gmpinc='-I$$s/mpc/src '"$gmpinc"
---
>   gmpinc='-I$$r/$(HOST_SUBDIR)/mpc/src -I$$s/mpc/src '"$gmpinc"
5201,5203c5201,5203
<   gmplibs='-L$$r/$(HOST_SUBDIR)/mpfr/'"$lt_cv_objdir $gmplibs"
<   gmpinc='-I$$r/$(HOST_SUBDIR)/mpfr -I$$s/mpfr '"$gmpinc"
<   extra_mpc_mpfr_configure_flags='--with-mpfr-include=$$s/mpfr 
--with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/'"$lt_cv_objdir"

---
>   gmplibs='-L$$r/$(HOST_SUBDIR)/mpfr/src/'"$lt_cv_objdir $gmplibs"
>   gmpinc='-I$$r/$(HOST_SUBDIR)/mpfr/src -I$$s/mpfr/src '"$gmpinc"
> extra_mpc_mpfr_configure_flags='--with-mpfr-include=$$s/mpfr/src 
--with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/src/'"$lt_cv_objdir"

Macintosh-85:gcc-4.7.2 regular$


Regards,
-ernesto

[Bug tree-optimization/54735] [4.8 Regression] Segmentation fault in walk_aliased_vdefs_1

[markus at trippelsdorf dot de]

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



Markus Trippelsdorf  changed:



   What|Removed |Added



 CC||dehao at gcc dot gnu.org,

   ||markus at trippelsdorf dot

   ||de



--- Comment #2 from Markus Trippelsdorf  
2012-09-28 19:29:48 UTC ---

Started with r191747:



commit bda16c7ca0bc1ec56857241a7313068f4824950f

Author: dehao 

Date:   Tue Sep 25 21:32:29 2012 +



libcpp:

2012-09-25  Dehao Chen  



PR middle-end/54704

* line-map.c (location_adhoc_data_hash): Fix the hash function.



Memory usage almost triples from 1GB to 3GB with this revisions

(after running for 2 minutes (then moment of the crash) on my CPU).

Re: gcc-4.7.2 bug in Makefile.in and configure.ac

[Jonathan Wakely]

Re: http://gcc.gnu.org/ml/gcc-bugs/2012-09/msg02363.html

Hi,

the gcc-bugs list is for automated mails from the GCC Bugzilla
database.  Please use Bugzilla to report bugs, rather than mailing the
list directly, this ensures the mail will be read and the issue can be
tracked correctly.

The issue you report is already known, you can see it at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50461 -- to build released
versions of GCC without changing the sources you need to use an older
version of MPFR.

[Bug bootstrap/54688] [4.8 regression] violation of implicit restriction "No_Elaboration_Code" on a-ioexce.ads

[bernds at gcc dot gnu.org]

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



--- Comment #14 from Bernd Schmidt  2012-09-28 
20:33:00 UTC ---

Author: bernds

Date: Fri Sep 28 20:32:55 2012

New Revision: 191838



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

Log:

PR bootstrap/54688

* sched-deps.c (parse_add_or_inc): Remove MINUS handling.  Take

STACK_GROWS_DOWNWARD into account.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/sched-deps.c

[Bug lto/54737] New: ICE on PA-RISC with LTO and -ftrapv

[mikulas at artax dot karlin.mff.cuni.cz]

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



 Bug #: 54737

   Summary: ICE on PA-RISC with LTO and -ftrapv

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: lto

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

ReportedBy: miku...@artax.karlin.mff.cuni.cz

  Host: hppa-linux-gnu

Target: hppa-linux-gnu

 Build: hppa-linux-gnu





Created attachment 28296

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

preprocessed files to reproduce the bug



When using flags "-ftrapv -flto -fwhole-program -O2" on PA-RISC, gcc fails

with an internal error:



In file included from ../links-current/url.c:574:0,

 from ../links-current/url.c:539,

 from :121:

../links-current/html_tbl.c: In function 'display_table_frames':

../links-current/html_tbl.c:1304:1: internal compiler error: in hoist_code, at

gcse.c:3119

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

lto-wrapper: gcc returned 1 exit status

collect2: error: lto-wrapper returned 1 exit status

make: *** [links] Error 1



I'm attaching preprocessed files to reproduce the bug --- extract the archive

parisc-flto-trapv-crash.tar.xz on Linux PA-RISC and run make to get the crash.



gcc-4.6.3 has this bug too.

[Bug bootstrap/54688] [4.8 regression] violation of implicit restriction "No_Elaboration_Code" on a-ioexce.ads

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #15 from Eric Botcazou  2012-09-28 
20:46:36 UTC ---

.

[Bug tree-optimization/54735] [4.8 Regression] Segmentation fault in walk_aliased_vdefs_1

[dehao at google dot com]

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



Dehao Chen  changed:



   What|Removed |Added



 CC||dehao at google dot com



--- Comment #3 from Dehao Chen  2012-09-28 20:51:07 
UTC ---

r191747 should not increase the memory consumption. Instead, it'll only speedup

compilation.



I tried to compile the testcase without the patch, the memory consumption still

increase, but very slowly (it took around 30 minutes to climb up to 1.8G)

[Bug tree-optimization/54735] [4.8 Regression] Segmentation fault in walk_aliased_vdefs_1

[markus at trippelsdorf dot de]

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



--- Comment #4 from Markus Trippelsdorf  
2012-09-28 20:55:22 UTC ---

(In reply to comment #3)

> r191747 should not increase the memory consumption. Instead, it'll only 
> speedup

> compilation.

> 

> I tried to compile the testcase without the patch, the memory consumption 
> still

> increase, but very slowly (it took around 30 minutes to climb up to 1.8G)



Yes, please ignore my bogus bisection. Sorry.



I will let the testcase run overnight with r191747 reverted and 

I guess it will also crash after a few hours.

[Bug c++/54738] New: [C++11][SFINAE] Hard errors for pointer-to-member function expressions

[daniel.kruegler at googlemail dot com]

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



 Bug #: 54738

   Summary: [C++11][SFINAE] Hard errors for pointer-to-member

function expressions

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: daniel.krueg...@googlemail.com





During my attempts to implement sfinae-friendly result_of I found the following

problems using gcc 4.8.0 20120923 (experimental) with compile-flags



-Wall -pedantic -std=c++0x



with pointer-to-member function expressions. 



First there are problems if we have an incompatible number of function call

arguments:



//---

template

T&& declval();



template

decltype(((*declval()).*declval())(declval()...))

test1(int);



template

void test1(...);



template

decltype((declval().*declval())(declval()...))

test2(int);



template

void test2(...);



struct S {};



typedef void (S::*Func)(int) const;



typedef decltype(test1(0)) type1a;  // #22

typedef decltype(test1(0)) type1b;

typedef decltype(test1(0)) type1c;

typedef decltype(test1(0)) type1d;



typedef decltype(test2(0)) type2a; // #27

typedef decltype(test2(0)) type2b;

typedef decltype(test2(0)) type2c;

typedef decltype(test2(0)) type2d;

//---



The error messages are:





22|  required from here|

6|error: too few arguments to function|

22|  required from here|

6|error: too few arguments to function|

23|  required from here|

6|error: too few arguments to function|

23|  required from here|

6|error: too few arguments to function|

24|  required from here|

6|error: too many arguments to function|

25|  required from here|

6|error: too many arguments to function|

27|  required from here|

13|error: too few arguments to function|

27|  required from here|

13|error: too few arguments to function|

28|  required from here|

13|error: too few arguments to function|

28|  required from here|

13|error: too few arguments to function|

29|  required from here|

13|error: too many arguments to function|

30|  required from here|

13|error: too many arguments to function|





Further there are also problems with corresponding function call expressions

where the arguments won't convert:



//---

template

T&& declval();



template

decltype(((*declval()).*declval())(declval()...))

test1(int);



template

void test1(...);



template

decltype((declval().*declval())(declval()...))

test2(int);



template

void test2(...);



struct S {};



typedef void (S::*Func)(int) const;



typedef decltype(test1(0)) type3a; // #22

typedef decltype(test1(0)) type3b;



typedef decltype(test2(0)) type4a; // #25

typedef decltype(test2(0)) type4b;

//---



The error messages are:





22|  required from here|

6|error: cannot convert 'S' to 'int' in argument passing|

22|  required from here|

6|error: cannot convert 'S' to 'int' in argument passing|

23|  required from here|

6|error: cannot convert 'S' to 'int' in argument passing|

23|  required from here|

6|error: cannot convert 'S' to 'int' in argument passing|

25|  required from here|

13|error: cannot convert 'S' to 'int' in argument passing|

25|  required from here|

13|error: cannot convert 'S' to 'int' in argument passing|

26|  required from here|

13|error: cannot convert 'S' to 'int' in argument passing|

26|  required from here|

13|error: cannot convert 'S' to 'int' in argument passing|





Further cv-violations aren't sfinaed away:



//---

template

T&& declval();



template

decltype(((*declval()).*declval())(declval()...))

test1(int);



template

void test1(...);



template

decltype((declval().*declval())(declval()...))

test2(int);



template

void test2(...);



struct S {};



typedef void (S::*Func2)(int);



typedef decltype(test1(0)) type5a; // #22

typedef decltype(test1(0)) type5b;



typedef decltype(test2(0)) type6a; // #25

typedef decltype(test2(0)) type6b;

//---



The error messages are:





22|  required from here|

6|error: invalid conversion from 'const S*' to 'S*' [-fpermissive]|

23|  required from here|

6|error: invalid conversion from 'const S*' to 'S*' [-fpermissive]|

25|  required from here|

13|error: invalid conversion from 'const S*' to 'S*' [-fpermissive]|

26|  required from here|

13|error: invalid conversion from 'const S*' to 'S*' [-fpermissive]|





These code examples should all be accepted.

[Bug c++/54738] [C++11][SFINAE] Hard errors for pointer-to-member function expressions

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-09-28

 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot

   |gnu.org |com

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from Paolo Carlini  2012-09-28 
23:12:08 UTC ---

Ok, I have a simple patch fixing all of them.

[Bug fortran/54725] cross gfortran always searches host paths (e.g. /usr/include)

[vapier at gentoo dot org]

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



--- Comment #6 from Mike Frysinger  2012-09-28 
23:12:08 UTC ---

(In reply to comment #5)



that's half the equation.  the other half is the build system support.



in gcc/Makefile.in, they do:

  CFLAGS-c-family/c-opts.o += @TARGET_SYSTEM_ROOT_DEFINE@



but you can't do that in gcc/fortran/Make-lang.in.  you can't use

$(TARGET_SYSTEM_ROOT_DEFINE) either because the variable is only AC_SUBST().



so you could add this line to gcc/Makefile.in:

  CFLAGS-fortran/cpp.o += @TARGET_SYSTEM_ROOT_DEFINE@

and it'd work.  this seems to be how they propagate the define into the

CFLAGS-c-family/c-opts.o variable, so maybe this is OK.



alternatively, gcc/Makefile.in does setup $(COMPILER_DEFINES), so adding this

to gcc/fortran/Make-lang.in works:

  CFLAGS-fortran/cpp.o += $(DRIVER_DEFINES)

but i'm sure that's the wrong answer.



the other alternative is to declare a "static const char *sysroot" inside of

gcc/fortran/gfortranspec.c and then initialize gfc_cpp_option.sysroot via that.

 this works because gfortranspec.c is compiled already with

$(COMPILER_DEFINES).



i'm wait out of my depth, so i don't know what the "right" answer is :).

[Bug c++/54738] [C++11][SFINAE] Hard errors for pointer-to-member function expressions

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

[Bug fortran/54724] libgfortran does not respect --disable-werror

[vapier at gentoo dot org]

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



--- Comment #2 from Mike Frysinger  2012-09-28 
23:20:09 UTC ---

i'm 50/50 on this.  if the code doesn't utilize anything beyond the local code

base, and isn't compiled/processed by anything other than the local compiler,

then the -Werror shouldn't be a problem.  but i noticed -Werror was being used

because some flags *were* causing warnings and so the build errored out (bug

54725).  granted, this warning was valid and it's good that it broke (otherwise

i might not have noticed as soon as i did), but in general, it's indeterminate

warnings like that why distros want to turn off -Werror in their builds.

[Bug rtl-optimization/54739] New: [4.8 regression] FAIL: gcc.dg/lower-subreg-1.c scan-rtl-dump subreg1 "Splitting reg"

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

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



 Bug #: 54739

   Summary: [4.8 regression] FAIL: gcc.dg/lower-subreg-1.c

scan-rtl-dump subreg1 "Splitting reg"

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: rtl-optimization

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

ReportedBy: sch...@linux-m68k.org

CC: uweig...@gcc.gnu.org

Target: m68k-*-*





gcc.dg/lower-subreg-1.c fails on m68k since r191805.

[Bug c++/54740] New: Empty base optimization gets confused when a member variable derives from the same empty base.

[avenikov at google dot com]

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



 Bug #: 54740

   Summary: Empty base optimization gets confused when a member

variable derives from the same empty base.

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: c++

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

ReportedBy: aveni...@google.com





struct empty_base {};

struct another_empty_base {};



struct inner : empty_base {};

struct outer : empty_base {

inner i_;

};





int main(int, char **)

{

return sizeof(outer);

}



This returns 2;

If you change outer to derive from another_empty_base, it returns 1 (which is

correct). Whatever the correct result should be, they at least should be the

same.



I tried it on 4.7.2 and on 4.4.3 - same problem is present.

The optimization flags don't seem to make any difference.



Setting it to major, as this seems like a very common idiom and people expect

empty base optimization to kick in in such cases.





Andy.



P.S. Just in case: partial output from my gcc -v:

Using built-in specs.

COLLECT_GCC=/<...>/stage-4.7.2/bin/gcc

COLLECT_LTO_WRAPPER=/<...>/stage-4.7.2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: ../gcc-4.7.2/configure --prefix=/<...>/stage-4.7.2

--with-gmp=/<...>/gmp-4.3.2/ --with-mpfr=/<...>/mpfr-3.0.0/

--with-mpc=/<...>/mpc-0.9/ --enable-languages=c,c++

Thread model: posix

gcc version 4.7.2 (GCC) 



It's a ubuntu-based system.

[Bug c++/54740] Empty base optimization gets confused when a member variable derives from the same empty base.

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID

   Severity|major   |normal



--- Comment #1 from Jonathan Wakely  2012-09-28 
23:58:34 UTC ---

(In reply to comment #0)

> If you change outer to derive from another_empty_base, it returns 1 (which is

> correct). Whatever the correct result should be, they at least should be the

> same.



No they shouldn't. The standard requires this to pass:



  outer o;

  assert( static_cast(&o) != &o.i_ );



[intro.object]/6 requires two separate objects of the same type to have

distinct addresses.

[Bug c++/54740] Empty base optimization gets confused when a member variable derives from the same empty base.

[redi at gcc dot gnu.org]

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



--- Comment #2 from Jonathan Wakely  2012-09-29 
00:01:31 UTC ---

(In reply to comment #1)

> No they shouldn't. The standard requires this to pass:

> 

>   outer o;

>   assert( static_cast(&o) != &o.i_ );



Oops, that should be:



   assert( static_cast(&o) != &o.i_ );

[Bug c++/54740] Empty base optimization gets confused when a member variable derives from the same empty base.

[avenikov at google dot com]

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



--- Comment #3 from Andy Venikov  2012-09-29 
00:09:55 UTC ---

(In reply to comment #2)

> (In reply to comment #1)

> > No they shouldn't. The standard requires this to pass:

> > 

> >   outer o;

> >   assert( static_cast(&o) != &o.i_ );

> 

> Oops, that should be:

> 

>assert( static_cast(&o) != &o.i_ );



I see.

I was aware of the rule you mentioned, but it was hard to see how it could

apply here.

Sorry for the noise then.

[Bug c++/54741] New: GCC 4.4, 4.5, 4.6 4.7 (probably 4.8) Generates un-usable code on AVX supported CPUs (FreeBSD)

[ace.of.zerosync at gmail dot com]

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



 Bug #: 54741

   Summary: GCC 4.4, 4.5, 4.6 4.7 (probably 4.8) Generates

un-usable code on AVX supported CPUs (FreeBSD)

Classification: Unclassified

   Product: gcc

   Version: 4.6.4

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: c++

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

ReportedBy: ace.of.zeros...@gmail.com





Created attachment 28297

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

both test.ii and test.s files from save-temp output



It's been quite a while that this bug is around with GCC 4.4+ on FreeBSD

systems (at least 8.2-Release and 9.0-Release which tested by me). If you have

a sandy-bridge or ivy-bridge cpu a code like this get killed by SIGILL when

compiled using -march=native:



#include 

#include 

#include 



int main() {

std::unordered_map hash; 

std::cout << "Hello, World!" << std::endl;

return 0;

}



# g++46 -std=c++0x -o test test.cpp

# ./test 

Hello, World!



# g++46 -std=c++0x -march=native -o test test.cpp

# ./test

Illegal instruction: 4



This is gdbs output:

Program received signal SIGILL, Illegal instruction.

0x004011dc in std::_Hashtable, std::allocator >,

std::_Select1st >,

std::equal_to, std::hash,

std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,

std::__detail::_Prime_rehash_policy, false, false, true>::_Hashtable ()



I know the code above is using C++11 standard headers, but this bug is not a

C++11 related bug, the code above is just a known example to me. If you look at

this thread (which was opened by me nearly 1.5 years ago) on FreeBSD forums

http://forums.freebsd.org/showthread.php?t=23535 you'll see even C code (GCC

itself and nearly anything compiled by -march=native on my system) affected by

this bug.





# g++46 -v -save-temps -std=c++0x -march=native -o test test.cpp

Using built-in specs.

COLLECT_GCC=g++46

COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.4/lto-wrapper

Target: x86_64-portbld-freebsd9.0

Configured with: ./../gcc-4.6-20120831/configure --disable-nls

--enable-languages=c,c++,objc,fortran --libdir=/usr/local/lib/gcc46

--libexecdir=/usr/local/libexec/gcc46 --program-suffix=46

--with-as=/usr/local/bin/as --with-gmp=/usr/local

--with-gxx-include-dir=/usr/local/lib/gcc46/include/c++/

--with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local

--with-pkgversion='FreeBSD Ports Collection' --with-system-zlib

--disable-libgcj --prefix=/usr/local --mandir=/usr/local/man

--infodir=/usr/local/info/gcc46 --build=x86_64-portbld-freebsd9.0

Thread model: posix

gcc version 4.6.4 20120831 (prerelease) (FreeBSD Ports Collection) 

COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-march=native' '-o' 'test'

'-shared-libgcc'

 /usr/local/libexec/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.4/cc1plus -E -quiet

-v test.cpp -march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt

-mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mavx -msse4.2

-msse4.1 -mno-rdrnd -mno-f16c -mno-fsgsbase --param l1-cache-size=32 --param

l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=corei7-avx -std=c++0x

-fpch-preprocess -o test.ii

ignoring nonexistent directory

"/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.4/../../../../../x86_64-portbld-freebsd9.0/include"

#include "..." search starts here:

#include <...> search starts here:

 /usr/local/lib/gcc46/include/c++/

 /usr/local/lib/gcc46/include/c++//x86_64-portbld-freebsd9.0

 /usr/local/lib/gcc46/include/c++//backward

 /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.4/include

 /usr/local/include

 /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.4/include-fixed

 /usr/include

End of search list.

COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-march=native' '-o' 'test'

'-shared-libgcc'

 /usr/local/libexec/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.4/cc1plus

-fpreprocessed test.ii -march=corei7-avx -mcx16 -msahf -mno-movbe -maes

-mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi

-mno-tbm -mavx -msse4.2 -msse4.1 -mno-rdrnd -mno-f16c -mno-fsgsbase --param

l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144

-mtune=corei7-avx -quiet -dumpbase test.cpp -auxbase test -std=c++0x -version

-o test.s

GNU C++ (FreeBSD Ports Collection) version 4.6.4 20120831 (prerelease)

(x86_64-portbld-freebsd9.0)

compiled by GNU C version 4.6.4 20120831 (prerelease), GMP version 5.0.5,

MPFR version 3.1.1, MPC version 0.9

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

GNU C++ (FreeBSD Ports Collection) version 4.6.4 20120831 (prerelease)

(x86_64-portbld-freebsd9.0)

compiled by GNU C version 4.6.4 20120831 (prerelease), GMP version 5.0.5,

MPFR version 3.1.1, MPC version 0.9

GGC heuristics: 

[Bug c++/54741] GCC 4.4, 4.5, 4.6 4.7 (probably 4.8) Generates un-usable code on AVX supported CPUs (FreeBSD)

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2012-09-29

 Ever Confirmed|0   |1



--- Comment #1 from Andrew Pinski  2012-09-29 
01:07:54 UTC ---

What is the instruction it is causing an illegal instruction signal?

Run the resulting program using gdb to find out.

[Bug tree-optimization/54742] New: Switch elimination in FSM loop

[joey.ye at arm dot com]

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



 Bug #: 54742

   Summary: Switch elimination in FSM loop

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: joey...@arm.com





Following interesting case is reduced from a benchmark. It implements a FSM

with a loop and switch. There is opportunity to eliminate the switch since all

state transition is definite in compile time.





Source program:

---

int sum0, sum1, sum2, sum3;

int foo(const char * str)

{

int state=0;

const char *s=str;



for (; *s; s++)

{

char c=*s;

switch (state) {

case 0:

if (c == '+') state = 1;

else if (c != '-') sum0+=c;

break;

case 1:

if (c == '+') state = 2;

else if (c == '-') state = 0;

else sum1+=c;

break;

case 2:

if (c == '+') state = 3;

else if (c == '-') state = 1;

else sum2+=c;

break;

case 3:

if (c == '-') state = 2;

else if (c != '+') sum3+=c;

break;

default:

break;

}

}

return state;

}

---

Say, instead of setting state=1 and loop back to switch head, it can be

optimized to setting state=1, check loop end condition and jump directly to the

label of case_1. Thus the overhead of switch (either if-then-else or jump

table) is eliminated. On machine without sophisticate branch prediction, such

an optimization is even more appealing.



GCC trunk 4.8 doesn't have such a optimization.



Expected tree output in source form:

---

int sum0, sum1, sum2, sum3;

int foo(const char * str)

{

int state=0;

const char *s=str;

char c=*s;

if (!c) goto end;

state_0:

if (c == '+') {

state = 1;

if ((c=* (++s))!=0) goto state_1;   // Check loop end condition and go

directly to next state

else goto end;

}

else if (c != '-') sum0+=c;

if ((c=* (++s))!=0) goto state_0;

goto end;



state_1:

if (c == '+') {

state = 2;

if ((c=* (++s))!=0) goto state_2;

else goto end;

}

else if (c == '-') {

state = 0;

if ((c=* (++s))!=0) goto state_0;

else goto end;

}

else sum1+=c;

if ((c=* (++s))!=0) goto state_1;

goto end;



state_2:

if (c == '+') {

state = 3;

if ((c=* (++s))!=0) goto state_3;

else goto end;

}

else if (c == '-') {

state = 1;

if ((c=* (++s))!=0) goto state_1;

else goto end;

}

else sum1+=c;

if ((c=* (++s))!=0) goto state_2;

goto end;



state_3:

if (c == '-') {

state = 2;

if ((c=* (++s))!=0) goto state_2;

else goto end;

}

else if (c != '+') sum3+=c;

if ((c=* (++s))!=0) goto state_3;

end:

return state;

}

---

[Bug tree-optimization/54742] Switch elimination in FSM loop

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



   Keywords||missed-optimization



--- Comment #1 from Andrew Pinski  2012-09-29 
03:20:57 UTC ---

This is coremarks.

[Bug debug/54731] [4.8 regression] arm-elf/arm-eabisim crosses fails in make-check due to undefined LFE references: corrupt debug_line tables

[bkoz at gcc dot gnu.org]

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



--- Comment #2 from Benjamin Kosnik  2012-09-29 
03:59:12 UTC ---

Confirmed, -g0 and the problem is not present, -g1 and yes.

[Bug c++/54741] GCC 4.4, 4.5, 4.6 4.7 (probably 4.8) Generates un-usable code on AVX supported CPUs (FreeBSD)

[ace.of.zerosync at gmail dot com]

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



--- Comment #2 from M.S. Babaei  2012-09-29 
05:43:13 UTC ---

(In reply to comment #1)

> What is the instruction it is causing an illegal instruction signal?

> Run the resulting program using gdb to find out.



As I mentiond above running the program inside gdb produces these:



Program received signal SIGILL, Illegal instruction.

0x004011dc in std::_Hashtable, std::allocator >,

std::_Select1st >,

std::equal_to, std::hash,

std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,

std::__detail::_Prime_rehash_policy, false, false, true>::_Hashtable ()

[Bug c/54743] New: Large loop runs endingless

[slbyan at gmail dot com]

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



 Bug #: 54743

   Summary: Large loop runs endingless

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

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

ReportedBy: slb...@gmail.com





When the loops is 10, the -O3 or -O2 -funroll-loops make the code runs

fast enough(~17sec, on Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz), and when

double the loops (20), the time doubles as expected. However, when

loops is 30, the code runs hours without ending.

The code is:



#include 

static long double vec_a[16] ={

1.0,2.0,3.0,4.0,

11.0,22.0,33.0,44.0,

111.0,222.0,333.0,444.0,

.0,.0,.0,.0};

static long double vec_b[16] ={

1.0,2.0,3.0,4.0,

11.0,22.0,33.0,44.0,

111.0,222.0,333.0,444.0,

.0,.0,.0,.0};

static long MAX = 30L;

int main(int argc, char** argv) {

long double c = 0.0f;

for (int i=0; i < MAX; ++i)

for (int j=0; j<16;++j)

c += vec_a[j]* vec_a[j];

printf("%llf\n",c);

return 0;

}