>>> On 04.01.11 at 21:02, Jakub Jelinek wrote:
> On Tue, Jan 04, 2011 at 10:35:42AM -0800, H. Peter Anvin wrote:
>> On 01/04/2011 09:56 AM, H.J. Lu wrote:
>> >>
>> >> I think it is a gross misconception to tie the ABI to the ELF class of
>> >> an object. Specifying the ABI should imo be done via e
Snapshot gcc-4.4-20110104 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110104/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 3 January 2011 05:24, Nathan Ridge wrote:
>
> Is this the desired behaviour?
Questions about whether code is valid or whether gcc has a bug should
be sent to the gcc-h...@gcc.gnu.org mailing list or entered into
bugzilla, thanks.
On Tue, Jan 04, 2011 at 10:35:42AM -0800, H. Peter Anvin wrote:
> On 01/04/2011 09:56 AM, H.J. Lu wrote:
> >>
> >> I think it is a gross misconception to tie the ABI to the ELF class of
> >> an object. Specifying the ABI should imo be done via e_flags or
> >> one of the unused bytes of e_ident, and
On 01/04/2011 09:56 AM, H.J. Lu wrote:
>>
>> I think it is a gross misconception to tie the ABI to the ELF class of
>> an object. Specifying the ABI should imo be done via e_flags or
>> one of the unused bytes of e_ident, and in all reality the ELF class
>> should *only* affect the file layout (and
This release added the ILP32 support
http://www.kernel.org/pub/linux/devel/binutils/ilp32/abi.pdf
to Linux/x86-64.
H.J.
---
This is the beta release of binutils 2.21.51.0.5 for Linux, which is
based on binutils 2011 0104 in CVS on sourceware.org plus various
changes. It is purely for Linux.
Al
Hi,
libiberty/.gitignore was added to src. But it isn't in gcc tree.
--
H.J.
On Mon, Jan 3, 2011 at 2:40 AM, Jan Beulich wrote:
On 30.12.10 at 21:02, "H.J. Lu" wrote:
>>
>> Here is the ILP32 psABI:
>>
>> http://www.kernel.org/pub/linux/devel/binutils/ilp32/
>>
>
> I think it is a gross misconception to tie the ABI to the ELF class of
> an object. Specifying the ABI s
On Tue, Jan 4, 2011 at 10:22, Richard Guenther
wrote:
> Ugh. Sebastian - can we nuke tree-loop-linear compeltely and
> make -ftree-loop-linear an alias for -floop-interchange without
> regressions? I'd like to reduce the number of broken passes from
> 2 to 1 this way ...
I wouldn't mind removin
On Mon, Jan 3, 2011 at 12:29 AM, Eric Botcazou wrote:
>> I was wondering about that lately. Should testsuite failures with
>> --enable-checking=all be reported? IIRC, the 4.5 branch won't even
>> bootstrap with that setting.
>
> I'd think so, but only for the trunk probably.
And don't report the
On 4 January 2011 14:11, Klaus Rudolph wrote:
>
>> > Is my code wrong
>>
>> Yes. You need to define A::x.
>
> Grrr... so stupid! :-)
>
> Yes, you are right. I stumbled that only a few lines generates an error. Yes,
> the compiler optimize them out if the access is direct. With -O3
> it compiles a
On 01/04/11 15:10, H.J. Lu wrote:
We need a testcase to investigate.
This is now PR47167.
Cheers,
Martin
> > Is my code wrong
>
> Yes. You need to define A::x.
Grrr... so stupid! :-)
Yes, you are right. I stumbled that only a few lines generates an error. Yes,
the compiler optimize them out if the access is direct. With -O3
it compiles and links without errors also without having const int A::x
On Tue, Jan 4, 2011 at 5:57 AM, Martin Reinecke
wrote:
>
>
> On 01/04/11 14:48, H.J. Lu wrote:
>>
>> On Tue, Jan 4, 2011 at 4:43 AM, Martin Reinecke
>> wrote:
>>>
>>> Hi,
>>>
>>> while benchmarking a numerical C library making heavy use of SSE2
>>> intrinsics, I have noticed a significant (aroun
On 01/04/11 14:48, H.J. Lu wrote:
On Tue, Jan 4, 2011 at 4:43 AM, Martin Reinecke
wrote:
Hi,
while benchmarking a numerical C library making heavy use of SSE2
intrinsics, I have noticed a significant (around 10 percent) slowdown
in the code generated by the current gcc trunk, compared to th
On 01/04/2011 12:49 PM, Klaus Rudolph wrote:
Is my code wrong
Yes. You need to define A::x.
Add this line:
const int A::x;
If the code is wrong, I expect a compiler error not a linker message!
No, because A::x might be defined in another translation unit.
Andrew.
On Tue, Jan 4, 2011 at 4:43 AM, Martin Reinecke
wrote:
> Hi,
>
> while benchmarking a numerical C library making heavy use of SSE2
> intrinsics, I have noticed a significant (around 10 percent) slowdown
> in the code generated by the current gcc trunk, compared to the one
> produced by the 4.5.1 r
Hi all,
the following code fails with gcc 4.4.3,4.5.0 and 4.6 snapshot (some weeks old)
:
#include
using namespace std;
class A
{
public:
static const int x=10;
};
class Zgr_A
{
public:
A* operator->() { return (A*)0; }
};
template
class Zgr
{
public:
Hi,
while benchmarking a numerical C library making heavy use of SSE2
intrinsics, I have noticed a significant (around 10 percent) slowdown
in the code generated by the current gcc trunk, compared to the one
produced by the 4.5.1 release.
It's quite hard to reduce the code to a small test case, b
On 01/04/2011 07:33 AM, Ian Lance Taylor wrote:
On Thu, Dec 30, 2010 at 9:07 PM, Jie Zhang wrote:
For a minimal fix, I propose to change combinable fields of assembly
languages in default_compilers[] to 0. See the attached patch
"gcc-not-combine-assembly-inputs.diff". I don't know why the comb
Status
==
Stage 3 is over and the trunk is now in regression and documentation
fixes only mode (operating as if we were on a release branch). This
means we are now moving towards a release candidate of GCC 4.6.0
which can materialize once the list of serious regressions no longer
contains a
21 matches
Mail list logo
