public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)
       [not found] <bug-36296-4@http.gcc.gnu.org/bugzilla/>
@ 2013-04-17  8:40 ` vincent-gcc at vinc17 dot net
  2013-04-17  9:19 ` manu at gcc dot gnu.org
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 12+ messages in thread
From: vincent-gcc at vinc17 dot net @ 2013-04-17  8:40 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296

--- Comment #16 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> 2013-04-17 08:40:09 UTC ---
(In reply to comment #3)
> A way to tell gcc a variable is not uninitialized is to perform
> self-initialization like
> 
>  int i = i;
> 
> this will cause no code generation but inhibits the warning.  Other compilers
> may warn about this construct of course.

What makes things worse about this workaround is that even protecting this by a

#if defined(__GNUC__)

may not be sufficient as other compilers may claim GNUC compatibility and
behave differently. This is the case of clang (at least under Debian):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705583

The only good solution would be to fix the bug. I've checked that it is still
there in the trunk revision 197260 (current Debian's gcc-snapshot).
>From gcc-bugs-return-420441-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 17 08:49:07 2013
Return-Path: <gcc-bugs-return-420441-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26206 invoked by alias); 17 Apr 2013 08:49:07 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 26002 invoked by uid 48); 17 Apr 2013 08:48:35 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/56982] [4.8/4.9 Regression] Bad optimization with setjmp()
Date: Wed, 17 Apr 2013 08:49:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.1
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56982-4-krIsHuxaY5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56982-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56982-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01586.txt.bz2
Content-length: 2221


http://gcc.gnu.org/bugzilla/show_bug.cgi?idV982

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> 2013-04-17 08:48:33 UTC ---
So the questions are:
- is it desirable that uncprop does anything to SSA_NAME_VAR == NULL phis?

sure - it is all about improving out-of-SSA coalescing opportunities
and avoiding copies

- shouldn't something like that be not performed if current function calls
setjmp (or more narrowly, if there is a returns twice function somewhere in
between the considered setter and user)?

the testcase shows that uncprop extends the lifetime of an SSA name
across a setjmp call - but it can only do so because it's an SSA name.
Which means the testcase is questionable as 'n' is not declared volatile, no?

- what other optimizations might be similarly problematic across returns twice
calls?

every optimization pass that performs hosting.  PRE comes to my mind for

  if (x)
    tem = expr;
  setjmp ()
  var = expr;

which would happily eliminate the partial redundancy, moving expr to the
else arm of the if () and thus extending the lifetime of 'var' across
the setjmp call.

We do not explicitely model the abnormal control flow for setjmp / longjmp
which is the reason all these issues may appear.  So I believe the
correct fix is to either declare the testcase invalid or to model
the abnormal control flow explicitely. Add abnormal edges from all
call sites in the function that may end up calling longjmp _and_ eventually an
abnormal edge from function entry as we can call longjmp from callers
as well (though that may be invalid and thus we do not have to care?).

I don't see an "easy" fix for the issue (well, maybe the specific testcase).
That it happens only after my patch is probably pure luck because of for
example the PRE issue.  Testcase for that:

int f (int a, int flag)
{
  int tem;
  if (flag)
    tem = a + 1;
  int x = setjmp (env);
  int tem2 = a + 1;
  if (x)
    return tem2;
  return tem;
}

validity of course is questionable, but we clearly use tem only on the
normal path and tem2 on the abnormal path.  PRE does the transform
I indicated, proper abnormal edges would disable the transform.


