Re: abs insn with QI and HI mode
Hi Jim, Thanks very much for your email. Will gcc add the optimization support in the future (method 1)? For method 2, if abs accept short/char, may I give the function names as sabs and qabs? Gcc does already have cabs as complex abs, doesn't it? Best regards Maggie Quoting Jim Wilson <[EMAIL PROTECTED]>: Ying Yi wrote: The generated codes do the following operations: 1) extend variable a_HI (HImode) to temp variable SImode, and do abs operation with SImode operators. I find the gimple intermedia represention as shown below: abs is a standard library function that takes an int as an argument. So if you call abs(), then gcc must convert the argument to type int before generating code for the abs. To get your special char/short abs instructions, we need one of two things 1) Optimization support to recognize a sign-extend followed by an abs, where the target has an abs instruction that operates on the pre-extended value. We can then optimize away the sign extend instruction. This optimization support apparently does not exist at the moment, perhaps because no one has needed it before. 2) Alternative abs function calls that accept short/char. We already have abs (int), labs (long), llabs(long long), fabs (double), fabsf (float) and fabsl (long double). -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: RFC: GIMPLE tuples. Design and implementation proposal
>In a message dated 7/9/2007 2:37:03 P.M. Pacific Daylight Time, [EMAIL PROTECTED] writes: >On 7/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> >In a message dated 7/7/2007 4:04:01 A.M. Pacific Daylight Time, Rob1weld >> writes: >> >This page http://deputy.cs.berkeley.edu/ has a link to this document >> http://hal.cs.berkeley.edu/cil/ >> >which describes a means to obtain three-address code here >> http://hal.cs.berkeley.edu/cil/ext.html#toc24 . >> >> >>2007/7/08, Diego Novillo <[EMAIL PROTECTED] >> (mailto:[EMAIL PROTECTED]) >: >> >>Any specific reasons why we should? Better memory savings? Faster >> >>processing? It's not clear from your message what the advantages would >> >>be (ignoring the fact that their implementation language is completely >> >>different). >> >You haven't explained what advantages CIL's IR has over GIMPLE. I thought it was well explained on page: _http://hal.cs.berkeley.edu/cil/cil001.html_ (http://hal.cs.berkeley.edu/cil/cil001.html) Please look at this page: _http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html_ (http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html) If you choose to run CIL _locally_ (not add it to GCC, but _only_ run it on your computer) then you can program in "Deputy". The Deputy language is very much like "C" but uses a few additional annotations which allow program checking when it is compiled. Deputy converts it's "C" to 'regular-C' which is processed by GCC. The result is (obviously) executable. A simple SED script can remove the annotations and leave you with 'regular-C' which can then be released as part of GCC (or you can release 'Deputy-C' with GCC and include the SED script which would process the file and produce the source for stage 1. Doing that "buys you" a better quality of code tested by CIL (and GCC) which is more likely to be correct since it is checked twice. It "costs you" having to learn a few Deputy annotations. When you have the CIL source to look at you can read the source and see if it helps you with GIMPLE that you are re-writing. You don't need to include CIL with GCC 4.3 (but you could since you don't need to learn Ocaml to compile it). The result will be better coding that looks no different and compiles without any modification to the current way of building GCC. The second link (above) may help you more. > I can't tell, but you may be under the impression GIMPLE is something > in the future. It is not. > Our IR is already GIMPLE, and a three address code simplified form of > C. We are simply talking about changing the underlying datastructures > that store it. Yes, I know GCC uses GIMPLE. >Hint: CIL's IR is almost exactly GIMPLE with alpha renaming over multiple units. >--Dan It is your project to write the way you want. You "RFC letter" said "Thoughts/comments on the proposal?". My reply is that this page:_http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html_ (http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html) and this site: _http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/INTRO.html_ (http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/INTRO.html) provide a better explanation of IR issues. You might also wish to read _http://deputy.cs.berkeley.edu/_ (http://deputy.cs.berkeley.edu/) or this one _http://www.cminusminus.org/_ (http://www.cminusminus.org/) or _http://www.nabble.com/Gnu---Lightning-f1717.html_ (http://www.nabble.com/Gnu---Lightning-f1717.html) or ... Best of luck with your project, I hope it brings a _huge_ advance to GCC. Rob
Crossbuild problem x86_64-pc-mingw32 related to crtbegin & crtend
Hi,
I tried to build the cross-compiler for the target x86_64-pc-mingw32 and
noticed some trouble about the crtbegin and crtend for this target. To the
specfile this object was introduced by the patch of Danny Smith from the
14th of Jine 2007. The problem is, that those objects are not compiled and
they seems to be not even build for i?86 AFAICS.
May somebody can help me for this problem. Is it ok to simply remove the
crt*.o from spec file for this target, or should these files be builded
for it ?
Thanks in advance and cheers,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
--
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
Handelsregister: HRA 6744, Amtsgericht Regensburg
Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
Ulrike Döhler, Manuela Kluger
RE: Crossbuild problem x86_64-pc-mingw32 related to crtbegin & crtend
On 10 July 2007 12:19, Kai Tietz wrote: > Hi, > > I tried to build the cross-compiler for the target x86_64-pc-mingw32 and > noticed some trouble about the crtbegin and crtend for this target. To the > specfile this object was introduced by the patch of Danny Smith from the > 14th of Jine 2007. The problem is, that those objects are not compiled and > they seems to be not even build for i?86 AFAICS. > May somebody can help me for this problem. Is it ok to simply remove the > crt*.o from spec file for this target, or should these files be builded > for it ? Are you trying to rebuild in an old objdir from before the patch? I found that something didn't work as I had hoped in the dependencies and I had to blow away my existing build dir and configure from fresh. cheers, DaveK -- Can't think of a witty .sigline today
RE: Crossbuild problem x86_64-pc-mingw32 related to crtbegin & crtend
Kai Tietz Tuesday, 10 July 2007 11:19 p.m. > > Hi, > > I tried to build the cross-compiler for the target > x86_64-pc-mingw32 and > noticed some trouble about the crtbegin and crtend for this > target. To the > specfile this object was introduced by the patch of Danny > Smith from the > 14th of Jine 2007. The problem is, that those objects are not > compiled and > they seems to be not even build for i?86 AFAICS. > The builds are specified in libgcc/config.host for i?86 mingw and cygwin. What happens if you do the same for x86_64-*-mingw*? May somebody can help me for this problem. Is it ok to simply > remove the > crt*.o from spec file for this target, or should these files > be builded > for it ? > How else can you initialize and clean up the Dwarf2 unwind registrations on x86_64-pc-mingw32? Danny
RE: Crossbuild problem x86_64-pc-mingw32 related to crtbegin & crtend
"Dave Korn" wrote on 10.07.2007 13:24:30:
> On 10 July 2007 12:19, Kai Tietz wrote:
>
> Are you trying to rebuild in an old objdir from before the patch?
> I found that something didn't work as I had hoped in the
> dependencies and I had to blow away my existing build dir and
> configure from fresh.
Nope, I used a fresh gcc trunk repository for this.
Cheers,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
--
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
Handelsregister: HRA 6744, Amtsgericht Regensburg
Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
Ulrike Döhler, Manuela Kluger
RE: Crossbuild problem x86_64-pc-mingw32 related to crtbegin & crtend
On 10 July 2007 12:38, Kai Tietz wrote: > "Dave Korn" wrote on 10.07.2007 13:24:30: > >> On 10 July 2007 12:19, Kai Tietz wrote: >> >> Are you trying to rebuild in an old objdir from before the patch? >> I found that something didn't work as I had hoped in the >> dependencies and I had to blow away my existing build dir and >> configure from fresh. > > Nope, I used a fresh gcc trunk repository for this. I would have to infer from that that you build in $srcdir Better show us your configure line then. What host type is this cross for? cheers, DaveK -- Can't think of a witty .sigline today
RE: Crossbuild problem x86_64-pc-mingw32 related to crtbegin & crtend
Hi Danny,
> How else can you initialize and clean up the Dwarf2 unwind
> registrations on x86_64-pc-mingw32?
Clear ;) But I meant, why those objects are not build for this target in
(lib)gcc ?
Cheers,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
--
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
Handelsregister: HRA 6744, Amtsgericht Regensburg
Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
Ulrike Döhler, Manuela Kluger
Re: abs insn with QI and HI mode
> Will gcc add the optimization support in the future (method 1)? Since GCC is a volunteer project, the answer for any sort of question like that is "if somebody writes it, it'll exist and if they don't, it won't". There's no good way to predict what projects people will find interesting.
RE: Crossbuild problem x86_64-pc-mingw32 related to crtbegin & crtend
Hi Dave,
> Better show us your configure line then. What host type is this cross
for?
I used for configure just "--target=x86_64-pc-mingw32".
Cheers,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
--
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
Handelsregister: HRA 6744, Amtsgericht Regensburg
Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
> On 09 July 2007 20:48, Nicolas Alt wrote: > > > Hi! > > > > On the AMD64 / x86-64Bit architecture, some arguments of a functions > > are passed using registers, but there seem to be two different > > conventions out there. The standard ABI uses 6 registers, but > > Microsoft compilers use only 4. Because of that, code compiled with > > gcc cannot call code compiled with a MS compiler without an ugly > > wrapper. > > > > Have there been any efforts to make gcc do function calls the MS way? > > I guess this would be an important feature for mingw on AMD64. > > > Does -mregparm=4 do what you want? Windows and GCC ABIs are on x86-64 more different than that (they was historically developed in parallel). GCC 4.3 will support attribute for this calling convention contributed by Kai Tiez and Richard Henderson, but before that there is not much to do... Honza > > > cheers, > DaveK > -- > Can't think of a witty .sigline today
Re: AMD64 ABI compatibility
> > On 09 July 2007 20:48, Nicolas Alt wrote:
> >
> > > Hi!
> > >
> > > On the AMD64 / x86-64Bit architecture, some arguments of a functions
> > > are passed using registers, but there seem to be two different
> > > conventions out there. The standard ABI uses 6 registers, but
> > > Microsoft compilers use only 4. Because of that, code compiled with
> > > gcc cannot call code compiled with a MS compiler without an ugly
> > > wrapper.
> > >
> > > Have there been any efforts to make gcc do function calls the MS
way?
> > > I guess this would be an important feature for mingw on AMD64.
> >
> >
> > Does -mregparm=4 do what you want?
>
> Windows and GCC ABIs are on x86-64 more different than that (they was
> historically developed in parallel). GCC 4.3 will support attribute for
> this calling convention contributed by Kai Tiez and Richard Henderson,
> but before that there is not much to do...
Note: My name is Kai Tietz ;) not Tiez
I think, it isn't to hard introducing this attributes to the AMD64 abi's.
What names should we use for it? I suggest "x86_64_ms" and "x86_64_linux".
Is this ok for you.
Cheers,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
--
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
Handelsregister: HRA 6744, Amtsgericht Regensburg
Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
> > Windows and GCC ABIs are on x86-64 more different than that (they was
> > historically developed in parallel). GCC 4.3 will support attribute for
> > this calling convention contributed by Kai Tiez and Richard Henderson,
> > but before that there is not much to do...
> Note: My name is Kai Tietz ;) not Tiez
>
> I think, it isn't to hard introducing this attributes to the AMD64 abi's.
> What names should we use for it? I suggest "x86_64_ms" and "x86_64_linux".
For code bridging MS and GNU codebases (such as wine, or lets say, GNU
runtime in windows if it ends up with non-MS calling convetions).
Then you want to use the attributes to call code from foreign world.
x86_64_linux is probably not very exact - we intended the ABI to be
generally useful for non-linux or non-GNU system (i.e. specified as
System V Application Binary Interface AMD64 Architecture Processor
Supplement with GCC as reference implementation). I believe Sparc and
other unixes are more or less following it too.
For MS I would probably suggest ms_abi (it makes it cleaner that the
attribute is affecting calling convetion). For our abi I am not sure, we
can sysv_abi or something else...
Sorry for the typo in your name!
Honza
> Is this ok for you.
>
> Cheers,
> i.A. Kai Tietz
>
> | (\_/) This is Bunny. Copy and paste Bunny
> | (='.'=) into your signature to help him gain
> | (")_(") world domination.
>
> --
> OneVision Software Entwicklungs GmbH & Co. KG
> Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
> Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
> Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
> Handelsregister: HRA 6744, Amtsgericht Regensburg
> Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
> Dr.-Leo-Ritter-Straße 9 ??? 93049 Regensburg
> Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
> Ulrike Döhler, Manuela Kluger
>
Re: AMD64 ABI compatibility
> > > Windows and GCC ABIs are on x86-64 more different than that (they
was
> > > historically developed in parallel). GCC 4.3 will support attribute
for
> > > this calling convention contributed by Kai Tiez and Richard
Henderson,
> > > but before that there is not much to do...
> > Note: My name is Kai Tietz ;) not Tiez
> >
> > I think, it isn't to hard introducing this attributes to the AMD64
abi's.
> > What names should we use for it? I suggest "x86_64_ms" and
"x86_64_linux".
>
> For code bridging MS and GNU codebases (such as wine, or lets say, GNU
> runtime in windows if it ends up with non-MS calling convetions).
> Then you want to use the attributes to call code from foreign world.
>
> x86_64_linux is probably not very exact - we intended the ABI to be
> generally useful for non-linux or non-GNU system (i.e. specified as
> System V Application Binary Interface AMD64 Architecture Processor
> Supplement with GCC as reference implementation). I believe Sparc and
> other unixes are more or less following it too.
>
> For MS I would probably suggest ms_abi (it makes it cleaner that the
> attribute is affecting calling convetion). For our abi I am not sure, we
> can sysv_abi or something else...
I will prepare an patch for it. For me "ms_abi" and "sysv_abi" is fine.
Cheers,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
--
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
Handelsregister: HRA 6744, Amtsgericht Regensburg
Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
Ulrike Döhler, Manuela Kluger
Re: RFC: GIMPLE tuples. Design and implementation proposal
[EMAIL PROTECTED] writes: > Please look at this page: > _http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html_ > (http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html) That tells me about the MLRISC IR, but it doesn't tell me what significant advantages it has over GIMPLE. > If you choose to run CIL _locally_ (not add it to GCC, but _only_ > run it on your computer) then you can program in "Deputy". The > Deputy language is very much like "C" but uses a few additional > annotations which allow program checking when it is compiled. Your e-mail messages do not make clear what you are proposing. Precisely what change do you propose should be made to GCC itself? If you just want to let us know about an alternative IR, then: thanks. Ian
Re: AMD64 ABI compatibility
> >
> > For MS I would probably suggest ms_abi (it makes it cleaner that the
> > attribute is affecting calling convetion). For our abi I am not sure, we
> > can sysv_abi or something else...
>
> I will prepare an patch for it. For me "ms_abi" and "sysv_abi" is fine.
I would say that it is in general very desirable feature for wine
programmers and similar projects (I would preffer to have
confirmation that they are going to need it however ;).
The implementation will be moderately tricky - you will need to keep
track of functions calling foreign functions and adjust behaviour of
ix86_function_arg_regno_p and friends accordingly.
Also the set of call clobbered registers differs. Since MS ABI has fewer
of them, calling from SYSV ABI is OK, but in the other direction I guess
the call pattern will need to have variants with clobbers of SI/DI.
But if you are interested to implement it, you are definitly welcome ;)
Honza
>
> Cheers,
> i.A. Kai Tietz
>
> | (\_/) This is Bunny. Copy and paste Bunny
> | (='.'=) into your signature to help him gain
> | (")_(") world domination.
>
> --
> OneVision Software Entwicklungs GmbH & Co. KG
> Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
> Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
> Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
> Handelsregister: HRA 6744, Amtsgericht Regensburg
> Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
> Dr.-Leo-Ritter-Straße 9 ??? 93049 Regensburg
> Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
> Ulrike Döhler, Manuela Kluger
>
Re: abs insn with QI and HI mode
Richard Kenner wrote: Will gcc add the optimization support in the future (method 1)? Since GCC is a volunteer project, the answer for any sort of question like that is "if somebody writes it, it'll exist and if they don't, it won't". There's no good way to predict what projects people will find interesting. Unless of course you hire someone to do the work for you, or do it yourself!
Re: AMD64 ABI compatibility
> > >
> > > For MS I would probably suggest ms_abi (it makes it cleaner that the
> > > attribute is affecting calling convetion). For our abi I am not
sure, we
> > > can sysv_abi or something else...
> >
> > I will prepare an patch for it. For me "ms_abi" and "sysv_abi" is
fine.
>
> I would say that it is in general very desirable feature for wine
> programmers and similar projects (I would preffer to have
> confirmation that they are going to need it however ;).
>
> The implementation will be moderately tricky - you will need to keep
> track of functions calling foreign functions and adjust behaviour of
> ix86_function_arg_regno_p and friends accordingly.
>
> Also the set of call clobbered registers differs. Since MS ABI has fewer
> of them, calling from SYSV ABI is OK, but in the other direction I guess
> the call pattern will need to have variants with clobbers of SI/DI.
>
> But if you are interested to implement it, you are definitly welcome ;)
> Honza
I am on that tricky thing ;) I think I need in i386.c an global variable
"ix86_amd64_abi" which helds the the current function abi. This means also
that I have to use instead of TARGET_64BIT_MS_ABI this variable. This var
may initioalized by init_cumulative_args and the overriden
REG_PARM_STACK_SPACE, OUTGOING_REG_PARM_STACK_SPACE, REGPARM_MAX,
SSE_REGPARM_MAX, STACK_BOUNDARY, etc.
Cheers,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
--
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
Handelsregister: HRA 6744, Amtsgericht Regensburg
Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
Ulrike Döhler, Manuela Kluger
crtbegin.o crtend.o
Hi all, What files are the sources of crtbegin.o and crtend.o ? What's their purposes ? thank you sunzir
missing "std::move"
Hi all, I tried to compile some rvalue reference examples by (from H.Hinnant at http://home.twcny.rr.com/hinnant/cpp_extensions/rvalue_ref_rationale.html) with one of the latest GCC 4.3 snapshots, but I'm getting error: 'move' is not a member of 'std' What can I do to get this working ? Cheers Maett Eugster
Re: missing "std::move"
fafa wrote:
Hi all,
I tried to compile some rvalue reference examples by (from H.Hinnant at
http://home.twcny.rr.com/hinnant/cpp_extensions/rvalue_ref_rationale.html)
with one of the latest GCC 4.3 snapshots, but I'm getting
error: 'move' is not a member of 'std'
What can I do to get this working ?
Provide a std::move? ;) std::move is evidently a library function in
namespace std and you should provide one, because we are not delivering
yet a complete C++0x library. For example this one (directly from N1690)
should work:
template
inline typename remove_reference::type&&
move(T&& x)
{ return x; }
(of course remember to include )
Paolo.
Re: AMD64 ABI compatibility
>
> I am on that tricky thing ;) I think I need in i386.c an global variable
> "ix86_amd64_abi" which helds the the current function abi. This means also
> that I have to use instead of TARGET_64BIT_MS_ABI this variable. This var
> may initioalized by init_cumulative_args and the overriden
> REG_PARM_STACK_SPACE, OUTGOING_REG_PARM_STACK_SPACE, REGPARM_MAX,
> SSE_REGPARM_MAX, STACK_BOUNDARY, etc.
In order to get all cases right (ie switching ABIs and calling foreign
function), you need more bookkeeping than this. I am just in hurry to
catch bus, but I will send you little guide tonight.
Honza
>
> Cheers,
> i.A. Kai Tietz
>
> | (\_/) This is Bunny. Copy and paste Bunny
> | (='.'=) into your signature to help him gain
> | (")_(") world domination.
>
> --
> OneVision Software Entwicklungs GmbH & Co. KG
> Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
> Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
> Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
> Handelsregister: HRA 6744, Amtsgericht Regensburg
> Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
> Dr.-Leo-Ritter-Straße 9 ??? 93049 Regensburg
> Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
> Ulrike Döhler, Manuela Kluger
>
Query regarding volatiles and store CCP.
Hi,
While upgrading a port of mine to trunk for a testcase I noticed the
following . Its more of a question for a language lawyer I guess.
The test looks like this.
int spinlock[2];
void foo (void)
{
volatile int * spinlock0;
while (*spinlock0 == 0)
{
/* do nothing */
}
}
Store CCP folds away the assignment in the following way :
Folded statement: *spinlock0_1 = 0;
into: spinlock[0] = 0;
Folded statement: *spinlock1_2 = 0;
into: spinlock[1] = 0;
Folded statement: D.1498_3 = *spinlock0_1;
into: D.1498_3 = spinlock[0];
main ()
{
volatile int * spinlock1;
volatile int * spinlock0;
int D.1498;
:
spinlock0_1 = &spinlock[0];
spinlock1_2 = &spinlock[1];
spinlock[0] = 0;
spinlock[1] = 0;
:
D.1498_3 = spinlock[0];
if (D.1498_3 != 0)
goto ;
else
goto ;
:
return;
}
which later results in the loop getting optimized away. However
marking spinlock as volatile let the loop remain.
I originally thought this to be a problem . However after chatting
about it on IRC I wasn't sure if this was (un)defined behaviour. I
looked through the standard but was unable to figure out from the
prose , whether it stated some place that the object pointed to also
should also have the same type qualifiers as the pointer being used to
access this.
Thanks in advance
Ramana
--
Ramana Radhakrishnan
Re: Query regarding volatiles and store CCP.
On 7/10/07, Ramana Radhakrishnan <[EMAIL PROTECTED]> wrote:
Hi,
While upgrading a port of mine to trunk for a testcase I noticed the
following . Its more of a question for a language lawyer I guess.
The test looks like this.
int spinlock[2];
void foo (void)
{
volatile int * spinlock0;
while (*spinlock0 == 0)
{
/* do nothing */
}
}
Store CCP folds away the assignment in the following way :
Folded statement: *spinlock0_1 = 0;
into: spinlock[0] = 0;
Folded statement: *spinlock1_2 = 0;
into: spinlock[1] = 0;
Folded statement: D.1498_3 = *spinlock0_1;
into: D.1498_3 = spinlock[0];
main ()
{
volatile int * spinlock1;
volatile int * spinlock0;
int D.1498;
:
spinlock0_1 = &spinlock[0];
spinlock1_2 = &spinlock[1];
spinlock[0] = 0;
spinlock[1] = 0;
:
D.1498_3 = spinlock[0];
if (D.1498_3 != 0)
goto ;
else
goto ;
:
return;
}
which later results in the loop getting optimized away. However
marking spinlock as volatile let the loop remain.
I originally thought this to be a problem . However after chatting
about it on IRC I wasn't sure if this was (un)defined behaviour. I
looked through the standard but was unable to figure out from the
prose , whether it stated some place that the object pointed to also
should also have the same type qualifiers as the pointer being used to
access this.
We usually try hard to keep this working (the testcase above is not complete
for sure).
Richard.
Re: missing "std::move"
PS: since apparently people would like that, I decided to implement immediately 20.2.2 of the working draft, thus std::identity, std::forward and std::move. Will be available in in one of the next snapshots of 4.3... Thanks, Paolo.
Re: Query regarding volatiles and store CCP.
Hi Richard,
On 7/10/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 7/10/07, Ramana Radhakrishnan <[EMAIL PROTECTED]> wrote:
> Hi,
>
> While upgrading a port of mine to trunk for a testcase I noticed the
> following . Its more of a question for a language lawyer I guess.
>
> The test looks like this.
>
> int spinlock[2];
>
> void foo (void)
> {
> volatile int * spinlock0;
>
> while (*spinlock0 == 0)
> {
> /* do nothing */
> }
> }
>
> Store CCP folds away the assignment in the following way :
>
>
> Folded statement: *spinlock0_1 = 0;
> into: spinlock[0] = 0;
>
> Folded statement: *spinlock1_2 = 0;
> into: spinlock[1] = 0;
>
> Folded statement: D.1498_3 = *spinlock0_1;
> into: D.1498_3 = spinlock[0];
>
> main ()
> {
> volatile int * spinlock1;
> volatile int * spinlock0;
> int D.1498;
>
> :
> spinlock0_1 = &spinlock[0];
> spinlock1_2 = &spinlock[1];
> spinlock[0] = 0;
> spinlock[1] = 0;
>
> :
> D.1498_3 = spinlock[0];
> if (D.1498_3 != 0)
> goto ;
> else
> goto ;
>
> :
> return;
>
> }
>
> which later results in the loop getting optimized away. However
> marking spinlock as volatile let the loop remain.
>
>
> I originally thought this to be a problem . However after chatting
> about it on IRC I wasn't sure if this was (un)defined behaviour. I
> looked through the standard but was unable to figure out from the
> prose , whether it stated some place that the object pointed to also
> should also have the same type qualifiers as the pointer being used to
> access this.
We usually try hard to keep this working (the testcase above is not complete
for sure).
Ah yes, I'd missed out an assignment . void foo (void)
> {
> volatile int * spinlock0;
Should be volatile int *spinlock0 = &spinlock[0];
}
Filed as PR 32721.
cheers
Ramana
Richard.
--
Ramana Radhakrishnan
ODR violation for std::cout etc.
Hello, Currently libstdc++ violates ODR: iostream: extern ostream cout; global_io.cc: fake_ostream cout; It assumes that gcc will work fine with this. Apparently it does, for now. After solving a similar problem in my code using a similar technique - to find out that it does not work for MS VS-2005 - when I had to find a different fix. The question is, why does GCC has to resolve to such construction-order issue this way? Idea (which I used): don't violate ODR in global_io.cc. Instead, construct and destroy std::cout two times, in a safe way: static PreSecondCtor coutPreSecondCtor(std::cout); ostream std::cout(NULL); static PostSecondCtor coutPostSecondCtor(coutPreSecodCtor); When PreSecondCtor saves all relevant data of cout (error bits, state, rdbuf, etc.), and then calls std::cout.~ostream(); Note that before this point, std::cout has already been constructed by an std::ios::Init, and we need to avoid double construction. In PostSecondCtor, restore the state of cout out of the saved data in outPreSecondCtor. During destruction the order is reversed. I still have a vague feeling that this solution is also undefined (since we are calling the constructor of std::cout, using placement new, after it had been automatically destroyed by the C++ environment). I don't have the standard near me, so I can't check. Anyway, even if this is undefined, the situation is arguably better since it does not seem to break whole program compilation (like current implementation might). What do you think? Michael
Re: crtbegin.o crtend.o
"Sunzir Deepur" <[EMAIL PROTECTED]> writes: > What files are the sources of crtbegin.o and crtend.o ? The single file gcc/crtstuff.c. > What's their purposes ? To ensure that global constructors and destructors are run at the appropriate times (i.e., before main and after exit, respectively). Ian
Re: ODR violation for std::cout etc.
Michael Veksler wrote: What do you think? I think that the "current" solution is very, very old, and "heaven" knows how many others didn't work at the time on some "exotic" platforms. I would suggest filing a PR and CCing Benjamin. Thanks, Paolo.
Re: crtbegin.o crtend.o
On 10 Jul 2007 09:51:14 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: "Sunzir Deepur" <[EMAIL PROTECTED]> writes: > What files are the sources of crtbegin.o and crtend.o ? The single file gcc/crtstuff.c. > What's their purposes ? To ensure that global constructors and destructors are run at the appropriate times (i.e., before main and after exit, respectively). Thanks !! Ian
Re: ODR violation for std::cout etc.
Michael Veksler wrote: > >What do you think? On Tue, Jul 10, 2007 at 06:58:50PM +0200, Paolo Carlini wrote: > I think that the "current" solution is very, very old, and "heaven" > knows how many others didn't work at the time on some "exotic" > platforms. I would suggest filing a PR and CCing Benjamin. The ODR is a rule that applies to users' programs; if they violate it, we can't make any promises that their program will work. If there's a violation in the internals of the libstdc++ implementation, then this only really matters if it breaks something. Otherwise I'd suggest classifying the "bug" P5 (absolute lowest priority); there are any number of real bugs that are more important to fix.
RFA: upcoming testsuite disruptions
There's a testsuite patch that I submitted, but haven't yet checked in, that will break test summary comparisons from before and after that patch is applied: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00834.html http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01076.html A patch from Manuel López-Ibáñez might result in failures for dg-error/dg-warning checks on targets that haven't been tested: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00962.html Both of these changes are worthwhile and should go in, but I'm worried about the disruptions they might cause. Should we coordinate the checkins of these patches with other major changes or freezes, or just do it? Janis
ICE while bootstraping on ppc64.
Hello, The following ICE is received on r126521 while bootstraping on ppc64. Revital /home/eres/test_again/build/./gcc/xgcc -B/home/eres/test_again/build/./gcc/ -B/home/eres/test_again/build/powerpc64-unknown-linux-gnu/bin/ -B/home/eres/test_again/build/powerpc64-unknown-linux-gnu/lib/ -isystem /home/eres/test_again/build/powerpc64-unknown-linux-gnu/include -isystem /home/eres/test_again/build/powerpc64-unknown-linux-gnu/sys-include -g -fkeep-inline-functions -m32 -fPIC -mstrict-align -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mno-minimal-toc -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -mlong-double-128 -I. -I. -I../../.././gcc -I../../../../gcc/libgcc -I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include -I../../../../gcc/libgcc/../libdecnumber/dpd -I../../../../gcc/libgcc/../libdecnumber -I../../../libdecnumber -DHAVE_CC_TLS -o _floatdisf.o -MT _floatdisf.o -MD -MP -MF _floatdisf.dep -DL_floatdisf -c ../../../../gcc/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS ../../../../gcc/libgcc/../gcc/libgcc2.c: In function ג__floatdisfג: ../../../../gcc/libgcc/../gcc/libgcc2.c:1530: internal compiler error: in gen_reg_rtx, at emit-rtl.c:785 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[5]: *** [_floatdisf.o] Error 1
Re: AMD64 ABI compatibility
That's cool! What version would you do the patch for?
Apart from wine, I guess mingw should have the biggest need for the
MS ABI in order to support AMD64.
Nicolas
On Jul 10, 2007, at 5:59 , Kai Tietz wrote:
Windows and GCC ABIs are on x86-64 more different than that (they
was
historically developed in parallel). GCC 4.3 will support attribute
for
this calling convention contributed by Kai Tiez and Richard
Henderson,
but before that there is not much to do...
Note: My name is Kai Tietz ;) not Tiez
I think, it isn't to hard introducing this attributes to the AMD64
abi's.
What names should we use for it? I suggest "x86_64_ms" and
"x86_64_linux".
For code bridging MS and GNU codebases (such as wine, or lets say,
GNU
runtime in windows if it ends up with non-MS calling convetions).
Then you want to use the attributes to call code from foreign world.
x86_64_linux is probably not very exact - we intended the ABI to be
generally useful for non-linux or non-GNU system (i.e. specified as
System V Application Binary Interface AMD64 Architecture Processor
Supplement with GCC as reference implementation). I believe Sparc
and
other unixes are more or less following it too.
For MS I would probably suggest ms_abi (it makes it cleaner that the
attribute is affecting calling convetion). For our abi I am not
sure, we
can sysv_abi or something else...
I will prepare an patch for it. For me "ms_abi" and "sysv_abi" is
fine.
Cheers,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
--
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 -
www.OneVision.com
Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
Handelsregister: HRA 6744, Amtsgericht Regensburg
Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
On 7/10/07, Nicolas Alt <[EMAIL PROTECTED]> wrote: That's cool! What version would you do the patch for? Apart from wine, I guess mingw should have the biggest need for the MS ABI in order to support AMD64. mingw x86_64 support is already added for 4.3 on the trunk. Thanks, Andrew Pinski
Re: AMD64 ABI compatibility
Ok - so question is if x86_64 is completely implemented already. For our case, especially the MS ABI. Andrew, do you have any knowledge if they introduced a new calling convention and how they named it? Nicolas On Jul 10, 2007, at 13:29 , Andrew Pinski wrote: On 7/10/07, Nicolas Alt <[EMAIL PROTECTED]> wrote: That's cool! What version would you do the patch for? Apart from wine, I guess mingw should have the biggest need for the MS ABI in order to support AMD64. mingw x86_64 support is already added for 4.3 on the trunk. Thanks, Andrew Pinski
Re: AMD64 ABI compatibility
On 7/10/07, Nicolas Alt <[EMAIL PROTECTED]> wrote: Ok - so question is if x86_64 is completely implemented already. For our case, especially the MS ABI. Andrew, do you have any knowledge if they introduced a new calling convention and how they named it? It is only implemented for the x86_64-mingw32 target. Thanks, Andrew Pinski
Re: RFC: GIMPLE tuples. Design and implementation proposal
On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >In a message dated 7/9/2007 2:37:03 P.M. Pacific Daylight Time, [EMAIL PROTECTED] writes: >On 7/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> >In a message dated 7/7/2007 4:04:01 A.M. Pacific Daylight Time, Rob1weld >> writes: >> >This page http://deputy.cs.berkeley.edu/ has a link to this document >> http://hal.cs.berkeley.edu/cil/ >> >which describes a means to obtain three-address code here >> http://hal.cs.berkeley.edu/cil/ext.html#toc24 . >> >> >>2007/7/08, Diego Novillo <[EMAIL PROTECTED] >> (mailto:[EMAIL PROTECTED]) >: >> >>Any specific reasons why we should? Better memory savings? Faster >> >>processing? It's not clear from your message what the advantages would >> >>be (ignoring the fact that their implementation language is completely >> >>different). >> >You haven't explained what advantages CIL's IR has over GIMPLE. I thought it was well explained on page: _http://hal.cs.berkeley.edu/cil/cil001.html_ (http://hal.cs.berkeley.edu/cil/cil001.html) No, since as i said, their IR is the same as GIMPLE. It is your project to write the way you want. You "RFC letter" said "Thoughts/comments on the proposal?". My reply is that this page:_http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html_ (http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html) and this site: _http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/INTRO.html_ (http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/INTRO.html) provide a better explanation of IR issues. Okay, let me ask a different question. What makes you believe we aren't aware of these projects? MLRISC has been around for *years* as has CIL. In fact, I reported bugs against CIL. We are quite aware of what all of them do, we just do not see the advantages, and you have not given any explicit enumeration of them.
Re: RFA: upcoming testsuite disruptions
Janis Johnson <[EMAIL PROTECTED]> writes: > There's a testsuite patch that I submitted, but haven't yet > checked in, that will break test summary comparisons from before > and after that patch is applied: > > http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00834.html > http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01076.html > > A patch from Manuel López-Ibáñez might result in failures for > dg-error/dg-warning checks on targets that haven't been tested: > > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00962.html > > Both of these changes are worthwhile and should go in, but I'm > worried about the disruptions they might cause. Should we > coordinate the checkins of these patches with other major > changes or freezes, or just do it? For my regression tester scripts, I think they'll have little or no effect, because the scripts only look at the first word of the test name (which is typically the input filename, eg. execute/something.c).
new events at GCC Summit
One of the best things about the GCC Summit is the opportunity to meet other developers and users of GCC and chat with them informally during breaks, meals, pub night, and the final party. This year the GCC Summit will provide new opportunities to share information with other summit participants: - lots of BoF slots available for anyone who wants to host a Birds of a Feather session - a Works in Progress, or Lightning Talks, session on Thursday afternoon at which people can have five minutes to talk about a GCC or GNU Toolchain project - space on the walls for posters, with poster board, pins, etc. provided, and plenty of time during breaks to discuss what's on them - opportunity to designate a table at breakfast for a particular interest group Although most of these can be arranged at the last minute, you might start thinking now about whether you'll want to take advantage of any of them. Janis Johnson
Re: AMD64 ABI compatibility
> >
> > I am on that tricky thing ;) I think I need in i386.c an global variable
> > "ix86_amd64_abi" which helds the the current function abi. This means also
> > that I have to use instead of TARGET_64BIT_MS_ABI this variable. This var
> > may initioalized by init_cumulative_args and the overriden
> > REG_PARM_STACK_SPACE, OUTGOING_REG_PARM_STACK_SPACE, REGPARM_MAX,
> > SSE_REGPARM_MAX, STACK_BOUNDARY, etc.
>
> In order to get all cases right (ie switching ABIs and calling foreign
> function), you need more bookkeeping than this. I am just in hurry to
> catch bus, but I will send you little guide tonight.
Hi,
so short overview. It seems to me that you have several cases:
- to keep track of current function ABI, you need to add struct
machine_function field (i386.g) and update TARGET_64BIT_MS_ABI that
cares about current function ABI accordingly.
To deal correclty with call_used registers, I think you need to set
the bits at same time machine_function is initialized and add a
function to regalloc that will update the internal representaiton via
regset (grep for use of the macro).
For example prologue/epologue code cares about this current ABI.
- to keep track of ABI used by currently expanded function call
CUMULATIVE_ARGS allows you to add extra info. See how cum->nregs
is handled, you need to do pretty much the same and add cum argument
to functions called form cumulative arguments machinery where you need them.
(as opposed to flipping the current abi above as you suggested).
There is one problem that RTL CALL instructions does not specify call
used registers that differ in between ABI. They are all assumed to
use ones specified by call_used.
I think you can't do anything to declare SI/DI unused when calling
function from SYSV ABI with MS ABI convention. We just lose code
quality a bit.
On the other hand you must specify them as clobbered when calling
SYSV ABI from MS ABI. This needs to be done by adding extra variants
of call instruction pattern with the clobber. You might want to
impleement SYSV->MS direction only first and not worry about this for
start.
Note that when calling libcalls, you always want to use the efault
conventions so the libgcc match.
- You need to keep track of cases function from one ABI calls functions
from different ABI. This can be done by adding yet another bit into
machine_function and simply set it when expanding the foreign call.
Some predicates (such as ix86_function_value_regno_p) cares about
if the reg can possibly be return value. In the case both ABIs
coexist in single function, you need to be conservative here and
merge both possibilities.
- You will need to update the calling convention of some of the
predicates you mentioned (such as I think OUTGOING_REG_PARM_STACK_SPACE)
to specify the function declaration they care about (so you know if
it is foreign call or not). GCC middleend is probably not quite
ready to deal with so different ABIs intermixed at once. This
include updating of calling conventions in all ports and should be
done first by separate patches. Not dificult, but tedious.
I guess thats it. I believe that if you don't do something of the
above, some of cases will go wildly wrong... (this is not to discougrate
you, just to explain why it is tricky :)
Honza
>
> Honza
> >
> > Cheers,
> > i.A. Kai Tietz
> >
> > | (\_/) This is Bunny. Copy and paste Bunny
> > | (='.'=) into your signature to help him gain
> > | (")_(") world domination.
> >
> > --
> > OneVision Software Entwicklungs GmbH & Co. KG
> > Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
> > Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
> > Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
> > Handelsregister: HRA 6744, Amtsgericht Regensburg
> > Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
> > Dr.-Leo-Ritter-Straße 9 ??? 93049 Regensburg
> > Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
> > Ulrike Döhler, Manuela Kluger
> >
ICE building libgcc2.c for MIPS, too
The error reported here http://gcc.gnu.org/ml/gcc/2007-07/msg00339.html is also happening when building for target mipsisa32r2-elfoabi on i686-pc-linux-gnu. -Sandra
GCC 4.2.1 Status Report (2007-07-10)
Summary --- The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th. As of 5PM PDT tomorrow, please consider the 4.2 branch closed to all changes. If you have outstanding changes that have been approved, but not committed, make the commits before that time. I plan to build GCC 4.2.1 RC2 tomorrow evening. I will probably wait until a few days after the 13th to build the final release, in order to make sure that people have had a chance to test out RC2. We still have 3 wrong-code P1s: PR 32182 -fstrict-aliasing ... PR 32327 Incorrect stack sharing... PR 32328 -fstrict-aliasing ... Priority# Change from Last Report --- - --- P1 21 -8 P2 113 0 P3 3 +1 Previous Report --- http://gcc.gnu.org/ml/gcc/2007-07/msg00062.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.1 Status Report (2007-07-10)
On 7/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: Summary --- The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th. As of 5PM PDT tomorrow, please consider the 4.2 branch closed to all changes. If you have outstanding changes that have been approved, but not committed, make the commits before that time. I plan to build GCC 4.2.1 RC2 tomorrow evening. I will probably wait until a few days after the 13th to build the final release, in order to make sure that people have had a chance to test out RC2. We still have 3 wrong-code P1s: PR 32182 -fstrict-aliasing ... This is not analyzed enough to know whether it's something i should look at, or the C++ FE people should look at. IE Nobody has pointed out what is actually going wrong here, so i don't know whether it's aliasing or what :) PR 32327 Incorrect stack sharing... PR 32328 -fstrict-aliasing ... This i have a patch for, but it really needs some performance testing. I'm happy to throw it in RC2 if you want to see how it does, with the caveat it may need to be pulled back out if it causes massive performance regressions :)
Re: ICE building libgcc2.c for MIPS, too
Sandra Loosemore <[EMAIL PROTECTED]> writes: > The error reported here > > http://gcc.gnu.org/ml/gcc/2007-07/msg00339.html > > is also happening when building for target mipsisa32r2-elfoabi on > i686-pc-linux-gnu. This should be fixed by revision 126536. Sorry for the problems. Ian
Re: ICE while bootstraping on ppc64.
Revital1 Eres <[EMAIL PROTECTED]> writes: > The following ICE is received on r126521 while bootstraping on ppc64. This should be fixed by revision 126536. Sorry for the problems. Ian
Re: GCC 4.2.1 Status Report (2007-07-10)
Daniel Berlin wrote: >> PR 32328 -fstrict-aliasing ... > > This i have a patch for, but it really needs some performance testing. > I'm happy to throw it in RC2 if you want to see how it does, with the > caveat it may need to be pulled back out if it causes massive > performance regressions :) No, I don't want to do that -- but thanks for working on the PR. If you can do some performance testing up front, then I might consider it for a post-RC2 inclusion, even if it means an RC3. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
