[Bug libstdc++/41351] std::rotate on RAI does not conform to ISO complexity requirement

[potswa at mac dot com]

--- Comment #32 from potswa at mac dot com  2009-10-10 01:15 ---
I have little experience in this field, so you would probably be a better judge
of the best alternative to complete revision. My suggested code is a complete
rewrite, based on creating a new algorithm from first principles. There's no
going halfway… there's the version I posted, without special cases for
left/right by one, but that's not so much safer as merely inferior.

Now that I've reread the forward iterator version and realized that it's the
same as my algorithm, less my right-rotating case, countdown-style loops, and
std::copy calls, I can see that its performance is nearly as good. If you like,
you can benchmark it against the bidirectional and RAI cases.

If you like the gain from simply deleting the bidirectional and RAI functions,
you might check in that change. It is ironic that the highest performing (at
least for large n) algorithm is the one which never gets used (as forward
iterators are nonexistent among the STL classes).

As currently written, the RAI algorithm accesses memory in long strides which
are likely to thrash the cache and cause the worst possible memory bottleneck
for large and coprime k. The bidirectional algorithm accesses memory in linear
fashion, but reads and writes each location twice and furthermore performs up
to twice as many swaps as necessary.

The forward iterator algorithm touches memory locations mostly only once and
always sequentially, locations which are touched repeatedly are spatially local
and hence cached, and it always performs the minimum number of swaps. Of the
current code, it gets the most fundamentals correct.

My impression is that any new code is inherently "untrustworthy." I haven't
benchmarked this suggestion, but I'm not really keen to check it in myself ;v)
. Feel free if you guys like…


-- 


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

[Bug fortran/40993] Empty error message with long lines

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2009-10-10 00:42 
---
The problem here is we don't pass the expression locus to the tag checking
routine so the best it can do is the end of the line.  To fix this is fairly
mechanical, but affects many places.


-- 


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

[Bug preprocessor/41632] The preprocessor incorrectly reports #ident as being deprecated

[nvachhar at google dot com]

--- Comment #1 from nvachhar at google dot com  2009-10-10 00:36 ---
Author: nvachhar
Date: Sat Oct 10 00:34:21 2009
New Revision: 152612

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152612
Log:
2009-10-09  Neil Vachharajani 

   * libcpp/directives.c (DIRECTIVE_TABLE): Remove DEPRECATED from ident
and
   sccs.

   * gcc/doc/cpp.texi (Other Directives): Do not list #ident and #sccs as
   deprecated.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/cpp.texi
trunk/libcpp/ChangeLog
trunk/libcpp/directives.c


-- 

nvachhar at google dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/41585] [OOP] Reject CLASS(T) as component of "TYPE :: T"

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2009-10-09 22:39 ---
Fixed with r152608. Closing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/41585] [OOP] Reject CLASS(T) as component of "TYPE :: T"

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2009-10-09 22:35 ---
Subject: Bug 41585

Author: janus
Date: Fri Oct  9 22:35:11 2009
New Revision: 152608

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152608
Log:
2009-10-09  Janus Weil  

PR fortran/41585
* decl.c (build_struct): Bugfix for CLASS components.


2009-10-09  Janus Weil  

PR fortran/41585
* gfortran.dg/class_2.f03: Extended test case.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/class_2.f03


-- 


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

[Bug testsuite/41651] g++.dg/lto/20080908-3.C is broken

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-10-09 22:35 ---
Ah, and it was diego who added it.  So Diego, what is it supposed to test? ;)


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dnovillo at gcc dot gnu dot
   ||org


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

[Bug lto/41638] Back-end builtins are mishandled

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-10-09 22:33 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug testsuite/41651] g++.dg/lto/20080908-3.C is broken

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-10-09 22:32 ---
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00623.html is where the testcase
came from, it was named differently a year ago :).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug lto/41638] Back-end builtins are mishandled

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-10-09 22:32 ---
Subject: Bug 41638

Author: rguenth
Date: Fri Oct  9 22:31:53 2009
New Revision: 152606

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152606
Log:
2009-10-09  Richard Guenther  

PR lto/41638
* target-def.h (TARGET_BUILTIN_DECL): Define.
(TARGET_INITIALIZER): Add TARGET_BUILTIN_DECL.
* target.h (struct gcc_target): Add builtin_decl target hook.
* doc/tm.texi (TARGET_BUILTIN_DECL): Document.

* lto-streamer-in.c (lto_get_builtin_tree): Fix handling of
target builtins.
* lto-streamer-out.c (lto_output_tree_pointers): Use sorry,
not gcc_unreachable.
(lto_output_builtin_tree): Sorry if the target does not support
streaming target builtins.

* config/rs6000/rs6000.c (TARGET_BUILTIN_DECL): Define.
(rs6000_builtin_decl): New function.
* config/i386/i386.c (TARGET_BUILTIN_DECL): Define.
(ix86_builtin_decl): New function.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/doc/tm.texi
trunk/gcc/lto-streamer-in.c
trunk/gcc/lto-streamer-out.c
trunk/gcc/target-def.h
trunk/gcc/target.h


-- 


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

[Bug testsuite/41651] New: g++.dg/lto/20080908-3.C is broken

[rguenth at gcc dot gnu dot org]

2008-09-08  Simon Baldwin  

* g++.dg/lto/20080908-3.C: New test.

I can't find a mail that adds this test.  But it looks broken because the
uninitialized variable can be NaN.

What is it supposed to test?


-- 
   Summary: g++.dg/lto/20080908-3.C is broken
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: lto
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug fortran/41044] internal compiler error: in gfc_conv_intrinsic_function

[burnus at gcc dot gnu dot org]

--- Comment #7 from burnus at gcc dot gnu dot org  2009-10-09 21:59 ---
(In reply to comment #6)
> idx=sum(maxloc(index(pfd%n,pfmt)))-1

The problem is that "pfd%n" is simplified to an array constructor [''] of type
expr->value.constructor->ts == CHARACTER(kind=1,len=3).

But this typespec is not propagated to expr->ts while doing the simplification
and thus expr->ts is BT_DERIVED and expr->ts.kind == 0 - which causes the
assert to trigger. If one applies the hack below, one continues a bit further
but ends up having an ICE in gfc_conv_string_parameter's
  gcc_assert (POINTER_TYPE_P (TREE_TYPE (se->expr)))

The proper solutions is presumably to find the spot in array.c or expr.c where
the derived-type constructor is simplified into an character constructor; there
at least updating the expr->ts is missing.


Not working hack (ICE in gfc_conv_string_parameter):

--- trans-intrinsic.c   (Revision 152601)
+++ trans-intrinsic.c   (Arbeitskopie)
@@ -5340,2 +5340,5 @@ gfc_conv_intrinsic_function (gfc_se * se
 case GFC_ISYM_INDEX:
+  if (expr->value.function.actual->expr->expr_type == EXPR_ARRAY)
+   expr->value.function.actual->expr->ts
+ = expr->value.function.actual->expr->value.constructor->expr->ts;
   kind = expr->value.function.actual->expr->ts.kind;


-- 


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

[Bug fortran/41650] New: [Cleanup] Use gfc_expr_attr in resolve_allocate_expr/resolve_deallocate_expr

[burnus at gcc dot gnu dot org]

As suggested http://gcc.gnu.org/ml/fortran/2009-10/msg00098.html

When checking for the 'abstract' attribute in resolve_allocate_expr,
one has to determine the attributes of the given expression. Couldn't
this be done via 'gfc_expr_attr' or 'gfc_variable_attr', or is there
something special about it? Similar things happen also in
resolve_deallocate_expr, and it looks quite kludgy ...


-- 
   Summary: [Cleanup] Use gfc_expr_attr in
resolve_allocate_expr/resolve_deallocate_expr
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug c/41649] Optimizer makes wrong integer arithmetic assumption

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-10-09 20:55 ---
Nope, overflow on signed integers is undefined.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID
Summary|Optimizer makes wrong   |Optimizer makes wrong
   |integer arithmetic  |integer arithmetic
   |assumption  |assumption


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

[Bug c/41649] New: Optimizer makes wrong integer arithmetic assumption

[enrico dot kravina at gmail dot com]

Consider this simple program

int main(){
  int a=0;
  while (a>=0) a+=1;
}

compiled with this version of gcc: (The bug also manifested in later versions)
:~$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang
--prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2
--program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu4)

Compiling without optimization and with -O2 gives two completely different
results

:~/work/sysprog/perf$ g++ cnt.c -o cnt; time ./cnt
real 0m1.199s
user 0m1.200s
sys 0m0.000s

:~/work/sysprog/perf$ g++ -O2 cnt.c -o cnt && time ./cnt

Examining the assembly code it is clear why:

Without optimization we get

movl $0, %eax
.L2:
addl $1, %eax
jns .L2

And with O2 we get:

.L2:
jmp .L2

As I understand, a C program working with integers should not change its
semantics depending on the optimization switch. It would have been fine
to remove the loop completely but not to turn it into an infinite loop.


-- 
   Summary: Optimizer makes wrong integer arithmetic assumption
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: enrico dot kravina at gmail dot com
 GCC build triplet: IA32, Linux, gcc 4.2 (and later)
  GCC host triplet: IA32, Linux
GCC target triplet: IA32, Linux


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