^ permalink raw reply	[flat|nested] 12+ messages in thread
* [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)
       [not found] <bug-36296-4@http.gcc.gnu.org/bugzilla/>
  2013-04-17  8:40 ` [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization) vincent-gcc at vinc17 dot net
@ 2013-04-17  9:19 ` manu at gcc dot gnu.org
  2013-04-17  9:32 ` manu at gcc dot gnu.org
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 12+ messages in thread
From: manu at gcc dot gnu.org @ 2013-04-17  9:19 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic

--- Comment #17 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-04-17 09:19:09 UTC ---
(In reply to comment #16)
> (In reply to comment #3)
> > A way to tell gcc a variable is not uninitialized is to perform
> > self-initialization like
> > 
> >  int i = i;
> > 
> > this will cause no code generation but inhibits the warning.  Other compilers
> > may warn about this construct of course.

> The only good solution would be to fix the bug. I've checked that it is still
> there in the trunk revision 197260 (current Debian's gcc-snapshot).

If you mean to fix the false warning, then you are likely to wait a long long
time (in order of years) because it doesn't seem a trivial thing to fix and
there are very very few people with enough GCC knowledge to fix it (and they
are busy with other things).

What would be trivial to fix (but require persistence, patience and time) is to
implement this idea:

http://gcc.gnu.org/ml/gcc/2010-08/msg00297.html

that is, either  __attribute__ ((initialized))

or _Pragma("GCC diagnostic ignored \"-Wuninitialized\"").

(Personally, I prefer the latter, since it reuses existing code).

Add as a follow-up, get rid of the non-portable valgrind-unfriendly i=i idiom
that has caused so much grief over the years.

However, we still need someone with the persistence, patience and time to
implement this and get it past the powers that be.
>From gcc-bugs-return-420450-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 17 09:29:28 2013
Return-Path: <gcc-bugs-return-420450-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19699 invoked by alias); 17 Apr 2013 09:29:28 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 19485 invoked by uid 48); 17 Apr 2013 09:28:56 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/56982] [4.8/4.9 Regression] Bad optimization with setjmp()
Date: Wed, 17 Apr 2013 09:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.1
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56982-4-BpwOZ4WBe8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56982-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56982-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01595.txt.bz2
Content-length: 1123


http://gcc.gnu.org/bugzilla/show_bug.cgi?idV982

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-17 09:28:55 UTC ---
#include <stdio.h>
#include <setjmp.h>

static sigjmp_buf env;
static inline int g (int x)
{
  if (x)
    {
      fprintf (stderr, "Returning 0\n");
      return 0;
    }
  else
    {
      fprintf (stderr, "Returning 1\n");
      return 1;
    }
}
__attribute__ ((noinline))
void bar (int n)
{
  if (n == 0)
    exit (0);
  static int x;
  if (x++) abort ();
  longjmp (env, 42);
}
int
f (int *e)
{
  int n = *e;
  if (n)
    return 1;
  int x = setjmp (env);
  n = g (x);
  fprintf (stderr, "x = %i, n = %i\n", x, n);
  bar (n);
}
int
main ()
{
  int v = 0;
  return f (&v);
}

Adjusted testcase that fails even with GCC 4.7.2 at -O2, works with -O2
-fno-dominator-opts (which disables uncprop).  Again, I don't see how
this could be declared invalid, while n is declared before the setjmp, it is
not live across the setjmp call.  This adjusted testcase regressed in April
2005 (i.e. 4.1+ regression).


^ permalink raw reply	[flat|nested] 12+ messages in thread
* [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)
       [not found] <bug-36296-4@http.gcc.gnu.org/bugzilla/>
  2013-04-17  8:40 ` [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization) vincent-gcc at vinc17 dot net
  2013-04-17  9:19 ` manu at gcc dot gnu.org
@ 2013-04-17  9:32 ` manu at gcc dot gnu.org
  2013-04-17  9:37 ` manu at gcc dot gnu.org
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 12+ messages in thread
From: manu at gcc dot gnu.org @ 2013-04-17  9:32 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296

--- Comment #18 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-04-17 09:31:59 UTC ---
In fact, we should have removed the i=i idiom a long time ago. The correct
thing to do (as Linus says) is to initialize the variable to a sensible value
to silence the warning: http://lwn.net/Articles/529954/

If GCC is smart enough to remove the initialization, then there is no harm. If
GCC is not smart enough, then the code is probably complex enough that GCC
cannot optimize it properly and this is why it gives a false positive, so the
fake initialization is the least of your worries.
>From gcc-bugs-return-420451-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 17 09:32:01 2013
Return-Path: <gcc-bugs-return-420451-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21452 invoked by alias); 17 Apr 2013 09:32:01 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 21161 invoked by uid 48); 17 Apr 2013 09:31:29 -0000
From: "skannan at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug web/44269] Search for PR number in mailing lists fails
Date: Wed, 17 Apr 2013 09:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: web
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: skannan at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: CC
Message-ID: <bug-44269-4-am2WhZYIFk@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-44269-4@http.gcc.gnu.org/bugzilla/>
References: <bug-44269-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01596.txt.bz2
Content-length: 604


http://gcc.gnu.org/bugzilla/show_bug.cgi?idD269

Shakthi Kannan <skannan at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |skannan at redhat dot com

--- Comment #2 from Shakthi Kannan <skannan at redhat dot com> 2013-04-17 09:31:28 UTC ---
Searching for 18249 in the web archive of the gcc-patches mailing list with
mnoGoSearch 3.3.13 does return the link to PR 18249.

http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01458.html


^ permalink raw reply	[flat|nested] 12+ messages in thread
* [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)
       [not found] <bug-36296-4@http.gcc.gnu.org/bugzilla/>
                   ` (2 preceding siblings ...)
  2013-04-17  9:32 ` manu at gcc dot gnu.org
@ 2013-04-17  9:37 ` manu at gcc dot gnu.org
  2013-04-17 11:17 ` vincent-gcc at vinc17 dot net
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 12+ messages in thread
From: manu at gcc dot gnu.org @ 2013-04-17  9:37 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296

--- Comment #19 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-04-17 09:37:24 UTC ---
(In reply to comment #2)

> 1. Split the -Wuninitialized into two different warnings: one for which gcc
> knows that the variable is uninitialized and one for which it cannot decide.
> -Wuninitialized currently does both.

Note that -Wmaybe-uninitialized is available since at least GCC 4.8.0
>From gcc-bugs-return-420454-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 17 09:40:32 2013
Return-Path: <gcc-bugs-return-420454-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28676 invoked by alias); 17 Apr 2013 09:40:32 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 27768 invoked by uid 48); 17 Apr 2013 09:40:00 -0000
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well
Date: Wed, 17 Apr 2013 09:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56981-4-zXXMTSdt7s@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56981-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56981-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01599.txt.bz2
Content-length: 5058


http://gcc.gnu.org/bugzilla/show_bug.cgi?idV981

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2013-04-17 09:39:58 UTC ---
(In reply to comment #2)
> There is a seek inside next_record_w_unf. That function is used for DIRECT I/O.
> Looks conceptually wrong to me for sequential unformatted.  I won't have time
> for a few days to look at this further.

Well, what gfortran does is:

* write place-holder record length in the heading record marker
* write actual data
* write tailing record marker (1st call to write_us_marker in
next_record_w_unf)
* write actual length of this record, i.e. seek back + write_us_marker + see to
past the tailing record marker (all in next_record_w_unf)


I think what other compilers do is to make use of the following item in the
Fortran standard:

"The value of the RECL= specifier shall be positive. It specifies the length of
each record in a file being connected for direct access, or specifies the
maximum length of a record in a file being connected for sequential access."
(F2008, "9.5.6.15 RECL= specifier in the OPEN statement")


I tried the following program:
-------------------------------
integer, allocatable :: array(:)
integer :: rl, i
open(99,file="/dev/null",form="unformatted")
inquire(99,recl=rl)
allocate(array(1024*1024*100))
array = 0
print *,rl, size(array)/4
write(99) (array, i=1,1000)
close(99)
end
-------------------------------

With gfortran, it takes only: 0.203s and one has:
     19 mmap
     26 open
    392 lseek
   1784 write

The question is why there are that many seeks. There should be only a single
record!


With pathf95, it fails after 0.099s with the error:
 "This request exceeds the maximum record size."

And with g95, it takes 4.946s (!) until it fails with "Writing more data than
the record size (RECL)":
     11 close
     17 fstat
     20 mprotect
     21 stat
     25 mmap
     30 write
     47 open
where the mmap+munmap pairs seem to take the lion share of the time.


However, one can do better: NAG f95 only needs 0.007s and does:
      5 read
      6 lseek
      8 mprotect
     10 fstat
     23 stat
     29 mmap
     40 open
   2003 write


Maybe something like the following would work:
* Create a reasonable sized buffer
* Use it to buffer the writes, and if it fits, write the length, the buffer,
the length.
* If the argument is a (too) big array, write the length of data in the buffer
plus array byte size, then the data - and only if another item comes, seek to
the beginning and update the length.

That should take care of:
  write(99) i, j, k
  write(99) i, j, k, small_array
  write(99) big_array
and even
  write(99) i, j, k, big_array
but it will not help for
  write(99) big_array1, big_array2

I think that covers the most important cases. One question is how large the
buffer should be initially, whether it should be resizable - and how long it
should remain allocated. Even a small buffer of 1024 kbyte (= 128 real(8)
values) will help when writing small data like in the example of comment 0.

If it is larger, the issue of freeing the data and/or resizing becomes more
important - and one needs to be careful not to require huge amount of memory
and/or do do very frequent memory allocation+freeing, which causes the problems
with g95.

 * * *

Closer look at NAG: It does the following (allocate moved before open, inquire
removed):

open("/dev/null", O_RDWR)               = 3
mmap(NULL, 3856, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 0x2aaaaab0e000
mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 0x2aaaaab22000
fstat(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
0x7fff645b1c90) = -1 ENOTTY (Inappropriate ioctl for device)
fstat(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
0x7fff645b2200) = -1 ENOTTY (Inappropriate ioctl for device)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 0x2aaaaac22000
lseek(3, 0, SEEK_CUR)                   = 0

write(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
4096) = 4096
write(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
419426304) = 419426304

(and 999 further write lines)

lseek(3, 0, SEEK_SET)                   = 0
read(3, "", 4096)                       = 0
lseek(3, 12, SEEK_CUR)                  = 0
write(3, "\0\0\0\250", 4)               = 4
lseek(3, 18446744072233156608, SEEK_SET) = 0
read(3, "", 4096)                       = 0
lseek(3, 20, SEEK_CUR)                  = 0
lseek(3, 0, SEEK_CUR)                   = 0
ftruncate(3, 0)                         = -1 EINVAL (Invalid argument)
close(3)                                = 0
munmap(0x2aaaaac22000, 4096)            = 0
munmap(0x2aaaab7a3000, 419430400)       = 0


^ permalink raw reply	[flat|nested] 12+ messages in thread
* [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)
       [not found] <bug-36296-4@http.gcc.gnu.org/bugzilla/>
                   ` (3 preceding siblings ...)
  2013-04-17  9:37 ` manu at gcc dot gnu.org
@ 2013-04-17 11:17 ` vincent-gcc at vinc17 dot net
  2013-04-17 12:25 ` vincent-gcc at vinc17 dot net
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 12+ messages in thread
From: vincent-gcc at vinc17 dot net @ 2013-04-17 11:17 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296

--- Comment #20 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> 2013-04-17 11:17:14 UTC ---
(In reply to comment #18)
> In fact, we should have removed the i=i idiom a long time ago. The correct
> thing to do (as Linus says) is to initialize the variable to a sensible value
> to silence the warning: http://lwn.net/Articles/529954/

There is no real sensible value except some trap value. Letting the variable
uninitialized at that point (the declaration) allows some tools, like the
Formalin compiler described in WG14/N1637, to detect potential problems if the
variable is really used uninitialized.

(In reply to comment #19)
> Note that -Wmaybe-uninitialized is available since at least GCC 4.8.0

OK, so a solution would be to add a configure test for projects that don't want
such warnings (while still using -Wall) to see whether -Wno-maybe-uninitialized
is supported.
>From gcc-bugs-return-420461-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 17 11:26:04 2013
Return-Path: <gcc-bugs-return-420461-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22867 invoked by alias); 17 Apr 2013 11:26:04 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 22832 invoked by uid 48); 17 Apr 2013 11:26:01 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)
Date: Wed, 17 Apr 2013 11:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-36296-4-TYCh4HRdTc@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-36296-4@http.gcc.gnu.org/bugzilla/>
References: <bug-36296-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01606.txt.bz2
Content-length: 861


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296

--- Comment #21 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-04-17 11:26:01 UTC ---
(In reply to comment #20)
> OK, so a solution would be to add a configure test for projects that don't want
> such warnings (while still using -Wall) to see whether -Wno-maybe-uninitialized
> is supported.

When an unrecognized warning option is requested (e.g., -Wunknown-warning), GCC
will emit a diagnostic stating that the option is not recognized.  However, if
the -Wno- form is used, the behavior is slightly different: No diagnostic will
be
produced for -Wno-unknown-warning unless other diagnostics are being produced. 
This allows the use of new -Wno- options with old compilers, but if something
goes wrong, the compiler will warn that an unrecognized option was used.
>From gcc-bugs-return-420462-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 17 11:31:33 2013
Return-Path: <gcc-bugs-return-420462-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25982 invoked by alias); 17 Apr 2013 11:31:32 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 25943 invoked by uid 48); 17 Apr 2013 11:31:30 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)
Date: Wed, 17 Apr 2013 11:31:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-36296-4-7NV6JZXQFe@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-36296-4@http.gcc.gnu.org/bugzilla/>
References: <bug-36296-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01607.txt.bz2
Content-length: 1107


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296

--- Comment #22 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-04-17 11:31:29 UTC ---
(In reply to comment #20)
> (In reply to comment #18)
> > In fact, we should have removed the i=i idiom a long time ago. The correct
> > thing to do (as Linus says) is to initialize the variable to a sensible value
> > to silence the warning: http://lwn.net/Articles/529954/
> 
> There is no real sensible value except some trap value. Letting the variable
> uninitialized at that point (the declaration) allows some tools, like the
> Formalin compiler described in WG14/N1637, to detect potential problems if the
> variable is really used uninitialized.

That doesn't contradict my assessment above that i=i idiom should die. With the
Pragma one can choose to ignore GCC warnings if they don't want to initialize
the value.

The trap value would be an additional improvement, but someone needs to
implement it. Clang has fsanitize=undefined-trap:

http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation
>From gcc-bugs-return-420463-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 17 11:41:24 2013
Return-Path: <gcc-bugs-return-420463-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30907 invoked by alias); 17 Apr 2013 11:41:24 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 30628 invoked by uid 48); 17 Apr 2013 11:41:21 -0000
From: "janus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/56814] [4.8/4.9 Regression] Bogus Interface mismatch in dummy procedure
Date: Wed, 17 Apr 2013 11:41:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: janus at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: janus at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.1
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56814-4-2UWiT3c1Em@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56814-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56814-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01608.txt.bz2
Content-length: 250


http://gcc.gnu.org/bugzilla/show_bug.cgi?idV814

--- Comment #6 from janus at gcc dot gnu.org 2013-04-17 11:41:21 UTC ---
(In reply to comment #5)
> Alternative patch:

In contrast to the patch in comment #3, this one regtests cleanly ...


^ permalink raw reply	[flat|nested] 12+ messages in thread
* [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)
       [not found] <bug-36296-4@http.gcc.gnu.org/bugzilla/>
                   ` (4 preceding siblings ...)
  2013-04-17 11:17 ` vincent-gcc at vinc17 dot net
@ 2013-04-17 12:25 ` vincent-gcc at vinc17 dot net
  2013-11-20  0:55 ` law at redhat dot com
  2014-02-16 13:13 ` jackie.rosen at hushmail dot com
  7 siblings, 0 replies; 12+ messages in thread
