Bug 24016 - Missing warning for unspecified evaluation order
Summary: Missing warning for unspecified evaluation order
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.1.0
: P2 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic, stmt-expr
Depends on:
Blocks:
 
Reported: 2005-09-22 17:14 UTC by Andrew Pinski
Modified: 2022-11-28 18:41 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-02-26 19:19:48


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Pinski 2005-09-22 17:14:24 UTC
Take the following example:
void f(int *a)
{
  *a++ = __extension__ ({ int bb = *a; bb; });
}
---
We don't warn for the operation on a.  This is most likely we don't look into a BLOCK or a statement list, 
I don't know which one.  If I remove the declation of bb, it works, so I am going to assume we don't 
look into BLOCKs.

This was reduced from the following code with glibc and -O1:
#include <ctype.h>
void strtolower(char *data) { while (*data != '\0') *data++ = tolower(*data); }
Comment 1 jsm-csl@polyomino.org.uk 2005-09-22 17:24:46 UTC
Subject: Re:  New: Missing "operation on xxx may be undefined"
 on obvious undefined code

On Thu, 22 Sep 2005, pinskia at gcc dot gnu dot org wrote:

> Take the following example:
> void f(int *a)
> {
>   *a++ = __extension__ ({ int bb = *a; bb; });
> }

I'm not convinced this is undefined: statement expressions act like 
(inline) function calls for the purpose of sequence point rules so the 
execution of the statement expression suspends the execution of the rest 
of the surrounding expression and there are sequence points at the 
beginning and end of the statement expression.

It is, however, at least unspecified order of evaluation and a warning 
here would still make sense.

Comment 2 Manuel López-Ibáñez 2007-03-12 17:48:41 UTC
(In reply to comment #1)
> 
> It is, however, at least unspecified order of evaluation and a warning 
> here would still make sense.
> 

A candidate for -Wsequence-points ?
Comment 3 Mikhail Maltsev 2015-05-23 06:09:08 UTC
It seems to me that __extension__ also inhibits some other useful warnings. For example:

#include <string.h>
int foo(void *x) {
    return strcmp(x + 1, "test");
}

does not cause warnings when compiled with -Wpointer-arith -O1 (glibc v. 2.17). It can be reduced to:

int foo(void *x) {
    return __extension__({ __builtin_strcmp(x + 1, "test"); });
}

Note, that we do warn about

int foo(void *x) {
    return ({ __builtin_strcmp(x + 1, "test"); });
}
Comment 4 Marek Polacek 2015-05-23 13:45:20 UTC
Since arithmetic on void * (treating sizeof(void) as 1) is a GNU extension, that behavior is desirable.
Comment 5 Eric Gallager 2021-12-31 01:58:32 UTC
(In reply to Manuel López-Ibáñez from comment #2)
> (In reply to comment #1)
> > 
> > It is, however, at least unspecified order of evaluation and a warning 
> > here would still make sense.
> > 
> 
> A candidate for -Wsequence-points ?

...or a new flag?