[Bug c/36296] New: wrong warning about potential uninitialized variable

[Bug c/36296] New: wrong warning about potential uninitialized variable

[zimmerma+gcc at loria dot fr]

When compiling mpfr-2.3.1 with gcc-4.3, one gets the following warning
(among others):
{{{
lngamma.c: In function 'mpfr_lngamma_aux':
lngamma.c:160: warning: 'B' may be used uninitialized in this function
}}}
However, looking at the code shows that this variable cannot be used
uninitialized:
* a variable Bm is initialized to zero
* if Bm=0, B is initialized using an auxiliary function, and Bm is set to 2
  (this code is in a do { ... } while loop, thus is always executed)


-- 
           Summary: wrong warning about potential uninitialized variable
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: zimmerma+gcc at loria dot fr
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-22 08:22 -------
It is most likely the case, that we have to use predicated PHI nodes to detect
that the variable is no unitialized.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[vincent at vinc17 dot org]

------- Comment #2 from vincent at vinc17 dot org  2008-05-22 08:34 -------
The severity should probably be changed to enhancement because gcc behaves as
documented (well, almost).

What can be done IMHO is:
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.
2. Provide an extension so that the user can tell gcc not to emit a warning for
some particular variable. This would sometimes be better than adding a dummy
initialization (which has its own drawbacks).

In the mean time, make the documentation better concerning -Wuninitialized:
change the first sentence "Warn if an automatic variable is used without first
being initialized [...]" to "Warn if an automatic variable *may be* used
without first being initialized" (though the behavior is detailed later).


-- 

vincent at vinc17 dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vincent at vinc17 dot org


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2008-05-22 10:21 -------
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.


-- 


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[vincent at vinc17 dot org]

