Re: Should 27_io/ios_base/storage/2.cc be XFAILed on powerpc64-apple-darwin9?
Hi, > I don't quite understand: does XFAILing the test mean that the test > isn't attempted, or just that if it fails it doesn't show up on the > report (except incrementing the number of expected failures)? The latter. I think you want to skip it completely for the targets affected by the malloc bug at issue. Paolo.
C++0x Concepts development schedule
Hi, I wonder if there's any kind schedule available on the development Concepts proposal into GCC. I know there's a related branch in svn, but it seems stale as of 11/2008. Please don't take this as a pressure to get things going. I just want to know the time frame it will be ready, I'm sort of excited because of the possibilities it unleashes. I'd really like to help on this task, but I never worked on GCC internals, and helping implement concepts for it isn't the best or more efficient way to start :) Best regards and thanks for the awesome compiler you guys put out, Rodolfo Lima
Re: [RFC] Remove -frtl-abstract-sequences in 4.5
On Thu, Nov 20, 2008 at 21:19, Weddington, Eric <[EMAIL PROTECTED]> wrote: > Are you also proposing to do the re-implementation as you describe above (as > a gimple pass, in IPA mode)? Not necessarily, but it's a possibility. Initially I'm more interested in removing code that is not useful and apparently not widely used. Proposing its removal is a good way of measuring interest. Diego.
Fwd: Mips, -fpie and TLS management
2008/11/20 Daniel Jacobowitz <[EMAIL PROTECTED]>:
> On Thu, Nov 20, 2008 at 05:28:16PM +0100, Joel Porquet wrote:
>> Gcc is using local-exec tls model instead of global-dynamic. The
>> option -fpie is supposed to act as -fpic though (dixit the manual).
>> Here is the first problem...
>
> Could you explain the problem with this? The choice of local-exec vs
> global-dynamic does not affect whether code is position independent.
I agree that wether the code is pic or not and the tls model are quite
independent.
According to the manual, the default policy for TLS is affected by the
pic model though:
-ftls-model=model
...
The default without -fpic is "initial-exec"; with -fpic the
default is "global-dynamic".
> It's a difference between linking an executable versus linking a
> shared library; this is one of the distinctions between -fpie and
> -fpic.
Yes for the linking stage but for the object compilation, -fpie should
be almost the same.
>> But then readelf tells me:
>>
>> Relocation section '.rel.dyn' at offset 0x3d4 contains 2 entries:
>> Offset InfoTypeSym.Value Sym. Name
>> R_MIPS_NONE
>> 5ffe1460 0026 R_MIPS_TLS_DTPMOD
>>
>> The symbol name is missing and most of all, the offset type is missing
>> too: there should be a R_MIPS_TLS_DTPREL type with the
>> R_MIPS_TLS_DTPMOD, since for each tls variable in global dynamic
>> model, tls_get_addr must receive the module index and the offset. Here
>> is the second problem...
>
> That's because this is the local dynamic model.
It could be but firstly when the global-dynamic model is specified one
should expect to get global-dynamic and not local-dynamic, and anyway
it is not local-dynamic.
Let's make the same test with two "global-dynamic" variables:
__thread int test_loc1 __attribute((tls_model("global-dynamic")));
__thread int test_loc2 __attribute((tls_model("global-dynamic")));
void func()
{
test_loc1 = 2;
test_loc2 = 3;
}
Which produces the following asm:
20: 8f99lw t9,0(gp)
20: R_MIPS_CALL16 __tls_get_addr
24: 2784addiu a0,gp,0
24: R_MIPS_TLS_GD test_loc1
28: 0320f809jalrt9
2c: nop
30: 8fbclw gp,0(sp)
34: 24030002li v1,2
38: 8f99lw t9,0(gp)
38: R_MIPS_CALL16 __tls_get_addr
3c: 2784addiu a0,gp,0
3c: R_MIPS_TLS_GD test_loc2
40: 0320f809jalrt9
44: ac43sw v1,0(v0)
48: 8fbf000clw ra,12(sp)
4c: 24030003li v1,3
50: 8fbclw gp,0(sp)
54: ac43sw v1,0(v0)
It is the code for global-dynamic handling (and not local-dynamic).
Otherwise there would be some R_MIPS_TLS_DTPREL_*16 symbols and
anyway, R_MIPS_TLS_GD is the symbol for global-dynamic (it is named
R_MIPS_TLS_LDM for local-dynamic).
However, readelf shows, after linking:
Relocation section '.rel.dyn' at offset 0x3f4 contains 3 entries:
Offset InfoTypeSym.Value Sym. Name
R_MIPS_NONE
5ffe14a0 0026 R_MIPS_TLS_DTPMOD
5ffe14a8 0026 R_MIPS_TLS_DTPMOD
Two R_MIPS_TLS_DTPREL are thus missing (at 5ffe14a4 and 5ffe14ac) .
And if we were really in local-dynamic, we would have only one
R_MIPS_TLS_DTPMOD.
Restrict implementation considered harmful
With looking at PRs 37742 and 37955 I reminded myself of our broken
restrict implementation which tries to model restrict semantics
within our type-based alias set framework. The implementation
heavily relies on correct tracking of restrict bases
(DECL_BASED_ON_RESTRICT_P/DECL_GET_RESTRICT_BASE) - but this
is completely bogus even for trivial testcases like
int foo (int *__restrict p)
{
int *__restrict q;
int v;
q = p + 1;
q = q - 1;
v = *q;
*p = 1;
return v + *q;
}
extern void abort (void);
int main()
{
int i = 0;
if (foo (&i) != 1)
abort ();
return 0;
}
where q is not set to be based on p (and in general with SSA form
its impossible to properly track this as the information is per
decl, not per SSA nae).
Luckily no single tree pass looks at the alias set of an indirect ref
but on the alias sets of the pointed-to types. Which makes the
special restrict pointer handling in get_alias_set ineffective.
Now, tree-vect-transform.c does - to verify that the new memory
reference conflicts with the old one. But this verification
obviously fails here because of the missing links.
I think the only reasonable thing to do is to rip out the broken
restrict pointer handling completely.
Any better ideas?
Thanks,
Richard.
Re: C++0x Concepts development schedule
2008/11/21 Rodolfo Lima <[EMAIL PROTECTED]>: > Please don't take this as a pressure to get things going. I just want to > know the time frame it will be ready, I'm sort of excited because of the > possibilities it unleashes. I'd really like to help on this task, but I > never worked on GCC internals, and helping implement concepts for it > isn't the best or more efficient way to start :) It won't be ready for GCC 4.4 for sure. So I wouldn't expect it in any released GCC in less than one year. On the other hand, you can certainly help. This seems a project that is contained in the C++ front-end (and perhaps touches the interface between middle-end and front-end). Hence, there is no so much internals to learn, in particular if you have a good grasp of standard C++, most of the code is in the cp/ subdir plus c-common.c. The description of the branch says: "At present, the concepts branch provides almost no support for concepts. We are in the process of migrating code from the prototype ConceptGCC." So it is not creating code from scratch. Moreover, diagnosing bugs (why this crashes? how we end up with this value here?) are time-consuming but not particularly difficult tasks. Keeping the branch in sync with mainline, running the testsuite from time to time, even coming up with new testcases and adding them to the testsuite, are also time-consuming but not difficult tasks. If your offer of help was honest, please consider contributing: http://gcc.gnu.org/contribute.html If you have further questions, feel free to ask them here. I am also happy to answer questions to the best of my knowledge by private email. Cheers, Manuel.
Re: Restrict implementation considered harmful
On Fri, Nov 21, 2008 at 06:21, Richard Guenther <[EMAIL PROTECTED]> wrote: > I think the only reasonable thing to do is to rip out the broken > restrict pointer handling completely. > > Any better ideas? I will assume that this program is valid. I am not familiar enough with the restrict definition, but ISTM that if __restrict implies a contract not to make the pointers conflict, then this program is obviously violating it. Having said that, relying on restrict based purely on the DECLs does seem like a bad idea. What if we encoded restrict in the SSA names themselves? PTA could flip a bit specifying whether get_alias_set can rely on restrict or not. Though that seems a bit kludgy. Diego.
Re: Restrict implementation considered harmful
On Fri, 21 Nov 2008, Diego Novillo wrote: > On Fri, Nov 21, 2008 at 06:21, Richard Guenther <[EMAIL PROTECTED]> wrote: > > > I think the only reasonable thing to do is to rip out the broken > > restrict pointer handling completely. > > > > Any better ideas? > > I will assume that this program is valid. I am not familiar enough > with the restrict definition, but ISTM that if __restrict implies a > contract not to make the pointers conflict, then this program is > obviously violating it. Pointers based on the same restrict base do conflict according to the standard. > Having said that, relying on restrict based purely on the DECLs does > seem like a bad idea. What if we encoded restrict in the SSA names > themselves? PTA could flip a bit specifying whether get_alias_set can > rely on restrict or not. Though that seems a bit kludgy. My idea was to instead compute the based-on property during PTA and treat restrict as additional source of points-to information (that is, if we identified two different restrict pointers as bases for two pointers then accesses through them cannot alias). The idea of indirecting this query through assigning an alias set seems to be a fundamental mistake and makes the query much more fragile. See PR38212 for a testcase that is miscompiled at -O2. Richard.
Re: Restrict implementation considered harmful
On Fri, Nov 21, 2008 at 08:31:18AM -0500, Diego Novillo wrote: > On Fri, Nov 21, 2008 at 06:21, Richard Guenther <[EMAIL PROTECTED]> wrote: > > > I think the only reasonable thing to do is to rip out the broken > > restrict pointer handling completely. > > > > Any better ideas? > > I will assume that this program is valid. I am not familiar enough > with the restrict definition, but ISTM that if __restrict implies a > contract not to make the pointers conflict, then this program is > obviously violating it. At least the second testcase in the PR you opened would be easily fixed if we did the same as internal_get_tmp_var does for user VAR_DECLs of restrict pointers from their initializers. Guess something similar would need to be done during inlining for restrict qualified arguments. For the first testcase, I'm not sure how the compiler is supposed to find out what other pointer is a restricted pointer based on, when it doesn't have an initializer. Jakub
Re: Restrict implementation considered harmful
On Fri, 21 Nov 2008, Jakub Jelinek wrote: > On Fri, Nov 21, 2008 at 08:31:18AM -0500, Diego Novillo wrote: > > On Fri, Nov 21, 2008 at 06:21, Richard Guenther <[EMAIL PROTECTED]> wrote: > > > > > I think the only reasonable thing to do is to rip out the broken > > > restrict pointer handling completely. > > > > > > Any better ideas? > > > > I will assume that this program is valid. I am not familiar enough > > with the restrict definition, but ISTM that if __restrict implies a > > contract not to make the pointers conflict, then this program is > > obviously violating it. > > At least the second testcase in the PR you opened would be easily fixed if > we did the same as internal_get_tmp_var does for user VAR_DECLs of restrict > pointers from their initializers. Guess something similar would need > to be done during inlining for restrict qualified arguments. And for variables used by insertion in PRE and LIM. And maybe in other places, like the vectorizer cases we hit. > For the first testcase, I'm not sure how the compiler is supposed to find > out what other pointer is a restricted pointer based on, when it doesn't > have an initializer. I'm not sure how to read 6.7.3.1/4 for this case (ok, the "Formal definition of restrict" is written in a completely confusing manner to me). If assigning a restrict based pointer to something uninitialized triggers "If P is assigned the value of a pointer expression E that is based on another restrict pointer object P2, ... then the behavior is undefined" and whatever is this about the blocks B and B2 doesn't hold then the first testcase would be undefined. But I think that this makes the implementation fragile again as we cannot distinguish between invalid transformations keeping the chains not intact and initial undefined code. For the alias-improvements branch I am going to remove the alias-set based restrict implementation and instead will hopefully end up implementing a points-to based solution annotating SSA_NAME_PTR_INFO and using the oracle for disambiguation. Richard.
Re: Fwd: Mips, -fpie and TLS management
On Fri, Nov 21, 2008 at 11:19:32AM +0100, Joel Porquet wrote: > I agree that wether the code is pic or not and the tls model are quite > independent. > According to the manual, the default policy for TLS is affected by the > pic model though: > > -ftls-model=model > ... > The default without -fpic is "initial-exec"; with -fpic the > default is "global-dynamic". Which is exactly what happens. Using -fpie does not cound as "with -fpic". > > It's a difference between linking an executable versus linking a > > shared library; this is one of the distinctions between -fpie and > > -fpic. > > Yes for the linking stage but for the object compilation, -fpie should > be almost the same. No, it shouldn't. `-fpie' `-fPIE' These options are similar to `-fpic' and `-fPIC', but generated position independent code can be only linked into executables. This is one of the reasons that the generated code can only be used in executables. > It could be but firstly when the global-dynamic model is specified one > should expect to get global-dynamic and not local-dynamic, and anyway > it is not local-dynamic. I don't remember what the deal is with the command line option, but I've run into that before. The answer was, I think, that it is behaving as designed - but not intuitively. As for the model, you're right, it's not local dynamic. It's global dynamic linked into an executable. The linker has performed some optimization on your output file because it can determine the symbol binding at static link time. There's no need for a dynamic relocation to calculate DTPREL when it's a link-time constant. This is all very interesting, but you didn't answer my question: is this causing some problem, or just confusing? These are all intended optimizations. -- Daniel Jacobowitz CodeSourcery
Re: Restrict implementation considered harmful
On Fri, 21 Nov 2008, Richard Guenther wrote: > On Fri, 21 Nov 2008, Jakub Jelinek wrote: > > > On Fri, Nov 21, 2008 at 08:31:18AM -0500, Diego Novillo wrote: > > > On Fri, Nov 21, 2008 at 06:21, Richard Guenther <[EMAIL PROTECTED]> wrote: > > > > > > > I think the only reasonable thing to do is to rip out the broken > > > > restrict pointer handling completely. > > > > > > > > Any better ideas? > > > > > > I will assume that this program is valid. I am not familiar enough > > > with the restrict definition, but ISTM that if __restrict implies a > > > contract not to make the pointers conflict, then this program is > > > obviously violating it. > > > > At least the second testcase in the PR you opened would be easily fixed if > > we did the same as internal_get_tmp_var does for user VAR_DECLs of restrict > > pointers from their initializers. Guess something similar would need > > to be done during inlining for restrict qualified arguments. > > And for variables used by insertion in PRE and LIM. And maybe in > other places, like the vectorizer cases we hit. > > > For the first testcase, I'm not sure how the compiler is supposed to find > > out what other pointer is a restricted pointer based on, when it doesn't > > have an initializer. > > I'm not sure how to read 6.7.3.1/4 for this case (ok, the "Formal > definition of restrict" is written in a completely confusing manner to > me). If assigning a restrict based pointer to something uninitialized > triggers "If P is assigned the value of a pointer expression E that is > based on another restrict pointer object P2, ... then the behavior is > undefined" and whatever is this about the blocks B and B2 doesn't hold > then the first testcase would be undefined. But I think that this > makes the implementation fragile again as we cannot distinguish > between invalid transformations keeping the chains not intact and > initial undefined code. Btw, the definition of "based on" in 6.7.3.1 seems to make any pointer P based on another pointer Q if changing Q prior to evaluating the expression initializing P changes the value of P. Thus it looks like a pointer P is "based on" a pointer Q if P is value-dependent on Q which is certainly the case for the first testcase. Richard.
Re: Restrict implementation considered harmful
Richard Guenther <[EMAIL PROTECTED]> writes:
> int foo (int *__restrict p)
> {
> int *__restrict q;
> int v;
> q = p + 1;
> q = q - 1;
> v = *q;
> *p = 1;
> return v + *q;
> }
> extern void abort (void);
> int main()
> {
> int i = 0;
> if (foo (&i) != 1)
> abort ();
> return 0;
> }
This program appears to me to be invalid according to C99 6.7.3.1,
which is the only definition of restrict that we have.
If P is assigned the value of a pointer expression E that is based
on another restricted pointer object P2, associated with block B2,
then either the execution of B2 shall begin before the execution
of B, or the execution of B2 shall end prior to the assignment.
If these requirements are not met, then the behavior is undefined.
In your program, P is q and P2 is p. Block B and B2 are the same
block: the only block in foo. It is obviously not the case that the
block executes before itself. So I believe the assignment "q = p + 1"
is undefined behaviour.
More generally, as I understand the restrict qualifier, it means that
if two pointers both have the restrict qualifier, and you use one of
the pointers to modify an object, you may not use the other pointer to
access that object. Your program clearly violates that guideline.
Ian
__Unwind_GetIPInfo on Darwin 8.11
hi, a freshly-checked-out gcc trunk, bootstraps fine and check is OK on gcc. However, I'm finding a huge number of failures with g++ caused by the fact that __Unwind_GetIPInfo is not defined. When 'make checking', I conventionally move the built libgcc_s. 1.dylib and libgcc_s.10.4.dylib to one side prior to testing (so that the Apple-supplied system version is used). __Unwind_GetIPInfo is not present in the stock: /usr/lib/libgcc_s.1.dylib or /Developer/SDKs/MacOSX10.4u.sdk/usr/ lib/libgcc_s.1.dylib [the symbol IS present in libgcc_s.1.dylib built from trunk] --- Is this the expected behavior? (there doesn't appear to be an update to the library version). If so - I guess that anyone building with 4.4 would have to supply an updated libgcc ??? cheers, Iain
Re: [PATCH] MIPS: Make BUG() __noreturn.
Geert Uytterhoeven wrote:
On Fri, 21 Nov 2008, Alan Cox wrote:
On Thu, 20 Nov 2008 17:26:36 -0800
David Daney <[EMAIL PROTECTED]> wrote:
MIPS: Make BUG() __noreturn.
Often we do things like put BUG() in the default clause of a case
statement. Since it was not declared __noreturn, this could sometimes
lead to bogus compiler warnings that variables were used
uninitialized.
There is a small problem in that we have to put a magic while(1); loop to
fool GCC into really thinking it is noreturn.
That sounds like your __noreturn macro is wrong.
Try using __attribute__ ((__noreturn__))
if that works then fix up the __noreturn definitions for the MIPS and gcc
you have.
Nope, gcc is too smart:
$ cat a.c
int f(void) __attribute__((__noreturn__));
int f(void)
{
}
$ gcc -c -Wall a.c
a.c: In function f:
a.c:6: warning: `noreturn' function does return
$
That's right.
I was discussing this issue with my colleague Adam Nemet, and we came
up with a couple of options:
1) Enhance the _builtin_trap() function so that we can specify the
break code that is emitted. This would allow us to do something
like:
static inline void __attribute__((noreturn)) BUG()
{
__builtin_trap(0x200);
}
2) Create a new builtin '__builtin_noreturn()' that expands to nothing
but has no CFG edges leaving it, which would allow:
static inline void __attribute__((noreturn)) BUG()
{
__asm__ __volatile__("break %0" : : "i" (0x200));
__builtin_noreturn();
}
David Daney
Re: Restrict implementation considered harmful
Hi,
> This program appears to me to be invalid according to C99 6.7.3.1,
> which is the only definition of restrict that we have.
>
> If P is assigned the value of a pointer expression E that is based
> on another restricted pointer object P2, associated with block B2,
> then either the execution of B2 shall begin before the execution
> of B, or the execution of B2 shall end prior to the assignment.
> If these requirements are not met, then the behavior is undefined.
>
> In your program, P is q and P2 is p. Block B and B2 are the same
> block: the only block in foo. It is obviously not the case that the
> block executes before itself. So I believe the assignment "q = p + 1"
> is undefined behaviour.
But the testcases in the PR can easily be transformed to fulfill this
requirement. E.g.:
int __attribute__((noinline))
foo (int *__restrict p, int i)
{
if (1)
{
int *__restrict q = p + 1;
if (1)
{
int *__restrict r = q - i;
int v, w;
v = *r;
*p = 1;
w = *r;
return v + w;
}
}
}
extern void abort (void);
int main()
{
int i = 0;
if (foo (&i, 1) != 1)
abort ();
return 0;
}
This (and the other testcases similarly changed) still break.
> More generally, as I understand the restrict qualifier, it means that
> if two pointers both have the restrict qualifier, and you use one of
> the pointers to modify an object, you may not use the other pointer to
> access that object.
Can you deduce this from the standard?
Ciao,
Michael.
Re: Fwd: Mips, -fpie and TLS management
> This is one of the reasons that the generated code can only be used
> in executables.
Okay, I abdicate on this point.
Nevertheless, how could i have a coherent compilation concerning the
TLS management, if my executable needs dynamically libraries ? Aren't
the exec and dynamic models completely incompatible in the same
"whole" (eg one executable and shared libraries) ?
I mean you cannot access at the same storage, once with only a pointer
and an offset and once with a DTV.
So if my libraries are compiled with global-dynamic model but the
executable referring to them (and thus to their TLS data) is compiled
with initial-exec, don't we have a problem ?? The libraries will
access their data through a call to tls_get_addr with a module number
and an offset, while the executable will try to access the data
through a simple pointer and an offset.
>> It could be but firstly when the global-dynamic model is specified one
>> should expect to get global-dynamic and not local-dynamic, and anyway
>> it is not local-dynamic.
>
> I don't remember what the deal is with the command line option, but
> I've run into that before. The answer was, I think, that it is
> behaving as designed - but not intuitively.
>
> As for the model, you're right, it's not local dynamic. It's global
> dynamic linked into an executable. The linker has performed some
> optimization on your output file because it can determine the symbol
> binding at static link time. There's no need for a dynamic relocation
> to calculate DTPREL when it's a link-time constant.
But there are no calculation. Here's the code for writing into two
global dynamic variable local to my exec:
__thread int test_loc1 __attribute((tls_model("global-dynamic")));
__thread int test_loc2 __attribute((tls_model("global-dynamic")));
void func()
{
test_loc1 = 2;
test_loc2 = 3;
}
And the compiled and linked code:
5ffe043c: 8f99802clw t9,-32724(gp)
5ffe0440: 27848038addiu a0,gp,-32712
5ffe0444: 0320f809jalrt9
#jump to tls_get_addr
5ffe0448: nop
5ffe044c: 8fbclw gp,0(sp)
5ffe0450: 24030002li v1,2
5ffe0454: 8f99802clw t9,-32724(gp)
5ffe0458: 27848030addiu a0,gp,-32720
5ffe045c: 0320f809jalrt9
#jump to tls_get_addr
5ffe0460: ac43sw v1,0(v0)
5ffe0464: 8fbf000clw ra,12(sp)
5ffe0468: 24030003li v1,3
5ffe046c: 8fbclw gp,0(sp)
5ffe0470: ac43sw v1,0(v0)
And the related reloc symbols are:
5ffe14b0 0026 R_MIPS_TLS_DTPMOD
5ffe14b8 0026 R_MIPS_TLS_DTPMOD
You can see that both the store instruction have not precalculated
offset but a 0 offset. It means that for accessing the two different
variables, the only way is to provide two different values for
R_MIPS_TLS_DTPMOD, which is incoherent. All the local variable for the
exec should be accessed via the same module number.
Well, I try but I really don't understand the "intended optimizations"
you mention. All I see is an attempt to make local-dynamic access (but
in a way that i don't understand and for which i cannot find any
documentation), although the attribute clearly specify
"global-dynamic".
> This is all very interesting, but you didn't answer my question: is
> this causing some problem, or just confusing? These are all intended
> optimizations.
I cannot answer to your question. It is confusing for sure, and
personnally, I think there is a problem, but you seems to think
otherwise, so
Re: __Unwind_GetIPInfo on Darwin 8.11
On Fri, Nov 21, 2008 at 03:57:15PM +, IainS wrote: > hi, > > a freshly-checked-out gcc trunk, bootstraps fine and check is OK on gcc. > However, I'm finding a huge number of failures with g++ caused by the > fact that __Unwind_GetIPInfo is not defined. > > When 'make checking', I conventionally move the built libgcc_s.1.dylib > and libgcc_s.10.4.dylib to one side prior to testing (so that the > Apple-supplied system version is used). > > __Unwind_GetIPInfo is not present in the stock: > /usr/lib/libgcc_s.1.dylib or /Developer/SDKs/MacOSX10.4u.sdk/usr/ > lib/libgcc_s.1.dylib > > [the symbol IS present in libgcc_s.1.dylib built from trunk] > > --- > Is this the expected behavior? (there doesn't appear to be an update to > the library version). > > If so - I guess that anyone building with 4.4 would have to supply an > updated libgcc ??? > > cheers, > Iain > Iain, Since the libgcc can contain new symbols which older libgcc's may not and libstdc++ is built against this newer libgcc, I wouldn't expect it to necessarily work. I would note that the recommended approach for building llvm-gcc42 is for the FSF gcc's libstdc++-v3 to be removed from the source tree so that the system copy is used. I wouldn't be surprised if the stock gcc-4.2 compiler in Xcode 3.1.x was doing the same (building against the legacy libstdc++ from gcc 4.0.1). On fink, we always package the libgcc from the FSF gcc releae in question and link against that by default. Jack
Re: [PATCH] MIPS: Make BUG() __noreturn.
On Fri, 21 Nov 2008, David Daney wrote:
> Geert Uytterhoeven wrote:
> > On Fri, 21 Nov 2008, Alan Cox wrote:
> > > On Thu, 20 Nov 2008 17:26:36 -0800
> > > David Daney <[EMAIL PROTECTED]> wrote:
> > >
> > > > MIPS: Make BUG() __noreturn.
> > > >
> > > > Often we do things like put BUG() in the default clause of a case
> > > > statement. Since it was not declared __noreturn, this could sometimes
> > > > lead to bogus compiler warnings that variables were used
> > > > uninitialized.
> > > >
> > > > There is a small problem in that we have to put a magic while(1); loop
> > > > to
> > > > fool GCC into really thinking it is noreturn.
> > > That sounds like your __noreturn macro is wrong.
> > >
> > > Try using __attribute__ ((__noreturn__))
> > >
> > > if that works then fix up the __noreturn definitions for the MIPS and gcc
> > > you have.
> >
> > Nope, gcc is too smart:
> >
> > $ cat a.c
> >
> > int f(void) __attribute__((__noreturn__));
> >
> > int f(void)
> > {
> > }
> >
> > $ gcc -c -Wall a.c
> > a.c: In function f:
> > a.c:6: warning: `noreturn' function does return
> > $
>
> That's right.
>
> I was discussing this issue with my colleague Adam Nemet, and we came
> up with a couple of options:
>
> 1) Enhance the _builtin_trap() function so that we can specify the
> break code that is emitted. This would allow us to do something
> like:
>
> static inline void __attribute__((noreturn)) BUG()
> {
> __builtin_trap(0x200);
> }
>
> 2) Create a new builtin '__builtin_noreturn()' that expands to nothing
> but has no CFG edges leaving it, which would allow:
>
> static inline void __attribute__((noreturn)) BUG()
> {
> __asm__ __volatile__("break %0" : : "i" (0x200));
> __builtin_noreturn();
> }
Now I remember, yes, __builtin_trap() is how we fixed it on m68k:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e8006b060f3982a969c5170aa869628d54dd30d8
Of course, if you need a different trap code than the default, you're in
trouble.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: Fwd: Mips, -fpie and TLS management
On Fri, Nov 21, 2008 at 06:51:26PM +0100, Joel Porquet wrote:
> Nevertheless, how could i have a coherent compilation concerning the
> TLS management, if my executable needs dynamically libraries ? Aren't
> the exec and dynamic models completely incompatible in the same
> "whole" (eg one executable and shared libraries) ?
No, there's nothing wrong with this. You can even use multiple models
in the same executable for the same symbol. The linker will take care
of everything necessary.
For instance, the executable's TLS block is at a fixed offset from the
DTV pointer.
If you're seeing a bug, then please give a test case that fails at
runtime - there can always be bugs. But there is nothing wrong
with the tests you've posted so far that I can see.
> And the related reloc symbols are:
> 5ffe14b0 0026 R_MIPS_TLS_DTPMOD
> 5ffe14b8 0026 R_MIPS_TLS_DTPMOD
>
> You can see that both the store instruction have not precalculated
> offset but a 0 offset. It means that for accessing the two different
> variables, the only way is to provide two different values for
> R_MIPS_TLS_DTPMOD, which is incoherent.
Your conclusion does not follow from the evidence. __tls_get_addr
takes a pointer to a {module, offset} pair. There's no dynamic
relocation for the offset, but that's OK - the linker has calculated
it at link time. Take a look at the contents of the GOT starting
at 0x5ffe14b0 for four words. The second and fourth words will be
the offsets. This is a global dynamic sequence, since it passes
non-zero offsets to __tls_get_addr.
--
Daniel Jacobowitz
CodeSourcery
Re: Restrict implementation considered harmful
Michael Matz <[EMAIL PROTECTED]> writes:
>> This program appears to me to be invalid according to C99 6.7.3.1,
>> which is the only definition of restrict that we have.
>>
>> If P is assigned the value of a pointer expression E that is based
>> on another restricted pointer object P2, associated with block B2,
>> then either the execution of B2 shall begin before the execution
>> of B, or the execution of B2 shall end prior to the assignment.
>> If these requirements are not met, then the behavior is undefined.
>>
>> In your program, P is q and P2 is p. Block B and B2 are the same
>> block: the only block in foo. It is obviously not the case that the
>> block executes before itself. So I believe the assignment "q = p + 1"
>> is undefined behaviour.
>
> But the testcases in the PR can easily be transformed to fulfill this
> requirement. E.g.:
>
> int __attribute__((noinline))
> foo (int *__restrict p, int i)
> {
> if (1)
> {
> int *__restrict q = p + 1;
> if (1)
> {
> int *__restrict r = q - i;
> int v, w;
> v = *r;
> *p = 1;
> w = *r;
> return v + w;
> }
> }
> }
> extern void abort (void);
> int main()
> {
> int i = 0;
> if (foo (&i, 1) != 1)
> abort ();
> return 0;
> }
>
> This (and the other testcases similarly changed) still break.
OK, let me quote the whole paragraph:
During each execution of B, let L be any lvalue that has &L based
on P. If L is used to access the value of the object X that it
designates, and X is also modified (by any means), then the
following requirements apply: T shall not be const-qualified.
Every other lvalue used to access the value of X shall also have
its address based on P. Every access that modifies X shall be
considered also to modify P, for the purposes of this subclause.
If P is assigned the value of a pointer expression E that is based
on another restricted pointer object P2, associated with block B2,
then either the execution of B2 shall begin before the execution
of B, or the execution of B2 shall end prior to the assignment.
If these requirements are not met, then the behavior is undefined.
The object X is *r. You are accessing the object as *r, so in this
paragraph P is r. The paragraph says that every lvalue used to access
the object must be based on P, which is r. Your program violates
that, because you are accessing it via p, which is not based on r.
Your argument is presumably that the value of r is based on p, which
it is. But I don't see how that helps. Can you walk through that
paragraph in terms of your program and show how it meets the
requirements of that paragraph?
>> More generally, as I understand the restrict qualifier, it means that
>> if two pointers both have the restrict qualifier, and you use one of
>> the pointers to modify an object, you may not use the other pointer to
>> access that object.
>
> Can you deduce this from the standard?
The standard is very obscure, but the rationale, while not normative,
is at least more clear:
A translator can assume that a restrict-qualified pointer declared
with block scope is, during each execution of the block, the sole
initial means of access to an object.
So I guess the question is whether the rationale is incorrect in its
paraphrasing of the standard.
Ian
Re: Restrict implementation considered harmful
On Fri, Nov 21, 2008 at 2:23 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Michael Matz <[EMAIL PROTECTED]> writes:
>
>>> This program appears to me to be invalid according to C99 6.7.3.1,
>>> which is the only definition of restrict that we have.
>>>
>>> If P is assigned the value of a pointer expression E that is based
>>> on another restricted pointer object P2, associated with block B2,
>>> then either the execution of B2 shall begin before the execution
>>> of B, or the execution of B2 shall end prior to the assignment.
>>> If these requirements are not met, then the behavior is undefined.
>>>
>>> In your program, P is q and P2 is p. Block B and B2 are the same
>>> block: the only block in foo. It is obviously not the case that the
>>> block executes before itself. So I believe the assignment "q = p + 1"
>>> is undefined behaviour.
>>
>> But the testcases in the PR can easily be transformed to fulfill this
>> requirement. E.g.:
>>
>> int __attribute__((noinline))
>> foo (int *__restrict p, int i)
>> {
>> if (1)
>> {
>> int *__restrict q = p + 1;
>> if (1)
>> {
>> int *__restrict r = q - i;
>> int v, w;
>> v = *r;
>> *p = 1;
>> w = *r;
>> return v + w;
>> }
>> }
>> }
>> extern void abort (void);
>> int main()
>> {
>> int i = 0;
>> if (foo (&i, 1) != 1)
>> abort ();
>> return 0;
>> }
>>
>> This (and the other testcases similarly changed) still break.
FWIW, I believe most other compiler get restrict "wrong" just as badly
as us when it comes to "based on" pointers.
Didn't you also find this to be the case, Richard?
It is going to be roughly impossible to be conformant unless we
propagate restrict around in the actual frontends, which still have
actual block information.
Re: [PATCH] MIPS: Make BUG() __noreturn.
On Fri, Nov 21, 2008 at 07:46:43PM +0100, Geert Uytterhoeven wrote:
> > up with a couple of options:
> >
> > 1) Enhance the _builtin_trap() function so that we can specify the
> > break code that is emitted. This would allow us to do something
> > like:
> >
> > static inline void __attribute__((noreturn)) BUG()
> > {
> > __builtin_trap(0x200);
> > }
I had suggested this one before ...
> > 2) Create a new builtin '__builtin_noreturn()' that expands to nothing
> > but has no CFG edges leaving it, which would allow:
> >
> > static inline void __attribute__((noreturn)) BUG()
> > {
> > __asm__ __volatile__("break %0" : : "i" (0x200));
> > __builtin_noreturn();
> > }
>
> Now I remember, yes, __builtin_trap() is how we fixed it on m68k:
I like this interface.
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e8006b060f3982a969c5170aa869628d54dd30d8
>
> Of course, if you need a different trap code than the default, you're in
> trouble.
MIPS ISA newer than MIPS I also have conditional break codes allowing
something like this:
#define BUG_ON(condition) \
do {\
__asm__ __volatile__("tne $0, %0, %1" \
: : "r" (condition), "i" (BRK_BUG)); \
} while (0)
that is test of condition and the trap as a single instruction. Note there
are break and trap instructions on MIPS and they are basically doing the
same job ...
Ralf
gcc-4.4-20081121 is now available
Snapshot gcc-4.4-20081121 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20081121/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 142103 You'll find: gcc-4.4-20081121.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20081121.tar.bz2 C front end and core compiler gcc-ada-4.4-20081121.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20081121.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20081121.tar.bz2 C++ front end and runtime gcc-java-4.4-20081121.tar.bz2 Java front end and runtime gcc-objc-4.4-20081121.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20081121.tar.bz2The GCC testsuite Diffs from 4.4-20081114 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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: Restrict implementation considered harmful
On Fri, Nov 21, 2008 at 10:14 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 21, 2008 at 2:23 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>> Michael Matz <[EMAIL PROTECTED]> writes:
>>
This program appears to me to be invalid according to C99 6.7.3.1,
which is the only definition of restrict that we have.
If P is assigned the value of a pointer expression E that is based
on another restricted pointer object P2, associated with block B2,
then either the execution of B2 shall begin before the execution
of B, or the execution of B2 shall end prior to the assignment.
If these requirements are not met, then the behavior is undefined.
In your program, P is q and P2 is p. Block B and B2 are the same
block: the only block in foo. It is obviously not the case that the
block executes before itself. So I believe the assignment "q = p + 1"
is undefined behaviour.
>>>
>>> But the testcases in the PR can easily be transformed to fulfill this
>>> requirement. E.g.:
>>>
>>> int __attribute__((noinline))
>>> foo (int *__restrict p, int i)
>>> {
>>> if (1)
>>> {
>>> int *__restrict q = p + 1;
>>> if (1)
>>> {
>>> int *__restrict r = q - i;
>>> int v, w;
>>> v = *r;
>>> *p = 1;
>>> w = *r;
>>> return v + w;
>>> }
>>> }
>>> }
>>> extern void abort (void);
>>> int main()
>>> {
>>> int i = 0;
>>> if (foo (&i, 1) != 1)
>>> abort ();
>>> return 0;
>>> }
>>>
>>> This (and the other testcases similarly changed) still break.
>
> FWIW, I believe most other compiler get restrict "wrong" just as badly
> as us when it comes to "based on" pointers.
> Didn't you also find this to be the case, Richard?
Yes, the Intel compiler at least (version 9.1) behaves as bad as we do.
> It is going to be roughly impossible to be conformant unless we
> propagate restrict around in the actual frontends, which still have
> actual block information.
I think we should try to implement a more sane and forgiving variant of
restrict - simply because not doing so makes many transformation GCC does
itself "violate" the restrict specification (for example just make PRE do
an insertion on a valid testcase - this would make it break again unless we
fix all GCC passes to properly update the based-on information).
Note that I am not suggesting we need to fix 4.4 or earlier versions - I am just
very confident that the current implementation using TBAA alias sets is
wrong.
Richard.
Re: [PATCH] MIPS: Make BUG() __noreturn.
Andrew Morton wrote:
Yup, this change will fix some compile warnings which will never be
fixed in any other way for mips.
+static inline void __noreturn BUG(void)
+{
+ __asm__ __volatile__("break %0" : : "i" (BRK_BUG));
+ /* Fool GCC into thinking the function doesn't return. */
+ while (1)
+ ;
+}
This kind of sucks, doesn't it? It adds instructions into the kernel
text, very frequently on fast paths. Those instructions are never
executed, and we're blowing away i-cache just to quash compiler
warnings.
For example, this:
--- a/arch/x86/include/asm/bug.h~a
+++ a/arch/x86/include/asm/bug.h
@@ -22,14 +22,12 @@ do {
\
".popsection"\
: : "i" (__FILE__), "i" (__LINE__),\
"i" (sizeof(struct bug_entry))); \
- for (;;) ; \
} while (0)
#else
#define BUG() \
do { \
asm volatile("ud2"); \
- for (;;) ; \
} while (0)
#endif
_
reduces the size of i386 mm/vmalloc.o text by 56 bytes.
I wonder if there is any clever way in which we can do this without
introducing additional runtime cost.
As I said in the other part of the thread, We are working on a GCC patch
that adds a new built-in function '__builtin_noreturn()', that you could
substitute for 'for(;;);' that emits no instructions in this case.
David Daney
