-gnu
Configured with: ../configure --prefix=/home/regehr/z/tmp/gcc-r149650-install
--program-prefix=r149650- --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20090714 (experimental) (GCC)
reg...@john-home:~/volatile/tmp174$ cat small.c
#include
#include
#include
uint8_t g_4;
int64_t
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-07-15 06:27
---
Thanks for the report, but we need a preprocessed testcase, see instructions at
http://gcc.gnu.org/bugs.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Add
#define ONE while (b())
#define TEN ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE
#define HUN TEN TEN TEN TEN TEN TEN TEN TEN TEN TEN
#define THOUHUN HUN HUN HUN HUN HUN HUN HUN HUN HUN
void foo()
{
/* 11,000 nested whiles. */
THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU
--- Comment #28 from burnus at gcc dot gnu dot org 2009-07-15 06:08 ---
> In a quick scan of the patch, I note that the mpfr versions
> of the simplifications weren't in the patch.
MPFR or MPC? The MPFR version should be there since years; the MPC version of
tan/sinh/cosh/tanh should be
--- Comment #1 from bonzini at gnu dot org 2009-07-15 06:06 ---
A regression from when, well, there was no gimplifier.
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #32 from bonzini at gnu dot org 2009-07-15 06:05 ---
Yes, but I don't think it's infinite recursion. There are 11,000 else ifs in
the testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
The testcase from PR/2161:
#define ONE else if (0) { }
#define TEN ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE
#define HUN TEN TEN TEN TEN TEN TEN TEN TEN TEN TEN
#define THOUHUN HUN HUN HUN HUN HUN HUN HUN HUN HUN
void foo()
{
if (0) { }
/* 11,000 else if's. */
THOU THOU THOU
.
reg...@john-home:~/volatile/tmp173$ current-gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/regehr/z/tmp/gcc-r149650-install
--program-prefix=r149650- --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20090714 (experimental) (GCC)
reg..
--- Comment #6 from bje at gcc dot gnu dot org 2009-07-15 03:29 ---
Using --with-libelf should work (I just checked it on several systems). Please
re-open this report if your problems persist.
--
bje at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #27 from kargl at gcc dot gnu dot org 2009-07-15 02:36 ---
(In reply to comment #26)
> Patch: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00739.html
> - MPC compile-time evaluation of complex tan and sinh/cosh/tanh
> - Run-time complex a(sin,cos,tan)(h) with C99 fallback (fo
--- Comment #1 from rmansfield at qnx dot com 2009-07-15 02:30 ---
Created an attachment (id=18197)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18197&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40758
: posix
gcc version 4.5.0 20090714 (experimental) [lto revision 149644] (lto merged
with rev 149625)
r...@ryan:~/gcc/lto/x86-build/gcc$ ./xgcc -B. ice.i -c -O -flto
r...@ryan:~/gcc/lto/x86-build/gcc$ ./xgcc -B. -shared ice.o -flto
In file included from :441:0:
ice.i: In function âffb_ctx_scaled_blitâ
--- Comment #1 from zimmerma+gcc at loria dot fr 2009-07-15 02:02 ---
Note this bug was noticed on a Sun T5240, and might be specific to T2+.
David Kirkby offers access to the machine for gcc developers who might want
to reproduce/isolate/fix the bug.
--
http://gcc.gnu.org/bugzilla/
--- Comment #2 from bje at gcc dot gnu dot org 2009-07-15 02:01 ---
Fixed in r149434.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from bje at gcc dot gnu dot org 2009-07-15 00:55 ---
*** Bug 39020 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39021
--- Comment #2 from bje at gcc dot gnu dot org 2009-07-15 00:55 ---
*** This bug has been marked as a duplicate of 39021 ***
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from bje at gcc dot gnu dot org 2009-07-15 00:51 ---
*** Bug 39097 has been marked as a duplicate of this bug. ***
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from bje at gcc dot gnu dot org 2009-07-15 00:51 ---
*** This bug has been marked as a duplicate of 39316 ***
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from bje at gcc dot gnu dot org 2009-07-15 00:49 ---
Fixed by this patch:
2009-07-09 Rainer Orth
* lto.c (free_section_data): Cast computed_offset to caddr_t.
I felt this was not the right fix, but I won't argue.
--
bje at gcc dot gnu dot org changed:
--- Comment #6 from bje at gcc dot gnu dot org 2009-07-15 00:37 ---
Fixed in r149434.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
See http://websympa.loria.fr/wwsympa/arc/mpfr/2009-07/msg00031.html
and the following discussion.
This was on t2.math.washington.edu with
/usr/local/gcc-4.4.0-sun-linker/bin/gcc:
zimme...@t2:/tmp/mpfr-2.4.1$ /usr/local/gcc-4.4.0-sun-linker/bin/gcc -v
Using built-in specs.
Target: sparc-sun-solaris
--- Comment #2 from bje at gcc dot gnu dot org 2009-07-15 00:20 ---
Subject: Bug 40725
Author: bje
Date: Wed Jul 15 00:20:11 2009
New Revision: 149654
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149654
Log:
PR lto/40725
* gfortran.dg/lto/pr40725_0.f03: New.
--- Comment #5 from rmansfield at qnx dot com 2009-07-14 23:47 ---
Works with rev 149644. Thanks.
--
rmansfield at qnx dot com changed:
What|Removed |Added
St
--- Comment #7 from mikpe at it dot uu dot se 2009-07-14 23:33 ---
(In reply to comment #6)
> Hmm, maybe scheduling is causing it. Does -fno-schedule-insns
> -fno-schedule-insns2 cause the memory usage to go down?
Nope, memory usage patterns stayed the same.
--
http://gcc.gnu.org/b
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00822.html
I was wrong when I thought TREE_BLOCKs were only attached to
DECL_INITIAL for current_function_decl. They are also reachable
from EXPRs embedded in some types emitted by Fortran.
These are pretty useless, so perhaps it'd be a good idea to c
Cloned functions appear not to be properly instrumented by mudflap e.g alloca
is not instrumented.
This is responsible for the recent regressions in libmudflap testsuite.
(pass45-frag.c,fail31-frag.c)
--
Summary: [4.5 Regression] Mudflap instrumentation missing in
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-07-14 23:10 ---
Hmm, maybe scheduling is causing it. Does -fno-schedule-insns
-fno-schedule-insns2 cause the memory usage to go down?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40735
--- Comment #5 from mikpe at it dot uu dot se 2009-07-14 23:07 ---
Seems heavily target-dependent. With 4.3.4 I see peak usage of 640M for i686,
just under 1.2G for powerpc, and 1.6G for arm.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40735
--- Comment #5 from bonzini at gnu dot org 2009-07-14 22:42 ---
I have a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40741
--- Comment #1 from bonzini at gnu dot org 2009-07-14 22:42 ---
I have a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39726
--- Comment #4 from bonzini at gnu dot org 2009-07-14 22:41 ---
I have a patch for both (two patches actually).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39715
--- Comment #3 from bonzini at gnu dot org 2009-07-14 22:38 ---
Fixed by the new SRA thanks to its usage of VIEW_CONVERT_EXPR at the tree
level.
--
bonzini at gnu dot org changed:
What|Removed |Added
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|000
--- Comment #2 from bryce dot schober at gmail dot com 2009-07-14 22:31
---
I now see that the following syntax packs as expected:
typedef enum {
ZERO = 0,
ONE,
TWO
} __attribute__ ((packed)) my_enum_t;
I have been unable to find a concise definition of how attr
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org
|dot org |
--- Comment #5 from manu at gcc dot gnu dot org 2009-07-14 22:30 ---
Then, let's keep this around as an enhancement request.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from ian at airs dot com 2009-07-14 22:23 ---
Manu, I agree that these warnings are in some sense technically correct but
they are not useful. They can't point to any actual bug. I guess would be
that if every input to the expression has the size of the target of the
exp
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-14 21:58 ---
Huh, we end up with a FUNCTION_DECL here, from
(gdb) call debug_rtx (mem)
(mem/c/i:SI (const:SI (plus:SI (symbol_ref:SI ("ffi_closure_LINUX64") [flags
0x41] )
(const_int 12 [0xc]))) [0 ffi_closure_LINUX6
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-14 21:46 ---
Obviously mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #4 from dnovillo at gcc dot gnu dot org 2009-07-14 21:41
---
This is likely fixed by
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00819.html,
could you try again?
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from bonzini at gnu dot org 2009-07-14 21:34 ---
I cannot reproduce this anymore.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from bonzini at gnu dot org 2009-07-14 21:32 ---
Cannot reproduce this anymore.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|U
--- Comment #2 from rguenther at suse dot de 2009-07-14 21:28 ---
Subject: Re: SRA scalarizes dead objects,
single-use objects
On Tue, 14 Jul 2009, jamborm at gcc dot gnu dot org wrote:
> --- Comment #1 from jamborm at gcc dot gnu dot org 2009-07-14 16:32
> ---
> OK, I have
--- Comment #1 from bonzini at gnu dot org 2009-07-14 21:25 ---
(This is peak-gcc-src/gcc/testsuite/gcc.c-torture/compile/pr38564.c).
I cannot reproduce this anymore.
--
bonzini at gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from bonzini at gnu dot org 2009-07-14 21:17 ---
(This is gcc.c-torture/compile/20071128-1.c).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39722
--- Comment #22 from pthaugen at gcc dot gnu dot org 2009-07-14 21:15
---
The original problem, multi-block loop preventing movement of loads, was
reintroduced with revision 149206, Jan's CD-DCE patch to remove empty loops.
--
pthaugen at gcc dot gnu dot org changed:
Wha
--- Comment #3 from manu at gcc dot gnu dot org 2009-07-14 20:56 ---
Joseph, could you comment on this?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2009-07-14 20:55 ---
Andrew, what you say is true, but in this case the warning is not very useful.
I'd prefer to warn only when the operator is larger than the target of the
assignment. I would like to hear other opinions.
--
manu at g
Running the testsuite on sparc-sun-solaris2.11 with the lto branch as of
20090709
reveals many testsuite errors like this:
Executing on host:
/vol/gccsrc/obj/gcc-lto-20090709/11-gcc/gcc/testsuite/g++/../../g++
-B/vol/gccsrc/obj/gcc-lto-20090709/11-gcc/gcc/testsuite/g++/../../
cp_lto_20080709_0.o
--- Comment #1 from bonzini at gnu dot org 2009-07-14 20:36 ---
I meant that on most targets this testcase was improved by cond-optab, but not
on m68hc11.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39719
--- Comment #1 from bonzini at gnu dot org 2009-07-14 20:35 ---
This fails for me with r149508 with a reload failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39716
--- Comment #15 from mikpe at it dot uu dot se 2009-07-14 19:51 ---
(In reply to comment #14)
> Bah. So this then becomes "it would be interesting to know what fixed this on
> the gimple-tuples-branch" ...
Revision 134191 fixed this on gimple-tuples-branch.
--
http://gcc.gnu.org/b
Compiling libffi/src/powerpc/ffi.c as part of a bootstrap for powerpc*-*-linux*
fails starting with this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=149624
r149624 | rguenth | 2009-07-14 09:59:18 + (Tue, 14 Jul 2009)
This minimized testcase demonstrates the problem:
-
--- Comment #7 from phorgan1 at gmail dot com 2009-07-14 19:37 ---
Verified that original test case now compiles with -g flag--Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40705
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-14 19:21 ---
Theses are not false warnings:
c >>= 1;
is really c = (int)c >> 1;
c += (char) 1;
c = (int)c + (int)(char)1;
c += c2;
c = (int)c + (int) c2;
c = ~c2;
c = ~(int)c2;
Only the l
--- Comment #6 from tkoenig at gcc dot gnu dot org 2009-07-14 19:18 ---
See also PR 30694.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40643
-Wconversion generates false warnings for the following clean code:
{
char c = 1;
char c2 = 2;
// warning: conversion to char from int may alter its value
c >>= 1;
c += (char) 1;
c += c2;
c = ~c2;
}
--
Summary: -Wconversion
--- Comment #1 from bryce dot schober at gmail dot com 2009-07-14 19:09
---
Created an attachment (id=18196)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18196&action=view)
test case
Built without warnings, to try to make sure I'm not doing something marginal:
gcc -Wall -Wextra
The following enumerated type definitions packs to one byte as expected in C,
but not in C++:
typedef enum __attribute__ ((packed)) {
ZERO = 0,
ONE,
TWO
} my_enum_t;
The enum will pack as expected if using -fshort-enums, but that doesn't allow
me to pack on a per-enum basi
--- Comment #3 from jason at gcc dot gnu dot org 2009-07-14 18:50 ---
Yeah, that's a known issue; it's XFAILed in one of the auto tests.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #13 from jason at gcc dot gnu dot org 2009-07-14 18:44 ---
Fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from jason at gcc dot gnu dot org 2009-07-14 18:43 ---
Fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #3 from jason at gcc dot gnu dot org 2009-07-14 18:41 ---
Fixed for 4.4.1.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNC
--- Comment #2 from jason at gcc dot gnu dot org 2009-07-14 18:35 ---
Subject: Bug 40740
Author: jason
Date: Tue Jul 14 18:35:13 2009
New Revision: 149640
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149640
Log:
PR c++/40740
* semantics.c (perform_koenig_lookup
--- Comment #12 from jason at gcc dot gnu dot org 2009-07-14 18:16 ---
Subject: Bug 37276
Author: jason
Date: Tue Jul 14 18:16:03 2009
New Revision: 149638
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149638
Log:
PR c++/37276
* decl.c (decls_match): A non-exter
--- Comment #1 from jason at gcc dot gnu dot org 2009-07-14 18:15 ---
Subject: Bug 40740
Author: jason
Date: Tue Jul 14 18:15:35 2009
New Revision: 149636
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149636
Log:
PR c++/40740
* semantics.c (perform_koenig_lookup
GCC mis-compiles the following code for mysterious reasons. While it should
output "called", it outputs nothing at all
// snip
typedef void Fn() const;
struct Foo { Fn fn; };
void Foo::fn() const { std::cout << "called" << std::endl; }
int main() { Foo f; f.fn(); }
// snap
Any one of the fol
--- Comment #10 from photon at seznam dot cz 2009-07-14 18:11 ---
(In reply to comment #9)
>
> So your definition of -Wall is not very useful at all and will be even more
> misleading to users or why the warnings are happening.
>
MSC's /Wall enables all warnings and I don't find it mi
--- Comment #4 from jakub at gcc dot gnu dot org 2009-07-14 18:00 ---
Indeed, caused by http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01303.html
(r134384).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2009-07-14
17:26 ---
Subject: Re: lto-plugin is built unconditionally
> --- Comment #4 from bje at gcc dot gnu dot org 2009-07-14 04:39 ---
> Can this PR be closed now, Rainer?
Yes, this works now.
Rainer
--- Comment #3 from jakub at gcc dot gnu dot org 2009-07-14 17:25 ---
Confirmed, introduced between r134374 + r134467, looking into it.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from zsojka at seznam dot cz 2009-07-14 17:11 ---
Created an attachment (id=18195)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18195&action=view)
testcase
Even at -O3, f1() and f2() don't have the same code as f3().
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #2 from sezeroz at gmail dot com 2009-07-14 17:16 ---
Also happens with i686-pc-linux-gnu with gcc-4.4.1 (gcc-4_4-branch, r149543).
--
sezeroz at gmail dot com changed:
What|Removed |Added
---
This code below wont generate a warning for function a(). Compiled with -Wall.
If you remove the const from the return, it will work.
class A {
public:
};
const A a() {
}
int main() {
A b = a();
}
--
Summary: g++ doesnt report missing return if return is of type
Tested r149624, 4.4.0 and 4.3.3
# ./gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++
--prefix=/mnt/svn/gcc-trunk/build/
Thread model: posix
gcc version 4.5.0 20090714 (experimental) (GCC)
4.4.0 and 4.5 have better behaviour in
--- Comment #7 from janus at gcc dot gnu dot org 2009-07-14 16:53 ---
Here is a much better patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 149623)
+++ gcc/fortran/resolve.c (working
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-07-14 16:47 ---
(In reply to comment #8)
> The current -Wall should be
> renamed to something like -W3 to prevent misleading users.
It only misleading users who don't read the documentation. The all part is
described in the docu
--- Comment #1 from zsojka at seznam dot cz 2009-07-14 16:35 ---
Created an attachment (id=18194)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18194&action=view)
preprocessed source
most of that file is content of included
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4074
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-07-14 16:32 ---
OK, I have now added this to my todo list. The simple tweaks would be
simple. On the other hand, if DCE is clever, it still might figure
out a structure is dead at some code paths while I don't even attempt
to
Tested with:
trunk r149624
# ./gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++
--prefix=/mnt/svn/gcc-trunk/build/
Thread model: posix
gcc version 4.5.0 20090714 (experimental) (GCC)
and gentoo's 4.4.0, 4.5_alpha20090709
--- Comment #8 from photon at seznam dot cz 2009-07-14 15:31 ---
(In reply to comment #6)
>
> As for Wall, we have users requesting less warnings from Wall and users
> requesting more. We try to find a balance. But you are free to suggest that
> existing warnings be moved to Wall or Wex
--- Comment #4 from dodji at gcc dot gnu dot org 2009-07-14 15:29 ---
Fixed by the patch for PR debug/40705
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dodji at gcc dot gnu dot org 2009-07-14 15:19 ---
Fixed in gcc 4.5
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASS
--- Comment #7 from photon at seznam dot cz 2009-07-14 15:13 ---
(In reply to comment #5)
> -Wconversion hits extremely often, it is definitely not a warning that can or
> should be enabled in -Wall, nor in -W.
>
The fact that "it hits often" should not be an argument against including
--- Comment #5 from dodji at gcc dot gnu dot org 2009-07-14 15:02 ---
Subject: Bug 40705
Author: dodji
Date: Tue Jul 14 15:01:55 2009
New Revision: 149628
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149628
Log:
2009-07-14 Dodji Seketeli
gcc/ChangeLog:
PR debug/407
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reco
namespace A
{
int i;// { dg-error "i" }
}
using namespace A;
namespace B
{
namespace B2
{
int i; // { dg-error "i" }
}
using namespace B2;
}
using namespace B;
int j = ::i;// { dg-error "ambiguous" }
The code currently
--- Comment #11 from rearnsha at gcc dot gnu dot org 2009-07-14 14:53
---
The following define_split works for this specific case, but it needs to be
made more generic (handling IOR and HImode variants).
It also needs reworking for big-endian -- that needs (subreg...3).
(define_split
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-14 14:08 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-14 14:08 ---
Subject: Bug 40745
Author: rguenth
Date: Tue Jul 14 14:08:09 2009
New Revision: 149627
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149627
Log:
2009-07-14 Richard Guenther
PR middle-end/40745
--- Comment #6 from manu at gcc dot gnu dot org 2009-07-14 14:04 ---
There is a FAQ for the new Wconversion:
http://gcc.gnu.org/wiki/NewWconversion#faq
It should answer users' concerns.
As for Wall, we have users requesting less warnings from Wall and users
requesting more. We try to
--- Comment #11 from paolo dot carlini at oracle dot com 2009-07-14 14:00
---
Jason, this is the issue, you are in CC. Actually, using declarations are not
directly involved - I was misremembering - are only part of my ugly workaround,
and, beware, I menace to use it... ;)
--
http:
--- Comment #6 from janus at gcc dot gnu dot org 2009-07-14 13:50 ---
The error goes away with the following patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 149623)
+++ gcc/fortran/resolve.
--- Comment #5 from janus at gcc dot gnu dot org 2009-07-14 13:38 ---
Backtrace for the code in comment #4:
#0 resolve_code (code=0x2f26580, ns=0x2f25520) at
/home/jweil/gcc45/trunk/gcc/fortran/resolve.c:7168
#1 0x00512703 in resolve_codes (ns=0x2f25520) at
/home/jweil/gcc45/t
--- Comment #5 from jakub at gcc dot gnu dot org 2009-07-14 13:31 ---
Created an attachment (id=18193)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18193&action=view)
gcc45-pr40643.patch
And now a patch which uses two loops instead of one if needed for performance
(in the honor n
--- Comment #4 from jakub at gcc dot gnu dot org 2009-07-14 13:26 ---
Created an attachment (id=18192)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18192&action=view)
gcc45-pr40643.patch
Slightly adjusted patch, so that even when array size isn't known compile time
constant it ca
--- Comment #4 from janus at gcc dot gnu dot org 2009-07-14 13:20 ---
Here is a minimal test case:
implicit none
type :: varying_string
end type
interface assignment(=)
procedure op_assign_VS_CH
end interface
contains
subroutine op_assign_VS_CH (var, exp)
type(v
Revision 149624:
http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00505.html
caused:
FAIL: gcc.target/x86_64/abi/test_3_element_struct_and_unions.c compilation,
-O0 (internal compiler error)
FAIL: gcc.target/x86_64/abi/test_basic_array_size_and_align.c compilation, -O0
(internal compiler error)
--
--- Comment #3 from bonzini at gnu dot org 2009-07-14 12:56 ---
Richard, is your testcase also a regression? In that case the culprit is
mostly
#if 0
/* Disabled to avoid exponential mutual recursion between nonzero_bits
and num_sign_bit_copies. */
if (num_sign_bi
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-14 12:32 ---
If 4.3.3 worked please add that release in the known-to-work field.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
1 - 100 of 136 matches
Mail list logo
