--- Comment #5 from marie dot vidal at inria dot fr 2007-02-06 07:27
---
I got exactly the same error, I tried to build a cross-compiler
x86 -> x86-64 using crosstool 0.43.
host: x86
-
Linux 2.6.10-1.771_FC2
gcc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)
glibc-2.3.6-3
binutils-2.1
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-02-06 03:04
---
See the commentary near the top of io/unit.c . This is a basic explanation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
--- Comment #5 from aoliva at gcc dot gnu dot org 2007-02-06 01:35 ---
Subject: Bug 30189
Author: aoliva
Date: Tue Feb 6 01:35:10 2007
New Revision: 121638
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121638
Log:
gcc/ChangeLog:
PR debug/30189
* dwarf2out.c (modified_type_die)
--- Comment #4 from aoliva at gcc dot gnu dot org 2007-02-06 01:34 ---
Subject: Bug 30189
Author: aoliva
Date: Tue Feb 6 01:34:37 2007
New Revision: 121637
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121637
Log:
gcc/ChangeLog:
PR debug/30189
* dwarf2out.c (modified_type_die)
--- Comment #6 from Scott at coral8 dot com 2007-02-06 01:01 ---
Ah, very good. Thanks for taking a look at this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30633
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-02-06 00:34 ---
This is a true warning.
With the mainline we get an extra note:
boost_1_33_1/boost/graph/detail/adjacency_list.hpp:2116: note:
'p.boost::property::m_value' was
declared here
That was added for fixing PR 17506.
whic
--- Comment #9 from kargl at gcc dot gnu dot org 2007-02-06 00:31 ---
Fixed in trunk and 4.2. Won't fix in 4.1 or earlier.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from kargl at gcc dot gnu dot org 2007-02-06 00:28 ---
Subject: Bug 30605
Author: kargl
Date: Tue Feb 6 00:28:14 2007
New Revision: 121631
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121631
Log:
2007-02-05 Steven G. Kargl <[EMAIL PROTECTED]>
PR fortr
--- Comment #4 from Scott at coral8 dot com 2007-02-06 00:21 ---
Created an attachment (id=13010)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13010&action=view)
Preprocessed source, as requested (gzipped)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30633
--- Comment #3 from Scott at coral8 dot com 2007-02-06 00:17 ---
Actually, I didn't look closely enough; the error generated by 4.1.2 RC1 is
different:
/usr/local/gcc-4.1.2/lib/gcc/i386-pc-solaris2.11/4.1.2/../../../../include/c++/4.1.2/ext/new_allocator.h:
In function void break_gcc(Fl
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-05 23:47 ---
>(This is, as you probably already realize, a name generated internally by g++;
> there is no such variable in the source.)
The name is generated internally by g++ but it is really p.m_value which was
actually alread
--- Comment #1 from Scott at coral8 dot com 2007-02-05 23:40 ---
I tried 4.1.2 RC1 -- the bug is still present.
--
Scott at coral8 dot com changed:
What|Removed |Added
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-02-05 22:51
---
... to mark as WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-02-05 22:51
---
Reopen ...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|RES
--- Comment #15 from steven at gcc dot gnu dot org 2007-02-05 22:46 ---
Closing as DONTCARE, by request from Diego :-)
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #14 from steven at gcc dot gnu dot org 2007-02-05 22:30 ---
I don't think there is a compelling reason to have the patch in GCC 4.2. But
it would still be nice to get this out of the way, to reduce the number of VOPs
a bit further.
I have updated the patch of comment #6 and
--- Comment #10 from steven at gcc dot gnu dot org 2007-02-05 22:23 ---
Reported as fixed, see comment #9.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-02-05 22:23
---
It's not target specific as it is also seen on i686-pc-linux-gnu with mainline,
when compiling enum_2.f90 under valgrind:
==6149== Invalid read of size 4
==6149==at 0x86522E3: __gmpz_add_ui (in
/home/fxcouder
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-02-05 22:15
---
When the program hangs, we're in
#0 0x9002bbc8 in semaphore_wait_signal_trap ()
#1 0x90001410 in pthread_mutex_lock ()
#2 0x0025595c in get_external_unit (n=6, do_create=275) at
../../../gcc/libgfortran/../gc
--- Comment #1 from wilson at gcc dot gnu dot org 2007-02-05 22:10 ---
Model and version_id are already documented. It is only syscall_linkage that
is undocmented, and that would be my fault.
Meanwhile, you can find info about it in the gcc sources, in the file
gcc/config/ia64/ia64.c.
--- Comment #10 from rakdver at gcc dot gnu dot org 2007-02-05 21:45
---
Hello,
(In reply to comment #8)
> (In reply to comment #1)
> > With -funsafe-loop-optimizations we remove them.
> > Using -Wunsafe-loop-optimizations, we get:
> > t.c:2: warning: cannot optimize loop, the loop cou
--- Comment #3 from hp at gcc dot gnu dot org 2007-02-05 21:44 ---
Might be worthwhile to import this to other branches, but closing with 4.3
milestone for now.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from sje at gcc dot gnu dot org 2007-02-05 21:28 ---
Subject: Bug 30432
Author: sje
Date: Mon Feb 5 21:28:46 2007
New Revision: 121615
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121615
Log:
Backport from trunk
PR fortran/30432
* trans-
--- Comment #2 from hp at gcc dot gnu dot org 2007-02-05 21:22 ---
Subject: Bug 30665
Author: hp
Date: Mon Feb 5 21:22:24 2007
New Revision: 121613
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121613
Log:
PR target/30665
* config/cris/cris.md ("*andsi_movu", "
--- Comment #1 from hp at gcc dot gnu dot org 2007-02-05 21:20 ---
Subject: Bug 30665
Author: hp
Date: Mon Feb 5 21:20:36 2007
New Revision: 121611
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121611
Log:
PR target/30665
* gcc.dg/torture/pr30665-1.c, gcc.dg/to
--- Comment #4 from sliedes at cc dot hut dot fi 2007-02-05 21:11 ---
It does compile (with gcc 4.1.1-15 in Debian amd64), but cc1 eats ~ 1 GiB of
memory.
--
sliedes at cc dot hut dot fi changed:
What|Removed |Added
--- Comment #6 from jv244 at cam dot ac dot uk 2007-02-05 20:12 ---
a patch:
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00353.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30391
--- Comment #28 from mark at codesourcery dot com 2007-02-05 20:08 ---
Subject: Re: Shared libstdc++ fails to link
amylaar at gcc dot gnu dot org wrote:
> --- Comment #27 from amylaar at gcc dot gnu dot org 2007-02-05 19:52
> ---
> (In reply to comment #25)
>> I think the ana
--- Comment #27 from amylaar at gcc dot gnu dot org 2007-02-05 19:52
---
(In reply to comment #25)
> I think the analysis should be deeper than just "binds_local_p", though;
> I think it should be based on whether "attribute ((weak))" (or
> equivalent) explicitly appears, so that we don
--- Comment #4 from dnovillo at gcc dot gnu dot org 2007-02-05 19:48
---
Testing alternate patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30562
--- Comment #17 from pinskia at gcc dot gnu dot org 2007-02-05 19:44
---
*** Bug 30705 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-05 19:44 ---
This was fixed in 3.4.4.
*** This bug has been marked as a duplicate of 19293 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-05 19:43 ---
Confirmed on powerpc64-linux-gnu also.
.LC0:
.tc FD__f[TC],0x000f
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from burnus at gcc dot gnu dot org 2007-02-05 19:40 ---
As Dick Hendrickson points out in c.l.fortran:
13.7 (the function descriptions) says
"A program is prohibited from invoking an intrinsic procedure under
circumstances where a value to be returned in a subroutine argu
--- Comment #26 from amylaar at gcc dot gnu dot org 2007-02-05 19:35
---
(In reply to comment #22)
> If you refer to http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00559.html this
> little patch would undo any semantic changes introduced there. I didn't
> follow
> the discussion however
--- Comment #25 from mark at codesourcery dot com 2007-02-05 19:33 ---
Subject: Re: Shared libstdc++ fails to link
rguenth at gcc dot gnu dot org wrote:
[Paolo, see below for question.]
> --- Comment #20 from rguenth at gcc dot gnu dot org 2007-02-05 09:06
> ---
> What we w
--- Comment #24 from amylaar at gcc dot gnu dot org 2007-02-05 19:26
---
(In reply to comment #18)
> It was argued in PR 29323 that it was incorrect to mark functions
> that don't bind locally with TREE_NOTHROW.
>
> I'm not sure whether it's valid at the language level to replace
> a f
--- Comment #14 from mmitchel at gcc dot gnu dot org 2007-02-05 19:17
---
Richard, thank you for the testing. Since David is now comfortable, I think we
should include this patch on the 4.1 branch, so that we fix this problem for
4.1.2. If nobody beats me to it, I will apply the patch
--- Comment #4 from jsm28 at gcc dot gnu dot org 2007-02-05 19:03 ---
Now we always require MPFR, it should be easy to fix this by using MPFR's
facilities for parsing numbers from strings.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #9 from pcarlini at suse dot de 2007-02-05 18:53 ---
Referring to Comment #7, currently in mainline, 4_2-branch and even 4.1.1 the
only loop not eliminated at -O2 is foo2 - actually, that is pretty good for the
library: very nice that we don't need special code to avoid foo4.
--- Comment #23 from amylaar at gcc dot gnu dot org 2007-02-05 18:34
---
(In reply to comment #20)
> I suppose PR29323 was found by inspection of GCC code rather than a real-world
> testcase so the option to revert that patch on the 4.1 branch looks appealing.
>
> (CCed Joern to clarif
--- Comment #1 from kargl at gcc dot gnu dot org 2007-02-05 17:46 ---
This code compiles with
troutmask:sgk[208] gfc41 --version
GNU Fortran 95 (GCC) 4.1.2 20070127 (prerelease)
troutmask:sgk[209] gfc42 --version
GNU Fortran 95 (GCC) 4.2.0 20070126 (prerelease)
troutmask:sgk[210] gfc
--- Comment #6 from dcb314 at hotmail dot com 2007-02-05 17:44 ---
(In reply to comment #5)
> Can you try after:
> http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121295
The snapshot 20070202 seems fixed to me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30559
--- Comment #13 from dje at gcc dot gnu dot org 2007-02-05 17:35 ---
If the patch is okay on SLES 9, as Richard says,
http://gcc.gnu.org/ml/gcc/2007-02/msg00068.html
then it's fine with me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30370
--- Comment #6 from Ralf dot Wildenhues at gmx dot de 2007-02-05 16:51
---
Proposed patch: http://gcc.gnu.org/ml/gcc/2007-02/msg00039.html
--
Ralf dot Wildenhues at gmx dot de changed:
What|Removed |Added
--
This bug may be fixed or not. It may be known or not.
It would be too much work for me to find out.
gfortran segfaults at:
subroutine bar(a, n)
implicit none
integer, intent(IN) :: n
character(n), pointer :: a(:)
allocate(a(1))
end subroutine bar
$ gfortran -v
Using built-in specs.
Ta
--- Comment #2 from kargl at gcc dot gnu dot org 2007-02-05 16:25 ---
(In reply to comment #1)
> Compiling the code above with
>
> gfortran -std=f2003
>
> gives
>
> In file xarithmetic_if.f90:5
>
> if (i) 10,20,30
> 1
> Error: Obsolete: arithmetic IF statement at (1)
gcc/objdir$../gcc/configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu
--prefix=$HOME/local && make bootstrap
failed with such message:
.libs/in_pack_generic.o: In function `gnu_dev_minor':
/home/evgeniy/test/gcc/objdir/./gcc/include/sys/sysmacros.h:66: multiple
definition of `gnu_dev_min
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-02-05 14:52 ---
Actually the original testcase also fails with 4.1.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from burnus at gcc dot gnu dot org 2007-02-05 14:45 ---
Thanks, aermod now works. :-)
channel, gas_dyn, induct, nf, protein, rnflow still fail respectively fail now.
$ gfortran -fprofile-generate -march=opteron -ffast-math -funroll-loops
-ftree-vectorize -O3 -o channel
--- Comment #9 from nickc at redhat dot com 2007-02-05 14:28 ---
Hi Steven,
There is no longer a buf to fix. In fact the hack mentioned in comment #4
has been removed and the test case compiles without problems using the current
mainline sources.
Cheers
Nick
--
http://gcc.gnu
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-05 14:19 ---
Confirmed. Maybe related to PR30088. The first alias dump at -O2 (-O
-fstrict-aliasing is fine) has
:
# common_head_5 = V_MUST_DEF ;
common_head = 0B;
...
:;
p_10 = &common_head;
goto ();
:;
# VU
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-02-05 14:10 ---
4.1.0 works, so this is a regression on the branch. Janis, can you hunt what
broke it?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-02-05 14:07 ---
Created an attachment (id=13008)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13008&action=view)
reduced testcase
This is a reduced testcase (still requires libstdc++ at link time) where you
can see the wrong
--- Comment #1 from vivekrao4 at yahoo dot com 2007-02-05 14:05 ---
Compiling the code above with
gfortran -std=f2003
gives
In file xarithmetic_if.f90:5
if (i) 10,20,30
1
Error: Obsolete: arithmetic IF statement at (1)
which is incorrect, because the arithmetic IF is
--- Comment #20 from hp at gcc dot gnu dot org 2007-02-05 13:51 ---
I see this for cris-elf (r121581) and mmix-knuth-mmixware (r121569) too, both
mayalias-2 and -3 both at "-O3 -g" like for x86_64.
As we have this PR, I intend to XFAIL it for these ports with those options;
IIRC that's p
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2007-02-05 13:28
---
Fixed on trunk and gcc-4_2-branch.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
-
struct obj_symbol
{
struct obj_symbol *next;
unsigned int size;
};
struct common_entry
{
struct common_entry *next;
struct obj_symbol *sym;
};
extern void do_something(struct obj_symbol *sym);
void obj_allocate_commons(struct obj_symbol *sym)
{
struct common_entry *common_head = ((void *)0)
--- Comment #6 from mkuvyrkov at gcc dot gnu dot org 2007-02-05 13:14
---
Subject: Bug 29682
Author: mkuvyrkov
Date: Mon Feb 5 13:14:20 2007
New Revision: 121599
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121599
Log:
PR target/29682
* config/ia64/ia64.c (ia
--- Comment #22 from mueller at gcc dot gnu dot org 2007-02-05 12:43
---
Fixed in 4.3.
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #21 from mueller at gcc dot gnu dot org 2007-02-05 12:43
---
Subject: Bug 30510
Author: mueller
Date: Mon Feb 5 12:43:17 2007
New Revision: 121596
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121596
Log:
2007-02-05 Dirk Mueller <[EMAIL PROTECTED]>
PR bo
--- Comment #1 from david_henry_il at hotmail dot com 2007-02-05 12:42
---
Created an attachment (id=13007)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13007&action=view)
preprocessor output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30705
Intermediate File
-
# 1 "b.c"
# 1 ""
# 1 ""
# 1 "b.c"
short fx;
void foo()
{
long diff;
int sample;
sample = 128;
diff = fx - (fx << 128);
}
Output
--
$ avr-gcc -v -fverbose-asm -S -save-temps b.c
Reading specs from /usr/lib/gcc/avr/3.4.3/specs
Configured with: ./configu
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-02-05 12:30 ---
We have (alias1):
Type memory tags
TMT.89, UID 17988, struct
basic_string,std::allocator >, is an alias
tag, is addressable, is global, call clobbered
...
TMT.95, UID 17994, float, is addressable, may aliases: { SF
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-02-05 12:17 ---
Slightly reduced testcase:
#include
#include
struct A
{
A() : _x(0.0), _y(0.0) { }
float& f(const int& i) { return (i == 0 ? _x : _y); }
float _x, _y;
};
A h(const char* s)
{
A a;
std::string b("");
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-05 10:16 ---
This works ok on a little-endian target. How does the optimized tree-dump look
like? (I suppose we use VIEW_CONVERT_EXPR for the memcpy and maybe even fold
the constant therein)
--
rguenth at gcc dot gnu dot or
--- Comment #11 from tbm at cyrius dot com 2007-02-05 09:55 ---
(In reply to comment #10)
> The testcase in comment #2 works for me on the 4.2 branch now, but the one in
> comment #7 fails with
> > t.ii:7: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:434
Yeah, I ment
--- Comment #6 from paulthomas2 at wanadoo dot fr 2007-02-05 09:37 ---
Subject: Re: [4.2 and 4.1 only] Allocatable components
of a derived type "require" the SAVE attribute.
toon,
> 1
> Error: Object 'g_dest' at (1) must have the SAVE attribute for default
> initia
--- Comment #22 from bonzini at gnu dot org 2007-02-05 09:22 ---
If you refer to http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00559.html this
little patch would undo any semantic changes introduced there. I didn't follow
the discussion however and I don't know if this is the correct fix
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-02-05 09:07
---
CCint Paolo who changed the meaning of TREE_NOTHROW.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-02-05 09:06
---
What we want to prevent with the patch for PR29323 is the TREE_NOTHROW flag
propagating to a locally binding function. Consider
void foo() nothrow __attribute__((weak)) {}
void bar()
{
foo();
}
we need EH unw
72 matches
Mail list logo
