--- Comment #5 from jason at gcc dot gnu dot org 2009-07-13 06:06 ---
Subject: Bug 36628
Author: jason
Date: Mon Jul 13 06:06:27 2009
New Revision: 149543
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149543
Log:
PR c++/36628
* tree.c (rvalue): Use
--- Comment #1 from jason at gcc dot gnu dot org 2009-07-13 06:06 ---
Subject: Bug 37206
Author: jason
Date: Mon Jul 13 06:06:27 2009
New Revision: 149543
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149543
Log:
PR c++/36628
* tree.c (rvalue): Use
--- Comment #7 from jason at gcc dot gnu dot org 2009-07-13 06:06 ---
Subject: Bug 40689
Author: jason
Date: Mon Jul 13 06:06:27 2009
New Revision: 149543
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149543
Log:
PR c++/36628
* tree.c (rvalue): Use
--- Comment #24 from burnus at gcc dot gnu dot org 2009-07-13 06:26 ---
Subject: Bug 22423
Author: burnus
Date: Mon Jul 13 06:26:38 2009
New Revision: 149545
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149545
Log:
2009-07-12 Tobias Burnus bur...@net-b.de
Philippe
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-13 06:26 ---
Subject: Bug 40588
Author: burnus
Date: Mon Jul 13 06:26:38 2009
New Revision: 149545
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149545
Log:
2009-07-12 Tobias Burnus bur...@net-b.de
Philippe
--- Comment #3 from burnus at gcc dot gnu dot org 2009-07-13 06:28 ---
FIXED on the trunk (4.5). Thanks for the report and patch!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from burnus at gcc dot gnu dot org 2009-07-13 06:31 ---
Fixed (cf. comment 24) the warning of comment 21 and comment 23. If a new
warning is spotted, feel free to open a new PR or reopen this PR.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #24 from manu at gcc dot gnu dot org 2009-07-13 06:44 ---
(In reply to comment #23)
Btw, since a couple of days the warning is back :-)
That probably means a regression in the optimizers. Can you identify the
revision?
--
Compile the attached source code with options -Os -mthumb -march=armv5te
-fno-strict-aliasing, Gcc generates:
iterate:
push{lr}
ldr r3, [r1]// C
b .L5
.L4:
ldr r3, [r3, #8]// D
.L5:
str r3, [r0]// A
ldr
--- Comment #1 from carrot at google dot com 2009-07-13 08:58 ---
Created an attachment (id=18183)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18183action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40730
Trying to build GCC 4.4.0 with `--enable-languages=c,c++,java' (on NixOS,
http://nixos.org/) fails as follows:
--8---cut here---start-8---
gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-13 09:50 ---
-fgcse-las should do the trick. Note that PRE would do this kind of
optimization on the tree-level, but it is disabled with -Os (so is gcse).
bb 2:
D.1614_2 = p2_1(D)-front;
p1_3(D)-head = D.1614_2;
goto bb
--- Comment #3 from steven at gcc dot gnu dot org 2009-07-13 10:10 ---
And no, it is *not* OK to remove this kind of redundant code in DCE. The load
may be redundant, but it is not dead.
It is not clear to me why cleanup_cfg would move that insn. Perhaps you can
show what is going on
--- Comment #2 from alexey at feldgendler dot ru 2009-07-13 11:40 ---
Happens also on x86_64-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31872
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-07-13 11:48
---
(In reply to comment #0)
What I/we at OOo would like to have is a warning when a when a function in a
derived class is overloaded without specifing 'virtual'.
To avoid further misunderstanding: you mean
--- Comment #3 from tsyvarev at ispras dot ru 2009-07-13 11:55 ---
(In reply to comment #2)
I think this constructor never ever worked correctly. The only solution I can
see at the moment is consistently dynamically allocating _M_data-_M_grouping,
and copying the characters of
--- Comment #6 from Thomas dot Lange at sun dot com 2009-07-13 11:56
---
(In reply to comment #5)
No. I do mean overloaded!
It might be nice to have a warning for overloading virtual functions of base
classes as well. But my point is that the compiler should help to enforce that
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-07-13 11:59 ---
Your example is overriding A::f, not overloading it. Overloading would be
int f(int x, int y);
do you want a warning for that as well?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
--- Comment #8 from Thomas dot Lange at sun dot com 2009-07-13 12:02
---
(In reply to comment #6)
Ooops... Sorry!
I just was told that I confused those two terms. _
(That might happen to non-native speakers)
My apologies!
Yes you are correct. It is about overwriting.
--
--- Comment #9 from Thomas dot Lange at sun dot com 2009-07-13 12:07
---
(In reply to comment #6)
I'm not concerned about that case.
Thank you for your time!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #6 from cppljevans at suddenlink dot net 2009-07-13 12:48
---
Created an attachment (id=18184)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18184action=view)
Similar but simpler source (no Tail... in impl_front specialization)
Same error message, but no Tail... in
--- Comment #7 from cppljevans at suddenlink dot net 2009-07-13 12:50
---
Created an attachment (id=18185)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18185action=view)
compilation using gcc-4.5-20090702
Compiler source from:
--- Comment #8 from mikpe at it dot uu dot se 2009-07-13 13:05 ---
Mystery solved. Buried in revision 146451, which should just fix enum
conversions for C++ compatibility, is the following bug fix:
--- trunk/gcc/config/arm/arm.c 2009/04/20 19:30:55 146450
+++
--- Comment #9 from mikpe at it dot uu dot se 2009-07-13 13:07 ---
Created an attachment (id=18186)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18186action=view)
fix arith_adjacentmem LDM splitting code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39429
--- Comment #9 from janus at gcc dot gnu dot org 2009-07-13 13:42 ---
Subject: Bug 40646
Author: janus
Date: Mon Jul 13 13:41:37 2009
New Revision: 149586
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149586
Log:
2009-07-13 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-07-13 13:42 ---
Subject: Bug 40721
Author: rguenth
Date: Mon Jul 13 13:42:03 2009
New Revision: 149587
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149587
Log:
2009-07-13 Richard Guenther rguent...@suse.de
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-07-13 13:43 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #10 from janus at gcc dot gnu dot org 2009-07-13 13:45 ---
Comment #8 is fixed by r149586. After three patches, I think we can finally
close this PR.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from pinskia at gcc dot gnu dot org 2009-07-13 16:16
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-07-13 16:16
---
Subject: Bug 22154
Author: pinskia
Date: Mon Jul 13 16:15:55 2009
New Revision: 149590
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149590
Log:
2009-07-13 Andrew Pinski
--- Comment #10 from jwakely dot gcc at gmail dot com 2009-07-13 16:46
---
(In reply to comment #8)
Ooops... Sorry!
I just was told that I confused those two terms. _
(That might happen to non-native speakers)
My apologies!
Yes you are correct. It is about overwriting.
--- Comment #11 from dominiq at lps dot ens dot fr 2009-07-13 16:58 ---
At revision 149589, bootstrap fails on i686-apple-darwin9 with:
...
/opt/gcc/i686-darwin/./prev-gcc/xgcc -B/opt/gcc/i686-darwin/./prev-gcc/
-B/opt/gcc/gcc4.5w/i686-apple-darwin9/bin/
gfortran -v -save-temps hello.f
Driving: gfortran -v -save-temps hello.f -lgfortranbegin -lgfortran -lm
-shared-libgcc
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.4.0/configure --with-gmp=/apps/gmp/4.2.2
--with-mpfr=/apps/mpfr/2.4.1 --prefix=/apps/gcc/4.4.0
--- Comment #2 from elizbus at yahoo dot com 2009-07-13 17:24 ---
(In reply to comment #1)
Your assumption is wrong, in the sense that nothing in the Standard mandates
it
(likewise in C, for plain C streams, by the way) and in fact most, if not all,
current good performing
--- Comment #4 from dodji at gcc dot gnu dot org 2009-07-13 17:41 ---
A candidate patch was posted to
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00743.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40705
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-07-13 18:00 ---
Fortran reports are never anything but normal.
However, would you really expect that a compiler would be released that can't
handle code like the one quoted? I find it hard to believe, especially on a
platform as
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2009-07-13 18:12
---
Try compiling without these:
-lgfortranbegin -lgfortran
Should not need to do this. Lets see what it does.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40734
--- Comment #2 from doko at ubuntu dot com 2009-07-13 18:16 ---
this is with a minimal int main() { return 0; }
--
doko at ubuntu dot com changed:
What|Removed |Added
--- Comment #3 from al dot danial at ngc dot com 2009-07-13 18:30 ---
(In reply to comment #1)
Fortran reports are never anything but normal.
However, would you really expect that a compiler would be released that can't
handle code like the one quoted? I find it hard to believe,
--- Comment #4 from al dot danial at ngc dot com 2009-07-13 18:33 ---
(In reply to comment #2)
Try compiling without these:
-lgfortranbegin -lgfortran
Should not need to do this. Lets see what it does.
I don't specify either of these options (or any others for that matter).
--- Comment #5 from jakub at gcc dot gnu dot org 2009-07-13 18:42 ---
My guess would be you have configured libgmp or libmpfr for a different CPU
than you really have. Try
gdb --args /apps/gcc/4.4.0/libexec/gcc/i686-pc-linux-gnu/4.4.0/f951 hello.f
run
and see on which insn it crashed
--- Comment #6 from al dot danial at ngc dot com 2009-07-13 18:51 ---
(In reply to comment #5)
My guess would be you have configured libgmp or libmpfr for a different CPU
than you really have. Try
gdb --args /apps/gcc/4.4.0/libexec/gcc/i686-pc-linux-gnu/4.4.0/f951 hello.f
run
and
[forwarded from https://launchpad.net/bugs/398403]
Building the attached file with gcc from the 4.4 branch with -g
-fstack-protector -fPIE -Os, the build fails (killed by oom), last info seen is
memory usage of about 1500mb. Building without -fPIE memory usage is limited
around 700MB.
Same
--- Comment #1 from doko at ubuntu dot com 2009-07-13 19:37 ---
Created an attachment (id=18188)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18188action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40735
--- Comment #3 from paolo dot carlini at oracle dot com 2009-07-13 19:59
---
The pointers are in some sense independent, but in this exact technical sense:
a seekg ends up calling the seekoff fstream virtual and therefore the mode
becomes 'uncommitted', neither read mode neither write
err_bad_typedef.c leads to a call to initialize_aggregate with
arg-elemnts==NULL. This sets ptr on line 46 of
libffi/src/prep_cif.c to NULL, which is then dereferenced on
line 48.
Environment:
System: Linux dps 2.6.30.1-nofb #3 SMP PREEMPT Tue Jul 7 13:26:53
--- Comment #2 from photon at seznam dot cz 2009-07-13 20:57 ---
-Wall has a very misleading name and should probably be changed to match the
MSC behaviour (enable all warnings available).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40733
--- Comment #7 from al dot danial at ngc dot com 2009-07-13 21:13 ---
One more data point: the build machine runs CentOS 4.3 and on it gfortran
works fine (!). The ICE happens on a CentOS 4.4 box (using the identical GCC
4.4.0/GMP 4.2.2/MPFR 2.4.1 bits from a shared NFS mount).
I'll
This bug appears in gfortran 4.4.0 on sparc-solaris, x86-solaris, and
x86-linux.
The attached test case is extracted from SPECmpi 2007 129.tera_tf
The two test files testmod.F90 and testuse.F90 define and use pointer types.
With -DBIGMOD certain variables are defined in the module; with -UBIGMOD,
--- Comment #1 from dh458 at oakapple dot net 2009-07-13 21:39 ---
Created an attachment (id=18189)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18189action=view)
module definition
This is the module definition file for the bug report.
--
--- Comment #2 from dh458 at oakapple dot net 2009-07-13 21:40 ---
Created an attachment (id=18190)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18190action=view)
module use file for bug report
Compile this module use with the other attachment module definition
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-07-13 21:42 ---
(In reply to comment #2)
-Wall has a very misleading name and should probably be changed to match the
MSC behaviour (enable all warnings available).
-Wall
This enables all the warnings about constructions that
This code, compiled with trunk:
templatetypename _Tp, typename _Alloc
class list
{
struct iterator;
struct const_iterator;
};
templatetypename _Tp, typename _Alloc
struct list_Tp, _Alloc::iterator
{ };
#if 0
templatetypename _Tp, typename _Alloc
--- Comment #1 from bkoz at gcc dot gnu dot org 2009-07-13 23:40 ---
eek that should be expected 'typename' before...
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from bje at gcc dot gnu dot org 2009-07-14 03:25 ---
Confirmed in lto revision 149607.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40429
--- Comment #4 from bje at gcc dot gnu dot org 2009-07-14 04:39 ---
Can this PR be closed now, Rainer?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39022
$ cat ~/hw.c
int main() {
printf(hello world\n);
}
r...@ryan:~/gcc/lto-branch/x86-build/gcc$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-languages=c --enable-lto
--disable-bootstrap
Thread model: posix
gcc version 4.5.0
--- Comment #6 from jason at gcc dot gnu dot org 2009-07-14 05:17 ---
Fixed for 4.4.1.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jason at gcc dot gnu dot org 2009-07-14 05:18 ---
Fixed for 4.4.1.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bje at gcc dot gnu dot org 2009-07-14 05:21 ---
There is a test case in gfortran.dg for this now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40724
61 matches
Mail list logo
