Re: GMP and GCC 4.3.2
Jean Christophe Beyler wrote: > Dear all, > > Found on http://gmplib.org/. > > "N.B. gcc 4.3.2 miscompiles GMP 4.3.x on 64-bit machines. The problem > is specific to that very release; specifically gcc 4.3.1 and 4.3.3 > seem to work fine." > > Since porting to a newer version is difficult for me right now, I was > wondering if anybody worked on a patch for this specific problem. There's no porting to be done: gcc 4.3.3 is just a bunch of bug fixes. Andrew.
Re: GMP and GCC 4.3.2
If it's the bug being discussed here: http://gmplib.org/list-archives/gmp-discuss/2009-April/003717.html ... then it was reported as fixed here: http://gcc.gnu.org/ml/gcc/2009-04/msg00562.html Jay.
GCC presentation targeted to users (43 slides in english)
Hi, FYI I just did a ~2 hours presentation of the GCC project to my local LUG in Toulouse, France: http://toulibre.org The 43 slides presentation in english is available here in PDF and openoffice format: http://guerby.org/ftp/gcc-toulibre-20091216.pdf http://guerby.org/ftp/gcc-toulibre-20091216.odp Feel free to mirror, reuse and adapt, they're public domain. Let me know if you do something with them :). The video for the presentation will be available in the coming weeks on the Toulibre web site (note: I spoke in french). Laurent
Re: GCC presentation targeted to users (43 slides in english)
On Thu, Dec 17, 2009 at 12:29 PM, Laurent GUERBY wrote: > Hi, > > FYI I just did a ~2 hours presentation of the GCC project to > my local LUG in Toulouse, France: > > http://toulibre.org > > The 43 slides presentation in english is available here > in PDF and openoffice format: > > http://guerby.org/ftp/gcc-toulibre-20091216.pdf > http://guerby.org/ftp/gcc-toulibre-20091216.odp > > Feel free to mirror, reuse and adapt, they're public domain. Let me know > if you do something with them :). > > The video for the presentation will be available in the > coming weeks on the Toulibre web site (note: I spoke in french). Might be interesting to link to this from the GCC wiki. Richard. > Laurent > > > >
A question about loop-unroll
Hello,
Is there a way to pass to the unroller the maximum number of iterations
of the loop such that it can decide to avoid unrolling if
the maximum number is small.
To be more specific, I am referring to the following case:
After the vectorizer decides to peel for alignment
it creates three loops:
[1] scalar loop - the prologue to align
memory access.
[2] the vecorized loop
[3] scalar loop - the remaining scalar computations.
If the unroller does not know the number of iterations at compile time
it unrolls loops with run-time checks in the following way
(taken from loop-unroll.c):
for (i = 0; i < n; i++)
body;
==>
i = 0;
mod = n % 4;
switch (mod)
{
case 3:
body; i++;
case 2:
body; i++;
case 1:
body; i++;
case 0: ;
}
while (i < n)
{
body; i++;
body; i++;
body; i++;
body; i++;
}
The vectorizer knowns at compile time the maximum number of iterations
that will be needed for the prologue and the epilogue. In some cases
seems there is no need to unroll and create redundant loops.
Thanks,
Revital
Re: A question about loop-unroll
On Thu, Dec 17, 2009 at 1:07 PM, Revital1 Eres wrote:
>
> Hello,
>
> Is there a way to pass to the unroller the maximum number of iterations
> of the loop such that it can decide to avoid unrolling if
> the maximum number is small.
>
> To be more specific, I am referring to the following case:
> After the vectorizer decides to peel for alignment
> it creates three loops:
> [1] scalar loop - the prologue to align
> memory access.
> [2] the vecorized loop
> [3] scalar loop - the remaining scalar computations.
>
> If the unroller does not know the number of iterations at compile time
> it unrolls loops with run-time checks in the following way
> (taken from loop-unroll.c):
>
> for (i = 0; i < n; i++)
> body;
>
> ==>
>
> i = 0;
> mod = n % 4;
>
> switch (mod)
> {
> case 3:
> body; i++;
> case 2:
> body; i++;
> case 1:
> body; i++;
> case 0: ;
> }
>
> while (i < n)
> {
> body; i++;
> body; i++;
> body; i++;
> body; i++;
> }
>
>
> The vectorizer knowns at compile time the maximum number of iterations
> that will be needed for the prologue and the epilogue. In some cases
> seems there is no need to unroll and create redundant loops.
You can set niter_max in the niter_desc of simple loops. There is
also nb_iter_bound for all loops. Of course the
issue is that loop information is destroyed sometimes. It also looks
like that RTL loop analysis may not re-use this information.
Maybe Zdenek knows a better answer.
Richard.
> Thanks,
> Revital
>
>
Re: A question about loop-unroll
Hi,
> > Is there a way to pass to the unroller the maximum number of iterations
> > of the loop such that it can decide to avoid unrolling if
> > the maximum number is small.
> >
> > To be more specific, I am referring to the following case:
> > After the vectorizer decides to peel for alignment
> > it creates three loops:
> > [1] scalar loop - the prologue to align
> > memory access.
> > [2] the vecorized loop
> > [3] scalar loop - the remaining scalar computations.
> >
> > If the unroller does not know the number of iterations at compile time
> > it unrolls loops with run-time checks in the following way
> > (taken from loop-unroll.c):
> >
> > for (i = 0; i < n; i++)
> > body;
> >
> > ==>
> >
> > i = 0;
> > mod = n % 4;
> >
> > switch (mod)
> > {
> > case 3:
> > body; i++;
> > case 2:
> > body; i++;
> > case 1:
> > body; i++;
> > case 0: ;
> > }
> >
> > while (i < n)
> > {
> > body; i++;
> > body; i++;
> > body; i++;
> > body; i++;
> > }
> >
> >
> > The vectorizer knowns at compile time the maximum number of iterations
> > that will be needed for the prologue and the epilogue. In some cases
> > seems there is no need to unroll and create redundant loops.
>
> You can set niter_max in the niter_desc of simple loops. There is
> also nb_iter_bound for all loops. Of course the
> issue is that loop information is destroyed sometimes. It also looks
> like that RTL loop analysis may not re-use this information.
>
> Maybe Zdenek knows a better answer.
currently, there is no reliable way how to pass this information to RTL. The
best
I can come up with (without significant amount of changes to other parts of the
compiler)
would be to insert a code like
if (n > 5)
special_abort ();
before the loop in the vectorizer if you know for sure that the loop will
iterate at most
5 times, use these hints to bound the number of iterations in the unroller (we
do not do this
at the moment, but it should be easy), and remove the calls to special_abort
and the
corresponding branches after the unroller.
Zdenek
Re: A question about loop-unroll
2009/12/17 Zdenek Dvorak :
> Hi,
>
>> > Is there a way to pass to the unroller the maximum number of iterations
>> > of the loop such that it can decide to avoid unrolling if
>> > the maximum number is small.
>> >
>> > To be more specific, I am referring to the following case:
>> > After the vectorizer decides to peel for alignment
>> > it creates three loops:
>> > [1] scalar loop - the prologue to align
>> > memory access.
>> > [2] the vecorized loop
>> > [3] scalar loop - the remaining scalar computations.
>> >
>> > If the unroller does not know the number of iterations at compile time
>> > it unrolls loops with run-time checks in the following way
>> > (taken from loop-unroll.c):
>> >
>> > for (i = 0; i < n; i++)
>> > body;
>> >
>> > ==>
>> >
>> > i = 0;
>> > mod = n % 4;
>> >
>> > switch (mod)
>> > {
>> > case 3:
>> > body; i++;
>> > case 2:
>> > body; i++;
>> > case 1:
>> > body; i++;
>> > case 0: ;
>> > }
>> >
>> > while (i < n)
>> > {
>> > body; i++;
>> > body; i++;
>> > body; i++;
>> > body; i++;
>> > }
>> >
>> >
>> > The vectorizer knowns at compile time the maximum number of iterations
>> > that will be needed for the prologue and the epilogue. In some cases
>> > seems there is no need to unroll and create redundant loops.
>>
>> You can set niter_max in the niter_desc of simple loops. There is
>> also nb_iter_bound for all loops. Of course the
>> issue is that loop information is destroyed sometimes. It also looks
>> like that RTL loop analysis may not re-use this information.
>>
>> Maybe Zdenek knows a better answer.
>
> currently, there is no reliable way how to pass this information to RTL. The
> best
> I can come up with (without significant amount of changes to other parts of
> the compiler)
> would be to insert a code like
>
> if (n > 5)
> special_abort ();
>
> before the loop in the vectorizer if you know for sure that the loop will
> iterate at most
> 5 times, use these hints to bound the number of iterations in the unroller
> (we do not do this
> at the moment, but it should be easy), and remove the calls to special_abort
> and the
> corresponding branches after the unroller.
We do have __builtin_unreachable (), but that is removed at expansion time
already ;) Also the code does have
n = orig_n % 4;
already (or the equivalent masking and subtraction),
but I guess the RTL loop analysis doesn't catch that either.
Richard.
> Zdenek
>
Re: [PATCH] ARM: Convert BUG() to use unreachable()
Jamie Lokier wrote:
Uwe Kleine-König wrote:
Use the new unreachable() macro instead of for(;;);
*(int *)0 = 0;
/* Avoid "noreturn function does return" */
- for (;;);
+ unreachable();
Will GCC-4.5 remove ("optimise away") the *(int *)0 = 0 because it
knows the branch of the code leading to unreachable can never be reached?
I don't know the definitive answer, so I am sending to g...@...
FYI: #define unreachable() __builtin_unreachable()
If GCC-4.5 does not, are you sure a future version of GCC will never
remove it? In other words, is __builtin_unreachable() _defined_ in
such a way that it cannot remove the previous assignment?
We have seen problems with GCC optimising away important tests for
NULL pointers in the kernel, due to similar propagation of "impossible
to occur" conditions, so it's worth checking with GCC people what the
effect of this one would be.
In C, there is a general theoretical problem with back-propagation of
optimisations from code with undefined behaviour. In the case of
__builtin_unreachable(), it would depend on all sorts of unclearly
defined semantics whether it can remove a preceding *(int *)0 = 0.
I'd strongly suggest asking on the GCC list. (I'd have mentioned this
earlier, if I'd known about the patch for other architectures).
The documentation for __builtin_unreachable() only says the program is
undefined if control flow reaches it. In other words, it does not say
what effect it can have on previous instructions, and I think it's
quite likely that it has not been analysed in a case like this.
One thing that would give me a lot more confidence, because the GCC
documentation does mention asm(), is this:
*(int *)0 = 0;
/* Ensure unreachableness optimisations cannot propagate back. *I/
__asm__ volatile("");
/* Avoid "noreturn function does return" */
unreachable();
-- Jamie
Re: [PATCH] ARM: Convert BUG() to use unreachable()
On Thu, Dec 17, 2009 at 6:09 PM, David Daney wrote:
> Jamie Lokier wrote:
>>
>> Uwe Kleine-König wrote:
>>>
>>> Use the new unreachable() macro instead of for(;;);
>>> *(int *)0 = 0;
>>> /* Avoid "noreturn function does return" */
>>> - for (;;);
>>> + unreachable();
>>
>> Will GCC-4.5 remove ("optimise away") the *(int *)0 = 0 because it
>> knows the branch of the code leading to unreachable can never be reached?
>>
>
> I don't know the definitive answer, so I am sending to g...@...
>
> FYI: #define unreachable() __builtin_unreachable()
It shouldn't as *(int *)0 = 0; might trap. But if you want to be sure
use
__builtin_trap ();
instead for the whole sequence (the unreachable is implied then).
GCC choses a size-optimal trap representation for your target then.
Richard.
>
>> If GCC-4.5 does not, are you sure a future version of GCC will never
>> remove it? In other words, is __builtin_unreachable() _defined_ in
>> such a way that it cannot remove the previous assignment?
>>
>> We have seen problems with GCC optimising away important tests for
>> NULL pointers in the kernel, due to similar propagation of "impossible
>> to occur" conditions, so it's worth checking with GCC people what the
>> effect of this one would be.
>>
>> In C, there is a general theoretical problem with back-propagation of
>> optimisations from code with undefined behaviour. In the case of
>> __builtin_unreachable(), it would depend on all sorts of unclearly
>> defined semantics whether it can remove a preceding *(int *)0 = 0.
>>
>> I'd strongly suggest asking on the GCC list. (I'd have mentioned this
>> earlier, if I'd known about the patch for other architectures).
>>
>> The documentation for __builtin_unreachable() only says the program is
>> undefined if control flow reaches it. In other words, it does not say
>> what effect it can have on previous instructions, and I think it's
>> quite likely that it has not been analysed in a case like this.
>>
>> One thing that would give me a lot more confidence, because the GCC
>> documentation does mention asm(), is this:
>>
>>> *(int *)0 = 0;
>>> /* Ensure unreachableness optimisations cannot propagate back. *I/
>>> __asm__ volatile("");
>>> /* Avoid "noreturn function does return" */
>>> unreachable();
>>
>> -- Jamie
>
>
Re: updated code size comparison
Hi Paolo, I would also avoid testcases using volatile. Smaller code on these testcases is often a sign of miscompilation rather than optimization. For example, http://embed.cs.utah.edu/embarrassing/src_harvested_dec_09/076389.c is miscompiled on GCC 3.4 and SunCC 5.10. Yeah, there are definitely several examples where small code is generated by miscompilation, especially of volatiles. However I would prefer to leave these testcases in, unless there is a strong feeling that they are too distracting. They serve as poignant little reminders about how easy it is to get volatile wrong... John
Linking against an specific glibc
Hello, I would like to know if it is possible to link binaries against old versions of glibc. What's the best way to do that? If I specify -L to point to my old glibc will be enough? I don't want to "install" those old libraries on my machine, so I just compiled the old glibc with my current stable gcc and then used the created library to link to my binary, but this dosn't work very well. BR, []s Douglas Gemignani
Re: Linking against an specific glibc
On Thu, Dec 17, 2009 at 10:00 AM, Douglas Gemignani wrote: > Hello, > > I would like to know if it is possible to link binaries against old > versions of glibc. What's the best way to do that? > If I specify -L to point to my old glibc will be enough? I don't want > to "install" those old libraries on my machine, so I just compiled the > old glibc with my current stable gcc and then used the created library > to link to my binary, but this dosn't work very well. > It depends on if you want to use a special gcc or not. You can build a new gcc with sysroot, which points to your old glibc. If you want to use the existing gcc, you need a special command line to link against the old glibc. -- H.J.
Re: [PATCH] ARM: Convert BUG() to use unreachable()
On Thu, Dec 17, 2009 at 06:17:11PM +0100, Richard Guenther wrote:
> On Thu, Dec 17, 2009 at 6:09 PM, David Daney
> wrote:
> > Jamie Lokier wrote:
> >>
> >> Uwe Kleine-König wrote:
> >>>
> >>> Use the new unreachable() macro instead of for(;;);
> >>> *(int *)0 = 0;
> >>> /* Avoid "noreturn function does return" */
> >>> - for (;;);
> >>> + unreachable();
> >>
> >> Will GCC-4.5 remove ("optimise away") the *(int *)0 = 0 because it
> >> knows the branch of the code leading to unreachable can never be reached?
> >>
> >
> > I don't know the definitive answer, so I am sending to g...@...
> >
> > FYI: #define unreachable() __builtin_unreachable()
>
> It shouldn't as *(int *)0 = 0; might trap. But if you want to be sure
> use
>__builtin_trap ();
> instead for the whole sequence (the unreachable is implied then).
> GCC choses a size-optimal trap representation for your target then.
How is "size-optimal trap" defined? The point of "*(int *)0 = 0;" is
to cause a NULL pointer dereference which is trapped by the kernel to
produce a full post mortem and backtrace which is easily recognised
as a result of this code.
Having gcc decide on, maybe, an undefined instruction instead would be
confusing.
Let me put it another way: I want this function to terminate with an
explicit NULL pointer dereference in every case.
Re: [PATCH] ARM: Convert BUG() to use unreachable()
On Thu, Dec 17, 2009 at 10:17:18AM -0800, Russell King - ARM Linux wrote: > > It shouldn't as *(int *)0 = 0; might trap. But if you want to be sure > > use > >__builtin_trap (); > > instead for the whole sequence (the unreachable is implied then). > > GCC choses a size-optimal trap representation for your target then. > > How is "size-optimal trap" defined? The point of "*(int *)0 = 0;" is > to cause a NULL pointer dereference which is trapped by the kernel to > produce a full post mortem and backtrace which is easily recognised > as a result of this code. With something like __builtin_trap, the compiler knows that your intent is to cause a trap. But it's asking for trouble, and for future flame wars between kernel developers and gcc developers, to put in sequences that happen to do the right thing if the compiler does no optimizations whatsoever, but that might be messed up by optimizations because they are code sequences whose behavior is undefined. Besides, didn't I see a whole bunch of kernel security patches related to null pointer dereferences lately? If page 0 can be mapped, you suddenly won't get your trap.
Re: Linking against an specific glibc
Hi, What command line? I found this -nostdinc and -I to include folders, -b also? []s Douglas Gemignani On Thu, Dec 17, 2009 at 4:11 PM, H.J. Lu wrote: > On Thu, Dec 17, 2009 at 10:00 AM, Douglas Gemignani > wrote: >> Hello, >> >> I would like to know if it is possible to link binaries against old >> versions of glibc. What's the best way to do that? >> If I specify -L to point to my old glibc will be enough? I don't want >> to "install" those old libraries on my machine, so I just compiled the >> old glibc with my current stable gcc and then used the created library >> to link to my binary, but this dosn't work very well. >> > > It depends on if you want to use a special gcc or not. You can build > a new gcc with sysroot, which points to your old glibc. If you want to > use the existing gcc, you need a special command line to link against > the old glibc. > > -- > H.J. >
Re: updated code size comparison
> However I would prefer to leave these testcases in, unless there is a > strong feeling that they are too distracting. They serve as poignant > little reminders about how easy it is to get volatile wrong... They skew the results in favor of the less careful compilers so they are more than simply distracting, they are unfair. -- Eric Botcazou
Re: Linking against an specific glibc
On Thu, Dec 17, 2009 at 10:48 AM, Douglas Gemignani wrote: > Hi, > > What command line? I found this -nostdinc and -I to include folders, -b also? Here is a Makefile to link against the newly built glibc. H.J. > []s > Douglas Gemignani > > > > On Thu, Dec 17, 2009 at 4:11 PM, H.J. Lu wrote: >> On Thu, Dec 17, 2009 at 10:00 AM, Douglas Gemignani >> wrote: >>> Hello, >>> >>> I would like to know if it is possible to link binaries against old >>> versions of glibc. What's the best way to do that? >>> If I specify -L to point to my old glibc will be enough? I don't want >>> to "install" those old libraries on my machine, so I just compiled the >>> old glibc with my current stable gcc and then used the created library >>> to link to my binary, but this dosn't work very well. >>> >> >> It depends on if you want to use a special gcc or not. You can build >> a new gcc with sysroot, which points to your old glibc. If you want to >> use the existing gcc, you need a special command line to link against >> the old glibc. >> >> -- >> H.J. >> > -- H.J. Makefile Description: Binary data
Re: [PATCH] ARM: Convert BUG() to use unreachable()
Russell King - ARM Linux wrote:
> Let me put it another way: I want this function to terminate with an
> explicit NULL pointer dereference in every case.
__builtin_trap cannot be used because the GCC manual says "The
mechanism used may vary from release to release so you should not rely
on any particular implementation". It includes calling abort() as a
possible implementation - not ideal.
This is not related to GCC, but I have an ARM system here where
dereferencing NULL does not trap. You guessed it, it doesn't have a
regular MMU. But there are other addresses which do trap. They would
be a much better choice for BUG().
(Aha! Maybe that's why the kernel just behaves weirdly when it runs
out of memory and eventually triggers a watchdog reboot, with no panic
message. I'd better try changing BUG() :-)
Even with an MMU, sometimes userspace maps page zero. For example,
Wine on x86 does that. (It might be possible to change Wine and
kernel vm86 to avoid it, but it has not happened).
Bug-free userspace behaviour should not stop kernel's BUG() from doing
it's basic job of trapping in the kernel!
It would be quite messy if userspace maps page zero, and then a kernel
BUG() ploughs ahead into __builtin_unreachable() and completely
undefined behaviour, possibly leading to worse behaviour than omitting
the check which called BUG().
Under those circumstances I'd rather see it use __builtin_trap() if
that really does trap :-)
The point of the exercise with __builtin_unreachable() is to reduce
the kernel size by removing the for(;;) loop. *(int *)0 = 0 isn't the
smallest trapping sequence. (When it works :-)
So the most compact _and_ reliable sequence for the kernel, on all
architectures, is probably:
__asm__ volatile("smallest undefined or always-trapping instruction")
followed by __builtin_unreachable(), because GCC documentation _does_
say that asm followed by that will execute the asm and assume the asm
doesn't return.
-- Jamie
Re: [PATCH] ARM: Convert BUG() to use unreachable()
On Thu, Dec 17, 2009 at 10:35:17AM -0800, Joe Buck wrote: > Besides, didn't I see a whole bunch of kernel security patches related > to null pointer dereferences lately? If page 0 can be mapped, you > suddenly won't get your trap. Page 0 can not be mapped on ARM kernels since the late 1990s, and this protection is independent of the generic kernel. Milage may vary on other architectures, but that's not a concern here.
Re: [PATCH] ARM: Convert BUG() to use unreachable()
On Thu, Dec 17, 2009 at 11:06:13AM -0800, Russell King - ARM Linux wrote: > On Thu, Dec 17, 2009 at 10:35:17AM -0800, Joe Buck wrote: > > Besides, didn't I see a whole bunch of kernel security patches related > > to null pointer dereferences lately? If page 0 can be mapped, you > > suddenly won't get your trap. > > Page 0 can not be mapped on ARM kernels since the late 1990s, and this > protection is independent of the generic kernel. > > Milage may vary on other architectures, but that's not a concern here. I don't understand, though, why you would want to implement a generally useful facility (make the kernel trap so you can do a post-mortem analysis) in a way that's only safe for the ARM port.
Re: [PATCH] ARM: Convert BUG() to use unreachable()
On Thu, Dec 17, 2009 at 11:14:01AM -0800, Joe Buck wrote: > On Thu, Dec 17, 2009 at 11:06:13AM -0800, Russell King - ARM Linux wrote: > > On Thu, Dec 17, 2009 at 10:35:17AM -0800, Joe Buck wrote: > > > Besides, didn't I see a whole bunch of kernel security patches related > > > to null pointer dereferences lately? If page 0 can be mapped, you > > > suddenly won't get your trap. > > > > Page 0 can not be mapped on ARM kernels since the late 1990s, and this > > protection is independent of the generic kernel. > > > > Milage may vary on other architectures, but that's not a concern here. > > I don't understand, though, why you would want to implement a generally > useful facility (make the kernel trap so you can do a post-mortem > analysis) in a way that's only safe for the ARM port. The discussion at hand is about code contained in the ARM supporting files (arch/arm/kernel/traps.c), rather than the generic kernel. As such, it is not relevant to any architecture other than ARM.
Re: [PATCH] ARM: Convert BUG() to use unreachable()
Joe Buck wrote: On Thu, Dec 17, 2009 at 11:06:13AM -0800, Russell King - ARM Linux wrote: On Thu, Dec 17, 2009 at 10:35:17AM -0800, Joe Buck wrote: Besides, didn't I see a whole bunch of kernel security patches related to null pointer dereferences lately? If page 0 can be mapped, you suddenly won't get your trap. Page 0 can not be mapped on ARM kernels since the late 1990s, and this protection is independent of the generic kernel. Milage may vary on other architectures, but that's not a concern here. I don't understand, though, why you would want to implement a generally useful facility (make the kernel trap so you can do a post-mortem analysis) in a way that's only safe for the ARM port. Each Linux kernel architecture has in its architecture specific bug.h an implementation that is deemed by the architecture maintainers to work. As far as I know, few if any of these use __builtin_trap(). Some could be converted to __builtin_trap(), others cannot (x86 for example). If we enhanced __builtin_trap() to take an argument for the trap code, MIPS could be converted. But as it stands now __builtin_trap() is not very useful. As more architectures start adding funky tables that get generated by the inline asm (as in x86), __builtin_trap() becomes less useful. David Daney
Re: [PATCH] ARM: Convert BUG() to use unreachable()
Joe Buck wrote: > On Thu, Dec 17, 2009 at 11:06:13AM -0800, Russell King - ARM Linux wrote: > > On Thu, Dec 17, 2009 at 10:35:17AM -0800, Joe Buck wrote: > > > Besides, didn't I see a whole bunch of kernel security patches related > > > to null pointer dereferences lately? If page 0 can be mapped, you > > > suddenly won't get your trap. > > > > Page 0 can not be mapped on ARM kernels since the late 1990s, and this > > protection is independent of the generic kernel. > > > > Milage may vary on other architectures, but that's not a concern here. It does not trap on at least one ARM-nommu kernel... > I don't understand, though, why you would want to implement a generally > useful facility (make the kernel trap so you can do a post-mortem > analysis) in a way that's only safe for the ARM port. The patch under discussion, which led to these questions and Cc gcc@gcc.gnu.org, is specific to the ARM architecture and that is Russell's focus, as ARM kernel maintainer. But yes, the whole principle of how to trap and whether it's safe to follow a null pointer dereference with __builtin_unreachable() applies to all the other architectures too. -- Jamie
Re: [PATCH] ARM: Convert BUG() to use unreachable()
On Thu, Dec 17, 2009 at 07:38:26PM +, Jamie Lokier wrote: > Joe Buck wrote: > > On Thu, Dec 17, 2009 at 11:06:13AM -0800, Russell King - ARM Linux wrote: > > > On Thu, Dec 17, 2009 at 10:35:17AM -0800, Joe Buck wrote: > > > > Besides, didn't I see a whole bunch of kernel security patches related > > > > to null pointer dereferences lately? If page 0 can be mapped, you > > > > suddenly won't get your trap. > > > > > > Page 0 can not be mapped on ARM kernels since the late 1990s, and this > > > protection is independent of the generic kernel. > > > > > > Milage may vary on other architectures, but that's not a concern here. > > It does not trap on at least one ARM-nommu kernel... I was going to say the following in a different reply but discarded it because it wasn't relevant to the GCC list. I regard ARM nommu as highly experimental, especially as the maintainer vanished half way through merging it into mainline. I know that there are some parts of ARM nommu that are highly buggy - such as ARM940 support invalidating the entire data cache on any DMA transaction... say goodbye stacked return addresses. As such, I would not be surprised if the ARM nommu kernel has _lots_ of weird and wonderful bugs. I am not surprised that NULL pointer dereferences don't work - its actually something I'd expect given that they have a protection unit which the kernel doesn't apparently touch. Maybe the protection unit code never got merged? I've no idea. As I say, uclinux support got as far as being half merged and that's roughly the state it's remained in ever since. We don't even have any no-MMU configurations which the kernel builder automatically tests for us. Given the lack of progress/bug reporting on ARM uclinux, the lack of platform support and the lack of configurations, my view is that there is no one actually using it. I know that I don't particularly take any care with respect to uclinux when making changes to the MMU based kernels. Why bother if apparantly no one's using it?
Re: updated code size comparison
On Thu, Dec 17, 2009 at 19:54, Eric Botcazou wrote: >> However I would prefer to leave these testcases in, unless there is a >> strong feeling that they are too distracting. They serve as poignant >> little reminders about how easy it is to get volatile wrong... > > They skew the results in favor of the less careful compilers so they are more > than simply distracting, they are unfair. Yes, that was my point. If you want to make a separate section for volatile, that would indeed be helpful. Paolo
Re: [PATCH] ARM: Convert BUG() to use unreachable()
On Thu, Dec 17, 2009 at 07:48:37PM +, Russell King - ARM Linux wrote: > Given the lack of progress/bug reporting on ARM uclinux, the lack of > platform support and the lack of configurations, my view is that there > is no one actually using it. I know that I don't particularly take any > care with respect to uclinux when making changes to the MMU based kernels. > Why bother if apparantly no one's using it? Jamie, As you seem to be a user of uclinux on ARM, could you help ensure that the support there is bug fixed and we at least have a configuration file which kautobuild can use to provide feedback on the build status of uclinux on ARM please?
Re: GCC presentation targeted to users (43 slides in english)
> The 43 slides presentation in english is available here > in PDF and openoffice format: > > http://guerby.org/ftp/gcc-toulibre-20091216.pdf > http://guerby.org/ftp/gcc-toulibre-20091216.odp A small nit: you don't need to do 'make bootstrap' anymore, 'make' is enough. -- Eric Botcazou
Re: GCC presentation targeted to users (43 slides in english)
On Thu, 2009-12-17 at 21:02 +0100, Eric Botcazou wrote: > > The 43 slides presentation in english is available here > > in PDF and openoffice format: > > > > http://guerby.org/ftp/gcc-toulibre-20091216.pdf > > http://guerby.org/ftp/gcc-toulibre-20091216.odp > > A small nit: you don't need to do 'make bootstrap' anymore, 'make' is enough. Yes I explained it during the presentation (on native vs cross) but I couldn't remember in what version the change was made so I erred on the safe side :). Laurent
Re: GCC presentation targeted to users (43 slides in english)
> Yes I explained it during the presentation (on native vs cross) but I > couldn't remember in what version the change was made so I erred on the > safe side :). GCC 4.2 I think. -- Eric Botcazou
Re: [LLVMdev] updated code size comparison
On Dec 16, 2009, at 1:26 AM, Paolo Bonzini wrote: > On 12/16/2009 03:21 AM, John Regehr wrote: >> Hopefully the results are more fair and useful now. Again, feedback is >> appreciated. > > I would also avoid testcases using volatile. Smaller code on these > testcases is often a sign of miscompilation rather than optimization. > For example, > http://embed.cs.utah.edu/embarrassing/src_harvested_dec_09/076389.c is > miscompiled on GCC 3.4 and SunCC 5.10. > Perhaps just leaving out those volatile tescases which are miscompiled on other platforms, since not every volatile testcase fails for all compilers. :-) -bw
Re: GMP and GCC 4.3.2
Actually, I just finished updating my 4.3.2 to 4.3.3 and tested it and
I still have the same issue.
This seems to be a problem more than "just" 4.3.2.
Here is the test program:
#include
#include
int main() {
mpz_t a,b;
mpz_init_set_str(a, "100", 10); // program works with 10^9, but not
// with 10^10 (10^20 > 2^64)
mpz_init_set(b, a);
mpz_mul(a, a, a);
gmp_printf("first, in GMP mpz_mul(a,a,a) with a=%Zd gives %Zd \n", b, a);
mpz_set(b, a);
mpz_mul(a, a, a);
gmp_printf("second, in GMP mpz_mul(a,a,a) with a=%Zd gives %Zd \n", b, a);
return 0;
}
We obtain:
first, in GMP mpz_mul(a,a,a) with a=100 gives 1
second, in GMP mpz_mul(a,a,a) with a=1 gives
2254536013160540992915637663717291581095979492475463214517286840718852096
Which clearly is wrong for the second output.
This was tested with a 64 bit architecture. I know that with a 4.1.1
port of the compiler, I do not see this issue.
I will see if I can port it forward to see if I still see the problem
but it might be difficult to port from 4.3.2 to 4.4.2, I'm not sure
how many things have changed but I'm sure quite a bit !
This is the -v of my GCC, version 4.3.3:
Using built-in specs.
Target: myarch64-linux-elf
Configured with:
/home/beyler/myarch64/src/myarch64-gcc-4.3.2/configure
--target=myarch64-linux-elf
--with-headers=/home/beyler/myarch64/src/newlib-1.16.0/newlib/libc/include
--prefix=/home/beyler/myarch64/local --disable-nls
--enable-languages=c --with-newlib --disable-libssp
--with-mpfr=/home/beyler/myarch64/local
Thread model: single
gcc version 4.3.3 (GCC)
Jc
PS: I have already asked the gmp bug mailing list to see if they have
any input on this.
On Thu, Dec 17, 2009 at 6:19 AM, Jay Foad wrote:
> If it's the bug being discussed here:
>
> http://gmplib.org/list-archives/gmp-discuss/2009-April/003717.html
>
> ... then it was reported as fixed here:
>
> http://gcc.gnu.org/ml/gcc/2009-04/msg00562.html
>
> Jay.
>
gcc-4.5-20091217 is now available
Snapshot gcc-4.5-20091217 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20091217/ 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 revision 155328 You'll find: gcc-4.5-20091217.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20091217.tar.bz2 C front end and core compiler gcc-ada-4.5-20091217.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20091217.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20091217.tar.bz2 C++ front end and runtime gcc-java-4.5-20091217.tar.bz2 Java front end and runtime gcc-objc-4.5-20091217.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20091217.tar.bz2The GCC testsuite Diffs from 4.5-20091210 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: GMP and GCC 4.3.2
On 12/18/2009 06:27 AM, Jean Christophe Beyler wrote:
Actually, I just finished updating my 4.3.2 to 4.3.3 and tested it and
I still have the same issue.
This seems to be a problem more than "just" 4.3.2.
Here is the test program:
#include
#include
int main() {
mpz_t a,b;
mpz_init_set_str(a, "100", 10); // program works with 10^9, but not
// with 10^10 (10^20> 2^64)
mpz_init_set(b, a);
mpz_mul(a, a, a);
gmp_printf("first, in GMP mpz_mul(a,a,a) with a=%Zd gives %Zd \n", b, a);
mpz_set(b, a);
mpz_mul(a, a, a);
gmp_printf("second, in GMP mpz_mul(a,a,a) with a=%Zd gives %Zd \n", b, a);
return 0;
}
We obtain:
first, in GMP mpz_mul(a,a,a) with a=100 gives 1
second, in GMP mpz_mul(a,a,a) with a=1 gives
2254536013160540992915637663717291581095979492475463214517286840718852096
Which clearly is wrong for the second output.
This was tested with a 64 bit architecture. I know that with a 4.1.1
port of the compiler, I do not see this issue.
I will see if I can port it forward to see if I still see the problem
but it might be difficult to port from 4.3.2 to 4.4.2, I'm not sure
how many things have changed but I'm sure quite a bit !
This is the -v of my GCC, version 4.3.3:
Using built-in specs.
Target: myarch64-linux-elf
Configured with:
/home/beyler/myarch64/src/myarch64-gcc-4.3.2/configure
--target=myarch64-linux-elf
--with-headers=/home/beyler/myarch64/src/newlib-1.16.0/newlib/libc/include
--prefix=/home/beyler/myarch64/local --disable-nls
--enable-languages=c --with-newlib --disable-libssp
--with-mpfr=/home/beyler/myarch64/local
Thread model: single
gcc version 4.3.3 (GCC)
What's myarch64? I got the correct result for your test with vanilla
gcc-4.3.2 and gmp-4.3.1 on Debian unstable AMD64.
Jie
Re: updated code size comparison
Yes, that was my point. If you want to make a separate section for volatile, that would indeed be helpful. I checked and there are about 37,000 harvested functions containing the volatile qualifier. Next time, there will be even more since we'll be harvesting code from the FreeBSD kernel in addition to Linux. It doesn't seem at all clear that it's productive to separate these out. If people are really hating volatile and think it leads to unfair results, I'll probably just #define away volatile next time. John
Re: How to support 40bit GP register - Take two
On Fri, 20 Nov 2009, Mohamed Shafi wrote: > I tried implementing the suggestion given by Richard, but got into > issues. The GCC frame work is written assuming that there are no modes > with HOST_BITS_PER_WIDE_INT < GET_MODE_BITSIZE (mode) < 2 * > HOST_BITS_PER_WIDE_INT. (Not seeing a reply regarding this issue, so here's mine, belated:) Perhaps a wart, but with a 64-bit HOST_BITS_PER_WIDE_INT, would that affect your port? It's not? Just set need_64bit_hwint=yes in config.gcc. And send a patch for the introductory comment in that file, unless your port already matches the "BITS_PER_WORD > 32 bits" condition. brgds, H-P
Re: How to support 40bit GP register - Take two
2009/12/18 Hans-Peter Nilsson : > On Fri, 20 Nov 2009, Mohamed Shafi wrote: >> I tried implementing the suggestion given by Richard, but got into >> issues. The GCC frame work is written assuming that there are no modes >> with HOST_BITS_PER_WIDE_INT < GET_MODE_BITSIZE (mode) < 2 * >> HOST_BITS_PER_WIDE_INT. > > (Not seeing a reply regarding this issue, so here's mine, belated:) > > Perhaps a wart, but with a 64-bit HOST_BITS_PER_WIDE_INT, would > that affect your port? It's not? Just set need_64bit_hwint=yes > in config.gcc. And send a patch for the introductory comment in > that file, unless your port already matches the "BITS_PER_WORD > > 32 bits" condition. > Thanks Hans for yourr reply I have already tried that. What you are suggesting is the first solution that i got from Richard Henderson. I have mentioned the issues if faced with this in my mail. The GCC frame work is written assuming that there are no modes with HOST_BITS_PER_WIDE_INT < GET_MODE_BITSIZE (mode) < 2 * HOST_BITS_PER_WIDE_INT. So i had to hack at places to get things working. For my target the BITS_PER_WORD == 32. The mode that i am using is RImode (5bytes) Regards, Shafi
