[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

[howarth at nitro dot med.uc.edu]

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

--- Comment #21 from Jack Howarth  2011-03-14 
06:10:09 UTC ---
We also need to scratch the section of http://gcc.gnu.org/gcc-4.6/changes.html
under Darwin/Mac OS X which says...

LTO-support.
Darwin has benefited from ongoing work on LTO; support for this is now stable
and enabled by default.

[Bug c++/47200] [C++0x] ICE: in adjust_temp_type, at cp/semantics.c:5821 with missing definition of constexpr function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Jason Merrill  2011-03-14 
05:09:47 UTC ---
Fixed.

[Bug c++/44909] [C++0x] Copy constructors implicitly deleted

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #10 from Jason Merrill  2011-03-14 
05:09:25 UTC ---
Closing.

[Bug c++/47125] [4.5/4.6 Regression] ICE occurs in combination with partial specialization and invalid template function.

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Jason Merrill  2011-03-14 
05:02:08 UTC ---
Fixed.

[Bug libfortran/48030] Implement read_x using fbuf_getc

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.03.14 03:29:30
 AssignedTo|unassigned at gcc dot   |jvdelisle at gcc dot
   |gnu.org |gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Jerry DeLisle  2011-03-14 
03:29:30 UTC ---
Created attachment 23647
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23647
Preliminary Patch

Here is a preliminary patch that has been regression tested OK. Holding for 4.7

[Bug lto/48108] lto should be containerized in a single mach-o section on darwin

[mikestump at comcast dot net]

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

--- Comment #2 from Mike Stump  2011-03-14 
03:13:27 UTC ---
Another fix might be to have pure elf .o files...  ld I think will read elf .o
files...  [s]   Don't tell anyone I said that.  If not, we might be able to
get Apple to do that.  This might then require an FSF binutils.

[Bug lto/48108] lto should be containerized in a single mach-o section on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #1 from Jack Howarth  2011-03-14 
03:10:24 UTC ---
Note that LTO was disabled for gcc 4.6.0 due to the inability of end-users to
obtain an appropriate Xcode 3.2.5 now that the broken Xcode 3.2.6/4.0 have been
released.

[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

[mikestump at comcast dot net]

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

--- Comment #20 from Mike Stump  2011-03-14 
03:09:08 UTC ---
I'm ambivalent.  If people developing or following would like one, feel free to
create one.  Depending on how safe it is, we could put it in sooner, and by
that time, we'd need one.

[Bug lto/48108] New: lto should be containerized in a single mach-o section on darwin

[howarth at nitro dot med.uc.edu]

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

   Summary: lto should be containerized in a single mach-o section
on darwin
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


The LTO support on darwin has been disabled...

Author: mrs
Date: Mon Mar 14 02:47:49 2011
New Revision: 170929

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170929
Log:
2011-03-13  Jack Howarth  

PR lto/48086
* configure.ac: Disable LTO on darwin due to an assembler change in
Xcode 3.2.6/4.0 that limits the total number of sections/segments to
under 256.
* configure: Regenerate.

Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac

due to the mishandling of , possible assembler bug
exposed by LTO, by the Apple assembler developer where a solid 255 limit has
been now imposed on all the sections= possible in a mach-o object file. This
breaks the current implementation in gcc/lto/lto-object.c which relied on the
ability to have an unlimited number of symbol-less GNU_LTO sections at the end
of the object file.
   The darwin LTO support in  gcc/lto/lto-object.c  and gcc/config/darwin.c
needs to be written to containerize all of these GNU_LTO sections into a single
mach-o section. Hopefully this can be done without having to resort to an elf
container, which would introduce an undesired dependency on libelf for FSF gcc
on darwin.

[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

[howarth at nitro dot med.uc.edu]

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

--- Comment #19 from Jack Howarth  2011-03-14 
02:57:50 UTC ---
Should I create a new PR for following the progress of the re-implementation of
LTO on darwin?

[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

[mrs at gcc dot gnu.org]

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

m...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mrs at gcc dot gnu.org
 Resolution||FIXED

--- Comment #18 from mrs at gcc dot gnu.org  2011-03-14 
02:54:37 UTC ---
Fixed.

[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

[mrs at gcc dot gnu.org]

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

--- Comment #17 from mrs at gcc dot gnu.org  2011-03-14 
02:47:53 UTC ---
Author: mrs
Date: Mon Mar 14 02:47:49 2011
New Revision: 170929

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170929
Log:
2011-03-13  Jack Howarth  

PR lto/48086
* configure.ac: Disable LTO on darwin due to an assembler change in
Xcode 3.2.6/4.0 that limits the total number of sections/segments to
under 256.
* configure: Regenerate.

Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac

[Bug bootstrap/42566] Bootstrap fails in stage3 building the libstdc++ PCH

[3dw4rd at verizon dot net]

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

--- Comment #12 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2011-03-14 
02:18:20 UTC ---
I tried to test this but I can't get to it because now I'm stuck with a
bootstrap compare bug.

Actually, if the object file comparison happens after the O2ggnu++0x.gch build
I would say cross this one out.

Ed

[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

[howarth at nitro dot med.uc.edu]

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

--- Comment #16 from Jack Howarth  2011-03-13 
22:45:57 UTC ---
Actually the situation with Xcode 3.2.5 is pretty grim as well. Currently only
Xcode 3.2.2 is available for download from connect.apple.com. So people needing
to do new installs are trapped at the release since Software Update will only
offer to take you to Xcode 3.2.6. This also that it will be trivial for a user
currently on Xcode 3.2.5 to accidentally, via Software Update, take their
machine to Xcode 3.2.6 and not be able to get back to 3.2.5. Perhaps we should
just disable lto again for gcc 4.6.0.

[Bug c++/48107] New: [C++0x] no explicit conversion from scoped enumeration type to bool

[redi at gcc dot gnu.org]

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

   Summary: [C++0x] no explicit conversion from scoped enumeration
type to bool
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org


4.4, 4.5 and 4.6 all reject this code

enum class E { };

void f(E e) {
  static_cast(e);
}

e.C:4: error: invalid operands of types ‘E’ and ‘int’ to binary ‘operator!=’

[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

[howarth at nitro dot med.uc.edu]

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

--- Comment #15 from Jack Howarth  2011-03-13 
21:54:17 UTC ---
FYI, it it comes down to having a dependency on libelf or heavily lobbying
Apple to fix the broke change made to the assembler in Xcode 4.0.1 and 4.1, I
would go with the second option. After all, they currently aren't properly
honoring their own documented mach-o specifications and who knows what grief
this change will cause for other software developers who have relied on this
behavior.

[Bug c++/48106] New: [C++0x] ICE with scoped enum with fixed underlying type

[redi at gcc dot gnu.org]

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

   Summary: [C++0x] ICE with scoped enum with fixed underlying
type
   Product: gcc
   Version: 4.4.6
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org


enum class E : char
{
  e
};

bool operator&(E e, char m)
{
  return static_cast(e) & m;
}


Program received signal SIGSEGV, Segmentation fault.
c_common_signed_or_unsigned_type (unsignedp=0, type=0x0) at
/home/redi/src/gcc/gcc-4.x/gcc/c-family/c-common.c:3010
3010  type1 = TYPE_MAIN_VARIANT (type);
(gdb) p type
$1 = (union tree_node *) 0x0
(gdb) bt 10
#0  c_common_signed_or_unsigned_type (unsignedp=0, type=0x0) at
/home/redi/src/gcc/gcc-4.x/gcc/c-family/c-common.c:3010
#1  0x006460ac in shorten_binary_op (result_type=0x7203c498,
op0=, op1=0x72029930, bitwise=1 '\001')
at /home/redi/src/gcc/gcc-4.x/gcc/c-family/c-common.c:1840
#2  0x005adc2c in cp_build_binary_op (location=1016, code=BIT_AND_EXPR,
orig_op0=0x72029900, orig_op1=0x7202f990, complain=3)
at /home/redi/src/gcc/gcc-4.x/gcc/cp/typeck.c:4374
#3  0x004bd546 in build_new_op (code=BIT_AND_EXPR, flags=3,
arg1=0x72029900, arg2=0x7202f990, arg3=0x0, overloaded_p=0x7fffd6af
"", 
complain=3) at /home/redi/src/gcc/gcc-4.x/gcc/cp/call.c:4931
#4  0x005a03b5 in build_x_binary_op (code=BIT_AND_EXPR,
arg1=0x72029900, arg1_code=ERROR_MARK, arg2=0x7202f990,
arg2_code=ERROR_MARK, 
overloaded_p=, complain=3) at
/home/redi/src/gcc/gcc-4.x/gcc/cp/typeck.c:3508
#5  0x00585e9d in cp_parser_binary_expression (parser=0x71f4e268,
cast_p=, no_toplevel_fold_p=0 '\000', 
prec=PREC_NOT_OPERATOR, pidk=) at
/home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:6939
#6  0x005861b3 in cp_parser_assignment_expression
(parser=0x71f4e268, cast_p=0 '\000', pidk=0x0)
at /home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:7044
#7  0x0058654a in cp_parser_expression (parser=0x71f4e268,
cast_p=, pidk=0x0)
at /home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:7190
#8  0x005791de in cp_parser_jump_statement (parser=0x71f4e268,
in_statement_expr=0x0, in_compound=1 '\001', if_p=)
at /home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:9196
#9  cp_parser_statement (parser=0x71f4e268, in_statement_expr=0x0,
in_compound=1 '\001', if_p=)
at /home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:8097
(More stack frames follow...)