[Bug fortran/41581] [OOP] Allocation of a CLASS with SOURCE= does not work

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-10-09 20:46 ---
To prevent wrong-code, SOURCE= is now rejected (cf. PR 41582).

For the run-time version: One might also need to check whether SOURCE is
allocated - at least with some checking option.


-- 


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

[Bug fortran/41582] Allocation of abstract types requires a type spec or a SOURCE

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2009-10-09 20:42 ---
Close as FIXED.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/41582] Allocation of abstract types requires a type spec or a SOURCE

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-10-09 20:34 ---
Subject: Bug 41582

Author: burnus
Date: Fri Oct  9 20:34:35 2009
New Revision: 152601

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152601
Log:
2009-10-09  Tobias Burnus  

PR fortran/41582
* decl.c (encapsulate_class_symbol): Save attr.abstract.
* resolve.c (resolve_allocate_expr): Reject class allocate
without typespec or source=.
* trans-stmt.c (gfc_trans_allocate): Change gfc_warning
into gfc_error for "not yet implemented".

2009-10-09  Tobias Burnus  

PR fortran/41582
* gfortran.dg/class_allocate_1.f03: Modify code such that
it compiles with the gfc_warning->gfc_error change.
* gfortran.dg/class_allocate_1.f03: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/class_allocate_2.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/class_allocate_1.f03


-- 


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

[Bug fortran/41579] [OOP] Nesting of SELECT TYPE

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2009-10-09 20:31 ---
Fixed with r152600. Closing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
Summary|[OOP/Polymorphism] Nesting  |[OOP] Nesting of SELECT TYPE
   |of SELECT TYPE  |


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

[Bug fortran/41579] [OOP/Polymorphism] Nesting of SELECT TYPE

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2009-10-09 20:25 ---
Subject: Bug 41579

Author: janus
Date: Fri Oct  9 20:25:19 2009
New Revision: 152600

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152600
Log:
2009-10-09  Janus Weil  

PR fortran/41579
* gfortran.h (gfc_select_type_stack): New struct, to be used as a stack
for SELECT TYPE statements.
(select_type_stack): New global variable.
(type_selector,select_type_tmp): Removed.
* match.c (type_selector,type_selector): Removed.
(select_type_stack): New variable, serving as a stack for
SELECT TYPE statements.
(select_type_push,select_type_set_tmp): New functions.
(gfc_match_select_type): Call select_type_push.
(gfc_match_type_is): Call select_type_set_tmp.
* parse.c (select_type_pop): New function.
(parse_select_type_block): Call select_type_pop.
* symbol.c (select_type_insert_tmp): New function.
(gfc_find_sym_tree): Call select_type_insert_tmp.


2009-10-09  Janus Weil  

PR fortran/41579
* gfortran.dg/select_type_6.f03: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/select_type_6.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/match.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug preprocessor/41445] Debug information is wrong with and without --save-temps.

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2009-10-09 19:55 ---
Subject: Bug 41445

Author: jakub
Date: Fri Oct  9 19:55:34 2009
New Revision: 152599

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152599
Log:
PR preprocessor/41445
* c-ppoutput.c (do_line_change): New function.
(cb_line_change): Use it.
(scan_translation_unit): Call do_line_change if
avoid_paste or PREV_WHITE and token location is on a different line
than print.src_line.

* gcc.dg/cpp/separate-1.c: Adjust.
* gcc.dg/cpp/spacing1.c: Add -P to dg-options.
* gcc.dg/debug/dwarf2/pr41445-1.c: New test.
* gcc.dg/debug/dwarf2/pr41445-2.c: New test.
* gcc.dg/debug/dwarf2/pr41445-3.c: New test.
* gcc.dg/debug/dwarf2/pr41445-4.c: New test.
* gcc.dg/debug/dwarf2/pr41445-5.c: New test.
* gcc.dg/debug/dwarf2/pr41445-6.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-1.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-2.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-3.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-4.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-ppoutput.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/cpp/separate-1.c
trunk/gcc/testsuite/gcc.dg/cpp/spacing1.c


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[mikpe at it dot uu dot se]

--- Comment #13 from mikpe at it dot uu dot se  2009-10-09 19:51 ---
Thanks for clarifying the !eh_personality_libfunc requirement. I'll do some
experiments to see which solution works best in 4.4.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug libstdc++/41645] Massive failures in parallel test mode

[joseph at codesourcery dot com]

--- Comment #13 from joseph at codesourcery dot com  2009-10-09 19:42 
---
Subject: Re:  Massive failures in parallel test mode

On Fri, 9 Oct 2009, chris at bubblescope dot net wrote:

> LD_LIBRARY_PATH doesn't exist on Mac. Usually linking libraries together 'just

It's called DYLD_LIBRARY_PATH there.


-- 


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

