--- Comment #9 from xenofears at gmail dot com 2009-07-14 06:35 ---
I was about to post this:
--enable-version-specific-runtime-libs is pretty broken:
in the /lib/gcc/x86_64-w64-mingw32 dir, there exists a lib32 and lib64
dir alongside the (i.e. 4.4.1) dir. Neither are searched in by
--- 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
--- 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
Status|UNC
--- Comment #2 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
Status|UNC
--- 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
Status|NEW
$ 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 2
--- 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
--- 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 #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
-
This code, compiled with trunk:
template
class list
{
struct iterator;
struct const_iterator;
};
template
struct list<_Tp, _Alloc>::iterator
{ };
#if 0
template
inline bool
operator!=(const typename list<_Tp, _Alloc>::iterator& __x,
--- 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
--- 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=18190&action=view)
module use file for bug report
Compile this module use with the other attachment module definition
--
http://gc
--- 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=18189&action=view)
module definition
This is the module definition file for the bug report.
--
http://gcc.gnu.org/bugzilla/show_bu
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 #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 m
--- 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
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 B
--- 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 m
--- 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=18188&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40735
[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 behavi
--- 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
>
--- 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 (d
--- 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 matt
--- 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 belie
--- 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 #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 #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 #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 #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 imple
> 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
--enable-
--- 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/
-B/opt/gcc/gcc4.5w/i686-apple-da
--- 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.
O
--- 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=gcc&view=rev&rev=149590
Log:
2009-07-13 Andrew Pinski
PR C++/22154
*
--- 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
Status|ASSIGNE
--- Comment #7 from ramana at gcc dot gnu dot org 2009-07-13 16:05 ---
Since there are no objections to comment #6 - I am closing this to WONTFIX
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-13 15:56 ---
-Wconversion needs to be supplied.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following code contains an implicit integer conversion involving a data
loss. There is no warning issued even when -Wall is specified.
int main()
{
int i = 0x12345678;
char c = i; // No warning is issued here
}
--
Summary: No warning is issued when an implicit co
--- Comment #8 from burnus at gcc dot gnu dot org 2009-07-13 15:29 ---
(Not restricted to Darwin, happens also on x86-64-linux.)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from ramana at gcc dot gnu dot org 2009-07-13 15:15 ---
(In reply to comment #2)
> I'll go farther than that and say that all single-precision fp numbers
> destined for integer registers should be passed through the normal
> constant splitting routines.
>
> For instan
--- Comment #2 from estrizhov at topcon dot com 2009-07-13 14:41 ---
Created an attachment (id=18187)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18187&action=view)
Fixing ICE in lto_end_uncompression, at lto-compress.c:282
I've solved this problem with this patch (lto rev. 1484
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-13 14:35
---
Note that Segmentation faults and Internal Compiler Errors are never library
issues: the compiler proper is definitely misbehaving.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40729
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-13 14:33
---
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 implementation do not satis
My understanding is that with fstream, get and put pointers move together.
Therefore expect output of following to be aabbc1234, output is actually aabbc.
This had expected result with 3.3.1, unexpected result with 3.4.4.
#include
using namespace std;
int main(int argc, char* argv[])
{
fstream
--- Comment #6 from rearnsha at arm dot com 2009-07-13 14:22 ---
Subject: Re: allocate local variables with fewer
instructions
On Mon, 2009-07-06 at 10:43 +, steven at gcc dot gnu dot org wrote:
> But how to do this in GCC... The "push {lr}" is never even in the
> RTL. Ou
--- Comment #2 from falk at debian dot org 2009-07-13 14:19 ---
It bootstraps now, except that it fails for objc. I'll file a bug report for
that later.
--
falk at debian dot org changed:
What|Removed |Added
--- 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 #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 #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=gcc&view=rev&rev=149587
Log:
2009-07-13 Richard Guenther
PR lto/40721
--- 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=gcc&view=rev&rev=149586
Log:
2009-07-13 Janus Weil
PR fortran/40646
* modu
--- 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=18186&action=view)
fix arith_adjacentmem LDM splitting code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39429
--- 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
+++ trunk/gcc/config/arm/a
--- 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=18185&action=view)
compilation using gcc-4.5-20090702
Compiler source from:
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090702/g
--- 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=18184&action=view)
Similar but simpler source (no Tail... in impl_front specialization)
Same error message, but no Tail... in i
--
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 #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
--- 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.
--
http://g
--- 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 #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
every
--- 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 __n
--- 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 o
--- 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 #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 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).
:
D.1614_2 = p2_1(D)->front;
p1_3(D)->head = D.1614_2;
goto ;
:
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 #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=18183&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40730
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
66 matches
Mail list logo
