Hi ,
are you getting the bug with latest trunk on this code. If you can
tell me , i'll forward it to debian/ubuntu mainters.
On Sat, Aug 23, 2008 at 4:07 AM, Niklaus <[EMAIL PROTECTED]> wrote:
> hi,
> -O0 gives me correct output
> but -O1 or -O2 gives me wrong output. i've attached .s files.
> C
Richard Guenther wrote:
the redundancy elimination performed by DOM can be better handled elsewhere.
The interesting question is there redundancy elimination left in DOM that is
unique and if not, can we get the same overall effect if we remove the
redundancy elimination from DOM and instead usi
Snapshot gcc-4.4-20080822 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080822/
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/trunk
hi andrew,
this is C code. I don't use the functions ispow2 etc.
see the code below .
[EMAIL PROTECTED]:/home/junk/prog/tju# gcc bug_short.c -lm -O2
[EMAIL PROTECTED]:/home/junk/prog/tju# ./a.out
2383,1
31727,1
132265613,1
3145439247023686464
[EMAIL PROTECTED]:/home/junk/prog/tju# gcc bug_short
On Fri, Aug 22, 2008 at 3:14 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 22, 2008 at 2:47 PM, Niklaus <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>>
>> When i run with the options g++ prog.c -o prog and run the exectuable
>> it gives me the correct output
>> but when i do g++ prog.c -o prog
On Fri, Aug 22, 2008 at 2:47 PM, Niklaus <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
> When i run with the options g++ prog.c -o prog and run the exectuable
> it gives me the correct output
> but when i do g++ prog.c -o prog -O2 i get the wrong output
>
On the trunk with -O2 I get the same value as with
Hi,
When i run with the options g++ prog.c -o prog and run the exectuable
it gives me the correct output
but when i do g++ prog.c -o prog -O2 i get the wrong output
The inputs are below
[EMAIL PROTECTED]:/home/junk/prog# g++ bug_gccopt.cpp -O2
[EMAIL PROTECTED]:/home/junk/prog# ./a.out
1
1000
Paolo Carlini wrote:
I'm going to revert again the whole thing and wait for a different,
safe, approach, sorry.
In the short time frame, i.e., something solid for 4.4.0, I would
suggest two possible strategies:
1- Try to re-organize the new code in order to make possible using in
*few* select
H.J. Lu wrote:
Can we declare that Linux/ia32 generates i486 insn by default?
We the gcc team? I'm not sure. For now I'll say no.
We an individual linux distributor? Certainly.
In fact I would be surprised if i586 wasn't a
decent minimum these days.
r~
Paolo Carlini wrote:
So, essentially, you want to *duplicate* all the exports now in
libstdc++ also in libsupc++? Because certainly you can't remove the
exports from libstdc++. No, no, I don't think we want to do that.
Disregard the above. Anyway, I'm not at all convinced that your plan is
doab
Sebastian Redl wrote:
What part, exactly? libstdc++.so still exports the symbol, since the
supc++ and stdc++ libraries are both in there.
So, essentially, you want to *duplicate* all the exports now in
libstdc++ also in libsupc++? Because certainly you can't remove the
exports from libstdc++. N
Paolo Carlini wrote:
Paolo Carlini wrote:
Sebastian Redl wrote:
Could we simply export __exchange_and_add and __atomic_add from
libsupc++ instead of libstdc++? They are pretty basic building
blocks in my opinion.
I agree, in principle.
Well, thinking more about it, I don't see how you can do
Paolo Carlini wrote:
Ok, then, we declare here, that, for gcc4.4.0 this C++0x feature is
available only for targets unconditionally implementing the atomic
builtins. I'll take care of the configury bits.
And even this, given the current structure of the patch, we don't want
to do, because there
On Fri, Aug 22, 2008 at 11:05:12AM -0700, H.J. Lu wrote:
> On Fri, Aug 22, 2008 at 10:53 AM, Sebastian Redl
> <[EMAIL PROTECTED]> wrote:
> > H.J. Lu wrote:
> >>
> >> Can we declare that Linux/ia32 generates i486 insn by default?
> >>
> >
> > Even if we do that, we'll still get errors if someone for
Sebastian Redl wrote:
Paolo Carlini wrote:
I think you should consider also the option of having less stuff
exported from libsupc++: if you somehow manage to have the different
code paths in the headers
That's impossible without exposing unwind-cxx.h to the public, and
that's a can of worms I
On Fri, Aug 22, 2008 at 10:53 AM, Sebastian Redl
<[EMAIL PROTECTED]> wrote:
> H.J. Lu wrote:
>>
>> Can we declare that Linux/ia32 generates i486 insn by default?
>>
>
> Even if we do that, we'll still get errors if someone forces i386. And the
> people doing that are more likely to want to link aga
H.J. Lu wrote:
Can we declare that Linux/ia32 generates i486 insn by default?
Yes, but again, I have to remind you that the problem is with *any*
target or subtarget not implementing the atomic builtins.
Paolo.
H.J. Lu wrote:
Can we declare that Linux/ia32 generates i486 insn by default?
Even if we do that, we'll still get errors if someone forces i386. And
the people doing that are more likely to want to link against the
standalone libsupc++, too, since i386 is mostly used in embedded systems
now
On Fri, Aug 22, 2008 at 10:06 AM, Richard Henderson <[EMAIL PROTECTED]> wrote:
> Sebastian Redl wrote:
>>
>> The other weird thing is that the 32-bit target of the x86_64 compiler
>> doesn't have _GLIBCXX_ATOMIC_BUILTINS_4 defined - apparently it defaults to
>> a i386 profile. Now, I understand tha
Paolo Carlini wrote:
I think you should consider also the option of having less stuff
exported from libsupc++: if you somehow manage to have the different
code paths in the headers
That's impossible without exposing unwind-cxx.h to the public, and
that's a can of worms I don't even want to look
Sebastian Redl wrote:
The other weird thing is that the 32-bit target of the x86_64 compiler
doesn't have _GLIBCXX_ATOMIC_BUILTINS_4 defined - apparently it defaults
to a i386 profile. Now, I understand that for the 32-bit x86 compiler,
but the 64-bit compiler is not a cross-compiler and should
Hi,
What macro do I switch on? _GLIBCXX_ATOMIC_BUILTINS_4?
Yes, should be safe for static switching. I think you should consider
also the option of having less stuff exported from libsupc++: if you
somehow manage to have the different code paths in the headers, then you
can dynamically switch
On Fri, Aug 22, 2008 at 05:34:30PM +0100, Andrew Haley wrote:
> >> I'm having a problem with GCC 2.95.3 that appears to be a compiler
> >> bug.
The handling of overloads with respect to const and non-const modifiers
on pointers was badly broken in gcc 2.95.3. That compiler accepted
so much crud t
Paolo Carlini wrote:
Sebastian Redl wrote:
Could we simply export __exchange_and_add and __atomic_add from
libsupc++ instead of libstdc++? They are pretty basic building blocks
in my opinion.
I agree, in principle. However, sorry, I don't feel like doing that,
it's a non trivial change, becaus
Andrew & Sebastian,
Thank you very much for you help, guys!
It's easier to fix our source code anyway :-)
Best Regards,
--Ray
-Original Message-
From: Andrew Haley [mailto:[EMAIL PROTECTED]
Sent: Friday, August 22, 2008 12:35 PM
To: Sebastian Redl
Cc: Balogh, Ray; [EMAIL PROTECTED]
Sub
Paolo Carlini wrote:
Sebastian Redl wrote:
Could we simply export __exchange_and_add and __atomic_add from
libsupc++ instead of libstdc++? They are pretty basic building blocks
in my opinion.
I agree, in principle.
Well, thinking more about it, I don't see how you can do it without
breaking t
Sebastian Redl wrote:
Could we simply export __exchange_and_add and __atomic_add from
libsupc++ instead of libstdc++? They are pretty basic building blocks
in my opinion.
I agree, in principle. However, sorry, I don't feel like doing that,
it's a non trivial change, because *anything* related t
Paolo Carlini wrote:
Anwyay, one way or the other, l porpose for now let's just support the
new facility only for targets providing the sync builtins and be done
with it. Agreed?
I have no objection to doing that in principle, but it basically means
programming effort in order to remove somethi
Paolo Carlini wrote:
H.J. Lu wrote:
/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_throw.o):
In function `__exchange_and_add_dispatch':^M
/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/ext/atomic
Sebastian Redl wrote:
That's my exception_ptr code again (indirectly, this time).
Apparently, __exchange_and_add has exactly the same problem as
__sync_add_and_fetch_4: it's just not implemented on i386 targets.
Not really, it would be too easy ;) It is implemented of course, but it
is provided
Sebastian Redl wrote:
> Balogh, Ray wrote:
>> Dear GCC folks:
>>
>> I'm having a problem with GCC 2.95.3 that appears to be a compiler
>> bug. It seems to be optimizing out inlined function code with side
>> effects, and is related to binding a non-const pointer to a const
>> pointer reference fun
Balogh, Ray wrote:
Dear GCC folks:
I'm having a problem with GCC 2.95.3 that appears to be a compiler bug. It
seems to be optimizing out inlined function code with side effects, and is
related to binding a non-const pointer to a const pointer reference function
parameter. The problem only h
H.J. Lu wrote:
/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_throw.o):
In function `__exchange_and_add_dispatch':^M
/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/ext/atomicity.h:84:
undefined refe
H.J. Lu wrote:
On Fri, Aug 22, 2008 at 8:59 AM, Paolo Carlini <[EMAIL PROTECTED]> wrote:
Hi,
apparently, between Revisions 139407 and 139411, this test started failing
the build:
FAIL: abi/cxx_runtime_only_linkage.cc (test for excess errors)
Any idea what's going wrong? Maybe HJ can post
Dear GCC folks:
I'm having a problem with GCC 2.95.3 that appears to be a compiler bug. It
seems to be optimizing out inlined function code with side effects, and is
related to binding a non-const pointer to a const pointer reference function
parameter. The problem only happens with optimizat
On Fri, Aug 22, 2008 at 8:59 AM, Paolo Carlini <[EMAIL PROTECTED]> wrote:
> Hi,
>
> apparently, between Revisions 139407 and 139411, this test started failing
> the build:
>
> FAIL: abi/cxx_runtime_only_linkage.cc (test for excess errors)
>
> Any idea what's going wrong? Maybe HJ can post the err
Hi,
apparently, between Revisions 139407 and 139411, this test started
failing the build:
FAIL: abi/cxx_runtime_only_linkage.cc (test for excess errors)
Any idea what's going wrong? Maybe HJ can post the error?
Thanks,
Paolo.
Status
==
The end of stage1 for GCC 4.4 is approaching fast, you have about one
week left to incorporate major changes into GCC for the next release.
There are still two major projects scheduled for merging, the
Integrated Register Allocator branch and the GRAPHITE branch. Please
make sure t
38 matches
Mail list logo