[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library

[rguenth at gcc dot gnu dot org]

--- Comment #15 from rguenth at gcc dot gnu dot org  2009-10-09 19:42 
---
Patches should be sent to gcc-patc...@gcc.gnu.org with a changelog entry and
a note on how you tested the patch.


-- 


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

[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library

[heydowns at borg dot com]

--- Comment #14 from heydowns at borg dot com  2009-10-09 19:38 ---
Ping - anyone able to comment on or integrate this patch please?
Thank you!


-- 


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

[Bug tree-optimization/41647] Early Loop Unrolling control

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-10-09 19:29 ---
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00621.html


-- 


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

[Bug fortran/41648] [OOP] Type-bound procedures refused

[sfilippone at uniroma2 dot it]

--- Comment #1 from sfilippone at uniroma2 dot it  2009-10-09 19:21 ---
Created an attachment (id=18769)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18769&action=view)
test case


-- 


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

[Bug fortran/41648] New: [OOP] Type-bound procedures refused

[sfilippone at uniroma2 dot it]

The attached code is not compiled correctly; gfortran accepts the subroutine
but not the function. NAG 5.2 compiles cleanly. 

[sfili...@localhost bug4]$ gfortran -v 
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/local/gnu45/bin/../libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gnu45
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.5.0 20091009 (experimental) (GCC) 
[sfili...@localhost bug4]$ gfortran -c test-der4.f03 
test-der4.f03:45.10:

res = a%a%getit()
  1
Error: Function 'getit' at (1) cannot be called recursively, as it is not
RECURSIVE


-- 
   Summary: [OOP] Type-bound procedures refused
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sfilippone at uniroma2 dot it
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2009-10-09 19:17 ---
Ah, now I see it in the 4.4 version.  Your backport is wrong then, you must not
return true from dwarf2out_do_cfi_asm when !eh_personality_libfunc, but
HAVE_GAS_CFI_SECTIONS_DIRECTIVE is 0 and not emitting normal unwind info.

Either you want:
int
dwarf2out_do_cfi_asm (void)
{
  int enc;

#ifdef MIPS_DEBUGGING_INFO
  return false;
#endif
  if (!flag_dwarf2_cfi_asm || !dwarf2out_do_frame ())
return false;
  if (saved_do_cfi_asm)
return true;
  if (eh_personality_libfunc)
{
  if (!HAVE_GAS_CFI_PERSONALITY_DIRECTIVE)
return false;

  /* Make sure the personality encoding is one the assembler can support.
 In particular, aligned addresses can't be handled.  */
  enc = ASM_PREFERRED_EH_DATA_FORMAT (/*code=*/2,/*global=*/1);
  if ((enc & 0x70) != 0 && (enc & 0x70) != DW_EH_PE_pcrel)
return false;
  enc = ASM_PREFERRED_EH_DATA_FORMAT (/*code=*/0,/*global=*/0);
  if ((enc & 0x70) != 0 && (enc & 0x70) != DW_EH_PE_pcrel)
return false;
}

  if (!HAVE_GAS_CFI_SECTIONS_DIRECTIVE)
{
#ifdef TARGET_UNWIND_INFO
  return false;
#else
  if (USING_SJLJ_EXCEPTIONS || (!flag_unwind_tables && !flag_exceptions))
return false;
#endif
}

  saved_do_cfi_asm = true;
  return true;
}

or move the !HAVE_GAS_CFI_SECTIONS_DIRECTIVE tests in between if
(saved_do_cfi_asm) return true; and if (!eh_personality_libfunc) return true;.


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2009-10-09 19:07 ---
Subject: Bug 40521

Author: jakub
Date: Fri Oct  9 19:07:23 2009
New Revision: 152598

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152598
Log:
PR debug/40521
* dwarf2out.c (dwarf2out_init): Test whether
HAVE_GAS_CFI_SECTIONS_DIRECTIVE is non-zero instead of checking
it is defined.

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


-- 


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

[Bug rtl-optimization/41646] [4.3/4.4/4.5 Regression] Reload ICE due to combiner extending life time of a hard register

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-10-09 19:02 ---
Subject: Bug 41646

Author: jakub
Date: Fri Oct  9 19:01:53 2009
New Revision: 152597

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152597
Log:
PR rtl-optimization/41646
* calls.c (expand_call): For BLKmode types returned in registers
avoid likely spilled hard regs in copy_blkmode_from_reg generated
insns.

* gcc.c-torture/compile/pr41646.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr41646.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2009-10-09 18:54 ---
Yes, it is a bug and I'll change it, but I wonder why it makes a difference
(unless you're using PCH).  .cfi_sections is only emitted if:
  if (dwarf2out_do_cfi_asm ())
{
#ifndef TARGET_UNWIND_INFO
  if (USING_SJLJ_EXCEPTIONS || (!flag_unwind_tables && !flag_exceptions))
#endif
fprintf (asm_out_file, "\t.cfi_sections\t.debug_frame\n");
}
#endif
but if !HAVE_CFI_SECTIONS_DIRECTIVE, dwarf2out_do_cfi_asm () has:
  if (!HAVE_GAS_CFI_SECTIONS_DIRECTIVE)
{
#ifdef TARGET_UNWIND_INFO
  return false;
#else
  if (USING_SJLJ_EXCEPTIONS || (!flag_unwind_tables && !flag_exceptions))
return false;
#endif
}

i.e. will return false under the exact same condition that dwarf2_init would
allow it.  The only exception is when using PCH, you could create PCH with
saved_do_cfi_asm true and then load it.


-- 


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

[Bug tree-optimization/41634] [4.5 Regression] ICE in dom

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2009-10-09 18:30 ---
Subject: Bug 41634

Author: rguenth
Date: Fri Oct  9 18:30:05 2009
New Revision: 152596

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152596
Log:
2009-10-09  Richard Guenther  

PR tree-optimization/41634
* tree-ssa-dom.c (remove_local_expressions_from_table): Assert
we remove the correct elements.
(optimize_stmt): Make sure to update stmt operands before
optimizing redundancies.

* gcc.c-torture/compile/pr41634.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr41634.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dom.c


-- 


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

[Bug tree-optimization/41634] [4.5 Regression] ICE in dom

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-10-09 18:30 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[mikpe at it dot uu dot se]

--- Comment #9 from mikpe at it dot uu dot se  2009-10-09 18:28 ---
I've been testing a backport of Jakub's patch to gcc-4.4, but it breaks
bootstrap on i686-linux with binutils-2.18.50.0.6 (Fedora 9) because stage1 gcc
outputs .cfi_sections directives even though the assembler doesn't support
them.
Current gcc-4.5 bootstraps Ok on the same machine.

The configure test correctly detects that cfi sections don't work with this as,
and records that with "#define HAVE_GAS_CFI_SECTIONS_DIRECTIVE 0".

In gcc-4.5 dwarf2out_do_cfi_asm() returns true. The code in dwarf2out_init()
inside #ifdef HAVE_GAS_CFI_SECTIONS_DIRECTIVE finds that USING_SJLJ_EXCEPTIONS
is false and !flag_exceptions is also false, so the call to emit a
.cfi_sections directive is not made. (!flag_unwind_tables varies, but it does
not matter since it's && with !flag_exceptions which always is false.)

In gcc-4.4 dwarf2out_do_cfi_asm() also returns true. The code in
dwarf2out_init() finds that USING_SJLJ_EXCEPTIONS is false but both
!flag_unwind_tables and !flag_exceptions are true, so a .cfi_sections directive
is emitted, causing the assembler to signal an error.

One thing that I find strange is that dwarf2out_do_cfi_asm() unconditionally
tests HAVE_GAS_CFI_SECTIONS_DIRECTIVE in an "if (!...)", which works since that
symbol is #defined as 0 or 1, while dwarf2out_init() instead has an #ifdef
HAVE_GAS_CFI_SECTIONS_DIRECTIVE around the conditional output of the directive.
Shouldn't that #ifdef be an #if?


-- 


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

[Bug other/41338] High memory consumption when compiling with -O3 -g

[d dot g dot gorbachev at gmail dot com]

--- Comment #3 from d dot g dot gorbachev at gmail dot com  2009-10-09 
18:19 ---
(In reply to comment #2)

Ok, thanks!


-- 


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

[Bug tree-optimization/41647] Early Loop Unrolling control

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-10-09 17:51 ---
Confirmed.  Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
   Severity|normal  |enhancement
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-10-09 17:51:33
   date||


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

[Bug libstdc++/41645] Massive failures in parallel test mode

[chris at bubblescope dot net]

--- Comment #12 from chris at bubblescope dot net  2009-10-09 17:51 ---
LD_LIBRARY_PATH doesn't exist on Mac. Usually linking libraries together 'just
works', but in this case it seems to have broken.

By configuring with --enable-fully-dynamic-string, I get a working compiler
(actually better than the system compiler, as now -D_GLIBCXX_DEBUG works) so
I'm happy for now. Someone who is better with linking-fu than me should
probably at some point look at just what Apple has managed to mess up however.


-- 


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

[Bug tree-optimization/41647] New: Early Loop Unrolling control

[dje at gcc dot gnu dot org]

GCC currently does not provide independent control over early loop unrolling. 
The early inner loop unrolling complicates Polyhedral analysis.  An individual
option that Graphite could access would be helpful.


-- 
   Summary: Early Loop Unrolling control
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dje at gcc dot gnu dot org
 GCC build triplet: *-*-*
  GCC host triplet: *-*-*
GCC target triplet: *-*-*


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

[Bug c/41045] Extended asm with C operands doesn�t work at top level

[anders at kaseorg dot com]

--- Comment #7 from anders at kaseorg dot com  2009-10-09 17:45 ---
> Really if the kernel should have compile time asserts that the offsets don't
> match up with the inline-asm.

Yes, it’s entirely possible that the kernel’s kludge could be made more robust
by adding complexity.  This doesn’t change the point that a solution based on
extended toplevel asm would be easier and simpler.


-- 


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

[Bug bootstrap/41399] [4.5 Regression] Internal error compiling fortran/intrinsic.c

[danglin at gcc dot gnu dot org]

--- Comment #5 from danglin at gcc dot gnu dot org  2009-10-09 17:22 ---
Approximately 512 MB of storage are allocated compiling this function
in the sched1 pass causing the system to kill cc1.  It doesn't help to
trigger ggc after every pass.  The function will compile with
-fno-schedule-insns.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu dot
   ||org


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

[Bug c/41045] Extended asm with C operands doesn�t work at top level

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2009-10-09 17:19 ---
Really if the kernel should have compile time asserts that the offsets don't
match up with the inline-asm.

There are ways of doing that it is not hard:
typedef static_assert_1[offsetof(a, b) != OFFSETAB ? -1 : 1];


-- 


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

[Bug target/41644] -minimal-toc not helping for toc section exceeding 64k

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-10-09 17:13 ---
Also the ABIs for powerpc32-linux-gnu and powerpc64-linux-gnu are different by
a huge amount.  In the 64bit mode, global addresses are made via the TOC
register while in 32bit mode, they are done via a simple lis/addi pair.


-- 


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

[Bug c/41045] Extended asm with C operands doesn�t work at top level

[anders at kaseorg dot com]

--- Comment #5 from anders at kaseorg dot com  2009-10-09 16:12 ---
As Nelson pointed out, the subsequent commit to that macro
 cannot
be done with C.  In any event, while it may also be useful to add extensions
like nobits to C, adding enough extensions to subsume all conceivable uses of
inline assembly clearly isn’t a sustainable solution.

A more fundamental source of ugliness in the Linux kernel is that many
functions which are written entirely in assembly (and must be, because they
have special calling conventions dictated by the hardware, or are involved in
setting up the appropriate environment for executing C code, or must be
hand-optimized for performance, etc.) need to access members of a C struct. 
Since there is no way to get the offset of a C struct member from assembly, the
kernel’s current solution is to compile (but not assemble) a special file named
asm-offsets.c:

#define DEFINE(sym, val) \
asm volatile("\n->" #sym " %0 " #val : : "i" (val))
int main(void)
{
#define ENTRY(entry) DEFINE(tsk_ ## entry, offsetof(struct task_struct, entry))
ENTRY(state);
ENTRY(flags); 
ENTRY(pid);
…   
}

resulting in asm-offsets.s:

main:
pushq   %rbp#
movq%rsp, %rbp  #,
#APP
->tsk_state $0 offsetof(struct task_struct, state)  #
->tsk_flags $20 offsetof(struct task_struct, flags) #
->tsk_pid $680 offsetof(struct task_struct, pid)#
…

which is post-processed with sed into a header asm-offsets.h that consists of a
long list of definitions for assembly code:

#define tsk_state 0 /* offsetof(struct task_struct, state)  # */
#define tsk_flags 20 /* offsetof(struct task_struct, flags) # */
#define tsk_pid 680 /* offsetof(struct task_struct, pid)# */
…

If toplevel extended asm was available, this entire mechanism could have been
unnecessary, because one could write this directly:

asm("kernel_thread:\n"
…
"movl %c[tsk_pid](%%rax),%%eax\n"
: : [tsk_pid] "n" (offsetof(struct task_struct, pid)));


-- 


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

[Bug middle-end/41573] [4.5 Regression] segfault in trunk related to strings

[matz at gcc dot gnu dot org]

--- Comment #5 from matz at gcc dot gnu dot org  2009-10-09 16:04 ---
Fixed.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/41634] [4.5 Regression] ICE in dom

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-10-09 15:54 ---
Breakpoint 5, lookup_avail_expr (stmt=0xb7d591a0, insert=1 '\1')
at /home/richard/src/trunk/gcc/tree-ssa-dom.c:2254
2254  slot = htab_find_slot_with_hash (avail_exprs, element, element->hash,
# VUSE <.MEM_21>
D.2003_28 = "0,1,2,3,4,5,6,7,8,9\r\n\r\nA,B,C,D,E\r\nX,Y,Z"[D.2001_61];
(gdb) p element
$10 = (struct expr_hash_elt *) 0x8dffd28
(gdb) p *element
$1 = {lhs = 0xb7d500d0, expr = {type = 0x0, kind = EXPR_SINGLE, ops = {
  single = {rhs = 0xb7d591d4}, unary = {op = 3084227028, opnd = 0x0}, 
  binary = {op = 3084227028, opnd0 = 0x0, opnd1 = 0x0}, call = {
fn = 0xb7d591d4, pure = 0 '\0', nargs = 0, args = 0x28}}}, 
  stmt = 0xb7d591a0, hash = 3753424485, stamp = 0x8dffd28}

Breakpoint 5, lookup_avail_expr (stmt=0xb7d5930c, insert=1 '\1')
at /home/richard/src/trunk/gcc/tree-ssa-dom.c:2254
2254  slot = htab_find_slot_with_hash (avail_exprs, element, element->hash,
# VUSE <.MEM_21>
D.2003_14 = "0,1,2,3,4,5,6,7,8,9\r\n\r\nA,B,C,D,E\r\nX,Y,Z"[D.2001_61];
(gdb) p element
$11 = (struct expr_hash_elt *) 0x8e2d8b8
(gdb) p *element
$12 = {lhs = 0xb7d32bfc, expr = {type = 0x0, kind = EXPR_SINGLE, ops = {
  single = {rhs = 0xb7d59340}, unary = {op = 3084227392, 
opnd = 0xb7d306ac}, binary = {op = 3084227392, opnd0 = 0xb7d306ac, 
opnd1 = 0xb7d32ac4}, call = {fn = 0xb7d59340, pure = 172 '\254', 
nargs = 3084069572, args = 0xb7c96498}}}, stmt = 0xb7d5930c, 
  hash = 3753424485, stamp = 0x8e2d8b8}

Breakpoint 6, avail_expr_eq (p1=0x8dffd28, p2=0x8e2d8b8)
at /home/richard/src/trunk/gcc/tree-ssa-dom.c:2340
(gdb) p *(const struct expr_hash_elt *)p1
$13 = {lhs = 0xb7d500d0, expr = {type = 0x0, kind = EXPR_SINGLE, ops = {
  single = {rhs = 0xb7d591d4}, unary = {op = 3084227028, opnd = 0x0}, 
  binary = {op = 3084227028, opnd0 = 0x0, opnd1 = 0x0}, call = {
fn = 0xb7d591d4, pure = 0 '\0', nargs = 0, args = 0x28}}}, 
  stmt = 0xb7d591a0, hash = 3753424485, stamp = 0x8dffd28}
(gdb) p *(const struct expr_hash_elt *)p2
$14 = {lhs = 0xb7d32bfc, expr = {type = 0x0, kind = EXPR_SINGLE, ops = {
  single = {rhs = 0xb7d59340}, unary = {op = 3084227392, 
opnd = 0xb7d306ac}, binary = {op = 3084227392, opnd0 = 0xb7d306ac, 
opnd1 = 0xb7d32ac4}, call = {fn = 0xb7d59340, pure = 172 '\254', 
nargs = 3084069572, args = 0xb7c96498}}}, stmt = 0xb7d5930c, 
  hash = 3753424485, stamp = 0x8e2d8b8}
(gdb) call debug_gimple_stmt (0xb7d591a0)
D.2003_28 = "0,1,2,3,4,5,6,7,8,9\r\n\r\nA,B,C,D,E\r\nX,Y,Z"[D.2001_61];
(gdb) call debug_gimple_stmt (0xb7d5930c)
# VUSE <.MEM_21>
D.2003_14 = "0,1,2,3,4,5,6,7,8,9\r\n\r\nA,B,C,D,E\r\nX,Y,Z"[D.2001_61];

whoops?  where did the VOP go?

#1  0x0866c1d7 in remove_local_expressions_from_table ()
at /home/richard/src/trunk/gcc/tree-ssa-dom.c:836
836   gcc_assert (slot && *slot == (void *) victim);
(gdb) p victim
$8 = (expr_hash_elt_t) 0x8e2d8d0
(gdb) p *slot
$9 = (void *) 0x8dffd28


-- 


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

[Bug tree-optimization/41634] [4.5 Regression] ICE in dom

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-10-09 15:43 ---
Created an attachment (id=18768)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18768&action=view)
debugging patch

Ok, the issue is that we insert a stmt for

2>>> 0x8dffd28 STMT D.2003_28 =
"0,1,2,3,4,5,6,7,8,9\r\n\r\nA,B,C,D,E\r\nX,Y,Z"[D.2001_61]

multiple times (thus not finding the already existing dup).

patch for debugging that attached.


-- 


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

[Bug rtl-optimization/41646] [4.3/4.4/4.5 Regression] Reload ICE due to combiner extending life time of a hard register

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-10-09 15:35 ---
Created an attachment (id=18767)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18767&action=view)
gcc45-pr41646.patch

Patch I'm going to bootstrap/regtest.

cant_combine_insn_p already takes care of not combining in hard registers with
likely spilled classes in the (set (reg) (hardreg)) cases, so it is just when
expand doesn't honor this.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug libstdc++/41645] Massive failures in parallel test mode

[paolo dot carlini at oracle dot com]

--- Comment #11 from paolo dot carlini at oracle dot com  2009-10-09 15:31 
---
(In reply to comment #10)
> To sum up the current state, as things are getting confusing:

A bit yes ;)

> Compiling 'testsuite/21_strings/basic_string/inserters_extractors/char/1.cc -I
> testsuite/util -O2'
> 
> using /newgccsvn/bin/g++ (recent svn compile) or /usr/bin/g++ (Apple's gcc
> 4.2.1)
> 
> No flags: Fine
> -D_GLIBCXX_PARALLEL (or _D_GLIBCXX_DEBUG): Fails
> -D_GLIBCXX_PARALLEL (or _D_GLIBCXX_DEBUG) -D_GLIBCXX_FULLY_DYNAMIC_STRING :
> Works
> 
> I built my compiler with:
> 
> ../gccsvn/configure --enable-languages=c,c++ --prefix=/newgccsvn
> make && make install
> 
> Using otool -l (an Apple system utility), it looks like when I use the system
> compiler I get linked against   /usr/lib/libstdc++.6.dylib, and when I use
> /newgccsvn/bin/g++ I get linked against /newgccsvn/lib/libstdc++.6.dylib

Just out of curiosity, it gets linked magically to the new library without
telling it to do so? On Linux, I need to add the new path to LD_LIBRARY_PATH,
otherwise, it doesn't happen. Any idea how it can be so smart?

> So there seems to be two issues:
> 
> 1) Someone in Apple has completely broken their standard library by turning on
> _GLIBCXX_FULLY_DYNAMIC_STRING  and worse not putting that in the headers, 
> which
> is breaking _GLIBCXX_DEBUG builds and I imagine will cause some other
> nastyness.

Definitely.

> 2) For some reason I cannot figure out, this is somehow 'leaking' into my
> build.

Yes, this is the most mysterious part.

One final remark, then I don't see I can do much about this issue right now, I
wonder if you can get a fully working compiler + libraries, if you just pass
--enable-fully-dynamic-string at build time. That breaks binary compatibility,
note (eg, old binaries cannot work fine linked to the new library), but I
vaguely suspect that this way you would get a more consistent whole.


-- 


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

[Bug libstdc++/41645] Massive failures in parallel test mode

[chris at bubblescope dot net]

--- Comment #10 from chris at bubblescope dot net  2009-10-09 15:10 ---
To sum up the current state, as things are getting confusing:

Compiling 'testsuite/21_strings/basic_string/inserters_extractors/char/1.cc -I
testsuite/util -O2'

using /newgccsvn/bin/g++ (recent svn compile) or /usr/bin/g++ (Apple's gcc
4.2.1)

No flags: Fine
-D_GLIBCXX_PARALLEL (or _D_GLIBCXX_DEBUG): Fails
-D_GLIBCXX_PARALLEL (or _D_GLIBCXX_DEBUG) -D_GLIBCXX_FULLY_DYNAMIC_STRING :
Works

I built my compiler with:

../gccsvn/configure --enable-languages=c,c++ --prefix=/newgccsvn
make && make install

Using otool -l (an Apple system utility), it looks like when I use the system
compiler I get linked against   /usr/lib/libstdc++.6.dylib, and when I use
/newgccsvn/bin/g++ I get linked against /newgccsvn/lib/libstdc++.6.dylib

So there seems to be two issues:

1) Someone in Apple has completely broken their standard library by turning on
_GLIBCXX_FULLY_DYNAMIC_STRING  and worse not putting that in the headers, which
is breaking _GLIBCXX_DEBUG builds and I imagine will cause some other
nastyness.

2) For some reason I cannot figure out, this is somehow 'leaking' into my
build.