The stack trace is from 4.6.0 but 4.4 and 4.5 fail in the same way

[Bug target/43700] [4.4/4.5/4.6 Regression] global register variables defect

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  2011-03-13 
21:09:40 UTC ---
4.4/4.5/4.6 Regression aren't P1s, we've shipped several GCC releases with that
bug, why suddenly it should be a blocker?

[Bug fortran/48066] [4.3/4.4/4.5 Regression] Segfault with SUM of zero-sized array

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #14 from Thomas Koenig  2011-03-13 
20:58:46 UTC ---
Backported to 4.5.

Closing.

[Bug fortran/48066] [4.3/4.4/4.5 Regression] Segfault with SUM of zero-sized array

[tkoenig at gcc dot gnu.org]

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

--- Comment #13 from Thomas Koenig  2011-03-13 
20:57:53 UTC ---
Author: tkoenig
Date: Sun Mar 13 20:57:49 2011
New Revision: 170924

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170924
Log:
2011-03-13  Thomas Koenig  

PR libfortran/48066
Backport from trunk
* m4/ifunction.m4:  If return array is empty, return.
* m4/ifunction_logical.m4:  Likewise.
* generated/all_l16.c: Regenerated.
* generated/all_l1.c: Regenerated.
* generated/all_l2.c: Regenerated.
* generated/all_l4.c: Regenerated.
* generated/all_l8.c: Regenerated.
* generated/any_l16.c: Regenerated.
* generated/any_l1.c: Regenerated.
* generated/any_l2.c: Regenerated.
* generated/any_l4.c: Regenerated.
* generated/any_l8.c: Regenerated.
* generated/count_16_l.c: Regenerated.
* generated/count_1_l.c: Regenerated.
* generated/count_2_l.c: Regenerated.
* generated/count_4_l.c: Regenerated.
* generated/count_8_l.c: Regenerated.
* generated/maxloc1_16_i16.c: Regenerated.
* generated/maxloc1_16_i1.c: Regenerated.
* generated/maxloc1_16_i2.c: Regenerated.
* generated/maxloc1_16_i4.c: Regenerated.
* generated/maxloc1_16_i8.c: Regenerated.
* generated/maxloc1_16_r10.c: Regenerated.
* generated/maxloc1_16_r16.c: Regenerated.
* generated/maxloc1_16_r4.c: Regenerated.
* generated/maxloc1_16_r8.c: Regenerated.
* generated/maxloc1_4_i16.c: Regenerated.
* generated/maxloc1_4_i1.c: Regenerated.
* generated/maxloc1_4_i2.c: Regenerated.
* generated/maxloc1_4_i4.c: Regenerated.
* generated/maxloc1_4_i8.c: Regenerated.
* generated/maxloc1_4_r10.c: Regenerated.
* generated/maxloc1_4_r16.c: Regenerated.
* generated/maxloc1_4_r4.c: Regenerated.
* generated/maxloc1_4_r8.c: Regenerated.
* generated/maxloc1_8_i16.c: Regenerated.
* generated/maxloc1_8_i1.c: Regenerated.
* generated/maxloc1_8_i2.c: Regenerated.
* generated/maxloc1_8_i4.c: Regenerated.
* generated/maxloc1_8_i8.c: Regenerated.
* generated/maxloc1_8_r10.c: Regenerated.
* generated/maxloc1_8_r16.c: Regenerated.
* generated/maxloc1_8_r4.c: Regenerated.
* generated/maxloc1_8_r8.c: Regenerated.
* generated/maxval_i16.c: Regenerated.
* generated/maxval_i1.c: Regenerated.
* generated/maxval_i2.c: Regenerated.
* generated/maxval_i4.c: Regenerated.
* generated/maxval_i8.c: Regenerated.
* generated/maxval_r10.c: Regenerated.
* generated/maxval_r16.c: Regenerated.
* generated/maxval_r4.c: Regenerated.
* generated/maxval_r8.c: Regenerated.
* generated/minloc1_16_i16.c: Regenerated.
* generated/minloc1_16_i1.c: Regenerated.
* generated/minloc1_16_i2.c: Regenerated.
* generated/minloc1_16_i4.c: Regenerated.
* generated/minloc1_16_i8.c: Regenerated.
* generated/minloc1_16_r10.c: Regenerated.
* generated/minloc1_16_r16.c: Regenerated.
* generated/minloc1_16_r4.c: Regenerated.
* generated/minloc1_16_r8.c: Regenerated.
* generated/minloc1_4_i16.c: Regenerated.
* generated/minloc1_4_i1.c: Regenerated.
* generated/minloc1_4_i2.c: Regenerated.
* generated/minloc1_4_i4.c: Regenerated.
* generated/minloc1_4_i8.c: Regenerated.
* generated/minloc1_4_r10.c: Regenerated.
* generated/minloc1_4_r16.c: Regenerated.
* generated/minloc1_4_r4.c: Regenerated.
* generated/minloc1_4_r8.c: Regenerated.
* generated/minloc1_8_i16.c: Regenerated.
* generated/minloc1_8_i1.c: Regenerated.
* generated/minloc1_8_i2.c: Regenerated.
* generated/minloc1_8_i4.c: Regenerated.
* generated/minloc1_8_i8.c: Regenerated.
* generated/minloc1_8_r10.c: Regenerated.
* generated/minloc1_8_r16.c: Regenerated.
* generated/minloc1_8_r4.c: Regenerated.
* generated/minloc1_8_r8.c: Regenerated.
* generated/minval_i16.c: Regenerated.
* generated/minval_i1.c: Regenerated.
* generated/minval_i2.c: Regenerated.
* generated/minval_i4.c: Regenerated.
* generated/minval_i8.c: Regenerated.
* generated/minval_r10.c: Regenerated.
* generated/minval_r16.c: Regenerated.
* generated/minval_r4.c: Regenerated.
* generated/minval_r8.c: Regenerated.
* generated/product_c10.c: Regenerated.
* generated/product_c16.c: Regenerated.
* generated/product_c4.c: Regenerated.
* generated/product_c8.c: Regenerated.
* generated/product_i16.c: Regenerated.
* generated/product_i1.c: Regenerated.
* generated/product_i2.c: Regenerated.
* generated/product_i4.c: Regenerated.
* generated/product_i8.c: Regenerated.
* generated/product_r10.c: Regenerated.
* generated/product_r16.c: Regenerated.
* generated/product_r4.c: Regenerated.
* generated/product_r8.c: Regenerated.
* generated/sum_c10.c: Regenerated.
* generated/sum_c16.c: Regenerated.
* generated/sum_c4.c: Regenerated.
* generated/sum_c8.c: Regenerated.
* generated/su

