Re: Uninitialized integers and warnings
On 04/09/13 16:06, Ian Lance Taylor wrote:
> On Wed, Sep 4, 2013 at 6:40 AM, Kirill Tkhai wrote:
>>
>> the following example compiles without warnings:
>>
>> $ cat a.c
>> int func (int p)
>> {
>> int x;
>> if (p != 0)
>> x = 1;
>> return x;
>> }
>>
>> $ gcc -c a.c -Wall
>> (no messages)
>>
>> Is there no error? Why compiler doesn't print a error
>> about uninitialized variable?
>>
>> I saw many pieces like this in GNU software. Does
>> it mean that it is a de-facto standard and gcc won't warn
>> about code like this in the future?
>
> This question would be more appropriate on the mailing list
> gcc-h...@gcc.gnu.org. The mailing list gcc@gcc.gnu.org is for
> discussions about the development of GCC itself. Please take any
> followups to gcc-help. Thanks.
>
> That said, I think this case is a bug. Please report it following the
> instructions at http://gcc.gnu.org/bugs. Thanks.
>
> Ian
>
That depends on the version of gcc. I believe the
"-Wmaybe-uninitialized" option was introduced in gcc 4.7, precisely to
cover cases like this. Previous versions of gcc considered "x" to be
initialised if some paths lead to its initialisation, so no warning is
triggered.
David
Reusing OpenMP front end infrastructure for OpenACC -- how?
Hi! Implementing OpenACC support in GCC's frontends, there are things that I trivially have to reimplement, that are already present for OpenMP. For example, the infrastructure for parsing clauses (as attached to OpenACC and OpenMP directives), and their representation in the GCC internal data structures. Given the syntactical similarity of OpenACC and OpenMP, this infrastructure is similar, too, if not even identical. Thus, my inner engineer tells me we ought to share this infrastructure instead of having a copy of it only different for s%omp%oacc. For a specific example, I'd like to reuse everything known by omp_clause* and similar, and extend it with the things OpenACC does additionally/differently (adding safe-guards, if not already present, to the OpenMP code so that no clauses specific to OpenACC end up there). Is this generally an accepted approach? If yes, should I rename omp* to, say, oacc_omp* (putting the OpenACC tag first for the simple reason that it sorts first alphabetically), or can we think of a better tag than oacc_omp, or should I leave the names as omp* and add comments that these things are used for OpenACC, too? Creating a (class) hierarchy of clauses that are valid for both OpenACC and OpenMP, and then specific ones for only OpenACC or OpenMP, seems overkill to me; I'd rather have the OpenACC/OpenMP passes that are handling the shared set of clauses error out if they meet one they aren't supposed to handle. Grüße, Thomas pgphRIZRynHul.pgp Description: PGP signature
Re: Reusing OpenMP front end infrastructure for OpenACC -- how?
On Thu, Sep 05, 2013 at 04:51:14PM +0200, Thomas Schwinge wrote: > Implementing OpenACC support in GCC's frontends, there are things that I > trivially have to reimplement, that are already present for OpenMP. For > example, the infrastructure for parsing clauses (as attached to OpenACC > and OpenMP directives), and their representation in the GCC internal data > structures. Given the syntactical similarity of OpenACC and OpenMP, this > infrastructure is similar, too, if not even identical. Thus, my inner > engineer tells me we ought to share this infrastructure instead of having > a copy of it only different for s%omp%oacc. > > For a specific example, I'd like to reuse everything known by omp_clause* > and similar, and extend it with the things OpenACC does > additionally/differently (adding safe-guards, if not already present, to > the OpenMP code so that no clauses specific to OpenACC end up there). Most of the omp-low.c code has asserts to verify no unknown clauses are passed to it, and during parsing it has bitmasks of allowable clauses. > Is this generally an accepted approach? If yes, should I rename omp* to, > say, oacc_omp* (putting the OpenACC tag first for the simple reason that > it sorts first alphabetically), or can we think of a better tag than > oacc_omp, or should I leave the names as omp* and add comments that these > things are used for OpenACC, too? I think there is no point in renaming the existing stuff, we use it for some Cilk+ stuff too these days, renaming could only complicate maintainance, making it harder to backport OpenMP bugfixes to older release branches etc. IMHO just use from the OpenMP parsing, trees and gimple stuff whatever is usable for OpenACC too, and just for stuff that doesn't have counterparts add oacc/OACC stuff. Say, for clauses IMHO it is just fine if you use OMP_CLAUSE tree code, and just add additional OACC_CLAUSE_SOMETHING, OACC_CLAUSE_SOMETHINGELSE etc. to the list of omp clauses and descriptors, just put it likely at the end of the list with a comment that it is OpenACC specific stuff. If some clause is used with the same meaning in both standards, you can either just always use OMP_CLAUSE_WHATEVER, or #define OACC_CLAUSE_WHATEVER OMP_CLAUSE_WHATEVER. Jakub
Re: Uninitialized integers and warnings
On Wed, Sep 4, 2013 at 10:34 PM, Umesh Kalappa wrote:
When p == 0 the program has undefined behaviour,
> Ian,What makes you to say this is undefined ?,Please can you elaborate more
> on this and again tried with below sample
>
>
> int func (int p)
> {
> int x;
> if (p != 1)
> x = 1;
> return x;
> }
When p == 1 the behaviour of this function is undefined.
C99 6.7.8 p10: "If an object that has automatic storage duration is
not initialized explicitly, its value is indeterminate."
C99 Annex J.2: "The behavior is undefined in the following
circumstances: ... — The value of an object with automatic storage
duration is used while it is indeterminate (6.2.4, 6.7.8, 6.8)."
Let me ask you: what makes you say that the behaviour of this function
is *not* undefined when p == 1?
> Still gcc return with 1 with 03 option and returns some junk with default
> run.Which is inconsistent or Did i missing something here ???
When the behaviour is undefined anything can happen. There is no
meaning to such a program.
Ian
gcc-4.8-20130905 is now available
Snapshot gcc-4.8-20130905 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20130905/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 202296 You'll find: gcc-4.8-20130905.tar.bz2 Complete GCC MD5=dfb12b0b1dd3b6d5076ef8b80180dde6 SHA1=3b559c123c3b87ba0689c834e78480b8abfe9f04 Diffs from 4.8-20130829 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 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.