Apologises for a few wild goose-cases along the way.


-- 


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

[Bug tree-optimization/41634] [4.5 Regression] ICE in dom

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-10-09 14:53 ---
We have the same expr on the stack more than once.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-10-08 21:46:36 |2009-10-09 14:53:55
   date||


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

[Bug libstdc++/41645] Massive failures in parallel test mode

[paolo dot carlini at oracle dot com]

--- Comment #9 from paolo dot carlini at oracle dot com  2009-10-09 14:51 
---
Sorry, your 'however' confused me. So, you *are* linking versus the new
library, right? In that case it is *incorrect* to pass
-D_GLIBCXX_FULLY_DYNAMIC_STRING in the command line, since your new library has
not been built with it.

As a matter of fact, the use itself of -D_GLIBCXX_FULLY_DYNAMIC_STRING is
**completely** unsupported, in other terms the user is **never** supposed to
pass it, only the configure can internally appropriately set
_GLIBCXX_FULLY_DYNAMIC_STRING basing on --enable-fully-dynamic-string. Somebody
should tell Apple ;)


-- 


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

[Bug libstdc++/41645] Massive failures in parallel test mode

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2009-10-09 14:46 
---
So, the problem is exactly that you *are* using the system libraries, a mix of
the new headers and the system library. This is in general unsupported of
course.

