* [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