Jason Merrill wrote:
> It isn't such a corner case, unfortunately; any code that tries to
> overload on multiple vector sizes (i.e. MMX and SSE vectors) will break.
> See bug 12909 and its duplicates. This is becoming more of a problem
> with the advent of the Intel AVX extension.
This still se
On 11/12/2009 05:19 PM, Mark Mitchell wrote:
So, I still tend to think that the best thing is to put the vector stuff
into v4, and switch that on when we update libstdc++. I think your
suggest is coherent and well-reasoned, but it seems like a lot of
complexity to deal with a template corner cas
Snapshot gcc-4.5-20091112 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20091112/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Jason Merrill wrote:
>> So, do you consider ABIv3 there only as a theoretical conformance
>> option? In other words, not something we're going to make the default
>> in any forseeable future? (Those aren't meant to be rhetorical
>> questions -- I'm just asking.)
>
> That has been my thinking, b
On 11/12/2009 04:48 PM, Mark Mitchell wrote:
So, do you consider ABIv3 there only as a theoretical conformance
option? In other words, not something we're going to make the default
in any forseeable future? (Those aren't meant to be rhetorical
questions -- I'm just asking.)
That has been my t
Jason Merrill wrote:
> I think that a linear progression is sufficient, but I want an
> additional point between 2 and 3 since 2 is the current default and 3
> already has meaning. Thus the 2.1 suggestion.
But, there's no longer a total ordering on ABIs; 3 isn't "bigger than"
2.1 anymore. (Pres
On 11/12/2009 04:32 PM, Mark Mitchell wrote:
I understand the argument, but it sounds overly complicated. Or else
not complicated enough. If we no longer think that a linear progression
of ABI versions is sufficient, then we should have switches for picking
your point in the multi-dimensional s
Hi,
this is WIP patch to deal with the unreachable clones problem. It
basically renders the clones as unanalyzed cgraph nodes (but with still
body in) so IPA passes don't see them.
Honza
Index: cgraph.c
===
--- cgraph.c(revision
Jason Merrill wrote:
> There is a difference from v3, which is just a correction to match the
> ABI document; it doesn't prevent us from implementing the full language,
> which is why we never bumped the default. So I would like to be able to
> make the vector change without also making the templ
Jason Merrill wrote:
> On 11/12/2009 11:50 AM, Ulrich Drepper wrote:
>> On 11/12/2009 08:35 AM, Jason Merrill wrote:
I'd favor this if you can emit aliases with the old names wherever this
is possible and currently done.
>>>
>>> I suppose if we unconditionally use the new mangling and emi
Axel Freyn wrote:
> Hi Ansis,
>
> first: you should use gcc-h...@gcc.gnu.org for questions like this...
Indeed. However, from the gcc@ point of view:
> Yes, this approach is save.
No, not remotely, and everyone on this list already knows why (or ought to
after a few moments thought, or el
* Paul Edwards wrote on Thu, Nov 12, 2009 at 03:02:59PM CET:
Well, I have good news to report. The restructuring was a success.
That means with those 30-odd changes to the configure scripts, I
was able to get an auto-host.h built that allowed me to take the
generated source and compile it with
Basile STARYNKEVITCH wrote:
Hello All
It seems that gcc/Makefile.in and friends support that the gcc/REVISION
contains some revision numbering.
Why does gcc/REVISION in the trunk svn does not contains something like
$Revision$
or perhaps having the gcc/Makefile.in containing something like a
Hello All
It seems that gcc/Makefile.in and friends support that the gcc/REVISION
contains some revision numbering.
Why does gcc/REVISION in the trunk svn does not contains something like
$Revision$
or perhaps having the gcc/Makefile.in containing something like around line 805
REVISION := $
> Jan Hubicka wrote:
> > I am testing patch for that still.
> > The current version is (updated per Joseph's comment about COMDAT making
> > sence
> > on !PUBLIC functions).
> >
> Thanks Honza, I just built successfully r154128
Note that there are still testsuite regressions found by the sanit
Hello Paul,
* Paul Edwards wrote on Thu, Nov 12, 2009 at 03:02:59PM CET:
> Well, I have good news to report. The restructuring was a success.
>
> That means with those 30-odd changes to the configure scripts, I
> was able to get an auto-host.h built that allowed me to take the
> generated source
On 11/12/2009 01:18 PM, Mark Mitchell wrote:
b) Take over -fabi-version=3 and bump the template arg change to v4.
I'm not sure what "take over" means, but I think this change should be
in v4. People might be using v3, and we shouldn't break their world.
Introducing 2.1, or a separate flag, see
Jan Hubicka wrote:
> I am testing patch for that still.
> The current version is (updated per Joseph's comment about COMDAT making sence
> on !PUBLIC functions).
>
Thanks Honza, I just built successfully r154128
Paolo.*
*
On Thu, 12 Nov 2009, Paolo Carlini wrote:
> the build is currently, ie 154122, broken in libstdc++-v3:
>
> ./src/system_error.cc:95:1: internal compiler error:
> Segmentation fault
>
> Version 154120 works fine for me.
FWIW, seen for cris-elf too. (Worked: r154119, failed from: r154122.)
On Thu, Nov 12, 2009 at 12:03 PM, Jack Howarth wrote:
> Are there any plans for further merges out of the
> graphite branch before gcc 4.5 is branched? I was
> under the impression that the graphite developers
> originally intended to keep trunk more closely
> synchronized with the graphite bran
> Hi,
>
> the build is currently, ie 154122, broken in libstdc++-v3:
>
> ./src/system_error.cc:95:1: internal compiler error:
> Segmentation fault
>
> Version 154120 works fine for me.
I am testing patch for that still.
The current version is (updated per Joseph's comment about COMDAT ma
Richard Henderson wrote:
> On 11/12/2009 07:24 AM, Jason Merrill wrote:
>> 1) Leave the current mangling as is
>> 2) Leave the current mangling as is for the most common vector size on a
>> target (SSE, Altivec) and use the new mangling for other vector sizes.
>> 3) Switch to the new mangling
>
>
Hi,
the build is currently, ie 154122, broken in libstdc++-v3:
./src/system_error.cc:95:1: internal compiler error:
Segmentation fault
Version 154120 works fine for me.
Paolo.
On 11/12/2009 11:50 AM, Ulrich Drepper wrote:
On 11/12/2009 08:35 AM, Jason Merrill wrote:
I'd favor this if you can emit aliases with the old names wherever this
is possible and currently done.
I suppose if we unconditionally use the new mangling and emit a weak
alias with the old mangling, o
Of course:
mov r6 = InputReg1
mov InputReg1 = InputReg2
mov InputReg2 = tmp
should read:
mov r6 = InputReg1
mov InputReg1 = InputReg2
mov InputReg2 = r6
Sorry about that.
Jc
On Thu, Nov 12, 2009 at 12:07 PM, Jean Christophe Beyler
wrote:
> Dear all,
>
> As I continue to work on this I have f
Dear all,
As I continue to work on this I have found something that is surprising.
I wrote this code :
int foo (int argc, int argv)
{
bar (argv, argc);
return 0;
}
On my architecture, this is transformed into the following assembly code:
mov r6 = InputReg1
mov InputReg1 = InputReg2
mov I
Are there any plans for further merges out of the
graphite branch before gcc 4.5 is branched? I was
under the impression that the graphite developers
originally intended to keep trunk more closely
synchronized with the graphite branch during the
gcc 4.5 release cycle and this doesn't seem to ha
On Thu, Nov 12, 2009 at 10:59 AM, Jack Howarth wrote:
> I am a tad confused by this thread. Is MPC going to be mandatory
> along side of gmp/mpfr for the gcc 4.5 release or is this further
> out into the future than that? Thanks in advance for any clarifications.
It's going to be mandatory.
Ri
Jan Hubicka wrote:
Perhaps the question is when not to use -flto and use -fwhopr instead?
My rule of thumb is: Try -flto first, if it does not work (running out
of memory), try -fwhopr. I think the advantage of -flto is also that it
is better tested, while -fwhopr has known issues.
-fwhopr is
I am a tad confused by this thread. Is MPC going to be mandatory
along side of gmp/mpfr for the gcc 4.5 release or is this further
out into the future than that? Thanks in advance for any clarifications.
Jack
On Thu, 12 Nov 2009, Daniel Jacobowitz wrote:
> On Thu, Nov 12, 2009 at 08:10:13AM -0800, Richard Henderson wrote:
> > On 11/12/2009 07:24 AM, Jason Merrill wrote:
> > >1) Leave the current mangling as is
> > >2) Leave the current mangling as is for the most common vector size on a
> > >target (SS
On 11/12/2009 08:35 AM, Jason Merrill wrote:
I'd favor this if you can emit aliases with the old names wherever this
is possible and currently done.
I suppose if we unconditionally use the new mangling and emit a weak
alias with the old mangling, old external references will resolve to
somthing
> On Wed, Nov 4, 2009 at 1:20 PM, Toon Moene wrote:
> > You don't happen to recall the bug number ?
>
> It might be related to PR 41735 which I noticed when looking at the
> generated assembly and trying to compare 4.5 to 4.4.
I fixed this bug today, so it might help. But it is related to COMDAT
> > Perhaps the question is when not to use -flto and use -fwhopr instead?
>
> My rule of thumb is: Try -flto first, if it does not work (running out
> of memory), try -fwhopr. I think the advantage of -flto is also that it
> is better tested, while -fwhopr has known issues.
-fwhopr is quite brok
On 11/12/2009 11:14 AM, Ulrich Drepper wrote:
On 11/12/2009 07:24 AM, Jason Merrill wrote:
c) Use -fabi-version=2.1.
I'd favor this if you can emit aliases with the old names wherever this
is possible and currently done.
I suppose if we unconditionally use the new mangling and emit a weak
a
On Thu, Nov 12, 2009 at 08:10:13AM -0800, Richard Henderson wrote:
> On 11/12/2009 07:24 AM, Jason Merrill wrote:
> >1) Leave the current mangling as is
> >2) Leave the current mangling as is for the most common vector size on a
> >target (SSE, Altivec) and use the new mangling for other vector siz
> On Wed, Nov 4, 2009 at 8:19 PM, Toon Moene wrote:
> > Jan,
> >
> > I had some time to study the example I sent you a couple of weeks ago.
> >
> > According to visible inspection of the source code, there are 5 functions
> > (subroutines in Fortran parlance) that are called once:
> >
> > MAIN c
On 11/12/2009 07:24 AM, Jason Merrill wrote:
c) Use -fabi-version=2.1.
I'd favor this if you can emit aliases with the old names wherever this
is possible and currently done.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
On 11/12/2009 07:24 AM, Jason Merrill wrote:
1) Leave the current mangling as is
2) Leave the current mangling as is for the most common vector size on a
target (SSE, Altivec) and use the new mangling for other vector sizes.
3) Switch to the new mangling
I vote for 2.
a) Add the vector change
On 11/12/2009 05:40 AM, Mohamed Shafi wrote:
So i need to change the mode of the register from SI to HI after
reloading. Is that allowed?
Of course. It's also allowed before reload:
(subreg:HI (reg:SI foo) 0)
See gen_lowpart.
r~
From: "David Edelsohn"
On Thu, Nov 12, 2009 at 10:00 AM, Kaveh R. Ghazi
wrote:
And do we want to update aix5.2 to aix5.3 in our platforms list?
AIX should be updated to 5.3 or 6.1.
David
For the last two months or so, the AIX reports I see are mostly (all?) for
5.3, so I suggest we use
The G++ mangling of SIMD vector types (SSE, Altivec, etc.) is
fundamentally broken as it doesn't currently encode the size of the
vector, only the element type. So overloading of different size vectors
fails. It seems when I implemented this I was modeling the Altivec
__vector qualifier, whic
On Thu, Nov 12, 2009 at 10:00 AM, Kaveh R. Ghazi wrote:
> And do we want to update aix5.2 to aix5.3 in our platforms list?
AIX should be updated to 5.3 or 6.1.
David
From: "Mark Mitchell"
Richard Guenther wrote:
If config.gcc handles both triples the same (*-*-solaris2.10 and
*-*-solaris2.11) then we can consider both at the same level.
Indeed. Furthermore, we certainly wouldn't want to break support for
Solaris 2.10 at this point, so having 2.10 liste
Well, I have good news to report. The restructuring was a success.
That means with those 30-odd changes to the configure scripts, I
was able to get an auto-host.h built that allowed me to take the
generated source and compile it with my own scripts as per
normal.
There's still a stack more work
Hi Ansis,
first: you should use gcc-h...@gcc.gnu.org for questions like this...
On Thu, Nov 12, 2009 at 05:44:58AM -0800, ansis atteka wrote:
> I have a struct in a header file. And I would like to have some of this
> struct member fields to be constant, in case if this header file is included
>
Greetings,
I have a struct in a header file. And I would like to have some of this
struct member fields to be constant, in case if this header file is included
from some particular Cpp files. Motivation for this is to avoid some silly
programmer errors by accidentally writing to this variable, wh
2009/11/10 Richard Henderson :
> On 11/10/2009 05:48 AM, Mohamed Shafi wrote:
>>
>> (define_insn "mulsi3"
>> [(set (match_operand:SI 0 "register_operand" "=&d")
>> (mult:SI (match_operand:SI 1 "register_operand" "%d")
>> (match_operand:SI 2 "register_operand" "d")))]
Andrew Haley wrote:
Within reason that's OK, or you can use pastebin.
Done. Patch attached. All you need to do to build is the following:
svn co svn://openbios.org/openbios/trunk/openbios-devel
cd openbios-devel
patch -p0 < openbios-fibonacci.patch
Then to build on x86:
rm -rf obj-x86/; ./co
Mark Cave-Ayland wrote:
Andrew Haley wrote:
There are a few possibilities, such as changing the alignment of the
data,
but without seeing the code it's hard to say.
It's just a standard checkout from the OpenBIOS SVN with a patch I can
provide to implement the recursive Fibonacci function i
Andrew Haley wrote:
There are a few possibilities, such as changing the alignment of the data,
but without seeing the code it's hard to say.
It's just a standard checkout from the OpenBIOS SVN with a patch I can
provide to implement the recursive Fibonacci function if someone is
happy to tak
Mark Cave-Ayland wrote:
So I'm really confused as to how adding a simply function pointer in the
global declaration section (without even adding any code to reference
it) suddenly incurs an extra 40% overhead? Can anyone explain why this
is, and/or point me to any suitable gcc optimisation gui
Hello
I notice maybe a simular problem.when there is a constant pointer then GCC
>4.0 do not inline the func.gcc 3 do.
that can see on this old whetstone benchmark.with gcc 3.4.0 run faster.
http://www.netlib.org/benchmark/whetstone.c
as soon the term double *Z is change to double Z the func i
>Can anyone tell me what I am doing wrong. The compiler oututs
>__trace__int(0) instead of using the function parameter as an argument:
> _trace_f1(int a,int b) {
> __trace_int(a);
> ...
Got the answer: I was missing
DECL_ARG_TYPE(argdecl) = TREE_TYPE(param);
54 matches
Mail list logo