While apparently we *do* have a problem in testsuite, not sure why, it seems to
me that the new installed compiler + libraries should be ok, in parallel mode,
debug mode and everything, assuming you consistently link vs the new libraries,
not the system ones. Can you do that and report back?


-- 


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

[Bug lto/40790] plugin-api.h unconditionally includes stdint.h

[joseph at codesourcery dot com]

--- Comment #16 from joseph at codesourcery dot com  2009-10-09 14:44 
---
Subject: Re:  plugin-api.h unconditionally includes stdint.h

On Fri, 9 Oct 2009, ro at techfak dot uni-bielefeld dot de wrote:

> > gold supports non-ELF hosts (or will once Andrew Pinski's MinGW host 
> > patches are in), and in due course should support plugins on such hosts.  
> 
> Ok, but only as a cross-linker to ELF targets, I suppose?

Yes.  Non-ELF targets only via converting from ELF to some other format 
after linking (like uClinux targets using FLT, or arm-symbianelf, do right 
now with a separate converter not included in binutils).

(Unlike gold, nothing in the design of LTO strongly links it to ELF; it 
uses ELF as a container for bytecode streams but should be adaptable to be 
able to use other formats - that allow arbitrary user-defined sections - 
as well if someone wishes to do so, and all that should be needed is a 
replacement of lto-elf.c for the other format or a generic version of it 
using BFD.)


-- 


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