From: vincent-gcc at vinc17 dot net @ 2013-04-17 12:25 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296

--- Comment #23 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> 2013-04-17 12:24:56 UTC ---
(In reply to comment #21)
> When an unrecognized warning option is requested (e.g., -Wunknown-warning), GCC
> will emit a diagnostic stating that the option is not recognized.  However, if
> the -Wno- form is used, the behavior is slightly different: No diagnostic will
> be
> produced for -Wno-unknown-warning unless other diagnostics are being produced. 

That was mainly for pre-4.7 GCC versions, where without the i=i idiom, one
would get the usual "may be used uninitialized in this function" warning
because -Wno-maybe-uninitialized is not supported, but also the

  unrecognized command line option "-Wno-maybe-uninitialized"

warning because there was already a warning. However this may not really be
important.
>From gcc-bugs-return-420466-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 17 12:34:43 2013
Return-Path: <gcc-bugs-return-420466-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27488 invoked by alias); 17 Apr 2013 12:34:43 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 27443 invoked by uid 48); 17 Apr 2013 12:34:40 -0000
From: "vincent-gcc at vinc17 dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)
Date: Wed, 17 Apr 2013 12:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vincent-gcc at vinc17 dot net
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-36296-4-2lzCZRpGfn@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-36296-4@http.gcc.gnu.org/bugzilla/>
References: <bug-36296-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01611.txt.bz2
Content-length: 351


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296

