Hi,
On Tue, 8 Dec 2009, H.J. Lu wrote:
> Both icc and gcc generate:
>
> [...@gnu-26 pr42324]$ cat b4.c
> extern unsigned int bartmp;
>
> void foo(_Bool bar)
> {
> bartmp = bar;
> }
> [...@gnu-26 pr42324]$ /usr/gcc-4.4/bin/gcc -O2 b4.c -S
> [...@gnu-26 pr42324]$ cat b4.s
> .file "b4.c"
Do we have any maintainers outside of the global reviewers and
the dwarf debugging code reviewer who can review changes to dwarf2out.c?
We have two outstanding patches that eliminate crashes in dsymutil on
darwin so that gcc trunk can generate complete debug code again on
that target. This does r
On Wed, Dec 9, 2009 at 2:04 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 8 Dec 2009, H.J. Lu wrote:
>
>> Both icc and gcc generate:
>>
>> [...@gnu-26 pr42324]$ cat b4.c
>> extern unsigned int bartmp;
>>
>> void foo(_Bool bar)
>> {
>> bartmp = bar;
>> }
>> [...@gnu-26 pr42324]$ /usr/gcc-4.4/bin/gcc -
On 12/09/2009 06:44 AM, H.J. Lu wrote:
>
> Aren't bits in the _Bool byte of"bar" specified by the psABI or the C
> language standard already?
>
The psABI, yes. They are obviously not defined by the C language standard.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I wor
Hi,
On Wed, 9 Dec 2009, H.J. Lu wrote:
> > ... because this part can only be guaranteed by the ABI. Without the
> > above language a compiler would be free to implement any non-zero byte as
> > true for parameter passing without violating the ABI.
> >
>
> Aren't bits in the _Bool byte of"bar" s
On Wed, Dec 9, 2009 at 6:56 AM, Michael Matz wrote:
> Hi,
>
> On Wed, 9 Dec 2009, H.J. Lu wrote:
>
>> > ... because this part can only be guaranteed by the ABI. Without the
>> > above language a compiler would be free to implement any non-zero byte as
>> > true for parameter passing without viola
On 12/09/2009 06:56 AM, Michael Matz wrote:
>>
>> Aren't bits in the _Bool byte of"bar" specified by the psABI
>
> Right now they are specified in the psABI, you suggested to remove that
> specification.
>
The intent of H.J.'s proposal is to require bits <7:1> == 0 in all cases
(and higher bits
Hi,
On Wed, 9 Dec 2009, H.J. Lu wrote:
> >> Why should the _Bool byte in "void foo(_Bool bar)" be any different?
> >
> > Because it can be different when the psABI doesn't say otherwise.
> >
>
> The psABI doesn't say anything about the _Bool return value.
That's a bug in the psABI. We probabl
H. Peter Anvin wrote:
> On 12/09/2009 06:56 AM, Michael Matz wrote:
>>> Aren't bits in the _Bool byte of"bar" specified by the psABI
>> Right now they are specified in the psABI, you suggested to remove that
>> specification.
>>
>
> The intent of H.J.'s proposal is to require bits <7:1> == 0 in a
Hi,
On Wed, 9 Dec 2009, H. Peter Anvin wrote:
> On 12/09/2009 06:56 AM, Michael Matz wrote:
> >>
> >> Aren't bits in the _Bool byte of"bar" specified by the psABI
> >
> > Right now they are specified in the psABI, you suggested to remove that
> > specification.
> >
>
> The intent of H.J.'s pr
On Wed, Dec 9, 2009 at 7:10 AM, Michael Matz wrote:
> Hi,
>
> On Wed, 9 Dec 2009, H. Peter Anvin wrote:
>
>> On 12/09/2009 06:56 AM, Michael Matz wrote:
>> >>
>> >> Aren't bits in the _Bool byte of"bar" specified by the psABI
>> >
>> > Right now they are specified in the psABI, you suggested to re
On Wed, Dec 9, 2009 at 7:10 AM, Andrew Haley wrote:
> H. Peter Anvin wrote:
>> On 12/09/2009 06:56 AM, Michael Matz wrote:
Aren't bits in the _Bool byte of"bar" specified by the psABI
>>> Right now they are specified in the psABI, you suggested to remove that
>>> specification.
>>>
>>
>> The
Andrew Haley wrote:
> Surely Postel's Law applies:
Surely Postel's Law must have been repealed by now? :-)
cheers,
DaveK
On Wed, Dec 9, 2009 at 7:15 AM, H.J. Lu wrote:
> On Wed, Dec 9, 2009 at 7:10 AM, Michael Matz wrote:
>> Hi,
>>
>> On Wed, 9 Dec 2009, H. Peter Anvin wrote:
>>
>>> On 12/09/2009 06:56 AM, Michael Matz wrote:
>>> >>
>>> >> Aren't bits in the _Bool byte of"bar" specified by the psABI
>>> >
>>> > Rig
Hi,
On Wed, 9 Dec 2009, Andrew Haley wrote:
> > The intent of H.J.'s proposal is to require bits <7:1> == 0 in all cases
> > (and higher bits as don't cares, the same way a char is passed), as
> > opposed to the current text which requires <63:1> == 0 when passed as
> > registers or on the stack
Hi,
On Wed, 9 Dec 2009, H.J. Lu wrote:
> > Then fix the psABI.
>
> Don't we need to specify passing and returning char, short and int since
> they are smaller than the integer class, which is eightbytes?
Since the mapping from domain to bitpatterns is bijective, we don't have
to (although if
H.J. Lu wrote:
> On Wed, Dec 9, 2009 at 7:10 AM, Andrew Haley wrote:
>> H. Peter Anvin wrote:
>>> On 12/09/2009 06:56 AM, Michael Matz wrote:
> Aren't bits in the _Bool byte of"bar" specified by the psABI
Right now they are specified in the psABI, you suggested to remove that
specifi
Hi,
Michael Matz wrote:
> On Wed, 9 Dec 2009, Andrew Haley wrote:
>
>>> The intent of H.J.'s proposal is to require bits <7:1> == 0 in all cases
>>> (and higher bits as don't cares, the same way a char is passed), as
>>> opposed to the current text which requires <63:1> == 0 when passed as
>>> r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rainer Emrich schrieb:
> Jason Merrill schrieb:
>> On 12/01/2009 09:02 AM, Rainer Emrich wrote:
>>> C:/MinGW/i686-pc/i686-pc/i686-pc/gcc-4.5.0/mingw/lib/libppl.a(Polyhedron_widenings.o):Polyhedron_widenings.cc:(.text$_ZN23Parma_Polyhedra_Library3BoxINS
On Wed, Dec 9, 2009 at 7:51 AM, Andrew Haley wrote:
> H.J. Lu wrote:
>> On Wed, Dec 9, 2009 at 7:10 AM, Andrew Haley wrote:
>>> H. Peter Anvin wrote:
On 12/09/2009 06:56 AM, Michael Matz wrote:
>> Aren't bits in the _Bool byte of"bar" specified by the psABI
> Right now they are speci
H.J. Lu wrote:
> On Wed, Dec 9, 2009 at 7:51 AM, Andrew Haley wrote:
>> H.J. Lu wrote:
>>> On Wed, Dec 9, 2009 at 7:10 AM, Andrew Haley wrote:
H. Peter Anvin wrote:
> On 12/09/2009 06:56 AM, Michael Matz wrote:
>>> Aren't bits in the _Bool byte of"bar" specified by the psABI
>> R
On Wed, Dec 9, 2009 at 7:49 AM, Michael Matz wrote:
> Hi,
>
> On Wed, 9 Dec 2009, H.J. Lu wrote:
>
>> > Then fix the psABI.
>>
>> Don't we need to specify passing and returning char, short and int since
>> they are smaller than the integer class, which is eightbytes?
>
> Since the mapping from dom
Hello,
The FTensor library referenced at
http://gcc.gnu.org/testing/testing-ftensor.html
has moved. The new location is
http://www.gps.caltech.edu/~walter/FTensor/index.html
Cheers,
Walter Landry
wlan...@caltech.edu
On Wed, 2009-12-09 at 09:56 -0800, Walter Landry wrote:
> Hello,
>
> The FTensor library referenced at
>
> http://gcc.gnu.org/testing/testing-ftensor.html
>
> has moved. The new location is
>
> http://www.gps.caltech.edu/~walter/FTensor/index.html
>
> Cheers,
> Walter Landry
> wlan...@cal
Hi,
When I visit:
http://gcc.gnu.org/ml/gcc-bugs/
http://gcc.gnu.org/ml/gcc-cvs/
at Wed Dec 9 10:41:43 PST 2009, I didn't see "December, 2009".
It was there yesterday. Has anyone else seen it? You may need to
clear browser cache first.
--
H.J.
H.J. Lu wrote:
> Hi,
>
> When I visit:
>
> http://gcc.gnu.org/ml/gcc-bugs/
> http://gcc.gnu.org/ml/gcc-cvs/
>
> at Wed Dec 9 10:41:43 PST 2009, I didn't see "December, 2009".
> It was there yesterday. Has anyone else seen it? You may need to
> clear browser cache first.
Looks ok from where I
H.J. Lu wrote:
Hi,
When I visit:
http://gcc.gnu.org/ml/gcc-bugs/
http://gcc.gnu.org/ml/gcc-cvs/
at Wed Dec 9 10:41:43 PST 2009, I didn't see "December, 2009".
It was there yesterday. Has anyone else seen it? You may need to
clear browser cache first.
You just said how to work around the pr
On Wed, Dec 9, 2009 at 10:51 AM, David Daney wrote:
> H.J. Lu wrote:
>>
>> Hi,
>>
>> When I visit:
>>
>> http://gcc.gnu.org/ml/gcc-bugs/
>> http://gcc.gnu.org/ml/gcc-cvs/
>>
>> at Wed Dec 9 10:41:43 PST 2009, I didn't see "December, 2009".
>> It was there yesterday. Has anyone else seen it? You m
I merge two SET insns to a PARALLEL before gcc's schedule_insns () in
pass_sched .
Would you please tell me where is the bug?
Thanks!
CODE:
void merge(rtx insn1,rtx insn2)
{
rtx parallel;
parallel = gen_rtx_PARALLEL (VOIDmode, rtvec_alloc (2));
XVECEXP (par, 0, 0) = PATT
29 matches
Mail list logo