[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

[hjl dot tools at gmail dot com]

--- Comment #19 from hjl dot tools at gmail dot com  2009-10-09 14:43 
---
Without a testcase, people may not review the patch.


-- 


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

[Bug rtl-optimization/41646] [4.3/4.4/4.5 Regression] Reload ICE due to combiner extending life time of a hard register

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-10-09 14:42 ---
Or perhaps the bug is that we should force the return value into a register to
avoid having hard regs in the arithmetic instructions so early.


-- 


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

[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

[mahatma at eu dot by]

--- Comment #18 from mahatma at eu dot by  2009-10-09 14:41 ---
Created an attachment (id=18766)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18766&action=view)
(2) for 4.5, fixed

Originals may produce illegal warnings without SSE.


-- 

mahatma at eu dot by changed:

   What|Removed |Added

  Attachment #18764|0   |1
is obsolete||


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

[Bug rtl-optimization/41646] New: [4.3/4.4/4.5 Regression] Reload ICE due to combiner extending life time of a hard register

[jakub at gcc dot gnu dot org]

struct A { unsigned long a; };
struct B { unsigned short b, c, d; };
struct B bar (unsigned long);
char *
foo (char *a, struct A *x)
{
  struct B b = bar (x->a);
  unsigned char c;
  unsigned short d;
  a[3] = ((unsigned char) (b.b % 10) + 48);
  d = b.b / 10;
  a[2] = ((unsigned char) (d % 10) + 48);
  d = d / 10;
  a[1] = ((unsigned char) (d % 10) + 48);
  a[0] = ((unsigned char) ((d / 10) % 10) + 48);
  a[4] = 46;
  c = (unsigned char) b.c;
  a[6] = (c % 10 + 48);
  a[5] = ((c / 10) % 10 + 48);
  a[7] = 46;
  c = b.d;
  a[9] = (c % 10 + 48);
  a[8] = ((c / 10) % 10 + 48);
  return a + 10;
}

ICEs with -O2 on x86_64-linux:
/tmp/tt.c: In function 'foo':
/tmp/tt.c:25:1: error: unable to find a register to spill in class 'AREG'
/tmp/tt.c:25:1: error: this is the insn:
(insn 82 81 83 2 /tmp/tt.c:18 (parallel [
(set (reg:HI 1 dx [170])
(mult:HI (zero_extend:HI (reg/v:QI 4 si [orig:82 c ] [82]))
(zero_extend:HI (reg:QI 2 cx [169]
(clobber (reg:CC 17 flags))
]) 337 {*umulqihi3_1} (expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (mult:HI (zero_extend:HI (reg/v:QI 4 si [orig:82 c
] [82]))
(const_int 205 [0xcd]))
(nil
/tmp/tt.c:25:1: internal compiler error: in spill_failure, at reload1.c:2151
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Worked in 3.4/4.0, ICEs from 4.1 onwards up to current trunk.

The problem seems to be in the combiner, it extremely lengthens the lifetime of
hard register (%rax):

in *.dce:
...
(insn 13 12 14 2 /tmp/tt.c:7 (parallel [
(set (reg:DI 113)
(lshiftrt:DI (reg:DI 0 ax)
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) 549 {*lshrdi3_1_rex64} (expr_list:REG_DEAD (reg:DI 0 ax)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 14 13 16 2 /tmp/tt.c:7 (set (reg:HI 114)
(subreg:HI (reg:DI 113) 0)) 53 {*movhi_1} (expr_list:REG_DEAD (reg:DI
113)
(nil)))
... 49 insns ...
(insn 82 81 83 2 /tmp/tt.c:18 (parallel [
(set (reg:HI 168)
(mult:HI (zero_extend:HI (reg/v:QI 82 [ c ]))
(zero_extend:HI (reg:QI 169
(clobber (reg:CC 17 flags))
]) 337 {*umulqihi3_1} (expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (mult:HI (zero_extend:HI (reg/v:QI 82 [ c ]))
(const_int 205 [0xcd]))
(nil
... 18 insns ...
(insn 108 107 110 2 /tmp/tt.c:21 (set (reg/v:QI 93 [ c ])
(subreg:QI (reg:HI 114) 0)) 62 {*movqi_1} (expr_list:REG_DEAD (reg:HI
114)
(nil)))
...
in *.combine:
...
(note 13 12 14 2 NOTE_INSN_DELETED)
(note 14 13 16 2 NOTE_INSN_DELETED)
... many insns ...
(insn 82 81 83 2 /tmp/tt.c:18 (parallel [
(set (reg:HI 168)
(mult:HI (zero_extend:HI (reg/v:QI 82 [ c ]))
(zero_extend:HI (reg:QI 169
(clobber (reg:CC 17 flags))
]) 337 {*umulqihi3_1} (expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (mult:HI (zero_extend:HI (reg/v:QI 82 [ c ]))
(const_int 205 [0xcd]))
(nil
... many insns ...
(insn 108 107 110 2 /tmp/tt.c:21 (parallel [
(set (subreg:DI (reg/v:QI 93 [ c ]) 0)
(lshiftrt:DI (reg:DI 0 ax)
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) 549 {*lshrdi3_1_rex64} (expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_DEAD (reg:DI 0 ax)
(nil
...


-- 
   Summary: [4.3/4.4/4.5 Regression] Reload ICE due to combiner
extending life time of a hard register
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-linux


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

[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

[mahatma at eu dot by]

--- Comment #17 from mahatma at eu dot by  2009-10-09 14:39 ---
Created an attachment (id=18765)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18765&action=view)
(2) for 4.4, fixed


-- 

mahatma at eu dot by changed:

   What|Removed |Added

  Attachment #18762|0   |1
is obsolete||


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

[Bug lto/41597] Bad .comm directive

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-10-09 14:29 ---
There's emit_common in varasm.c, but somebody with more experience in this
area might want to suggest a more proper way to emit this .comm.


-- 


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

[Bug libstdc++/41645] Massive failures in parallel test mode

[chris at bubblescope dot net]

--- Comment #7 from chris at bubblescope dot net  2009-10-09 14:20 ---
Further: If I add -D_GLIBCXX_FULLY_DYNAMIC_STRING, the code compiles fine!

However, if I run otool on my executable, it says it is linked with:

Load command 10
  cmd LC_LOAD_DYLIB
  cmdsize 64
 name /newgccsvn/lib/libstdc++.6.dylib (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
  current version 7.14.0
compatibility version 7.0.0
Load command 11
  cmd LC_LOAD_DYLIB
  cmdsize 56
 name /newgccsvn/lib/libgcc_s.1.dylib (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
  current version 1.0.0
compatibility version 1.0.0
Load command 12
  cmd LC_LOAD_DYLIB
  cmdsize 56
 name /usr/lib/libSystem.B.dylib (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
  current version 124.1.1
compatibility version 1.0.0


-- 


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

[Bug libstdc++/41645] Massive failures in parallel test mode

[chris at bubblescope dot net]

--- Comment #6 from chris at bubblescope dot net  2009-10-09 14:16 ---
Ah yes, something I should have tried earlier.

The resulting compiler generally works fine, until I add -D_GLIBCXX_PARALLEL,
when things break.

I only seem to get a problem when I have enough optimisation to inline
functions.

-O0 works fine
-O1 breaks
-O1 -fno-inline works fine

Which is a shame, as it makes debugging that much harder.

The same problem occurs with _GLIBCXX_DEBUG, so actually this isn't related to
parallel, sorry for the false alarm. I assume it's related to extern templates,
but I'm not sure how exactly.


-- 


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

[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

[mahatma at eu dot by]

--- Comment #16 from mahatma at eu dot by  2009-10-09 14:10 ---
Created an attachment (id=18764)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18764&action=view)
2) sse-stackrealign-sse4a-4.5.patch


-- 


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

[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

[mahatma at eu dot by]

--- Comment #15 from mahatma at eu dot by  2009-10-09 14:10 ---
Created an attachment (id=18763)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18763&action=view)
1) sse-stackrealign-misalignsse-4.5.patch


-- 


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

[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

[mahatma at eu dot by]

--- Comment #14 from mahatma at eu dot by  2009-10-09 14:09 ---
Created an attachment (id=18762)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18762&action=view)
2) sse-stackrealign-sse4a-4.4.patch


-- 


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

[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

[mahatma at eu dot by]

--- Comment #13 from mahatma at eu dot by  2009-10-09 14:08 ---
Created an attachment (id=18761)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18761&action=view)
1) sse-stackrealign-misalignsse-4.4.patch


-- 

mahatma at eu dot by changed:

   What|Removed |Added

  Attachment #18650|0   |1
is obsolete||


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

[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

[mahatma at eu dot by]

--- Comment #12 from mahatma at eu dot by  2009-10-09 14:07 ---
I found new AMD CPUs not required to stack aligning for SSE. IMHO there are
"misalignsse" cpu feature, found near SSE4a (fixme). Then, requirement for
stack realigning may be checked from "misalignsse" (precise) or "sse4a"
(simple).

I don't want (while) to exeperiments with make scripts for isolating
"-mno-stackrealign" CFLAGS for unwinding library and only suggest two variants
of common solution:
1) Checking "misalignsse" for -march=native, -mno-stackrealign (if given) may
produce broken code with SSE, gcc libs not verifyed against it.
2) Use TARGET_SSE4A as "cname" to misalignsse to detect realigning requirement.
Also trying to disable SSE if realigning forced to disable (-mno-stackrealign
given). SSE for gcc libs will be disabled.

This solutions may be mixed, but I see no sense. Or SSE4A is used or no. If no
- I not found way to move "misalignsse" flag to configuration section. Just may
be sense to remove SSE disabling in (2) - just remove i386.c changes.

IMHO last todo in this case: unwinding library (CFLAGS or -mstackrealign
support).

PS Both are untested. But sse-stackrealign-1.patch have not problems for me.

Both are


-- 


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

[Bug libstdc++/41645] Massive failures in parallel test mode

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2009-10-09 13:52 
---
Indeed, the system library should not be used at all, but in your example above
the system library *is* used unless you make sure to properly install
everything, set the appropriate LD_LIBRARY_PATH, etc. In other terms, I would
be curious to know what happens if you just build everything, install it, and
then use normally the new compiler, for example to compile and run outside the
testsuite some tests... If everything works, it's just some sort of weird
testsuite issue.

PS: in case you didn't notice already, libtestc++.a is built by
v3-build_support in libstdc++.exp, indeed, the system stuff should not be
involved at all...


-- 


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

[Bug fortran/41044] internal compiler error: in gfc_conv_intrinsic_function

[ros at rzg dot mpg dot de]

--- Comment #6 from ros at rzg dot mpg dot de  2009-10-09 13:51 ---
(In reply to comment #5)
I have further reducd the test code to:
idx=sum(maxloc(index(pfd%n,pfmt)))-1
Program GF_BUG
!
type psfd
  character  :: n*3
end type psfd
character:: pfmt*3=''
type(psfd), parameter:: pfd(1)=[psfd('')]
!
idx=sum(maxloc(index(pfd%n,pfmt)))-1
end

For the error message to appear it is essential
- that the variable 'psfd' is of derived type,
- that the type declaration statement for 'pdf' has the attribute PARAMETER
- and the statement 'idx=sum(maxloc(index(pfd%n,pfmt)))-1' exists in this form.
Splitting up this statement into 
  'idx=sum(maxloc(index(pfd%n,pfmt)))'   and
  'idx=idx-1'
makes the error message disappear!

I hope, this helps for fixing the bug.


-- 

ros at rzg dot mpg dot de changed:

   What|Removed |Added

 CC||ros at rzg dot mpg dot de


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

[Bug driver/41637] testsuite (-flto/-fwhopr) leaves does not clean up in /tmp

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-10-09 13:37 ---
It remains PR41564 (the testsuite doesn't cleanup dumps in /tmp).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug lto/41636] lto-elf.c i18n problems

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-10-09 13:37 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug lto/41635] inappropriate assertion that fopen succeeds

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-10-09 13:36 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug lto/40790] plugin-api.h unconditionally includes stdint.h

[espindola at google dot com]

--- Comment #15 from espindola at google dot com  2009-10-09 13:30 ---
> Why the complications?  Just use GCC_HEADER_STDINT in both gcc and gold and
> be done with it.  If the intention is for gold to support platforms beyond
> GNU/Linux with ELF, it will run into the need sooner or later anyway.

I assumed GCC_HEADER_STDINT was gcc specific :-)

Will try to code a patch with your suggestion.

> Rainer
> 

Thanks,
Rafael


-- 


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

[Bug lto/41636] lto-elf.c i18n problems

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-10-09 13:25 ---
Subject: Bug 41636

Author: rguenth
Date: Fri Oct  9 13:24:59 2009
New Revision: 152588

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152588
Log:
2009-10-09  Richard Guenther  

PR driver/41637
* lto-wrapper.c (ltrans_output_file, flto_out, args_name): New
globals.
(lto_wrapper_exit): New function.
(fatal): Use it.
(fatal_perror): Likewise.
(fork_execute): Use global args_name, do not free it.
(run_gcc): Use global ltrans_output_file, flto_out, do not free them.
* lto-streamer.h: Remove duplicate prototypes.

PR lto/41635
PR lto/41636
lto/
* lto.c (read_cgraph_and_symbols): Do not assert we can open
a file.
* lto-elf.c (init_shdr##BITS): Fix i18n problems.
(init_ehdr##BITS): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer.h
trunk/gcc/lto-wrapper.c
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-elf.c
trunk/gcc/lto/lto.c


-- 


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

[Bug lto/41635] inappropriate assertion that fopen succeeds

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-10-09 13:25 ---
Subject: Bug 41635

Author: rguenth
Date: Fri Oct  9 13:24:59 2009
New Revision: 152588

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152588
Log:
2009-10-09  Richard Guenther  

PR driver/41637
* lto-wrapper.c (ltrans_output_file, flto_out, args_name): New
globals.
(lto_wrapper_exit): New function.
(fatal): Use it.
(fatal_perror): Likewise.
(fork_execute): Use global args_name, do not free it.
(run_gcc): Use global ltrans_output_file, flto_out, do not free them.
* lto-streamer.h: Remove duplicate prototypes.

PR lto/41635
PR lto/41636
lto/
* lto.c (read_cgraph_and_symbols): Do not assert we can open
a file.
* lto-elf.c (init_shdr##BITS): Fix i18n problems.
(init_ehdr##BITS): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer.h
trunk/gcc/lto-wrapper.c
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-elf.c
trunk/gcc/lto/lto.c


-- 


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

[Bug driver/41637] testsuite (-flto/-fwhopr) leaves does not clean up in /tmp

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-10-09 13:25 ---
Subject: Bug 41637

Author: rguenth
Date: Fri Oct  9 13:24:59 2009
New Revision: 152588

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152588
Log:
2009-10-09  Richard Guenther  

PR driver/41637
* lto-wrapper.c (ltrans_output_file, flto_out, args_name): New
globals.
(lto_wrapper_exit): New function.
(fatal): Use it.
(fatal_perror): Likewise.
(fork_execute): Use global args_name, do not free it.
(run_gcc): Use global ltrans_output_file, flto_out, do not free them.
* lto-streamer.h: Remove duplicate prototypes.

PR lto/41635
PR lto/41636
lto/
* lto.c (read_cgraph_and_symbols): Do not assert we can open
a file.
* lto-elf.c (init_shdr##BITS): Fix i18n problems.
(init_ehdr##BITS): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer.h
trunk/gcc/lto-wrapper.c
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-elf.c
trunk/gcc/lto/lto.c


-- 


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

[Bug c++/9381] attribute on member function pointer have no effect

[jacek at codeweavers dot com]

--- Comment #12 from jacek at codeweavers dot com  2009-10-09 13:24 ---
(In reply to comment #6)
> Not a regression any more.

It is a regression now. It worked in 3.4 and doesn't work in 4.x. That's why
I'm still using GCC 3.4.6.


-- 


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

[Bug lto/40790] plugin-api.h unconditionally includes stdint.h

[ro at techfak dot uni-bielefeld dot de]

--- Comment #14 from ro at techfak dot uni-bielefeld dot de  2009-10-09 
13:24 ---
Subject: Re:  plugin-api.h unconditionally includes stdint.h

> --- Comment #12 from joseph at codesourcery dot com  2009-10-09 12:58 
> ---
[...]
> > That would be no problem since AFAIK gold only supports ELF targets by
> > design, and Tru64 UNIX uses ECOFF.  Not even GNU ld supports that anymore
> > (or the support has bitrotten to the point of being unusable).
> 
> gold supports non-ELF hosts (or will once Andrew Pinski's MinGW host 
> patches are in), and in due course should support plugins on such hosts.  

Ok, but only as a cross-linker to ELF targets, I suppose?

> (I've no idea whether Tru64 has a dynamic loading interface making plugins 
> on such a host possible at all, but if it has such an interface there is 
> no reason in principle against someone adding support for plugins for a 
> cross compiler and linker from Tru64 to an ELF target.)

Tru64 UNIX supports dlopen(3), so you should be set.

Rainer


-- 


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

[Bug lto/40790] plugin-api.h unconditionally includes stdint.h

[ro at techfak dot uni-bielefeld dot de]

--- Comment #13 from ro at techfak dot uni-bielefeld dot de  2009-10-09 
13:21 ---
Subject: Re:  plugin-api.h unconditionally includes stdint.h

> --- Comment #11 from espindola at google dot com  2009-10-09 12:58 ---
> > Why all those contortions if there seems to be an easy way out: just use
> > the GCC_HEADER_STDINT macro from config/m4 and include the resulting (e.g.)
> > gstdint.h instead of stdint.h?
> 
> Interesting. One problem is that this header is also used on gold. Maybe we
> could do
> 
> #ifdef HAVE_STDINT_H
> #include 
> #elif HAVE_INTTYPES_H
> #include 
> #else
> #include "gstdint.h"
> #endif
> 
> That way gcc would build on anything thanks to GCC_HEADER_STDINT and gold 
> would
> require something with stdint.h or inttypes.h.

Why the complications?  Just use GCC_HEADER_STDINT in both gcc and gold and
be done with it.  If the intention is for gold to support platforms beyond
GNU/Linux with ELF, it will run into the need sooner or later anyway.

Rainer


-- 


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

[Bug libstdc++/41645] Massive failures in parallel test mode

[chris at bubblescope dot net]

--- Comment #4 from chris at bubblescope dot net  2009-10-09 13:21 ---
I have confirmed that after compiling with 'make check-parallel', the code:

#include 

int main(void)
{ string s; s = "X"; }

Fails when compiled with: 

/gccsvn/bin/g++ test.cc libtestc++.a -fopenmp

Fails with the same error message.

I wonder if somehow this is connected to:
http://www.cocoabuilder.com/archive/message/cocoa/2009/9/17/245285, which
suggests on snow leopard the standard system library is built differently, with
_GLIBCXX_FULLY_DYNAMIC_STRING enabled. I would assume the system library
shouldn't be used at all however.


-- 


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

[Bug libstdc++/41645] Massive failures in parallel test mode

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-10-09 12:59 
---
... for sure the libtestc++.a thing is *very* mysterious...


-- 


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

[Bug lto/40790] plugin-api.h unconditionally includes stdint.h

[joseph at codesourcery dot com]

--- Comment #12 from joseph at codesourcery dot com  2009-10-09 12:58 
---
Subject: Re:  plugin-api.h unconditionally includes stdint.h

On Fri, 9 Oct 2009, ro at techfak dot uni-bielefeld dot de wrote:

> --- Comment #10 from ro at techfak dot uni-bielefeld dot de  2009-10-09 
> 12:42 ---
> Subject: Re:  plugin-api.h unconditionally includes stdint.h
> 
> > --- Comment #9 from espindola at google dot com  2009-10-08 18:20 
> > ---
> [...]
> > The only thing the compiler should need the plugin-api.h for is the enum 
> > ld_plugin_symbol_resolution. If we split plugin-api.h in two, we would be 
> > able
> > to compile gcc itself without stdint.h.
> > 
> > The problem with this approach is that the lto plugin would still fail to 
> > build
> > in a system without stdint.h. Is it OK to have optional features like the 
> > gold
> > plugin not supported in systems like "Tru64 UNIX V4.0F"?
> 
> That would be no problem since AFAIK gold only supports ELF targets by
> design, and Tru64 UNIX uses ECOFF.  Not even GNU ld supports that anymore
> (or the support has bitrotten to the point of being unusable).

gold supports non-ELF hosts (or will once Andrew Pinski's MinGW host 
patches are in), and in due course should support plugins on such hosts.  
(I've no idea whether Tru64 has a dynamic loading interface making plugins 
on such a host possible at all, but if it has such an interface there is 
no reason in principle against someone adding support for plugins for a 
cross compiler and linker from Tru64 to an ELF target.)


-- 


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

[Bug lto/40790] plugin-api.h unconditionally includes stdint.h

[espindola at google dot com]

--- Comment #11 from espindola at google dot com  2009-10-09 12:58 ---
> Why all those contortions if there seems to be an easy way out: just use
> the GCC_HEADER_STDINT macro from config/m4 and include the resulting (e.g.)
> gstdint.h instead of stdint.h?

Interesting. One problem is that this header is also used on gold. Maybe we
could do

#ifdef HAVE_STDINT_H
#include 
#elif HAVE_INTTYPES_H
#include 
#else
#include "gstdint.h"
#endif

That way gcc would build on anything thanks to GCC_HEADER_STDINT and gold would
require something with stdint.h or inttypes.h.

> Rainer
> 

Thanks!
Rafael


-- 


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

[Bug libstdc++/41645] Massive failures in parallel test mode

[chris at bubblescope dot net]

--- Comment #2 from chris at bubblescope dot net  2009-10-09 12:57 ---
I shall try to track it down -- it wouldn't suprise me if this is a snow
leopard bug, as there has been a few issues with the default system compiler
switching from 32-bit to 64-bit.


-- 

chris at bubblescope dot net changed:

   What|Removed |Added

 CC||chris at bubblescope dot net


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

[Bug tree-optimization/40071] ICE (aliasing assert) in vectorizable_store at tree-vect-stmts.c:3117

[ebotcazou at gcc dot gnu dot org]

--- Comment #12 from ebotcazou at gcc dot gnu dot org  2009-10-09 12:53 
---
This particular ICE shouldn't occur anymore.  However, there is a couple of
ACATS failures at -O3 on x86 again related to vectorization:

=== acats tests ===
FAIL:   cxa4016
FAIL:   cxb3007

=== acats Summary ===
# of expected passes2313
# of unexpected failures2


It's apparently SLP failing to clean up EH edges.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug libstdc++/41645] Massive failures in parallel test mode

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-10-09 12:51 
---
Can you sat when did this problem start? Because I'm running again the tests on
x86_64-linux and everything seems in good shape so far (in 23_containers now),
thus I can't confirm it, the problem seems definitely target-dependent...


-- 


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

[Bug tree-optimization/40071] ICE (aliasing assert) in vectorizable_store at tree-vect-stmts.c:3117

[ebotcazou at gcc dot gnu dot org]

--- Comment #11 from ebotcazou at gcc dot gnu dot org  2009-10-09 12:45 
---
Subject: Bug 40071

Author: ebotcazou
Date: Fri Oct  9 12:44:59 2009
New Revision: 152585

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152585
Log:
PR tree-optimization/40071
* tree-vect-data-refs.c (vect_create_data_ref_ptr): Build a ref-all
pointer if the original data reference doesn't conflict with the
created vector data reference.  Fix long line.

Added:
trunk/gcc/testsuite/gnat.dg/opt3.adb
trunk/gcc/testsuite/gnat.dg/opt3_pkg.ads
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c


-- 


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

[Bug lto/40790] plugin-api.h unconditionally includes stdint.h

[ro at techfak dot uni-bielefeld dot de]

--- Comment #10 from ro at techfak dot uni-bielefeld dot de  2009-10-09 
12:42 ---
Subject: Re:  plugin-api.h unconditionally includes stdint.h

> --- Comment #9 from espindola at google dot com  2009-10-08 18:20 ---
[...]
> The only thing the compiler should need the plugin-api.h for is the enum 
> ld_plugin_symbol_resolution. If we split plugin-api.h in two, we would be able
> to compile gcc itself without stdint.h.
> 
> The problem with this approach is that the lto plugin would still fail to 
> build
> in a system without stdint.h. Is it OK to have optional features like the gold
> plugin not supported in systems like "Tru64 UNIX V4.0F"?

That would be no problem since AFAIK gold only supports ELF targets by
design, and Tru64 UNIX uses ECOFF.  Not even GNU ld supports that anymore
(or the support has bitrotten to the point of being unusable).

> Yet another possibility would be to change the build system so that we always
> build the lto plugin with xgcc (in addition to the plugin-api.h split). No 
> idea
> how hard this is.

Why all those contortions if there seems to be an easy way out: just use
the GCC_HEADER_STDINT macro from config/m4 and include the resulting (e.g.)
gstdint.h instead of stdint.h?

Rainer


-- 


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

[Bug target/41644] -minimal-toc not helping for toc section exceeding 64k

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-10-09 12:20 ---
For generated code it is obviously best to adjust the generator so that it
doesn't generate so big translation units, instead emits more smaller files, or
puts all the string literal addresses into an array and uses that array instead
of directly.


-- 


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

[Bug fortran/41618] [OOP] accepts-invalid with CLASS pointer component

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2009-10-09 12:17 ---
The problem here is that the error check comes too late: It should happen
already before the call to encapsulate_class_symbol.

This is effectively fixed by the patch for PR41629:

http://gcc.gnu.org/ml/fortran/2009-10/msg00088.html


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-10-09 12:17:50
   date||


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

[Bug libstdc++/41645] New: Massive failures in parallel test mode

[chris at bubblescope dot net]

In 'libstdc++-v3', type 'make check-parallel' and a huge number of tests fail.

Some of these are expected, in particular several in 25_algorithm, to do with
lack of c++0x support, but most of the failures seem to be related to a string
problem.

Taking one example
(testsuite/26_numerics/complex/inserters_extractors/char/1.cc), I get the
error:

1.exe(21140) malloc: *** error for object 0x100019ae0: pointer being freed was
not allocated
*** set a breakpoint in malloc_error_break to debug

And backtrace:

#0  0x7fff879fdb91 in malloc_error_break ()
#1  0x7fff87927083 in free ()
#2  0x000100094bfa in std::basic_stringbuf,
std::allocator >::overflow (this=0x7fff5fbff428, __c=40) at
bits/basic_string.h:236
#3  0x00010009911c in std::basic_streambuf
>::xsputn (this=0x7fff5fbff428, __s=, __n=13) at bits/streambuf.tcc:97
#4  0x00010008f4b5 in std::__ostream_insert >
(__o...@0x7fff5fbff420, __s=, __n=13) at streambuf:427
#5  0x000100053aac in std::operator<< 
> (__...@0x7fff5fbff420, __x=) at bits/basic_string.h:2539
#6  0x0001521d in test01 ()
#7  0x00015cd8 in main ()

All the errors seem to be similarly related to string. The standard 'make
check' works fine, as does the compiler in general use. 

This problem seems to be connected to libtestc++.a (If I remove it when
compiling the test, the result works fine), but I am not sufficiently expert on
linking to figure out exactly what is going wrong.


-- 
   Summary: Massive failures in parallel test mode
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
 GCC build triplet: x86_64-apple-darwin10.0.0
  GCC host triplet: x86_64-apple-darwin10.0.0
GCC target triplet: x86_64-apple-darwin10.0.0


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

[Bug fortran/38936] F2003: ASSOCIATE construct / improved SELECT TYPE (a=>expr)

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-10-09 12:08 ---
  SELECT TYPE (name => expr)
and
  ASSOCIATE (name1 => expr1, name2 => expr2)
have similar syntax and issues. SELECT TYPE (name=>expr) is already implemented
(via creating a new pointer variable), but it has some issues.

The idea is to replace the expression - at least when it is definable - by the
variable (be it in resolve.c or in trans*.c).
Cf. also http://gcc.gnu.org/ml/fortran/2009-10/msg00075.html

Maybe one should do something alike for TYPE IS() and (when implemented) CLASS
IS(), cf. http://gcc.gnu.org/ml/fortran/2009-10/msg00075.html


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|F2003: ASSOCIATE construct  |F2003: ASSOCIATE construct /
   ||improved SELECT TYPE
   ||(a=>expr)


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

[Bug driver/41637] testsuite (-flto/-fwhopr) leaves does not clean up in /tmp

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-10-09 11:55 ---
Mine.  I have a partial patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-10-09 09:01:10 |2009-10-09 11:55:14
   date||


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

[Bug target/41644] -minimal-toc not helping for toc section exceeding 64k

[sathishpy at gmail dot com]

--- Comment #3 from sathishpy at gmail dot com  2009-10-09 11:22 ---
I tried the same program with -m32 and it works fine. I have also tried it for
10 times bigger time file (10 string constants and 1 functions) without
using -mminimal-toc, so it looks like some issue with gcc only when using -m64. 


-- 


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

[Bug target/41644] -minimal-toc not helping for toc section exceeding 64k

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-10-09 10:54 ---
Even though PR 34708 is similar, it is talking about the inliner creating a
huge amount of TOC references.  The problem here is even more serious.  You
have a huge TOC references in your source to begin with.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |target


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

[Bug c/41644] -minimal-toc not helping for toc section exceeding 64k

[sathishpy at gmail dot com]

--- Comment #1 from sathishpy at gmail dot com  2009-10-09 10:51 ---
Created an attachment (id=18760)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18760&action=view)
Test program


-- 


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

[Bug c/41644] New: -minimal-toc not helping for toc section exceeding 64k

[sathishpy at gmail dot com]

I have an in-house debugger which uses some auto generated files having too
many string constants. Compiling this (with gcc 4.3) always fails with the
error 

/tmp/ccrzE6fi.s: Assembler messages:
/tmp/ccrzE6fi.s:95429: Warning: TOC section size exceeds 64k
/tmp/ccCSriww.o:(.text+0x22672): relocation truncated to fit: R_PPC64_TOC16_DS
against `.toc'+1
/tmp/ccCSriww.o:(.text+0x2267e): relocation truncated to fit: R_PPC64_TOC16_DS
against `.toc'+10008
/tmp/ccCSriww.o:(.text+0x2268a): relocation truncated to fit: R_PPC64_TOC16_DS
against `.toc'+10010
/tmp/ccCSriww.o:(.text+0x22696): relocation truncated to fit: R_PPC64_TOC16_DS
against `.toc'+10018
/tmp/ccCSriww.o:(.text+0x226a2): relocation truncated to fit: R_PPC64_TOC16_DS
against `.toc'+10020
/tmp/ccCSriww.o:(.text+0x226ae): relocation truncated to fit: R_PPC64_TOC16_DS
against `.toc'+10028
/tmp/ccCSriww.o:(.text+0x226ba): relocation truncated to fit: R_PPC64_TOC16_DS
against `.toc'+10030
/tmp/ccCSriww.o:(.text+0x226c6): relocation truncated to fit: R_PPC64_TOC16_DS
against `.toc'+10038
/tmp/ccCSriww.o:(.text+0x22706): relocation truncated to fit: R_PPC64_TOC16_DS
against `.toc'+10040
/tmp/ccCSriww.o:(.text+0x22712): relocation truncated to fit: R_PPC64_TOC16_DS
against `.toc'+10048
/tmp/ccCSriww.o:(.text+0x2271e): additional relocation overflows omitted from
the output
collect2: ld returned 1 exit status

I have tried using -mminimal-toc and other options, but –minimal-toc is giving
a different set of errors like

/tmp/cc4SUbmt.s:97184: Error: operand out of range (0x9918 is not
between 0x8000 and 0x7ffc)
/tmp/cc4SUbmt.s:97187: Error: operand out of range (0x9920 is not
between 0x8000 and 0x7ffc)
/tmp/cc4SUbmt.s:97190: Error: operand out of range (0x9928 is not
between 0x8000 and 0x7ffc)
/tmp/cc4SUbmt.s:97193: Error: operand out of range (0x9930 is not
between 0x8000 and 0x7ffc)
/tmp/cc4SUbmt.s:97196: Error: operand out of range (0x9938 is not
between 0x8000 and 0x7ffc)

A similar issue was reported in gcc bugzilla bug 34708 (for gcc 4.3), for which
the resolution says fixed in mainstream. I have tried the same with gcc 4.4.1,
but that didn’t help either. 

I have attached a test program similar to my application to reproduce
this[compiled as: gcc -m64 -o toctest [-mno-fp-in-toc -mno-sum-in-toc
|-mminimal-toc]  toctest.c]


-- 
   Summary: -minimal-toc not helping for toc section exceeding 64k
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sathishpy at gmail dot com


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

[Bug tree-optimization/41643] ICE (segmentation fault) for SPEC CPU2000's 176.gcc when using -fno-tree-dce

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-10-09 10:49 ---
Doesn't happen on trunk.  But, confirmed.

../../gcc44-g/gcc/cc1 -quiet bug.i -O2 -fno-tree-dce
bug.i: In function 'f':
bug.i:5: error: missing PHI def
add_acc.0_10 = PHI <0(0), (5)>

bug.i:5: error: missing PHI def
x_8 = PHI 

bug.i:5: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

After the tail-recursion pass.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.4.1
  Known to work||4.5.0
   Last reconfirmed|-00-00 00:00:00 |2009-10-09 10:49:19
   date||


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

[Bug target/41642] Cross-compiling error on cris os while building openwrt

[hp at gcc dot gnu dot org]

--- Comment #3 from hp at gcc dot gnu dot org  2009-10-09 10:15 ---
I think this is a duplicate.  I guess I'll have to go fix it finally, sorry for
the delay.


-- 


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

[Bug target/41642] Cross-compiling error on cris os while building openwrt

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-10-09 10:04 ---
Can you provide the preprocessed source as requested by
http://gcc.gnu.org/bugs.html ?


-- 


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

[Bug fortran/41640] [Regression] Compilation failure with "-g": bad assembler?

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-10-09 10:01 ---
>says your gas supports this.

Easy this is a binary build with a newer binutils than you have.

So closing as invalid.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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