--- Comment #24 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> 2013-04-17 12:34:40 UTC ---
BTW, since with the latest GCC versions (such as Debian's GCC 4.7.2), the
warning is no longer issued with -Wno-maybe-uninitialized, perhaps the bug
severity could be lowered to "enhancement".
>From gcc-bugs-return-420467-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 17 13:04:46 2013
Return-Path: <gcc-bugs-return-420467-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12043 invoked by alias); 17 Apr 2013 13:04:46 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 12002 invoked by uid 48); 17 Apr 2013 13:04:43 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug web/45688] Typo in __attribute__((version-id)) docs
Date: Wed, 17 Apr 2013 13:04:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: web
X-Bugzilla-Keywords: documentation
X-Bugzilla-Severity: trivial
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: Status CC Resolution
Message-ID: <bug-45688-4-OUD4ncxslu@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-45688-4@http.gcc.gnu.org/bugzilla/>
References: <bug-45688-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01612.txt.bz2
Content-length: 573


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45688

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |manu at gcc dot gnu.org
         Resolution|                            |FIXED

--- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-04-17 13:04:42 UTC ---
So FIXED. Thanks!
>From gcc-bugs-return-420468-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 17 13:27:29 2013
Return-Path: <gcc-bugs-return-420468-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10225 invoked by alias); 17 Apr 2013 13:27:29 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 10195 invoked by uid 48); 17 Apr 2013 13:27:25 -0000
From: "dje at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/56948] PPC V2DI ICE when loading zero into GPRs
Date: Wed, 17 Apr 2013 13:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dje at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: dje at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.1
X-Bugzilla-Changed-Fields: Status Resolution
Message-ID: <bug-56948-4-t7KElzMVCK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56948-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56948-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01613.txt.bz2
Content-length: 491