[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

[iains at gcc dot gnu.org]

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

--- Comment #14 from Iain Sandoe  2011-03-13 20:54:03 
UTC ---
(In reply to comment #13)
> Alright, multiple segments will not work. Or even if they do, it is another
> solution that may or may not work in the future depending on the whims of
> Apple.
> 
> So, a rewrite it will have to be, then.

the response from Nick is a confirmation of both points:

"The suggestion of using different segment names will not work.  Segments
aren't really used in mach-o object files.   All mach-o object files have
exactly one LC_SEGMENT load command.  It is final linked images that support
multiple  LC_SEGMENT load commands.

It is possible to fix this in Xcode 4.x, but I think a solution that just uses
one section for all gcc LTO data (and have your own sub-section scheme) will
work with all darwin assembler versions."

==

I can only hope that the simple_object interface in libiberty will make this
possible without introducing a dependency on libelf (which seems a little OTT
for this relatively small requirement).

[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

[steven at gcc dot gnu.org]

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

--- Comment #13 from Steven Bosscher  2011-03-13 
20:41:12 UTC ---
Alright, multiple segments will not work. Or even if they do, it is another
solution that may or may not work in the future depending on the whims of
Apple.

So, a rewrite it will have to be, then.

[Bug c/48090] gcc 4.5.2 miscompilation when building on arm

[arnaud.pat...@rtp-net.org]

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

--- Comment #9 from arnaud patard  2011-03-13 
20:40:27 UTC ---
I confirm that backporting r159644 and r159683 make things work. From comment
8, I guess that the bug is still there and that one can still hit it sooner or
later, right  ? (btw, amazing job)

[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

[iains at gcc dot gnu.org]

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

--- Comment #12 from Iain Sandoe  2011-03-13 20:32:56 
UTC ---
(In reply to comment #11)
> (In reply to comment #10)
> > The easiest way to fix this is maybe to just have more than one GNU_LTO
> > segment. AFAIU the limit of 255 sections is a limit per segment. It is not
> > difficult to have multiple GNU_LTO segments, I could even hack that in 
> > before
> > GCC 4.6.

hmmm. maybe not .. re-reading:

n_sect 
An integer specifying the number of the section that this symbol can be found
in, or NO_SECT if the 
symbol is not to be found in any section of this image.  The sections are
contiguously numbered across 
segments, starting from 1, according to the order they appear in the LC_SEGMENT
load commands. 

contiguously numbered across segments; seems to indicate that the section count
is per file - not per segment.

[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe  2011-03-13 20:19:31 
UTC ---
(In reply to comment #10)
> The easiest way to fix this is maybe to just have more than one GNU_LTO
> segment. AFAIU the limit of 255 sections is a limit per segment. It is not
> difficult to have multiple GNU_LTO segments, I could even hack that in before
> GCC 4.6.

I'm sure that someone who as already updated would be willing to test a
proposed solution ..  (Jack, Dominique...).  
... my systems are going to remain at XCode 3.2.5 at present ...

In the process of re-reading the Mach-o doc.  I haven't found any reason (other
than the nlist struct) to see a limitation - e.g. nsects is uint32_t in the
segment header - so no problem there.

===

(speculation) I guess it would depend on how 'as' detects the perceived
problem.

Since an intermediate object puts all sections into single anonymous segment,
if the error is reported on a simple section header count, increasing the
number of segments won't make any difference (pessimistic assessment).  

The sources don't seem to have been released so far, so can't look there for an
answer (yet).

> Confirming with Apple and having an answer on public record would be
> recommended.

Will put this into the melting pot.

[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

[steven at gcc dot gnu.org]

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

--- Comment #10 from Steven Bosscher  2011-03-13 
19:48:41 UTC ---
The easiest way to fix this is maybe to just have more than one GNU_LTO
segment. AFAIU the limit of 255 sections is a limit per segment. It is not
difficult to have multiple GNU_LTO segments, I could even hack that in before
GCC 4.6.

Ian, what do you think?

Confirming with Apple and having an answer on public record would be
recommended.

[Bug c/48090] gcc 4.5.2 miscompilation when building on arm

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||kazu at gcc dot gnu.org

--- Comment #8 from Mikael Pettersson  2011-03-13 
19:32:46 UTC ---
The test case broke due to the combination of r154181 and r147087.  r147087 is
Kazu's "expmed.c: Improve multiplication by more constants" patch, see
.

Backporting either of these to 4.4.5 doesn't break the test case, but when both
are backported at the same time it breaks.  And reverting r147087 from current
4.5 branch unbreaks the test case.

[Bug bootstrap/48102] [4.6 Regression] Bootstrap failure: error: macro "build_cloog_prog" requires 4 arguments, but only 3 given

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug bootstrap/48102] [4.6 Regression] Bootstrap failure: error: macro "build_cloog_prog" requires 4 arguments, but only 3 given

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed|2011-03-13 17:51:50 |2011.03.13 18:12:12
 CC||steven at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #4 from Steven Bosscher  2011-03-13 
18:12:12 UTC ---
Redo Joseph's changes: confirmed (NEW) and P1.
Dominique, please be more careful next time.

[Bug bootstrap/48102] [4.6 Regression] Bootstrap failure: error: macro "build_cloog_prog" requires 4 arguments, but only 3 given

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P1  |P3
 Status|NEW |UNCONFIRMED
   Target Milestone|4.6.0   |---
 Ever Confirmed|1   |0

--- Comment #3 from Dominique d'Humieres  2011-03-13 
17:56:41 UTC ---
With the patch in comment #1, I hit a second failure at stage 2:

/opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.6w/powerpc-apple-darwin9/include -isystem
/opt/gcc/gcc4.6w/powerpc-apple-darwin9/sys-include-c   -g -O2
-mdynamic-no-pic -gtoggle -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../gcc-4.6-work/gcc -I../../gcc-4.6-work/gcc/.
-I../../gcc-4.6-work/gcc/../include -I../../gcc-4.6-work/gcc/../libcpp/include
-I/sw/include  -I../../gcc-4.6-work/gcc/../libdecnumber
-I../../gcc-4.6-work/gcc/../libdecnumber/dpd -I../libdecnumber  -I/sw/include 
../../gcc-4.6-work/gcc/graphite-clast-to-gimple.c -o graphite-clast-to-gimple.o
../../gcc-4.6-work/gcc/graphite-clast-to-gimple.c: In function
'build_cloog_prog':
../../gcc-4.6-work/gcc/graphite-clast-to-gimple.c:1239:33: error: unused
parameter 'options' [-Werror=unused-parameter]
cc1: all warnings being treated as errors

make[3]: *** [graphite-clast-to-gimple.o] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2

With the following additional patch

--- ../_gcc_clean/gcc/graphite-clast-to-gimple.c2011-03-13
12:03:48.0 +0100
+++ ../gcc-4.6-work/gcc/graphite-clast-to-gimple.c2011-03-13
14:43:34.0 +0100
@@ -1236,7 +1236,7 @@ init_cloog_input_file (int scop_number)

 static void
 build_cloog_prog (scop_p scop, CloogProgram *prog,
-  CloogOptions *options)
+  CloogOptions *options __attribute__((unused)))
 {
   int i;
   int max_nb_loops = scop_max_loop_depth (scop);

I am now at stage 3.

[Bug bootstrap/48102] [4.6 Regression] Bootstrap failure: error: macro "build_cloog_prog" requires 4 arguments, but only 3 given

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Target|powerpc-apple-darwin9   |
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.13 17:51:50
   Host|powerpc-apple-darwin9   |
   Target Milestone|--- |4.6.0
Summary|[4.6 Regression] Bootstrap  |[4.6 Regression] Bootstrap
   |failure for |failure: error: macro
   |powerpc-apple-darwin9:  |"build_cloog_prog" requires
   |error: macro|4 arguments, but only 3
   |"build_cloog_prog" requires |given
   |4 arguments, but only 3 |
   |given   |
 Ever Confirmed|0   |1
  Build|powerpc-apple-darwin9   |

--- Comment #2 from Joseph S. Myers  2011-03-13 
17:51:50 UTC ---
Confirmed, not target-specific.

[Bug fortran/47348] wrong string length with array constructor

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #11 from Paul Thomas  2011-03-13 17:40:13 
UTC ---
(In reply to comment #10)
Fixed on 4.5 and trunk.

Closing

Thanks for the report.

Paul

[Bug fortran/47348] wrong string length with array constructor

[pault at gcc dot gnu.org]

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

--- Comment #10 from Paul Thomas  2011-03-13 17:37:47 
UTC ---
Author: pault
Date: Sun Mar 13 17:37:43 2011
New Revision: 170923

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170923
Log:
2011-03-13  Paul Thomas  

PR fortran/47348
* trans-array.c (get_array_ctor_all_strlen): Move up in file.
(get_array_ctor_var_strlen): Add block dummy and add call to
get_array_ctor_all_strlen instead of giving up on substrings.
Call gcc_unreachable for default case.
(get_array_ctor_strlen): Add extra argument to in call to
get_array_ctor_var_strlen.

2011-03-13  Paul Thomas  

PR fortran/47348
* gfortran.dg/array_constructor_36.f90 : New test.
* gfortran.dg/bounds_check_10.f90 : Change dg-output message to
allow for comparison between different elements of the array
constructor at different levels of optimization.


Added:
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/array_constructor_36.f90
Modified:
branches/gcc-4_5-branch/gcc/fortran/ChangeLog
branches/gcc-4_5-branch/gcc/fortran/trans-array.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mahatma at eu dot by]

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

--- Comment #87 from Dzianis Kahanovich  2011-03-13 
16:56:05 UTC ---
(In reply to comment #85)
> Am I the only one who thinks this bug should be nominated as the first 
> priority
> GCC 4.6.0 bug?

Some lazy people ;) may use global mstackrealign [patch] instead and remind
only if some new package breaks in asm code on mstackrealign. But it is too old
known problem to doubts about it priority.

Really I found first package with mstackrealign problem, exclude gcc/libunwind
- gst-ffmpeg-0.10.11/libavcodec (in Gentoo, may be other similar ebuilds just
filtering sse/cpu options).

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

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.13 15:59:24
 CC||pault at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Paul Thomas  2011-03-13 15:59:24 
UTC ---
This could certainly do with a cleanup.

Confirmed

Paul

[Bug c/48104] aaaaaa

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #1 from Kai Tietz  2011-03-13 15:55:57 
UTC ---
invalid

[Bug fortran/41603] [-fwhole-file] Add diagnostic for assumed-length character function

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||pault at gcc dot gnu.org
 Resolution||WONTFIX

--- Comment #7 from Paul Thomas  2011-03-13 15:54:19 
UTC ---
(In reply to comment #6)
> Just for completeness: The wording in
>   J3/04-007 (p. 259, ll. 38-41; "12.3.2.1 Interface block")
> and in
>   J3/97-007r2 (p. 194, ll. 32-34)
> is effectively the same. Thus there does not seem to be any change in the
> normative text. Assuming that there is none, I think concluding that the note
> still holds in F2003 is likely. I think I follow this line of thought and do
> not hand in an interpretation request.
> 
> If someone does not think so, we can still do so - an IR is only little work
> for us and does also not take so much work in this case for J3/WG5.

Dear Tobias,

I think that this is a WONTFIX.  Please reopen it if you disagree.

Cheers

Paul

[Bug c/48104] New: aaaaaa

[bobby2 at bobmail dot info]

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

   Summary: aa
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bob...@bobmail.info


aa

[Bug fortran/41107] [F03] Proc-pointer components: Fix calling DECL for f2c

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #1 from Paul Thomas  2011-03-13 15:40:47 
UTC ---
Hi Tobias,

A bit more explanation would be good here :-)

Cheers

Paul

[Bug fortran/41083] Implicit typing: Save implicit type for external procedures

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #3 from Paul Thomas  2011-03-13 15:34:27 
UTC ---
(In reply to comment #2)
> Intel (#i552365) pointed out the following, which is part of 11.2 Modules of
> the F2003 spec:
> 
> "If a procedure declared in the scoping unit of a module has an implicit
> interface, it shall be given the EXTERNAL attribute in that scoping unit; if 
> it
> is a function, its type and type parameters shall be explicitly declared in a
> type declaration statement in that scoping unit."
> 
> 
> It seems that the current result is OK and standard conforming. One should
> check that the test cases here are properly rejected (they seem to be) and one
> should re-check the referenced PRs and the mailing-lists links and the
> interpretation request. But presumably, one can close this PR as INVALID.

Dear Tobias,

I think that you are right.  If you have changed your mind in the meanwhile,
please reopen it.

Cheers

Paul

[Bug fortran/41023] Inconsistent error locations for wrong interfaces with overloaded operators

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.13 15:24:42
 CC||pault at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #6 from Paul Thomas  2011-03-13 15:24:42 
UTC ---
This can be confirmed

Paul

[Bug c/48090] gcc 4.5.2 miscompilation when building on arm

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu.org

--- Comment #7 from Mikael Pettersson  2011-03-13 
15:09:36 UTC ---
The miscompilation on 4.5 branch started with r154181, the PR42031 fix; see
.

On the standalone test case, r154181 changed the -march=armv5t -O2 code as
follows:

--- pr48090.s-r154180   2011-03-13 15:39:16.0 +0100
+++ pr48090.s-r154181   2011-03-13 15:43:21.0 +0100
@@ -81,11 +81,9 @@
mov r6, r1
bl  seek_archive
cmp r1, #0
-   mov r3, r0
-   mov r4, r1
blt .L14
-   rsbsr1, r3, #0
-   rsc r2, r4, #0
+   rsbsr1, r0, #0
+   rsc r2, r1, #0
mov r4, r2, asl #9
mov r3, r1, asl #9
orr r4, r4, r1, lsr #23

which breaks the second 'rsc' insn since it now reads the updated r1 value
instead of the original one.

[Bug fortran/39988] F2008: Default initialization, structure constructors, and allocatable components

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.13 15:09:07
 AssignedTo|unassigned at gcc dot   |pault at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Paul Thomas  2011-03-13 15:09:07 
UTC ---
Created attachment 23645
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23645
Un-regtested patch for the PR

Will regtest and submit once trunk is open again.

Paul

[Bug c++/48103] Lambda function incorrect syntax leads to internal compiler error and segfault

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #1 from Jonathan Wakely  2011-03-13 
14:43:32 UTC ---
no ICE with 4.6.0 20110312

[Bug fortran/35913] INTRINISIC vs. host-associated procedures (check conformance)

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #3 from Paul Thomas  2011-03-13 14:34:07 
UTC ---
Tobias,

Nearly two years unconfirmed time to close this one as a WONTFIX?

Cheers

Paul

[Bug c++/48103] New: Lambda function incorrect syntax leads to internal compiler error and segfault

[vlad at lazarenko dot me]

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

   Summary: Lambda function incorrect syntax leads to internal
compiler error and segfault
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: v...@lazarenko.me


Here is a simple code snippet leading to compiler crash:

struct foo {
void say () const {}
};

struct bar {};

template 
void do_work (const T & pred) {
pred (foo ());
pred (bar ());
}

int main () {
do_work ([] (bar & b) { b.say (); });
}

Here is an output (with compilation flags):

$ g++ -std=c++0x -o test ./test.cpp 
./test.cpp: In lambda function:
./test.cpp:14:31: error: 'struct bar' has no member named 'say'
./test.cpp: In function 'void do_work(const T&) [with T =
main()::]':
./test.cpp:14:40:   instantiated from here
./test.cpp:9:5: error: no match for call to '(const main()::)
(foo)'
./test.cpp:14:15: note: candidates are:
./test.cpp:9:5: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

g++'s version:

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.6-20110129/configure --prefix=/opt/local
--build=x86_64-apple-darwin10 --enable-languages=c,c++,objc,obj-c++
--libdir=/opt/local/lib/gcc46 --includedir=/opt/local/include/gcc46
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.6 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-4.6
--with-gxx-include-dir=/opt/local/include/gcc46/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking
--disable-multilib --enable-fully-dynamic-string
Thread model: posix
gcc version 4.6.0 20110129 (experimental) (GCC) 

The operating system is Mac OS X 10.6.6, gcc is installed from Mac Ports 1.9.2.

The code itself is not legitimate, but compiler should not crash. So priority
is minor.
Please let me know if you need more details.

[Bug fortran/46896] [4.3/4.4/4.5/4.6 Regression] Wrong code with transpose(a) passed to subroutine

[pault at gcc dot gnu.org]

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

--- Comment #16 from Paul Thomas  2011-03-13 14:16:25 
UTC ---
(In reply to comment #15)
> Tobias,
> 
> You shame me - I undertook to do something with this one and did not.
> I do not know that the fix is compatible even with 4.5 - I think not.
> I will take a quick look tonight.
> 
> 
> > Feel free to re-open if you think it really should be backported.
> 
> Better still, backport if it is possible :-)
> 
> Thanks
> 
> Paul

15 out of 37 chunks failed to apply to 4.5.  They point to all sorts of
divergences between trunk and 4.5 that I do not have the time to deal with.

I think that the answer is that it is not possible to backport.

Paul

[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream

[paolo.carlini at oracle dot com]

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

--- Comment #12 from Paolo Carlini  2011-03-13 
13:11:38 UTC ---
Ian, I see you are returning to this old issue. Really, today I don't have a
strong opinion, if you are willing to post to the mailing list a patchlet (I
think both std/ostream and bits/ostream.tcc have to be touched + adjusting the
testsuite) outputting "(null)" instead of setting badbit I have no objections
(to be clear, I didn't decide or existing impl defined behavior, thus we
serious reasons to hear the mailing list before applying it). Only, I'm not
sure what we want to do for the "primary" overload,
operator<<(basic_ostream<_CharT, _Traits>&, const _CharT*), maybe just do
nothing, I don't know, really, up to you (and the mailing list, again).

[Bug middle-end/45273] [4.4/4.5/4.6 Regression] The compiler depends on the host double (-fprofile-corection only)

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

  Attachment #23643|0   |1
is obsolete||

--- Comment #6 from Steven Bosscher  2011-03-13 
12:39:51 UTC ---
Created attachment 23644
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23644
Use mpfr in predict.c instead of sreal, and in mcf.c instead of host double

Bootstrapped&tested on x86_64-unknown-linux-gnu. Can be queued for GCC 4.7 if
the Powers That Be agree this is the right approach.

The mcf.c parts can be posted separately for GCC 4.6 if necessary, but I
propose to close this big as WONTFIX for older releases.

[Bug libstdc++/48101] obscure error message with std::set

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-03-13 
12:24:13 UTC ---
Do you have a suggestion for a better error?  We could use a static_assert in
std::allocator to reject const T

As far as I can see, the reason the code is invalid is exactly the reason
given: std::allocator can't be instantiated with const T.   I don't think it's
invalid to default construct a set::set with a const value_type, as long as
don't use std::allocator.

[Bug bootstrap/48102] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: error: macro "build_cloog_prog" requires 4 arguments, but only 3 given

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  2011-03-13 
12:23:47 UTC ---
I am now at stage 2 with the following patch:

--- ../_gcc_clean/gcc/graphite-cloog-compat.h2010-10-01 14:21:41.0
+0200+++ ../gcc-4.6-work/gcc/graphite-cloog-compat.h2011-03-13
12:45:17.0 +0100
@@ -37,8 +37,8 @@ typedef const char *clast_name_p;
 #ifndef CLOOG_ORG

 /* CloogOptions compatibility.  */
-#define build_cloog_prog(SCOP, PROG, OPT, STATE)\
-  build_cloog_prog (SCOP, PROG, STATE)
+/* #define build_cloog_prog(SCOP, PROG, OPT, STATE)\
+  build_cloog_prog (SCOP, PROG, STATE) */
 #define cloog_program_extract_scalars(PROG, SCATT, OPT)\
   cloog_program_extract_scalars (PROG, SCATT)
 #define cloog_program_scatter(PROG, SCATT, OPT)\

[Bug lto/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  2011-03-13 12:13:05 
UTC ---
(In reply to comment #2)
> (a) the first is because LTO has produced two image_info instances with
> different mangled names ...
> 
>  e.g. L_OBJC_ImageInfo.2044 / L_OBJC_ImageInfo.2048
> 
>  this is visible on darwin 9 (although it does not produce an error).

This only applies when -flto is given together with the partitioning algorithm
= none.  
For 1to1 or default, the instances of L_OBJC_ImageInfo are correctly combined
into a single var.

I'm not sure whether this is expected behavior (c.f. PR43038) ?

[Bug target/41894] wrong code with -fno-split-wide-types

[avr at gjlay dot de]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||avr at gjlay dot de

--- Comment #10 from Georg-Johann Lay  2011-03-13 12:07:06 
UTC ---
(In reply to comment #9)
> Closing as fixed in 4.5.0.

Why and how is this bug fixed? Slight variations in source/compiler will make
this bug appear/disappear, so that testing the same source against other
compiler version does not tell wether or not the bug actually has gone.

QImode still is not allowed in r28/r29.

PR46779 (4.4.x) and PR45291 (4.5.x) are duplicates for this bug in different
compiler versions.

Some passes like subreg lowering, RTL lowering generate 
  (set (subreg:QI (REG:HI ...
where HI reg finally gets allocated to r29:r28, however, the subreg is not
allowed in r28 resp. r29 leading to wrong code.

See also comment in 
http://gcc.gnu.org/ml/gcc/2011-02/msg00498.html

All the hacks in avr_hard_regno_mode_ok just work around prolems somewhere
else, and maybe around problems that have been fixed long ago.

IMO avr_hard_regno_mode_ok should be written according to documentation and
look what regressions that triggers, if any.

Johann

[Bug bootstrap/48102] New: [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: error: macro "build_cloog_prog" requires 4 arguments, but only 3 given

[dominiq at lps dot ens.fr]

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

   Summary: [4.6 Regression] Bootstrap failure for
powerpc-apple-darwin9: error: macro "build_cloog_prog"
requires 4 arguments, but only 3 given
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: s...@gcc.gnu.org
  Host: powerpc-apple-darwin9
Target: powerpc-apple-darwin9
 Build: powerpc-apple-darwin9


At revision 170921, bootstrapping on powerpc-apple-darwin9 fails with:

...
gcc -c   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../gcc-4.6-work/gcc -I../../gcc-4.6-work/gcc/.
-I../../gcc-4.6-work/gcc/../include -I../../gcc-4.6-work/gcc/../libcpp/include
-I/sw/include  -I../../gcc-4.6-work/gcc/../libdecnumber
-I../../gcc-4.6-work/gcc/../libdecnumber/dpd -I../libdecnumber  -I/sw/include 
../../gcc-4.6-work/gcc/graphite-clast-to-gimple.c -o graphite-clast-to-gimple.o
../../gcc-4.6-work/gcc/graphite-clast-to-gimple.c:1239:40: error: macro
"build_cloog_prog" requires 4 arguments, but only 3 given
../../gcc-4.6-work/gcc/graphite-clast-to-gimple.c:1240: error: expected '=',
',', ';', 'asm' or '__attribute__' before '{' token
../../gcc-4.6-work/gcc/graphite-clast-to-gimple.c:1440:43: error: macro
"build_cloog_prog" requires 4 arguments, but only 3 given
../../gcc-4.6-work/gcc/graphite-clast-to-gimple.c: In function 'scop_to_clast':
../../gcc-4.6-work/gcc/graphite-clast-to-gimple.c:1440: error:
'build_cloog_prog' undeclared (first use in this function)
../../gcc-4.6-work/gcc/graphite-clast-to-gimple.c:1440: error: (Each undeclared
identifier is reported only once
../../gcc-4.6-work/gcc/graphite-clast-to-gimple.c:1440: error: for each
function it appears in.)
../../gcc-4.6-work/gcc/graphite-clast-to-gimple.c: At top level:
../../gcc-4.6-work/gcc/graphite-clast-to-gimple.c:1433: warning: unused
parameter 'scop'
make[3]: *** [graphite-clast-to-gimple.o] Error 1
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2

This is likely due to

--- trunk/gcc/graphite-clast-to-gimple.c2011/03/12 16:58:33170906
+++ trunk/gcc/graphite-clast-to-gimple.c2011/03/12 22:05:38170907
@@ -1236,7 +1236,7 @@

 static void
 build_cloog_prog (scop_p scop, CloogProgram *prog,
-  CloogOptions *options, CloogState *state ATTRIBUTE_UNUSED)
+  CloogOptions *options)
 {
   int i;
   int max_nb_loops = scop_max_loop_depth (scop);

of revision 170907.

[Bug middle-end/45273] [4.4/4.5/4.6 Regression] The compiler depends on the host double (-fprofile-corection only)

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #5 from Steven Bosscher  2011-03-13 
10:55:05 UTC ---
Heh, with my patch (with some further changes) I get failures like this one:
../../trunk/gcc/sel-sched-ir.c:6253:1: error: caller edge frequency 38613 does
not match BB frequency 38610

Excess precision? :-)

[Bug libstdc++/48101] New: obscure error message with std::set

[gdr at gcc dot gnu.org]

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

   Summary: obscure error message with std::set
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org


The error message displayed on the
following program is quite obscure
and has no apparent relation with
the actual error.  Quite mystifying.

#include 

int main() {
  std::set s;
}

With my system compiler (GCC-4.5), I get:

In file included from
/usr/include/c++/4.5/x86_64-suse-linux/bits/c++allocator.h:34:0,
 from /usr/include/c++/4.5/bits/allocator.h:48,
 from /usr/include/c++/4.5/bits/stl_tree.h:63,
 from /usr/include/c++/4.5/set:60,
 from b.C:1:
/usr/include/c++/4.5/ext/new_allocator.h: In instantiation of
‘__gnu_cxx::new_allocator’:
/usr/include/c++/4.5/bits/allocator.h:87:5:   instantiated from
‘std::allocator’
/usr/include/c++/4.5/bits/stl_set.h:90:61:   instantiated from ‘std::set’
b.C:4:24:   instantiated from here
/usr/include/c++/4.5/ext/new_allocator.h:79:7: error: ‘const _Tp*
__gnu_cxx::new_allocator<_Tp>::address(const _Tp&) const [with _Tp = const int,
const _Tp* = const int*, const _Tp& = const int&]’ cannot be overloaded
/usr/include/c++/4.5/ext/new_allocator.h:76:7: error: with ‘_Tp*
__gnu_cxx::new_allocator<_Tp>::address(_Tp&) const [with _Tp = const int, _Tp*
= const int*, _Tp& = const int&]’


Go and figure out what the actual error was (hint: use of 'const int')
when the compiler displays internals of libstdc++ with unoverloadable
address of operator (which the user never overloaded in the first place.)

-- Gaby

[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

[iains at gcc dot gnu.org]

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

--- Comment #9 from Iain Sandoe  2011-03-13 10:07:50 
UTC ---
my +1 generally to comment #8,

We are (re)-discussing with the Apple developer for ld (obviously that can't be
in this forum).

IMO, 'as' is trying to check "if someone tries to write a section > 255 into
the symbol n_sect field"  which we won't do. 

It is just a little to simplistic to do this by a simple count of sections.

The Apple developers are really helpful guys - and I'm sure we'll get an answer
soon (I don't think we need to be paranoid, I suspect an oversight rather than
a release plan... ;-) ).

containerizing the LTO stuff would probably be much easier now that we have
simple-object in libiberty --- but it doesn't seem to be a last-minute kinda
job - better left for stage 1 and back-ported for 4.6.1 (my £0.02).

[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #8 from Steven Bosscher  2011-03-13 
09:59:30 UTC ---
(In reply to comment #7)
> Blocks bootstrap on a primary target; shouldn't it be P1/critical?

I don't think so, for the following reasons.

First of all, there are no primary targets in *-apple-darwin*. The only Apple
target in the release criteria is i686-apple-darwin which is a secondary target
(xf. http://gcc.gnu.org/gcc-4.6/criteria.html).

But IMVHO this is not a problem in GCC. LTO worked before, and now does not
work anymore due to a change in software that GCC has no control over. This is
a regression in Apple XCode. Even now, I can't find anywhere in the
documentation of the Mach-O file format that there is a limitation to 255
sections per segment
(xf.
http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html).
There is a limitation of 255 for sections with relocations, but that is not
applicable with GCC's LTO sections, because there are no relocations.

Call me paranoid, but I find it a suspicious coincidence that XCode 3.2.5
accepts GCC's LTO model, but Xcode 3.2.6 and newer do not, and this change
happens days before GCC's first release with LTO for Apple... The XCode
developers know that  GCC can use more than 255 sections, because we explicitly
discussed this with XCode developers when I developed LTO for Mach-O.

[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot
   ||gnu.org

--- Comment #7 from Francois-Xavier Coudert  
2011-03-13 08:16:01 UTC ---
Blocks bootstrap on a primary target; shouldn't it be P1/critical?