[Bug other/45808] FreeBSD: -pthread is handled incompletely

[avg at icyb dot net.ua]

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

--- Comment #3 from Andriy Gapon  2010-09-28 05:26:24 
UTC ---


(In reply to comment #2)
> Patches should be posted to gcc-patc...@gcc.gnu.org

And, in fact, I did that a (short?) while ago:
http://thread.gmane.org/gmane.comp.gcc.patches/217482/focus=217484
But it seems that nobody has picked it so far.
Perhaps I am the one to blame for that given the incorrect attachments.

[Bug target/45814] New: ICE in extract_insn, at recog.c:2127

[rmansfield at qnx dot com]

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

   Summary: ICE in extract_insn, at recog.c:2127
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rmansfi...@qnx.com
  Host: i686-linux-gnu
Target: arm-unknown-linux-gnu
 Build: i686-linux-gnu


Created attachment 21900
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=21900
preprocessed source

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: arm-unknown-linux-gnu
Configured with: ../configure --target=arm-unknown-linux-gnu
--prefix=/home/ryan/x-tools/arm-unknown-linux-gnu
--with-headers=/home/ryan/x-tookls/arm-unknown-linux-gnu/arm-unknown-linux-gnu/include
--with-local-prefix=/home/ryan/xtools/arm-unknown-linux-gnu/arm-unknown-linux-gnu
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c --enable-shared --enable-c99 --enable-long-long
--enable-checking=all
Thread model: posix
gcc version 4.6.0 20100928 (experimental) [trunk revision 164675] (GCC) 
$ ./xgcc -B. -march=armv6 -mfpu=vfp -mfloat-abi=softfp -O3 ~/ice.i -mapcs-frame
/home/ryan/ice.i: In function 'SendTg':
/home/ryan/ice.i:25:7: warning: incompatible implicit declaration of built-in
function 'memset' [enabled by default]
/home/ryan/ice.i:39:1: error: unrecognizable insn:
(insn 155 154 156 6 (set (reg:HI 4 r4)
(reg:SI 77 s14)) /home/ryan/ice.i:30 -1
 (nil))
/home/ryan/ice.i:39:1: internal compiler error: in extract_insn, at
recog.c:2127
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Also happens with gnueabi and -mapcs-frame (I can't imagine why anyone would
want to do that).

[Bug rtl-optimization/45813] New: alias analysis problem ?

[darrenrjenkins at gmail dot com]

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

   Summary: alias analysis problem ?
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: darrenrjenk...@gmail.com


I think I am having some wrong code generated due to a compiler bug.
I am compiling for ARM/Thumb.

USB_INT16U  ReadLE16U ( volatile USB_INT08U  *pmem )
{
USB_INT16U  val;
USB_INT08U *bytes = (USB_INT08U *)&val;

bytes[0] = pmem[0];
bytes[1] = pmem[1];

return (val);
}

gives me

B580push {r7, lr}
B081sub sp, #4
AF00add r7, sp, #0
1CBBadds r3, r7, #2
7802ldrb r2, [r0, #0]
701Astrb r2, [r3, #0]
7842ldrb r2, [r0, #1]
8818ldrh r0, [r3, #0]
46BDmov sp, r7
B001add sp, #4
BC80pop {r7}
BC02pop {r1}
4708bx r1

Which reads the second byte into r2 but does not store it on the stack, so the
second byte of val is returned uninitialized.
It looks like the alias analysis knows that bytes points to val but doesn't
know that bytes+1 points to a part of val also, so optimizes it away.

Yell out if you need any more information

[Bug tree-optimization/45656] [4.6 Regression]: gfortran.dg/forall_4.f90 -O3, wrong code with -g

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

Summary|[4.5 Regression]:   |[4.6 Regression]:
   |gfortran.dg/forall_4.f90|gfortran.dg/forall_4.f90
   |-O3, wrong code with -g |-O3, wrong code with -g

--- Comment #10 from Hans-Peter Nilsson  2010-09-28 
00:40:30 UTC ---
Any chance of the tested patch being submitted to gcc-patches soon?
(Also, corrected title).

[Bug c++/43601] Enormous increase in DLL object files size in 4.5

[cestrauss at gmail dot com]

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

--- Comment #32 from Cesar Strauss  2010-09-28 
00:16:48 UTC ---
(In reply to comment #31)
> This is somewhat off topic but unfortunately (MinGW) c++filt doesn't work for
> me, e.g.:
> 
> % echo '.text$_ZNK17wxMBConvUTF16Base11GetMBNulLenEv'|/mingw/bin/c++filt.exe
> .text$_ZNK17wxMBConvUTF16Base11GetMBNulLenEv

Try echo '__ZNK17wxMBConvUTF16Base11GetMBNulLenEv'|/mingw/bin/c++filt.exe
Anyway, look at the end of each line of objdump -h  | c++filt, where it
says 'COMDAT '. 

> > Why there is one section for each emitted inline method?
> 
> Excellent question which I'm unfortunately totally unable to answer.

When two or more source files include the same header, the exported inline
functions end up duplicated in both object files. When linking these objects
together in the final DLL, the linker would give an error because of the
multiple definitions. To avoid this, each exported inline function is placed in
a separate section, identified by the COMDAT name. When the linker sees two or
more sections with the same COMDAT name, it can safely keep one of them and
discard the rest.

[Bug libffi/45677] Bad stack allocation for ffi function calls on x86-64

[dwitte at gmail dot com]

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

--- Comment #11 from Dan Witte  2010-09-27 23:40:05 
UTC ---
Jakub -- did you commit this fix to gcc's libffi? If not, I'll push upstream to
Anthony.

[Bug c++/43601] Enormous increase in DLL object files size in 4.5

[vz-gcc at zeitlins dot org]

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

--- Comment #31 from Vadim Zeitlin  2010-09-27 
22:42:55 UTC ---
(In reply to comment #30)
> Sorry, but I do not completely agree with this assessment. If you run
> 
> objdump -h  | c++filt
> 
> you will see that 4.4 still generates one section per method, not per class
> (the name of the method is reveled by c++filt).

This is somewhat off topic but unfortunately (MinGW) c++filt doesn't work for
me, e.g.:

% echo '.text$_ZNK17wxMBConvUTF16Base11GetMBNulLenEv'|/mingw/bin/c++filt.exe
.text$_ZNK17wxMBConvUTF16Base11GetMBNulLenEv

I don't know what could be wrong with it but, anyhow, you're right, of course,
and I was wrong (I managed to look at the classes whose methods were not used
by the object file I was checking...), sorry for misinformation and thanks for
correcting it!

> In my view, the difference is only that 4.5 emits a section for every inline
> method of every dllexported class in sight. 4.4 only emitted those which the
> code actually needed.

Yes, exactly.

> Why there is one section for each emitted inline method?

Excellent question which I'm unfortunately totally unable to answer.

[Bug libgcj/40868] ecjx.cc should be compiled by host gcc

[dmitrij.ledkov at ubuntu dot com]

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

--- Comment #16 from Dima  2010-09-27 
22:13:18 UTC ---
(In reply to comment #15)
> (In reply to comment #14)
> > Created attachment 21898 [details] [details]
> > backport
> > 
> > This is the backport I use against gcc-4.4
> 
> dear dima, thanks for that patch but it's not sufficient. it even applies and
> configures right but too many things had changed between release 4.4.4 and
> revision 163580. so the resulting generated makefile is faulty and leaves the
> variable @GCC_FOR_ECJX@ unsubtituted which causes compile to fail.

This patch does apply against snapshot gcc-4.4 branch 26-09-2010. And does
build libgcj & java cross-compiler from i386|x86_64-gnu-linux to
i686-w64-mingw32.
After the patch is applied you do need to rerun correct autoreconf (2.59).

Buildlog -
http://launchpadlibrarian.net/56490712/buildlog_ubuntu-lucid-i386.w64-toolchain_1.0b%2B201009260029-0w2228g93841b22110p11~lucid1_FULLYBUILT.txt.gz

[Bug libgcj/40868] ecjx.cc should be compiled by host gcc

[andreas.fri...@multimedia-labs.de]

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

--- Comment #15 from Fraxinas  2010-09-27 
21:57:43 UTC ---
(In reply to comment #14)
> Created attachment 21898 [details]
> backport
> 
> This is the backport I use against gcc-4.4

dear dima, thanks for that patch but it's not sufficient. it even applies and
configures right but too many things had changed between release 4.4.4 and
revision 163580. so the resulting generated makefile is faulty and leaves the
variable @GCC_FOR_ECJX@ unsubtituted which causes compile to fail.
instead, i did it like Andrew proposed and simply imported the entire libjava
directory from svn head with which it works correctly.


now i am struggeling to cross compile statically linked mipsel java code with a
c++ .so linked to it...

[Bug target/45804] ARM: unnecessary sign extension

[rearnsha at gcc dot gnu.org]

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

--- Comment #3 from Richard Earnshaw  2010-09-27 
21:52:38 UTC ---
(In reply to comment #2)
> 
> What do you mean by "returned"? This is an inline function, so it depends
> entirely on what the referencing code is doing whether or not this value is
> returned, as function return.

You didn't cite any context of the use.  Just a single function.

[Bug c++/43601] Enormous increase in DLL object files size in 4.5

[LpSolit at netscape dot net]

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

--- Comment #30 from Cesar Strauss  2010-09-27 
02:00:39 UTC ---
(In reply to comment #29)

Dear Vadim

> The difference in number of sections seems to correspond to the fact that 4.5
> now generates one section per method of any exported class used by the object
> file instead of just one section per class as in 4.4.

Sorry, but I do not completely agree with this assessment. If you run

objdump -h  | c++filt

you will see that 4.4 still generates one section per method, not per class
(the name of the method is reveled by c++filt).

In my view, the difference is only that 4.5 emits a section for every inline
method of every dllexported class in sight. 4.4 only emitted those which the
code actually needed.

Why there is one section for each emitted inline method? As I understand it,
since the same inline method can be exported by multiple object files, there
would be a danger of having multiple definitions at link time. To avoid this,
they reside in separate sections marked as LINK_ONCE_DISCARD, so the linker can
discard these multiple copies and keep just the first one encountered. 

To avoid all these copies in the first place, the idea from Yu Simin in comment
#26 seems to be a good one.

Regards,
Cesar

[Bug libgcj/40868] ecjx.cc should be compiled by host gcc

[LpSolit at netscape dot net]

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

Fraxinas  changed:

   What|Removed |Added

 CC||andreas.fri...@multimedia-l
   ||abs.de

--- Comment #12 from Fraxinas  2010-09-23 
22:36:05 UTC ---
Hi Ralf,
i tried destilling your rev 163580 patches into one accumulated backport to
gcc-4.4.4. in our openembedded cross development toolchain. 
http://pastebin.com/pU3zF6MP

the patch actually does apply correctly, but during compile time, fails in the
libjava directory:
...
libtool: link: ( cd ".libs" && rm -f "libgcj_bc.la" && ln -s "../libgcj_bc.la"
"libgcj_bc.la" )
/bin/bash: GCC_FOR_ECJX@: command not found

turns out that the generated Makefile has the line GCC_FOR_ECJX =
@GCC_FOR_ECJX@ in it, so the variable wasn't substituted correctly during
configure, even though config.log says GCC_FOR_ECJX='x86_64-linux-gcc'

i probably need to backport other parts to be able to apply this patch
correctly on gcc release 4.4.4. but unfortunately the revision log
http://gcc.gnu.org/viewcvs/trunk/libjava/configure.ac?view=log&pathrev=163580
doesn't have information about the releases

is there an easy way to find out what else i need?

greetings,
fraxinas

--- Comment #13 from Andrew Haley  2010-09-24 07:54:17 
UTC ---
On 23/09/10 23:36, andreas.fri...@multimedia-labs.de wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40868
> 
> Fraxinas  changed:
> 
>What|Removed |Added
> 
>  CC||andreas.fri...@multimedia-l
>||abs.de
> 
> --- Comment #12 from Fraxinas  2010-09-23 
> 22:36:05 UTC ---
> Hi Ralf,
> i tried destilling your rev 163580 patches into one accumulated backport to
> gcc-4.4.4. in our openembedded cross development toolchain. 
> http://pastebin.com/pU3zF6MP
> 
> the patch actually does apply correctly, but during compile time, fails in the
> libjava directory:
> ...
> libtool: link: ( cd ".libs" && rm -f "libgcj_bc.la" && ln -s "../libgcj_bc.la"
> "libgcj_bc.la" )
> /bin/bash: GCC_FOR_ECJX@: command not found
> 
> turns out that the generated Makefile has the line GCC_FOR_ECJX =
> @GCC_FOR_ECJX@ in it, so the variable wasn't substituted correctly during
> configure, even though config.log says GCC_FOR_ECJX='x86_64-linux-gcc'
> 
> i probably need to backport other parts to be able to apply this patch
> correctly on gcc release 4.4.4. but unfortunately the revision log
> http://gcc.gnu.org/viewcvs/trunk/libjava/configure.ac?view=log&pathrev=163580
> doesn't have information about the releases
> 
> is there an easy way to find out what else i need?

It's hard to say.  I'd just import libgcj from gcc trunk.

Andrew.

[Bug bootstrap/44621] syntax error in gcc-4.5.0/configure for ksh

[rwild at gcc dot gnu.org]

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

--- Comment #5 from Ralf Wildenhues  2010-09-27 
20:19:48 UTC ---
Author: rwild
Date: Mon Sep 27 20:19:41 2010
New Revision: 164668

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164668
Log:
Fix unportable shell quoting.

/:
PR bootstrap/44621
* configure.ac: Fix unportable shell quoting.
* configure: Regenerate.

config/:
* po.m4 (AM_PO_SUBDIRS): Fix unportable shell quoting.

contrib/reghunt/:
* bin/gcc-svn-ids: Fix unportable shell quoting.
* date_based/reg_periodic: Likewise.
* date_based/reg_search: Likewise.

intl/:
PR bootstrap/44621
* configure: Regenerate.

Modified:
trunk/ChangeLog
trunk/config/ChangeLog
trunk/config/po.m4
trunk/configure
trunk/configure.ac
trunk/contrib/reghunt/ChangeLog
trunk/contrib/reghunt/bin/gcc-svn-ids
trunk/contrib/reghunt/date_based/reg_periodic
trunk/contrib/reghunt/date_based/reg_search
trunk/intl/ChangeLog
trunk/intl/configure

[Bug rtl-optimization/45792] [4.6 Regression]: cris-elf build failure (hangs) due to fix for PR44374

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #6 from Hans-Peter Nilsson  2010-09-27 
19:58:07 UTC ---
committed

[Bug rtl-optimization/45792] [4.6 Regression]: cris-elf build failure (hangs) due to fix for PR44374

[hp at gcc dot gnu.org]

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

--- Comment #5 from Hans-Peter Nilsson  2010-09-27 
19:55:31 UTC ---
Author: hp
Date: Mon Sep 27 19:55:29 2010
New Revision: 164663

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164663
Log:
PR rtl-optimization/45792
* cfgcleanup.c (try_head_merge_bb): New rtx vector nextptr.
If not all insns are to be merged, for each edge, stash the
next candidate after the to-be-merged insns before doing the
merge, and use them for the retry at the new insertion point.
Handle CC0 targets when retrying.

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

[Bug target/43358] [4.5 Regression] IRA: internal compiler error: in pool_free, at alloc-pool.c:335

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #12 from rsandifo at gcc dot gnu.org  
2010-09-27 19:53:44 UTC ---
Fixed in trunk and 4.5 branch.

[Bug target/43764] -mrelax-pic-calls fails with complex types

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
2010-09-27 19:48:39 UTC ---
Author: rsandifo
Date: Mon Sep 27 19:48:35 2010
New Revision: 164662

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164662
Log:
gcc/
Backport from mainline:

2010-05-19  James E. Wilson  

PR target/43764
* config/mips/mips.c (mips_call_expr_from_insn): New arg second_call.
Set it.
(mips_annotate_pic_calls): Pass new arg to mips_call_expr_from_insn.
Use it.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/mips/mips.c

[Bug target/43358] [4.5 Regression] IRA: internal compiler error: in pool_free, at alloc-pool.c:335

[rsandifo at gcc dot gnu.org]

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

--- Comment #11 from rsandifo at gcc dot gnu.org  
2010-09-27 19:48:18 UTC ---
Author: rsandifo
Date: Mon Sep 27 19:48:13 2010
New Revision: 164660

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164660
Log:
gcc/
PR rtl-optimization/43358
* ira-lives.c (process_single_reg_class_operands): Adjust the costs
of a single hard register, using simplify_subreg_regno to decide
what that register should be.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/ira-lives.c

[Bug objc/25464] objc_sizeof_type vs zero sized arrays

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Nicola Pero  2010-09-27 19:35:46 
UTC ---
Fixed in trunk.

Thanks

[Bug objc/25450] Enums are encoded incorrectly

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Nicola Pero  2010-09-27 19:34:59 
UTC ---
Fixed in trunk.

Thanks

[Bug objc/45763] incorrect @encode(BOOL *)

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Nicola Pero  2010-09-27 19:33:55 
UTC ---
Fixed on trunk, including a testcase to test that it is fixed. ;-)

Thanks

[Bug objc++/35551] internal compiler error: in encode_gnu_bitfield, at objc/objc-act.c:8175

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #4 from Nicola Pero  2010-09-27 19:32:48 
UTC ---
Thanks - I'll close the bug as we can't reproduce it :-(

If you manage to reproduce it, please open a new bug! :-)

Thanks

[Bug target/45693] [4.6 regression] All Tru64 UNIX EH tests fail

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe  2010-09-27 19:24:17 
UTC ---
(In reply to comment #6)
> > As I recall, the patch was to circumvent a race condition - which manifest 
> > most
> > frequently in the decision as to whether libgomp used TLS or not.
> 
> I see no indications of this sort of problem here: before your patch,
> TLS support was reliably/consistently detected to be missing, now it's
> reliably found to be present.

IIUC, comment #2 indicates that the platform should show as having (emulated)
TLS.
If that is so, the situation is that the problem you now see was masked by a
faulty configure macro, fixed by the patch.

I will try and dig out the test code we used to stress the TLS implementation -
it might be worth running that on the alpha to see whether is shows a
difference.   (it's probably attached to 43170).

IIRC the fix was quite heavily discussed on patches - there might be something
useful in those threads.

[Bug objc/25450] Enums are encoded incorrectly

[nicola at gcc dot gnu.org]

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

--- Comment #4 from Nicola Pero  2010-09-27 19:22:17 
UTC ---
Author: nicola
Date: Mon Sep 27 19:22:13 2010
New Revision: 164659

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164659
Log:
In gcc/:
2010-09-27  Nicola Pero  

* doc/objc.texi (Type encoding): Added the new 'long double' (D)
code.  Added byref, which was missing in the list of codes.
Explain that enumeration values are encoded as the integer type
that the compiler uses to store them.  Explain and make examples
of how 'const' interacts with pointers, and the complication of
the encoding of 'const char *'.
(Legacy type encoding): New subsection, explaining that GCC emits
incorrect type encodings for the NeXT runtime for compatibility
reasons.
(@@encode): New subsection, explaining @encode and particularly
that protocol qualifiers are not recognized inside an @encode()
expression.
(Method signatures): New subsection, explaining how method
signatures are encoded.

In gcc/objc/:
2010-09-27  Nicola Pero  

PR objc/45763
PR objc/25450
PR objc/25464
* objc-act.c: Improved comments for encoding functions.
(encode_aggregate_within): For the GNU runtime, rewritten some
obsfuscated code to clarify the various cases.
(encode_aggregate): Function removed.
(encode_array): Generate an error if asked to encode an incomplete
array as part of generating instance variables.  Else, when
encoding an incomplete array inside a structure, encode it as an
array of zero size.
(encode_pointer): For the GNU runtime, fixed encoding 'BOOL *' as
'^c' instead of '*'.
(encode_gnu_bitfield): Encode enumerated types exactly in the same
type as integer types instead of using a hardcoded 'i'.  If asked
to encode a non-integer type as a bitfield, do not abort
compilation immediately; instead generate an error, then skip the
type.
(encode_type): Use a 'switch' instead of a sequence of 'if's.
Added a 'default' clause that gets executed if the type can not be
matched, and that encodes it as '?' (unknown) and produces a
warning.  For the GNU runtime, encode enumerated types exactly in
the same way as integer types instead of using a hardcoded 'i'.
Encode long double as 'D'.  Encode 128-bit integers as 'T' or 't'.
Encode C++ reference types as pointers.  Call encode_vector to
encode vectors.
(encode_vector): New function.

2010-09-27  Nicola Pero  

Merge from 'apple/trunk' branch on FSF servers.  I modified the
changes to be used only when compiling for the NeXT runtime.

2005-10-10  Fariborz Jahanian 

Radar 4301047

* objc-act.c (encode_type): Remove the hack.

2005-07-20  Ziemowit Laski  

Radar 4136935
* objc-act.c (pointee_is_readonly): New function.
(encode_pointer, encode_aggregate_within, encode_type):
Attempt to emulate GCC 3.3 when generating type encodings.

In gcc/testsuite/:
2010-09-27  Nicola Pero  

PR objc/25464
* objc.dg/type-size-3.m: New test.

2010-09-27  Nicola Pero  

PR objc/45763
* objc.dg/encode-1.m: Execute the test with the GNU runtime as
well.

2010-09-27  Nicola Pero  

PR objc/25450
* objc.dg/encode-3.m: Updated for fix of encoding of enums.
* objc.dg/type-size-2.m: Same change.
* obj-c++.dg/encode-5.mm: Same change.

2010-09-27  Nicola Pero  

Merge from 'apple/trunk' branch on FSF servers.  The original
Changelogs are below.

* objc.dg/encode-6.m: Execute the test only with the GNU runtime.
* objc.dg/encode-6-next.m: New file (from encode-6.m in the
branch).
* objc.dg/encode-7-next.m: New file (from encode-7.m in the
branch).
* objc.dg/encode-7-next-64bit.m: New file (from encode-7-64bit.m
in the branch).
* objc.dg/proto-qual-1.m: Test the 3.3 ABI on NeXT (from
proto-qual-1.m in the branch) and the normal ABI on GNU.
* objc.dg/threedotthree-abi-1.m: New file (from the branch).  Run
the test only with the NeXT runtime.
* obj-c++/encode-1.mm: Execute the test only with the GNU runtime.
* obj-c++/encode-1-next.mm: New file (from encode-1.mm in the
branch).
* obj-c++.dg/threedotthree-abi-1.mm: New file (from the branch).
Run the test only with the NeXT runtime.

2006-03-30 Fariborz Jahanian 

Radar 4492973
* objc.dg/encode-7-64bit.m: New.
* objc.dg/encode-7.m: Skip if -m64.

2005-10-19  Fariborz Jahanian 

Radar 4301047
* objc.dg/proto-qual-1.m: Fix test to match 3.3 ABI
* obj-c++.dg/threedotthree-abi-1.mm: New
* objc

[Bug objc/45763] incorrect @encode(BOOL *)

[nicola at gcc dot gnu.org]

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

--- Comment #2 from Nicola Pero  2010-09-27 19:22:17 
UTC ---
Author: nicola
Date: Mon Sep 27 19:22:13 2010
New Revision: 164659

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164659
Log:
In gcc/:
2010-09-27  Nicola Pero  

* doc/objc.texi (Type encoding): Added the new 'long double' (D)
code.  Added byref, which was missing in the list of codes.
Explain that enumeration values are encoded as the integer type
that the compiler uses to store them.  Explain and make examples
of how 'const' interacts with pointers, and the complication of
the encoding of 'const char *'.
(Legacy type encoding): New subsection, explaining that GCC emits
incorrect type encodings for the NeXT runtime for compatibility
reasons.
(@@encode): New subsection, explaining @encode and particularly
that protocol qualifiers are not recognized inside an @encode()
expression.
(Method signatures): New subsection, explaining how method
signatures are encoded.

In gcc/objc/:
2010-09-27  Nicola Pero  

PR objc/45763
PR objc/25450
PR objc/25464
* objc-act.c: Improved comments for encoding functions.
(encode_aggregate_within): For the GNU runtime, rewritten some
obsfuscated code to clarify the various cases.
(encode_aggregate): Function removed.
(encode_array): Generate an error if asked to encode an incomplete
array as part of generating instance variables.  Else, when
encoding an incomplete array inside a structure, encode it as an
array of zero size.
(encode_pointer): For the GNU runtime, fixed encoding 'BOOL *' as
'^c' instead of '*'.
(encode_gnu_bitfield): Encode enumerated types exactly in the same
type as integer types instead of using a hardcoded 'i'.  If asked
to encode a non-integer type as a bitfield, do not abort
compilation immediately; instead generate an error, then skip the
type.
(encode_type): Use a 'switch' instead of a sequence of 'if's.
Added a 'default' clause that gets executed if the type can not be
matched, and that encodes it as '?' (unknown) and produces a
warning.  For the GNU runtime, encode enumerated types exactly in
the same way as integer types instead of using a hardcoded 'i'.
Encode long double as 'D'.  Encode 128-bit integers as 'T' or 't'.
Encode C++ reference types as pointers.  Call encode_vector to
encode vectors.
(encode_vector): New function.

2010-09-27  Nicola Pero  

Merge from 'apple/trunk' branch on FSF servers.  I modified the
changes to be used only when compiling for the NeXT runtime.

2005-10-10  Fariborz Jahanian 

Radar 4301047

* objc-act.c (encode_type): Remove the hack.

2005-07-20  Ziemowit Laski  

Radar 4136935
* objc-act.c (pointee_is_readonly): New function.
(encode_pointer, encode_aggregate_within, encode_type):
Attempt to emulate GCC 3.3 when generating type encodings.

In gcc/testsuite/:
2010-09-27  Nicola Pero  

PR objc/25464
* objc.dg/type-size-3.m: New test.

2010-09-27  Nicola Pero  

PR objc/45763
* objc.dg/encode-1.m: Execute the test with the GNU runtime as
well.

2010-09-27  Nicola Pero  

PR objc/25450
* objc.dg/encode-3.m: Updated for fix of encoding of enums.
* objc.dg/type-size-2.m: Same change.
* obj-c++.dg/encode-5.mm: Same change.

2010-09-27  Nicola Pero  

Merge from 'apple/trunk' branch on FSF servers.  The original
Changelogs are below.

* objc.dg/encode-6.m: Execute the test only with the GNU runtime.
* objc.dg/encode-6-next.m: New file (from encode-6.m in the
branch).
* objc.dg/encode-7-next.m: New file (from encode-7.m in the
branch).
* objc.dg/encode-7-next-64bit.m: New file (from encode-7-64bit.m
in the branch).
* objc.dg/proto-qual-1.m: Test the 3.3 ABI on NeXT (from
proto-qual-1.m in the branch) and the normal ABI on GNU.
* objc.dg/threedotthree-abi-1.m: New file (from the branch).  Run
the test only with the NeXT runtime.
* obj-c++/encode-1.mm: Execute the test only with the GNU runtime.
* obj-c++/encode-1-next.mm: New file (from encode-1.mm in the
branch).
* obj-c++.dg/threedotthree-abi-1.mm: New file (from the branch).
Run the test only with the NeXT runtime.

2006-03-30 Fariborz Jahanian 

Radar 4492973
* objc.dg/encode-7-64bit.m: New.
* objc.dg/encode-7.m: Skip if -m64.

2005-10-19  Fariborz Jahanian 

Radar 4301047
* objc.dg/proto-qual-1.m: Fix test to match 3.3 ABI
* obj-c++.dg/threedotthree-abi-1.mm: New
* objc

[Bug objc/25464] objc_sizeof_type vs zero sized arrays

[nicola at gcc dot gnu.org]

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

--- Comment #6 from Nicola Pero  2010-09-27 19:22:17 
UTC ---
Author: nicola
Date: Mon Sep 27 19:22:13 2010
New Revision: 164659

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164659
Log:
In gcc/:
2010-09-27  Nicola Pero  

* doc/objc.texi (Type encoding): Added the new 'long double' (D)
code.  Added byref, which was missing in the list of codes.
Explain that enumeration values are encoded as the integer type
that the compiler uses to store them.  Explain and make examples
of how 'const' interacts with pointers, and the complication of
the encoding of 'const char *'.
(Legacy type encoding): New subsection, explaining that GCC emits
incorrect type encodings for the NeXT runtime for compatibility
reasons.
(@@encode): New subsection, explaining @encode and particularly
that protocol qualifiers are not recognized inside an @encode()
expression.
(Method signatures): New subsection, explaining how method
signatures are encoded.

In gcc/objc/:
2010-09-27  Nicola Pero  

PR objc/45763
PR objc/25450
PR objc/25464
* objc-act.c: Improved comments for encoding functions.
(encode_aggregate_within): For the GNU runtime, rewritten some
obsfuscated code to clarify the various cases.
(encode_aggregate): Function removed.
(encode_array): Generate an error if asked to encode an incomplete
array as part of generating instance variables.  Else, when
encoding an incomplete array inside a structure, encode it as an
array of zero size.
(encode_pointer): For the GNU runtime, fixed encoding 'BOOL *' as
'^c' instead of '*'.
(encode_gnu_bitfield): Encode enumerated types exactly in the same
type as integer types instead of using a hardcoded 'i'.  If asked
to encode a non-integer type as a bitfield, do not abort
compilation immediately; instead generate an error, then skip the
type.
(encode_type): Use a 'switch' instead of a sequence of 'if's.
Added a 'default' clause that gets executed if the type can not be
matched, and that encodes it as '?' (unknown) and produces a
warning.  For the GNU runtime, encode enumerated types exactly in
the same way as integer types instead of using a hardcoded 'i'.
Encode long double as 'D'.  Encode 128-bit integers as 'T' or 't'.
Encode C++ reference types as pointers.  Call encode_vector to
encode vectors.
(encode_vector): New function.

2010-09-27  Nicola Pero  

Merge from 'apple/trunk' branch on FSF servers.  I modified the
changes to be used only when compiling for the NeXT runtime.

2005-10-10  Fariborz Jahanian 

Radar 4301047

* objc-act.c (encode_type): Remove the hack.

2005-07-20  Ziemowit Laski  

Radar 4136935
* objc-act.c (pointee_is_readonly): New function.
(encode_pointer, encode_aggregate_within, encode_type):
Attempt to emulate GCC 3.3 when generating type encodings.

In gcc/testsuite/:
2010-09-27  Nicola Pero  

PR objc/25464
* objc.dg/type-size-3.m: New test.

2010-09-27  Nicola Pero  

PR objc/45763
* objc.dg/encode-1.m: Execute the test with the GNU runtime as
well.

2010-09-27  Nicola Pero  

PR objc/25450
* objc.dg/encode-3.m: Updated for fix of encoding of enums.
* objc.dg/type-size-2.m: Same change.
* obj-c++.dg/encode-5.mm: Same change.

2010-09-27  Nicola Pero  

Merge from 'apple/trunk' branch on FSF servers.  The original
Changelogs are below.

* objc.dg/encode-6.m: Execute the test only with the GNU runtime.
* objc.dg/encode-6-next.m: New file (from encode-6.m in the
branch).
* objc.dg/encode-7-next.m: New file (from encode-7.m in the
branch).
* objc.dg/encode-7-next-64bit.m: New file (from encode-7-64bit.m
in the branch).
* objc.dg/proto-qual-1.m: Test the 3.3 ABI on NeXT (from
proto-qual-1.m in the branch) and the normal ABI on GNU.
* objc.dg/threedotthree-abi-1.m: New file (from the branch).  Run
the test only with the NeXT runtime.
* obj-c++/encode-1.mm: Execute the test only with the GNU runtime.
* obj-c++/encode-1-next.mm: New file (from encode-1.mm in the
branch).
* obj-c++.dg/threedotthree-abi-1.mm: New file (from the branch).
Run the test only with the NeXT runtime.

2006-03-30 Fariborz Jahanian 

Radar 4492973
* objc.dg/encode-7-64bit.m: New.
* objc.dg/encode-7.m: Skip if -m64.

2005-10-19  Fariborz Jahanian 

Radar 4301047
* objc.dg/proto-qual-1.m: Fix test to match 3.3 ABI
* obj-c++.dg/threedotthree-abi-1.mm: New
* objc

[Bug web/45811] bugzilla: editing search loses host/target/build

[LpSolit at netscape dot net]

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

Frédéric Buclin  changed:

   What|Removed |Added

   See Also||https://bugzilla.mozilla.or
   ||g/show_bug.cgi?id=599953

--- Comment #2 from Frédéric Buclin  2010-09-27 
19:04:36 UTC ---
This is an upstream bug.

[Bug target/45804] ARM: unnecessary sign extension

[felipe.contreras at gmail dot com]

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

--- Comment #2 from Felipe Contreras  
2010-09-27 19:02:19 UTC ---
(In reply to comment #1)
> This particular case is invalid.  
> 
> The ARM ABI requires that short and char result types are extended to 32 bits
> (using signed or unsigned extension as appropriate) before being returned. 
> Since the compiler can't see inside the asm block to work out what is being
> done it cannot remove the uxth instruction on the result.

What do you mean by "returned"? This is an inline function, so it depends
entirely on what the referencing code is doing whether or not this value is
returned, as function return.

Say:

if ((read16_be(data) & 0xfffe) == 0xfff8)

> This does not mean that some of your x-refed reports are invalid though.

Come again?

[Bug target/45693] [4.6 regression] All Tru64 UNIX EH tests fail

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  2010-09-27 18:40:36 UTC ---
> As I recall, the patch was to circumvent a race condition - which manifest 
> most
> frequently in the decision as to whether libgomp used TLS or not.

I see no indications of this sort of problem here: before your patch,
TLS support was reliably/consistently detected to be missing, now it's
reliably found to be present.

> It's odd that after this time a problem should show in libstdc++ (which was
> never, AFAIR flagged up in the original problem series).

I had noticed the problem (all C++ EH tests failing on Tru64 UNIX)
before, but only now found the time to investigate.  There are no other
serious testsuite regressions caused by the patch as far as I can see.

> As for a platform with TLS  - Darwin is regularly testing libstdc++ on powepc,
> and x86 .. so there must be some corner case at work.

As is Solaris 8 and 9 without GNU as, which use emutls as well.

[Bug target/45693] [4.6 regression] All Tru64 UNIX EH tests fail

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  2010-09-27 18:34:46 
UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > But that support was present before, and still GCC_CHECK_TLS didn't
> > detect it before Iain's patch.  Something is certainly fishy here...
> 
> His patch was explicitly to fix checking for TLS when emulated TLS was used. 
> Sometimes it would detect it as working and other times it would not.

As I recall, the patch was to circumvent a race condition - which manifest most
frequently in the decision as to whether libgomp used TLS or not.

It's odd that after this time a problem should show in libstdc++ (which was
never, AFAIR flagged up in the original problem series).

As for a platform with TLS  - Darwin is regularly testing libstdc++ on powepc,
and x86 .. so there must be some corner case at work.

[Bug target/45805] VFP/Neon double precision register expected -- `vmovl.s16 q2,s8

[raj.khem at gmail dot com]

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

--- Comment #2 from Khem Raj  2010-09-27 18:33:58 
UTC ---
(In reply to comment #1)
> Created attachment 21897 [details]
> Fix register specifier in instruction template for vmovl.

I tried similar patch locally before submitting the bug (changed only vmovl
pattern)
but I got an ICE which is again same I am getting with this patch too

$ arm-none-linux-gnueabi-gcc-4.6.0 -mfloat-abi=softfp -mfpu=neon a.c -O3
a.c: In function ‘try_8x8basis_c’:
a.c:14:1: internal compiler error: output_operand: invalid operand for code 'P'

[Bug target/45693] [4.6 regression] All Tru64 UNIX EH tests fail

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  2010-09-27 
18:26:54 UTC ---
(In reply to comment #3)
> But that support was present before, and still GCC_CHECK_TLS didn't
> detect it before Iain's patch.  Something is certainly fishy here...

His patch was explicitly to fix checking for TLS when emulated TLS was used. 
Sometimes it would detect it as working and other times it would not.

[Bug target/45693] [4.6 regression] All Tru64 UNIX EH tests fail

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  2010-09-27 18:21:04 UTC ---
> --- Comment #2 from Andrew Pinski  2010-09-27 
> 18:14:21 UTC ---
>>After it, libstdc++-v3/configure incorrectly concludes that alpha-dec-osf5.1 
>>has TLS support.
>
>  No it should be detected that way as it has emulated TLS support.

But that support was present before, and still GCC_CHECK_TLS didn't
detect it before Iain's patch.  Something is certainly fishy here...

Rainer

[Bug target/45693] [4.6 regression] All Tru64 UNIX EH tests fail

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2010-09-27 
18:14:21 UTC ---
>After it, libstdc++-v3/configure incorrectly concludes that alpha-dec-osf5.1 
>has TLS support.

 No it should be detected that way as it has emulated TLS support.

[Bug target/45693] [4.6 regression] All Tru64 UNIX EH tests fail

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.09.27 18:12:02
   date||
 CC||iains at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Rainer Orth  2010-09-27 18:12:02 UTC 
---
A reghunt revealed that this patch

2010-06-09  Iain Sandoe  

   PR bootstrap/43170
   * tls.m4 (GCC_CHECK_TLS): Add volatile qualifier to the test 
   references.  Move the main () test reference ahead of 
   pthread_create().  Add a comment to explain the requirements
   of the test.

is the culprit.  After it, libstdc++-v3/configure incorrectly concludes that
alpha-dec-osf5.1 has TLS support.

I've yet to determine how the change could have this effect.

[Bug objc/27377] [4.3/4.4 Regression] false compiler warnings generated in Objective-C code

[nicola at gcc dot gnu.org]

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

--- Comment #13 from Nicola Pero  2010-09-27 
18:04:14 UTC ---
Author: nicola
Date: Mon Sep 27 18:04:09 2010
New Revision: 164655

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164655
Log:
In gcc/:
2010-09-27  Nicola Pero  

Merge from 'apple/trunk' branch on FSF servers.  Removed small
change in build_conditional_expr that had been added when fixing
PR objc/27377 and which did the same check in a less complete way.

2005-12-15  Fariborz Jahanian 

Radar 4229905
* c-typeck.c (build_conditional_expr): Call objc_have_common_type when
looking for objective-c common pointer types.

2005-06-22  Ziemowit Laski  

Radar 4154928
* c-typeck.c (build_conditional_expr): For two ObjC pointer types,
use their ObjC common type.

In gcc/c-family:
2010-09-27  Nicola Pero  

Merge from 'apple/trunk' branch on FSF servers.

2005-12-15  Fariborz Jahanian 

Radar 4229905
* c-common.h (objc_have_common_type): New declaration.
* stub-objc.c (objc_have_common_type): New stub.

2005-06-22  Ziemowit Laski  

Radar 4154928
* c-common.h (objc_common_type): New prototype.
* stub-objc.c (objc_common_type): New stub.

In gcc/objc/:
2010-09-27  Nicola Pero  

Merge from 'apple/trunk' branch on FSF servers.

2005-12-15  Fariborz Jahanian 

Radar 4229905
* objc-act.c (objc_have_common_types): New function.

2005-06-22  Ziemowit Laski  

Radar 4154928
* objc-act.c (objc_common_type): New function.

In gcc/cp/:
2010-09-27  Nicola Pero  

Merge from apple/trunk branch on FSF servers:

2005-12-15  Fariborz Jahanian 

Radar 4229905
* typeck.c (composite_pointer_type): Call objc_have_common_type
when comparing two objective-c pointer types.

2005-06-22  Ziemowit Laski  

Radar 4154928
* call.c (standard_conversion): Allow for a pointer conversion
between any two ObjC pointer types.
* typeck.c (composite_pointer_type): Determine common type
for two ObjC pointer types.

In gcc/testsuite/:
2010-09-27  Nicola Pero  

Merge from 'apple/trunk' branch on FSF servers.  Renamed
const-str-12.m to constr-str-12b.m to avoid conflicts.

2005-12-15  Fariborz Jahanian 

Radar 4229905
* obj-c++.dg/warn5.mm: New

2005-06-22  Ziemowit Laski  

Radar 4154928
* obj-c++.dg/const-str-12.mm: New.
* objc.dg/const-str-12.m: New.

Added:
trunk/gcc/testsuite/obj-c++.dg/const-str-12.mm
trunk/gcc/testsuite/obj-c++.dg/warn5.mm
trunk/gcc/testsuite/objc.dg/const-str-12b.m
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.h
trunk/gcc/c-family/stub-objc.c
trunk/gcc/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/typeck.c
trunk/gcc/objc/ChangeLog
trunk/gcc/objc/objc-act.c
trunk/gcc/testsuite/ChangeLog

[Bug web/45811] bugzilla: editing search loses host/target/build

[LpSolit at netscape dot net]

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

Frédéric Buclin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.09.27 17:52:19
   date||
 CC||LpSolit at netscape dot net
 Ever Confirmed|0   |1

--- Comment #1 from Frédéric Buclin  2010-09-27 
17:52:19 UTC ---
Hum yes, indeed.

[Bug web/45802] [bugzilla] "driver" component description needs updating

[LpSolit at netscape dot net]

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

Frédéric Buclin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Last reconfirmed||2010-09-27
   date||
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |LpSolit at netscape dot net
   |gnu.org |

--- Comment #1 from Frédéric Buclin  2010-09-27 
17:50:18 UTC ---
done.

[Bug bootstrap/45612] [4.6 regression] Reference to undefined label building libada on Solaris 2/SPARC

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  2010-09-27 17:48:14 UTC ---
Jan,

again, no progress at all for 2 1/2 weeks on a bootstrap failure on a
primary platform.  Please fix or revert.

Rainer

[Bug bootstrap/45658] [4.6 regression] Comparison failure in gcc/ada/ali.o on Solaris 2/SPARC

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  2010-09-27 17:46:29 UTC ---
Jan, this bug is now open for two weeks with no indication of any
progress.  It breaks Ada bootstrap on a primary platform, so please fix
or revert your patch.

Rainer

[Bug lto/45702] [4.6 Regression] New LTO test failures

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #18 from Rainer Orth  2010-09-27 17:44:09 
UTC ---
*-*-solaris2* is equally affected.  There doesn't even exist a static libm.a.
For other LTO tests, this is handled by lib/lto.exp (lto_init) which
temporarily
removes -lm from the link.

[Bug rtl-optimization/45792] [4.6 Regression]: cris-elf build failure (hangs) due to fix for PR44374

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p
   |atches/2010-09/msg02097.htm |atches/2010-09/msg02117.htm
   |l   |l

--- Comment #4 from Hans-Peter Nilsson  2010-09-27 
17:34:15 UTC ---
For the record, updated patch URL to point to Bernds patch.

[Bug libgcj/44341] [4.6 Regression] libjava cross build fails when configured with --with-gmp=

[cgf at gcc dot gnu.org]

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

--- Comment #2 from Chris Faylor  2010-09-27 17:23:18 
UTC ---
once again.  sorry for the noise.

[Bug libgcj/44341] [4.6 Regression] libjava cross build fails when configured with --with-gmp=

[cgf at gcc dot gnu.org]

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

Chris Faylor  changed:

   What|Removed |Added

 CC||cgf at gcc dot gnu.org

--- Comment #1 from Chris Faylor  2010-09-27 17:18:01 
UTC ---
additional comment to check mail to java-prs.

[Bug java/45322] libjava error: libtool: compile: libobj name `ltdl.lo' may not contain shell special

[fche at redhat dot com]

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

Ralf Wildenhues  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.09.24 18:33:22
   date||
 Ever Confirmed|0   |1

Frank Ch. Eigler  changed:

   What|Removed |Added

 CC||fche at redhat dot com

--- Comment #4 from Ralf Wildenhues  2010-09-24 
18:33:22 UTC ---
Waiting for feedback asked for in comment #1.

--- Comment #5 from Frank Ch. Eigler  2010-09-27 
16:34:50 UTC ---
test test test

--- Comment #6 from Frank Ch. Eigler  2010-09-27 
17:05:17 UTC ---
test test test

[Bug web/45782] bugzilla internal error trying to update existing PR

[LpSolit at netscape dot net]

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

Frédéric Buclin  changed:

   What|Removed |Added

 CC||fche at redhat dot com,
   ||LpSolit at netscape dot net
   See Also||https://bugzilla.mozilla.or
   ||g/show_bug.cgi?id=599890

--- Comment #2 from Frédéric Buclin  2010-09-27 
16:39:16 UTC ---
About the error being thrown, we do it intentionally, but I agree we shouldn't.
I filed bug 599890 upstream.

About java-prs, I don't see why it only fails with this email recipient.
http://gcc.gnu.org/ml/java-prs/2010-q3/ indeed shows that no bugmail has been
sent to this mailing-list since I upgraded Bugzilla. Looks like the move from
Qmail to SMTP is blocked for this recipient for some reason.

[Bug java/45322] libjava error: libtool: compile: libobj name `ltdl.lo' may not contain shell special

[fche at redhat dot com]

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

Ralf Wildenhues  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.09.24 18:33:22
   date||
 Ever Confirmed|0   |1

Frank Ch. Eigler  changed:

   What|Removed |Added

 CC||fche at redhat dot com

--- Comment #4 from Ralf Wildenhues  2010-09-24 
18:33:22 UTC ---
Waiting for feedback asked for in comment #1.

--- Comment #5 from Frank Ch. Eigler  2010-09-27 
16:34:50 UTC ---
test test test

[Bug target/45804] ARM: unnecessary sign extension

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Earnshaw  2010-09-27 
16:30:35 UTC ---
This particular case is invalid.  

The ARM ABI requires that short and char result types are extended to 32 bits
(using signed or unsigned extension as appropriate) before being returned. 
Since the compiler can't see inside the asm block to work out what is being
done it cannot remove the uxth instruction on the result.

This does not mean that some of your x-refed reports are invalid though.

[Bug debug/45088] pointer type information lost in debuginfo

[uweigand at gcc dot gnu.org]

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

--- Comment #4 from Ulrich Weigand  2010-09-27 
16:25:01 UTC ---
(In reply to comment #3)
> is this another dup of PR 43628?  should be fixed if it is

No, unfortunately it's not.  In mainline and 4.5 (which have the 43628) fix,
all other GDB C++ test suite regressions over 4.4 are fixed, *except* for the
one described in this bug report.

[Bug debug/45088] pointer type information lost in debuginfo

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2010-09-27 
16:22:18 UTC ---
is this another dup of PR 43628?  should be fixed if it is

[Bug c/45779] pointer difference error/ptrdiff_t representability

[aklauer at rumms dot uni-mannheim.de]

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

--- Comment #1 from Alexander  2010-09-27 
16:20:48 UTC ---
While fiddling around a bit more I found that gcc normally doesn't let me
create objects whose size exceeds PTRDIFF_MAX. For objects of size at most
PTRDIFF_MAX, the bug cannot be triggered. The only function I found which does
create such large objects is malloc(). Presumably, its companions calloc() and
realloc() do so as well.

In this light, the best fix for this bug seems to be for malloc() and
companions to simply return NULL upon a request for an object whose size
exceeds PTRDIFF_MAX.

[Bug debug/45088] pointer type information lost in debuginfo

[uweigand at gcc dot gnu.org]

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

Ulrich Weigand  changed:

   What|Removed |Added

 CC||uweigand at gcc dot gnu.org

--- Comment #2 from Ulrich Weigand  2010-09-27 
16:19:31 UTC ---
Any update on this bug?  I'm seeing this in 4.5 as well ...

[Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  
2010-09-27 15:54:06 UTC ---
On Mon, 27 Sep 2010, anemo at mba dot ocn.ne.jp wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45704
> 
> --- Comment #5 from Atsushi Nemoto  2010-09-27 
> 15:48:32 UTC ---
> Here is a similar test case with "packed" attribute, which still produces bad
> result.
> Four load-byte instructions are generated instead of one load-word.
> 
> struct st {
> int ptr;
> } __attribute__ ((packed));
> 
> int foo(struct st *st)
> {
> int v = *(volatile int *)&st->ptr;
> return v & 0xff;
> }
> 
> gcc 4.4.4 works fine (same result with the first test case)
> 
> gcc 4.6.0 20100927 (or 4.5.2 20100927) generates:
> lbu$2,0($4)
> lbu$3,1($4)
> andi$2,$2,0x00ff
> lbu$3,2($4)
> lbu$3,3($4)
> j$31
> nop
> 
> I do not know this should be another PR or not.

It should be as this is likely a problem with unaligned access
support.  I think you can't generally expect unaligned volatile
accesses to work (on ia64 for example they certainly wouldn't).

[Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int

[anemo at mba dot ocn.ne.jp]

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

--- Comment #5 from Atsushi Nemoto  2010-09-27 
15:48:32 UTC ---
Here is a similar test case with "packed" attribute, which still produces bad
result.
Four load-byte instructions are generated instead of one load-word.

struct st {
int ptr;
} __attribute__ ((packed));

int foo(struct st *st)
{
int v = *(volatile int *)&st->ptr;
return v & 0xff;
}

gcc 4.4.4 works fine (same result with the first test case)

gcc 4.6.0 20100927 (or 4.5.2 20100927) generates:
lbu$2,0($4)
lbu$3,1($4)
andi$2,$2,0x00ff
lbu$3,2($4)
lbu$3,3($4)
j$31
nop

I do not know this should be another PR or not.

[Bug other/44803] LIBRARY_PATH should work on cross-compilers

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

  Component|c   |other

--- Comment #3 from Felipe Contreras  
2010-09-27 01:28:24 UTC ---
Is this not clear?

It would be useful to cross-compile like this:

export C_INCLUDE_PATH=/opt/arm/ffmpeg/include
export LIBRARY_PATH=/opt/arm/ffmpeg/lib

But LIBRARY_PATH is ignored.

[Bug other/45806] gcc build failure

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  2010-09-27 
14:02:11 UTC ---
Perhaps you didn't run /sbin/ldconfig after installing libmpc.so.2 into
/usr/local/lib ?

[Bug other/45806] gcc build failure

[terry at chem dot gu.se]

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

terry at chem dot gu.se changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME

--- Comment #5 from terry at chem dot gu.se 2010-09-27 13:13:43 UTC ---
OK, this is a bit strange.

The offending error is:
/home/tjf/InstallTrees/gcc-4.5.1-build/./gcc/cc1: error while loading shared
libraries: libmpc.so.2: cannot open shared object file: No such file or
directory

Now libmpc.so.2 -> libmpc.so.2.0.0 both exist in /usr/local/lib, along with all
the other libraries that are regularly linked to.  Back up in the top-level
config.log we have
configure:5665: gcc -o conftest -g -O2conftest.c  -lmpc -lmpfr -lgmp >&5
which worked happily.

/usr/local/lib is listed in /etc/ld.so.conf.d/libc.conf and usually works. 
LD_LIBRARY_PATH is unset.

Explicitly setting LD_LIBRARY_PATH to /usr/local/lib has gcc compiling past
this point as we speak.

I've never before had library path issues on this machine.  On a very similar
x86_64 machine (that has LD_LIBRARY_PATH explicitly set by default) 4.5.1
compiled without issue.

I'll close this now, but will nonetheless welcome any comments anyone wants to
make that might shed light on why my configuration appears to have gone
selectively bung.

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[bernds at gcc dot gnu.org]

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

--- Comment #22 from Bernd Schmidt  2010-09-27 
12:45:36 UTC ---
Thanks, that's very well done.  I've investigated a bit, and it seems the
sequence

  mark_pseudo_regno_live (REGNO (reg));
  mark_pseudo_regno_live (REGNO (dreg));
  mark_pseudo_regno_dead (REGNO (reg));
  mark_pseudo_regno_dead (REGNO (dreg));

in make_pseudo_conflict is breaking lifetimes of subwords of one of the DImode
registers.  Not entirely sure yet how to fix it, but I'll think of something.

[Bug other/45806] gcc build failure

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2010-09-27 
12:31:53 UTC ---
That looks like the top-level log, the problem is while configuring libgcc, so
you need to look in i686-pc-linux-gnu/libgcc/config.log

[Bug web/45811] New: bugzilla: editing search loses host/target/build

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

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

   Summary: bugzilla: editing search loses host/target/build
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sch...@linux-m68k.org


Editing a search involving the host/target/build custom fields loses the search
string in those fields.

http://gcc.gnu.org/bugzilla/query.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&cf_gcctarget=m68k&cf_gcctarget_type=allwordssubstr&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&query_format=advanced

[Bug other/45806] gcc build failure

[terry at chem dot gu.se]

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

--- Comment #3 from terry at chem dot gu.se 2010-09-27 12:23:45 UTC ---
I could see nothing in config.log that looked to my untrained eye like the
problem, so I didn't attach it before.  Here it is.  What am I missing here?

[Bug target/40414] gcc 4.4.0 error at postreload.c:396

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

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

Andreas Schwab  changed:

   What|Removed |Added

  Known to work||4.5.0
   Target Milestone|4.5.2   |4.4.6

[Bug objc++/35551] internal compiler error: in encode_gnu_bitfield, at objc/objc-act.c:8175

[schnorr at gmail dot com]

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

--- Comment #3 from Lucas  2010-09-27 11:52:44 UTC ---
I am also having a problem to uncompact this file.
Unfortunately, I no longer have the original
source file that caused that error with gcc.

[Bug c++/44561] using nullptr_t with -flto/-fwhopr causes ICE: tree code 'lang_type' is not supported in gimple streams

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2010-09-27 
11:10:21 UTC ---
*** Bug 45789 has been marked as a duplicate of this bug. ***

[Bug lto/45789] [4.6 Regression] ICE: tree code 'lang_type' is not supported in gimple streams with -flto when using __builtin_printf()

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Richard Guenther  2010-09-27 
11:10:21 UTC ---
Dup

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

[Bug c++/45799] ICE + segfault when compiling Qt's WebKit JavaScriptCore

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2010-09-27 
11:08:35 UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580 it was.

[Bug c++/45799] ICE + segfault when compiling Qt's WebKit JavaScriptCore

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Richard Guenther  2010-09-27 
11:07:26 UTC ---
This has been fixed and there is a duplicate bug about this.  I just can't
find it because bugzilla is slow these days.

[Bug bootstrap/45801] [4.6 regression] powerpc64-linux bootstrap comparison failure

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug target/45804] ARM: unnecessary sign extension

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||arm-*-*
  Component|c   |target
   Severity|normal  |enhancement

[Bug other/45808] FreeBSD: -pthread is handled incompletely

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2010-09-27 
10:49:36 UTC ---
Patches should be posted to gcc-patc...@gcc.gnu.org

[Bug lto/45810] 40% slowdown when using LTO for a single-file program

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2010-09-27 
10:48:33 UTC ---
For single-file programs -fwhole-program and -flto should be basically
equivalent if the Frontend provides correctly merged decls.  I suppose
it does not and thus we do less inlining with -fwhole-program compared
to -flto.

[Bug lto/45810] 40% slowdown when using LTO for a single-file program

[Joost.VandeVondele at pci dot uzh.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at pci
   ||dot uzh.ch

--- Comment #1 from Joost VandeVondele  
2010-09-27 10:39:05 UTC ---
I have observed similar 40% slowdown in CP2K as a result of LTO. I haven't yet
investigated.

[Bug lto/45790] 1308 new GCC h...@164592 regressions

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  2010-09-27 
10:31:13 UTC ---
On powerpc64-unknown-linux-gnu, this problem seems to only affect the
gcc.dg/vmx/* tests (see
http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg02397.html ).

[Bug target/45807] Lying eh_frame r2 save info causes crashes with static libgcc_eh and libstdc++

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.09.27 10:27:49
   date||
 Ever Confirmed|0   |1

[Bug lto/45810] New: 40% slowdown when using LTO for a single-file program

[burnus at gcc dot gnu.org]

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

   Summary: 40% slowdown when using LTO for a single-file program
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


That's on a Intel Core(TM)2 Duo CPU E8400 @ 3.00GHz and using CentOS Linux 5.5
(x86-64)  with glibc-2.5-49.el5_5.2, binutils-2.17.50.0.6-14.el5 and
gcc version 4.6.0 20100921 (experimental) [trunk revision 164472] (GCC)

The performance for fatigue of the Polyhedron test case drops by 40% if one
enables LTO (using -fwhole=program):

gfortran -march=native -ffast-math -funroll-loops -fwhole-program
-fno-protect-parens -O3

real0m5.115s / user0m5.071s / sys 0m0.015s

gfortran -march=native -ffast-math -funroll-loops -flto -fwhole-program
-fno-protect-parens -O3

real0m7.225s / user0m7.129s / sys 0m0.017s

For the other test cases, the results are mostly similar w/ and w/o LTO though
in tendency, the non-LTO version seems to be slightly slower (but also other
programs are running now thus the results are not 100% comparable with my
previous ones at
https://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/iff/ )

[Bug lto/45790] 1308 new GCC h...@164592 regressions

[jiez at gcc dot gnu.org]

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

Jie Zhang  changed:

   What|Removed |Added

 CC||jiez at gcc dot gnu.org

--- Comment #2 from Jie Zhang  2010-09-27 10:07:21 UTC 
---
The same issue was found on arm-none-eabi:

http://gcc.gnu.org/ml/gcc-patches/2010-09/msg02004.html

[Bug preprocessor/45809] New: Canonicalize file names output during dependency generation

[konrad.schwarz at siemens dot com]

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

   Summary: Canonicalize file names output during dependency
generation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: konrad.schw...@siemens.com


I have a make file responsible for files in several directories (say
main_dir, other_dir).

The files in these directories include header files using relative paths:

other_dir/source.c
# include "../main_dir/header.h"


GCC, invoked with -MMD, produces dependency files of the form

other_dir/source.d
../other_dir/source.o:\
../other_dir/../main_dir/header.h


These dependency files are included via

Makefile
-include ../other_dir/*.d


If header.h is generated using a rule of the form

Makefile
header.h: header.m4
m4 header.m4 > header.h


(GNU) make fails to realize that a change to header.m4 requires a rebuild
of ../other_dir/source.o, since make uses string compares to identify targets
with prerequisites.

Pseudo-targets in Make require this sort of comparison.

Were GCC to canonicalize the file names in the dependency files it generates:

other_dir/source.d
../other_dir/source.o:\
 header.h


this problem would be solved.

[Bug lto/45790] 1308 new GCC h...@164592 regressions

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org,
   ||rguenther at suse dot de

--- Comment #1 from Dominique d'Humieres  2010-09-27 
09:42:21 UTC ---
This pr seems to be due to revision 164591:

Author:rguenth
Date:Fri Sep 24 13:21:30 2010 UTC (2 days, 19 hours ago)
Changed paths:5
Log Message:
2010-09-24  Richard Guenther  

* c-decl.c (pop_scope): Always set file-scope DECL_CONTEXT.
Make sure to not call set_type_context with error_mark_node.
* langhooks.c (lhd_set_decl_assembler_name): Use DECL_FILE_SCOPE_P.

* gcc.dg/lto/20091006-2_0.c: Prune warnings.
Changed paths:

PathDetails
trunk/gcc/ChangeLogmodified , text changed
trunk/gcc/c-decl.cmodified , text changed
trunk/gcc/langhooks.cmodified , text changed
trunk/gcc/testsuite/ChangeLogmodified , text changed
trunk/gcc/testsuite/gcc.dg/lto/20091006-2_0.cmodified , text changed

If I revert it at revision 164604, the failures are gone.

[Bug target/45808] New: FreeBSD: -pthread is handled incompletely

[avg at icyb dot net.ua]

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

   Summary: FreeBSD: -pthread is handled incompletely
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@icyb.net.ua


On recent (and maintained) versions of FreeBSD it is required that shared
libraries using pthread functions are linked to libpthread.  This was not the
case in older and now unsupported versions of the OS.
So, currently GCC on FreeBSD expands -pthread option to -lpthread only when
target is a final binary.  When compilation target is a shared library -pthread
is ignored.
This needs to be fixed in -pthread specifications for FreeBSD.

[Bug rtl-optimization/45792] [4.6 Regression]: cris-elf build failure (hangs) due to fix for PR44374

[bernds at gcc dot gnu.org]

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

--- Comment #3 from Bernd Schmidt  2010-09-27 
09:32:14 UTC ---
Looking at it now.

[Bug rtl-optimization/45792] [4.6 Regression]: cris-elf build failure (hangs) due to fix for PR44374

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

   Keywords||patch
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2010-09/msg02097.htm
   ||l
 AssignedTo|unassigned at gcc dot   |hp at gcc dot gnu.org
   |gnu.org |

--- Comment #2 from Hans-Peter Nilsson  2010-09-27 
09:16:59 UTC ---
I'd better take it, now that I have a patch.  Bernd, I certainly don't mind if
you grab this PR for yourself, definitely if you don't like the patch.

[Bug other/45806] gcc build failure

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.09.27 09:13:07
   date||
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2010-09-27 
09:13:07 UTC ---
(In reply to comment #0)
> checking for suffix of object files... configure: error: in
> `/home/tjf/InstallTrees/gcc-4.5.1-build/i686-pc-linux-gnu/libgcc':
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.

Like it says, see config.log for more details, it could be a number of things.

[Bug target/45807] New: Lying eh_frame r2 save info causes crashes with static libgcc_eh and libstdc++

[amodra at gmail dot com]

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

   Summary: Lying eh_frame r2 save info causes crashes with static
libgcc_eh and libstdc++
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amo...@gmail.com


Created attachment 21893
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=21893
testcase from Allan Pratt 

In the eh_frame description for _Unwind_Resume_or_Rethrow, I see

12a0 007c 12a4 FDE cie= pc=100712c0..100714f8
  DW_CFA_advance_loc: 4 to 100712c4
  DW_CFA_def_cfa_offset: 3216
  DW_CFA_advance_loc: 164 to 10071368
  DW_CFA_offset_extended_sf: r2 at cfa+40
[snip]

but, r2 is not saved by this function, at least, not before
_Unwind_RaiseException is called.  So the lie that r2 is saved at
cfa+40 once we are past 10071368 can cause the unwinder to return a bad
value for r2 when unwinding through _Unwind_Resume_or_Rethrow from 
_Unwind_RaiseException.  r2 won't be saved if _Unwind_Resume_of_Rethrow is
called statically from the same toc group, but this bug is often covered by the
fact that a previous call into exception handling functions has written the
correct r2 value to the stack.

100712c0 <._Unwind_Resume_or_Rethrow>:
100712c0:   f8 21 f3 71 stdur1,-3216(r1)
100712c4:   7d 80 00 26 mfcrr12
100712c8:   7c 08 02 a6 mflrr0
100712cc:   d9 c1 0c 00 stfdf14,3072(r1)
100712d0:   d9 e1 0c 08 stfdf15,3080(r1)
100712d4:   f8 01 0c a0 std r0,3232(r1)
100712d8:   da 01 0c 10 stfdf16,3088(r1)
100712dc:   da 21 0c 18 stfdf17,3096(r1)
100712e0:   da 41 0c 20 stfdf18,3104(r1)
100712e4:   da 61 0c 28 stfdf19,3112(r1)
100712e8:   da 81 0c 30 stfdf20,3120(r1)
100712ec:   da a1 0c 38 stfdf21,3128(r1)
100712f0:   da c1 0c 40 stfdf22,3136(r1)
100712f4:   da e1 0c 48 stfdf23,3144(r1)
100712f8:   db 01 0c 50 stfdf24,3152(r1)
100712fc:   db 21 0c 58 stfdf25,3160(r1)
10071300:   db 41 0c 60 stfdf26,3168(r1)
10071304:   db 61 0c 68 stfdf27,3176(r1)
10071308:   db 81 0c 70 stfdf28,3184(r1)
1007130c:   db a1 0c 78 stfdf29,3192(r1)
10071310:   db c1 0c 80 stfdf30,3200(r1)
10071314:   db e1 0c 88 stfdf31,3208(r1)
10071318:   f9 c1 0b 70 std r14,2928(r1)
1007131c:   f9 e1 0b 78 std r15,2936(r1)
10071320:   fa 01 0b 80 std r16,2944(r1)
10071324:   fa 21 0b 88 std r17,2952(r1)
10071328:   fa 41 0b 90 std r18,2960(r1)
1007132c:   fa 61 0b 98 std r19,2968(r1)
10071330:   fa 81 0b a0 std r20,2976(r1)
10071334:   fa a1 0b a8 std r21,2984(r1)
10071338:   fa c1 0b b0 std r22,2992(r1)
1007133c:   fa e1 0b b8 std r23,3000(r1)
10071340:   fb 01 0b c0 std r24,3008(r1)
10071344:   fb 21 0b c8 std r25,3016(r1)
10071348:   fb 41 0b d0 std r26,3024(r1)
1007134c:   fb 61 0b d8 std r27,3032(r1)
10071350:   fb 81 0b e0 std r28,3040(r1)
10071354:   fb a1 0b e8 std r29,3048(r1)
10071358:   fb c1 0b f0 std r30,3056(r1)
1007135c:   fb e1 0b f8 std r31,3064(r1)
10071360:   e8 03 00 10 ld  r0,16(r3)
10071364:   7c 7f 1b 78 mr  r31,r3
10071368:   2f a0 00 00 cmpdi   cr7,r0,0
1007136c:   f8 61 0b 50 std r3,2896(r1)
10071370:   f8 81 0b 58 std r4,2904(r1)
10071374:   f8 a1 0b 60 std r5,2912(r1)
10071378:   f8 c1 0b 68 std r6,2920(r1)
1007137c:   91 81 0c 98 stw r12,3224(r1)
10071380:   40 9e 00 e0 bne-cr7,10071460
<._Unwind_Resume_or_Rethrow+0x1a0>
10071384:   4b ff f8 0d bl  10070b90 <._Unwind_RaiseException>