http://gcc.gnu.org/bugzilla/show_bug.cgi?idV948

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from David Edelsohn <dje at gcc dot gnu.org> 2013-04-17 13:27:24 UTC ---
Patch applied to trunk and GCC 4.8 branch.


^ permalink raw reply	[flat|nested] 12+ messages in thread
* [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)
       [not found] <bug-36296-4@http.gcc.gnu.org/bugzilla/>
                   ` (5 preceding siblings ...)
  2013-04-17 12:25 ` vincent-gcc at vinc17 dot net
@ 2013-11-20  0:55 ` law at redhat dot com
  2014-02-16 13:13 ` jackie.rosen at hushmail dot com
  7 siblings, 0 replies; 12+ messages in thread
From: law at redhat dot com @ 2013-11-20  0:55 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |law at redhat dot com
         Resolution|---                         |WORKSFORME

--- Comment #25 from Jeffrey A. Law <law at redhat dot com> ---
All tests included in this BZ were tested and work fine on the trunk.


^ permalink raw reply	[flat|nested] 12+ messages in thread
* [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)
       [not found] <bug-36296-4@http.gcc.gnu.org/bugzilla/>
                   ` (6 preceding siblings ...)
  2013-11-20  0:55 ` law at redhat dot com
@ 2014-02-16 13:13 ` jackie.rosen at hushmail dot com
  7 siblings, 0 replies; 12+ messages in thread
From: jackie.rosen at hushmail dot com @ 2014-02-16 13:13 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #26 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.


^ permalink raw reply	[flat|nested] 12+ messages in thread
* [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)
  2008-05-22  7:28 [Bug c/36296] New: wrong warning about potential uninitialized variable zimmerma+gcc at loria dot fr
                   ` (2 preceding siblings ...)
  2009-02-02 23:44 ` av1474 at comtv dot ru
@ 2009-02-03  0:28 ` manu at gcc dot gnu dot org
  3 siblings, 0 replies; 12+ messages in thread
