> OK.
Thanks, committed.
DJ Delorie wrote:
> How about this?
OK.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
How about this?
--- gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr36321.c 2008-07-23
00:21:31.0 -0400
+++ ./pr36321.c 2008-11-24 13:46:04.0 -0500
@@ -17,7 +17,9 @@
}
+static char * volatile argp = "pr36321.x";
+
int main(int argc, char **argv)
{
- foo (argv[0]);
+ fo
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Andreas Schwab wrote:
>> Mark Mitchell <[EMAIL PROTECTED]> writes:
>>
>>> However, I think an even better fix is just to hard-code the string and
>>> make it volatile. Presumably, the use of argv[0] here is just to keep
>>> the compiler from optimizing
Andreas Schwab wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
>> However, I think an even better fix is just to hard-code the string and
>> make it volatile. Presumably, the use of argv[0] here is just to keep
>> the compiler from optimizing the program away. So, I suggest doing
>> somethi
Mark Mitchell <[EMAIL PROTECTED]> writes:
> However, I think an even better fix is just to hard-code the string and
> make it volatile. Presumably, the use of argv[0] here is just to keep
> the compiler from optimizing the program away. So, I suggest doing
> something like:
>
> volatile char *
Paul Brook wrote:
> foo (argv[0]);
> I'd say it's a broken test then.
It's a broken program, in full generality.
DJ, you could fix this either by checking argc != 0 in the test, or by
adding an effective-target condition that the test be run only on
targets that pass argv[0]. I think t
On Tuesday 18 November 2008, DJ Delorie wrote:
> > I think a more relevant question is whether it's ok to pass 0, {NULL} for
> > argc, argv.
>
> You can do that on desktop linux, you know:
>
> execl(some_prog_name, NULL);
>
> argv[0] is NOT guaranteed to be non-NULL:
>
> ISO/IEC 9899:1999(E)
> I think a more relevant question is whether it's ok to pass 0, {NULL} for
> argc, argv.
You can do that on desktop linux, you know:
execl(some_prog_name, NULL);
argv[0] is NOT guaranteed to be non-NULL:
ISO/IEC 9899:1999(E) 5.1.2.2.1
2 If they are declared, the parameters to the main
> What are the expectations here? Do we expect simulators to set up
> argv[0]? (the m32c BSP acts like you're on real hardware) Do we expect
> simulators to blithely ignore NULL pointer references?
I think a more relevant question is whether it's ok to pass 0, {NULL} for
argc, argv. If yes then
gcc.c-torture/execute/pr36321.c fails on m32c because the simulator
doesn't set argv[0] *and* the simulator has NULL pointer detection:
void foo(char *str)
{
int len2 = strlen (str);
. . .
int main(int argc, char **argv)
{
foo (argv[0
11 matches
Mail list logo