------- Comment #4 from vincent at vinc17 dot org  2008-05-22 11:01 -------
(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 doesn't seem to be valid C code.

> this will cause no code generation but inhibits the warning.  Other compilers
> may warn about this construct of course.

Or worse, generate non-working code.


-- 


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[vincent at vinc17 dot org]

------- Comment #5 from vincent at vinc17 dot org  2008-05-22 11:23 -------
BTW, the i = i trick, which is guaranteed to be valid and no-op only *after* i
has been initialized doesn't avoid the warning in such a case. I don't know if
this would be a good feature (the main drawback I can see would be to miss
warnings when this is a result of macro expansion). For instance:

#include <assert.h>
int foo (int x)
{
  int y;
  assert (x == 0 || x == 1);
  if (x == 0)
    y = 1;
  else if (x == 1)
    y = 2;
  y = y;  /* to tell the compiler that y has been initialized */
  return y;
}


-- 


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2008-05-28 07:31 -------
(In reply to comment #5)
> BTW, the i = i trick

it only works in the initializer and not as a statement after the fact.

That is: 
#include <assert.h>
int foo (int x)
{
  int y = y;
  assert (x == 0 || x == 1);
  if (x == 0)
    y = 1;
  else if (x == 1)
    y = 2;
  return y;
}

Will work, also with the jump threading, GCC should be able to figure out that
y is always inlined (except when -DNDEBUG is used).

-- Pinski


-- 


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[vincent at vinc17 dot org]

------- Comment #7 from vincent at vinc17 dot org  2008-05-28 08:18 -------
(In reply to comment #6)
> (In reply to comment #5)
> > BTW, the i = i trick
> 
> it only works in the initializer and not as a statement after the fact.

But in such a case, as i is not initialized yet, this may be undefined behavior
with some C implementations.


-- 


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[manu at gcc dot gnu dot org]

------- Comment #8 from manu at gcc dot gnu dot org  2008-08-18 17:24 -------
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.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org
OtherBugsDependingO|                            |24639
              nThis|                            |
             Status|UNCONFIRMED                 |WAITING


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[vincent at vinc17 dot org]

------- Comment #9 from vincent at vinc17 dot org  2008-08-18 22:58 -------
(In reply to comment #8)
> Please provide a preprocessed reduced testcase as similar to the original as
> possible. 

Here's a similar testcase.

$ cat tst.c
void *foo (void);
void bar (void *);

void f (void)
{
  int init = 0;
  void *p;

  while (1)
    {
      if (init == 0)
        {
          p = foo ();
          init = 2;
        }
      bar (p);
    }
}

$ gcc -Wall -O2 tst.c -c
tst.c: In function 'f':
tst.c:7: warning: 'p' may be used uninitialized in this function

This is quite strange: if I replace the value 2 by 1 or if I replace foo() by
0, the warning is no longer displayed.

Note: in the reality (in MPFR), the variable I called init here is the size of
the array (0 when the array hasn't been allocated yet).


-- 


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

[Bug middle-end/36296] bogus uninitialized warning (loop representation)

[manu at gcc dot gnu dot org]

------- Comment #10 from manu at gcc dot gnu dot org  2008-08-18 23:38 -------
(In reply to comment #9)
> (In reply to comment #8)
> > Please provide a preprocessed reduced testcase as similar to the original as
> > possible. 
> 
> Here's a similar testcase.

Thanks.

This is the optimized SSA dump:

f ()
{
  voidD.39 * pD.1952;
  intD.0 initD.1951;

  # BLOCK 2 freq:1
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  # SUCC: 3 [100.0%]  (fallthru,exec)

  # BLOCK 3 freq:10000
  # PRED: 2 [100.0%]  (fallthru,exec) 5 [100.0%]  (fallthru,dfs_back,exec)
  # initD.1951_1 = PHI <0(2), initD.1951_2(5)>
  # pD.1952_3 = PHI <pD.1952_6(D)(2), pD.1952_4(5)>
  [/home/manuel/src/pr36296.c : 11] if (initD.1951_1 == 0)
    goto <bb 4>;
  else
    goto <bb 5>;
  # SUCC: 4 [29.0%]  (true,exec) 5 [71.0%]  (false,exec)

  # BLOCK 4 freq:2900
  # PRED: 3 [29.0%]  (true,exec)
  [/home/manuel/src/pr36296.c : 13] # SMT.10D.1967_13 = VDEF <SMT.10D.1967_10>
{ SMT.10D.1967 }
  pD.1952_7 = fooD.1945 ();
  # SUCC: 5 [100.0%]  (fallthru,exec)

  # BLOCK 5 freq:10000
  # PRED: 3 [71.0%]  (false,exec) 4 [100.0%]  (fallthru,exec)
  # initD.1951_2 = PHI <initD.1951_1(3), 2(4)>
  # pD.1952_4 = PHI <pD.1952_3(3), pD.1952_7(4)>
  [/home/manuel/src/pr36296.c : 16] # SMT.10D.1967_14 = VDEF <SMT.10D.1967_11>
{ SMT.10D.1967 }
  barD.1947 (pD.1952_4);
  [/home/manuel/src/pr36296.c : 17] goto <bb 3>;
  # SUCC: 3 [100.0%]  (fallthru,dfs_back,exec)

}

Because we create a PHI node for p in BB 3, we think that p can be used
uninitialized. Notice also that we are not able to move the 'if' and the call
to foo() out of the infinite loop. This is perhaps a missed optimization.


> This is quite strange: if I replace the value 2 by 1 or if I replace foo() by
> 0, the warning is no longer displayed.

If you replace foo() by 0, then CCP just assumes the p is always 0. In fact, it
will remove p altogether, even if you use 'if (init == 2)', thus missing a real
uninitialized use. This behaviour is known to hide warnings, both correct and
wrong warnings.

If I replace the value 2 by 1 I still get the warning in GCC 4.4, so that
really sounds strange. Are you sure about that?

Anyway, this is a confirmed bug but not easy to fix.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-08-18 23:38:16
               date|                            |
            Summary|wrong warning about         |bogus uninitialized warning
                   |potential uninitialized     |(loop representation)
                   |variable                    |


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

[Bug middle-end/36296] bogus uninitialized warning (loop representation)

[vincent at vinc17 dot org]

------- Comment #11 from vincent at vinc17 dot org  2008-08-19 01:31 -------
(In reply to comment #10)
> If I replace the value 2 by 1 I still get the warning in GCC 4.4, so that
> really sounds strange. Are you sure about that?

Yes and here Debian's GCC 4.4 snapshot has the same behavior as GCC 4.3.1 (also
from Debian). Also, the optimized trees are not the same for 1 and 2.

vin% cat tst.c
void *foo (void);
void bar (void *);

void f (void)
{
  int init = 0;
  void *p;

  while (1)
    {
      if (init == 0)
        {
          p = foo ();
          init = INIT;
        }
      bar (p);
    }
}
vin% gcc --version
gcc.real (Debian 4.3.1-9) 4.3.1
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

vin% gcc -Wall -O2 tst.c -c -fdump-tree-optimized -DINIT=1
vin% cat tst.c.126t.optimized

;; Function f (f)

Analyzing Edge Insertions.
f ()
{
  void * p;

<bb 2>:
  p = foo ();

<bb 3>:
  bar (p);
  goto <bb 3>;

}


vin% gcc -Wall -O2 tst.c -c -fdump-tree-optimized -DINIT=2
tst.c: In function 'f':
tst.c:7: warning: 'p' may be used uninitialized in this function
vin% cat tst.c.126t.optimized

;; Function f (f)

Analyzing Edge Insertions.
f ()
{
  void * p;
  int init;

<bb 2>:
  init = 0;

<bb 3>:
  if (init == 0)
    goto <bb 4>;
  else
    goto <bb 5>;

<bb 4>:
  p = foo ();
  init = 2;

<bb 5>:
  bar (p);
  goto <bb 3>;

}


vin% /usr/lib/gcc-snapshot/bin/gcc --version
gcc (Debian 20080802-1) 4.4.0 20080802 (experimental) [trunk revision 138551]
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

vin% /usr/lib/gcc-snapshot/bin/gcc -Wall -O2 tst.c -c -DINIT=1
vin% /usr/lib/gcc-snapshot/bin/gcc -Wall -O2 tst.c -c -DINIT=2
tst.c: In function 'f':
tst.c:7: warning: 'p' may be used uninitialized in this function
vin% 


-- 


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

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[manu at gcc dot gnu dot org]

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

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[pinskia at gcc dot gnu dot org]

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

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[av1474 at comtv dot ru]

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

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[manu at gcc dot gnu dot org]

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

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[vincent-gcc at vinc17 dot net]

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.

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[manu at gcc dot gnu.org]

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).

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[manu at gcc dot gnu.org]

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

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[manu at gcc dot gnu.org]

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

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[vincent-gcc at vinc17 dot net]

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 ...

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[vincent-gcc at vinc17 dot net]

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.

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[law at redhat dot com]

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.

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[jackie.rosen at hushmail dot com]

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.