From: manu at gcc dot gnu dot org @ 2009-02-03  0:28 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #15 from manu at gcc dot gnu dot org  2009-02-03 00:27 -------
(In reply to comment #14)
> I'm not sure whether following warrants a new bug entry so doing it here,
> sorry,
> if it was inappropriate.

That is a different case. This PR is about loops. Your case is about 
initialization and use guarded by the same predicate. I think there is already
a bug report for this. But it is always better to open a new bug report in case
of doubt.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296


^ permalink raw reply	[flat|nested] 12+ messages in thread
* [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)
  2008-05-22  7:28 [Bug c/36296] New: wrong warning about potential uninitialized variable zimmerma+gcc at loria dot fr
  2008-08-19  2:34 ` [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization) manu at gcc dot gnu dot org
  2008-12-25  3:03 ` pinskia at gcc dot gnu dot org
@ 2009-02-02 23:44 ` av1474 at comtv dot ru
  2009-02-03  0:28 ` manu at gcc dot gnu dot org
  3 siblings, 0 replies; 12+ messages in thread
From: av1474 at comtv dot ru @ 2009-02-02 23:44 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #14 from av1474 at comtv dot ru  2009-02-02 23:44 -------
(In reply to comment #8)
> Please provide a preprocessed reduced testcase as similar to the original as
> possible. 
> 
> I think this is not only predicated PHI but our representation of loops may
> also have something to do.
> 

I'm not sure whether following warrants a new bug entry so doing it here,
sorry,
if it was inappropriate.

Following code, triggers:
 "repro.c:5: warning: 'b' may be used uninitialized in this function"
with 4.3.0 and 4.3.1 on PowerPC when invoked like this:

gcc -c -O -Wuninitialized repro.c

int f (void);

int g (int a)
{
    int b;

    if (a) b = f ();
    asm volatile ("#");
    if (a) return b;
    return 1;
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296


^ permalink raw reply	[flat|nested] 12+ messages in thread
* [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)
  2008-05-22  7:28 [Bug c/36296] New: wrong warning about potential uninitialized variable zimmerma+gcc at loria dot fr
  2008-08-19  2:34 ` [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization) manu at gcc dot gnu dot org
@ 2008-12-25  3:03 ` pinskia at gcc dot gnu dot org
  2009-02-02 23:44 ` av1474 at comtv dot ru
  2009-02-03  0:28 ` manu at gcc dot gnu dot org
  3 siblings, 0 replies; 12+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-12-25  3:03 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #13 from pinskia at gcc dot gnu dot org  2008-12-25 03:00 -------
*** Bug 37361 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |benoit dot hudson at gmail
                   |                            |dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296


^ permalink raw reply	[flat|nested] 12+ messages in thread
* [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)
  2008-05-22  7:28 [Bug c/36296] New: wrong warning about potential uninitialized variable zimmerma+gcc at loria dot fr
@ 2008-08-19  2:34 ` manu at gcc dot gnu dot org
  2008-12-25  3:03 ` pinskia at gcc dot gnu dot org
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 12+ messages in thread
From: manu at gcc dot gnu dot org @ 2008-08-19  2:34 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #12 from manu at gcc dot gnu dot org  2008-08-19 02:33 -------
The key difference is -ftree-vrp (which is enabled at -O2). With INIT=2, it is
missing the obvious optimization that it detects with INIT=1. I wonder if this
is expected (after all, it is value-RANGE-propagation) or there is a PR open
about this.

Notice that any two consecutive integers trigger the optimization 0,1 but also
1,2 and thus remove the bogus uninitialized warning.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|bogus uninitialized warning |bogus uninitialized warning
                   |(loop representation)       |(loop representation, VRP
                   |                            |missed-optimization)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296


^ permalink raw reply	[flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-02-16 13:13 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-36296-4@http.gcc.gnu.org/bugzilla/>
2013-04-17  8:40 ` [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization) vincent-gcc at vinc17 dot net
2013-04-17  9:19 ` manu at gcc dot gnu.org
2013-04-17  9:32 ` manu at gcc dot gnu.org
2013-04-17  9:37 ` manu at gcc dot gnu.org
2013-04-17 11:17 ` vincent-gcc at vinc17 dot net
2013-04-17 12:25 ` vincent-gcc at vinc17 dot net
2013-11-20  0:55 ` law at redhat dot com
2014-02-16 13:13 ` jackie.rosen at hushmail dot com
2008-05-22  7:28 [Bug c/36296] New: wrong warning about potential uninitialized variable zimmerma+gcc at loria dot fr
2008-08-19  2:34 ` [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization) manu at gcc dot gnu dot org
2008-12-25  3:03 ` pinskia at gcc dot gnu dot org
2009-02-02 23:44 ` av1474 at comtv dot ru
2009-02-03  0:28 ` manu at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).