--- Comment #3 from zackw at panix dot com 2007-05-12 07:34 ---
I believe Mike means to suggest you use -Wl,yada,yada,yada instead of -Xlinker
yada -Xlinker yada -Xlinker yada. (I also suspect this will help.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906
--- Comment #7 from pault at gcc dot gnu dot org 2007-05-12 07:22 ---
Fixed on trunk.
Please note that recursive_reference_1.f90 was replaced, accidentally, by an
identical copy of itself.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-12 07:19 ---
Subject: Bug 30746
Author: pault
Date: Sat May 12 06:19:43 2007
New Revision: 124633
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124633
Log:
2007-05-12 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-05-12 06:02
---
In the expr for a or b, the lower bound is coming up BT_INTEGER and the upper
bound is BT_REAL. Eventually we hit the error for wrong type. Then, because
this fails to resolve, that is interpreted by resolve_fl_
--- Comment #2 from mrs at apple dot com 2007-05-12 05:51 ---
Can you work around it with the -Xlinker,-arg1,val1,-arg2,val2 syntax?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906
--- Comment #1 from prj-bugzilla-gcc at multivac dot cwru dot edu
2007-05-12 05:31 ---
Created an attachment (id=13545)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13545&action=view)
complete build output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906
--- Comment #1 from kkojima at gcc dot gnu dot org 2007-05-12 04:23 ---
I've confirmed that this doesn't fail on the current 4.2 branch
and trunk anymore. Closed as FIXED.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from blaisorblade_spam at yahoo dot it 2007-05-12 04:18
---
Created an attachment (id=13544)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13544&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31905
My glibc is installed in an unusual place, so before building, I edited the
top-level Makefile.in to set:
LDFLAGS_FOR_TARGET = -Xlinker --dynamic-linker -Xlinker
/package/host/code.dogmap.org/foreign/gcc-4.2.0-20070501+spf+0/conf/glibc/library/ld-linux.so.2
-L/nil -Xlinker -R -Xlinker
/package/host
I get an ICE when instantiating the following template:
template
typeof(&T::method2) method2_of(T) {
return &T::method2;
}
Note that both '&' are needed, as well as instantiating this template on a
type having a ::method2 member function. If I omit any of them, I get just
various error
The following code fail to compile under cygwin. The relevant error message is:
...: undefined reference to `Base::x'
collect2: ld returned 1 exit status
However if I change the statement "y=-x" to "y=x", then it compiles fine.
class Base
{
public:
virtual void f () = 0;
static const do
--- Comment #28 from dave at hiauly1 dot hia dot nrc dot ca 2007-05-12
02:36 ---
Subject: Re: [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
> > The 11.11 man page indicates that single-byte character code sets
> > are supported. It also st
--- Comment #27 from dave at hiauly1 dot hia dot nrc dot ca 2007-05-12
02:23 ---
Subject: Re: [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
> An additional remark on hppa: a *theoretical* possibility is that on hppa
> strtold (or sscanf), e
--- Comment #26 from pcarlini at suse dot de 2007-05-12 02:01 ---
More simply, we could define a macro in config/os/hpux/os_defines.h like:
#define _GLIBCXX_HAVE_BROKEN_STRTOLD 1
to inform the library to avoid strtold, checked in clocale.cc. If you find this
reasonable, could you suggest
--- Comment #25 from pcarlini at suse dot de 2007-05-12 01:51 ---
(In reply to comment #24)
> It's defined.
Ok, thanks.
> The 11.11 man page indicates that single-byte character code sets
> are supported. It also states that this function is "to be obsoleted
> at a future date."
Well
--- Comment #50 from dberlin at gcc dot gnu dot org 2007-05-12 01:36
---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
On 11 May 2007 23:22:14 -, ian at airs dot com
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #49 from i
--- Comment #24 from dave at hiauly1 dot hia dot nrc dot ca 2007-05-12
01:22 ---
Subject: Re: [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
> which code do we have on hppa? _GLIBCXX_HAVE_STRTOLD is defined or not?
It's defined.
The 11.11
--- Comment #6 from sabre at nondot dot org 2007-05-12 01:00 ---
The real bug here is that they are not getting internal linkage. Just
uniquing/randifying the names would allow them to link, but could be a perf
issue (more symbols for the static/dynamic linker).
--
http://gcc.gnu.o
--- Comment #49 from ian at airs dot com 2007-05-12 00:22 ---
Created an attachment (id=13543)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13543&action=view)
Patch
Like sands through the hourglass, so are the patches to PR 29286.
This version creates a new tree code. At the RT
--- Comment #5 from mrs at apple dot com 2007-05-12 00:00 ---
Odd, I see:
X:
.long _ZTIN12_GLOBAL__N_13fooE
.weak _ZTSN12_GLOBAL__N_13fooE
.section.gnu.linkonce.r._ZTSN12_GLOBAL__N_13fooE,"a",@progbits
.type _ZTSN12_GLOBAL__N_13fooE, @object
--- Comment #1 from sje at gcc dot gnu dot org 2007-05-11 23:56 ---
Subject: Bug 31829
Author: sje
Date: Fri May 11 22:56:10 2007
New Revision: 124628
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124628
Log:
PR c++/31829
* g++.dg/warn/multiple-overflow-warn-3.C
--- Comment #23 from dave at hiauly1 dot hia dot nrc dot ca 2007-05-11
23:37 ---
Subject: Re: [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
> --- Comment #21 from pcarlini at suse dot de 2007-05-11 19:03 ---
> And of course please
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2007-05-11 23:00
---
Fixed on 4.2, Closing. Sorry for the premature commit on 4.1.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2007-05-11 22:57
---
Subject: Bug 31880
Author: jvdelisle
Date: Fri May 11 21:57:05 2007
New Revision: 124627
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124627
Log:
2007-05-11 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-11 22:55 ---
(In reply to comment #3)
> I think this is a bug on Linux as well, though, I suspect it don't fail to
> build, but rather I think it will compare the two typeinfo objects as equal
> even though they are unrelated to
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2007-05-11 22:54
---
Subject: Bug 31880
Author: jvdelisle
Date: Fri May 11 21:53:52 2007
New Revision: 124626
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124626
Log:
2007-05-11 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #14 from dberlin at gcc dot gnu dot org 2007-05-11 22:53
---
Subject: Re: [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE
> > Actually shouldn't has_volatile_ops be set? I am thinking something is not
> > setting that.
>
> Just to say that we have seen this prob
--- Comment #3 from mrs at apple dot com 2007-05-11 22:44 ---
I think this is a bug on Linux as well, though, I suspect it don't fail to
build, but rather I think it will compare the two typeinfo objects as equal
even though they are unrelated to each other.
--
mrs at apple dot com c
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-11 22:25 ---
debian:~> ~/x86-local-fsf/bin/g++ -c -o t1.o t.cc
debian:~> ~/x86-local-fsf/bin/g++ -c -o t2.o t.cc -DFOO
debian:~> ~/x86-local-fsf/bin/g++ t1.o t2.o
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-11 22:20 ---
This works correctly on i686-Linux-gnu in 4.2.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
It appears that 4.2 isn't making anonymous namespace variables unique (it's
also making them global). This is preventing LLVM from compiling with the 4.2
compiler.
$ cat foo.cpp
#include
namespace {
class foo {
virtual void bar();
};
}
void foo::bar() {}
#ifdef FOO
const std::type_info
--- Comment #4 from steven at gcc dot gnu dot org 2007-05-11 21:51 ---
There doesn't seem to be another way to get this to work, than the proposed way
with extra basic blocks. The things I've tried either break gcc, or gdb, or
debug info. Unassigning.
--
steven at gcc dot gnu dot o
--- Comment #1 from kriptomik at gmail dot com 2007-05-11 21:44 ---
Created an attachment (id=13542)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13542&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31902
--- Comment #7 from steven at gcc dot gnu dot org 2007-05-11 21:42 ---
This bug is beyond my regalloc/reload fu, so unassigning...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
While trying to compiling cinelerra on
athlon X2, Debian lenny, Latest Beta Nvidia drivers (may be usefull), 2.6.20
with cfs patchv4
gcc -v :
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2007-05-11 21:27
---
> Actually shouldn't has_volatile_ops be set? I am thinking something is not
> setting that.
Just to say that we have seen this problem with the Ada compiler and the cause
was indeed the (non-)propagation of th
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31809
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31797
--- Comment #14 from mark at codesourcery dot com 2007-05-11 19:45 ---
Subject: Re: [4.2 only] silent data corruption in gfortran
read statement
tkoenig at gcc dot gnu dot org wrote:
> I second Jerry's DeLisle's request for inclusion in 4.2. This is a
> regression versus g77, the fi
--- Comment #13 from tkoenig at gcc dot gnu dot org 2007-05-11 19:19
---
Mark, this bug is critical - silent data corruption upon read
is really, really bad.
I second Jerry's DeLisle's request for inclusion in 4.2. This is a
regression versus g77, the fix is simple and safe.
--
tk
--- Comment #22 from pcarlini at suse dot de 2007-05-11 19:17 ---
An additional remark on hppa: a *theoretical* possibility is that on hppa
strtold (or sscanf), even if infinities are available, doesn't return an
infinity in case of input overflow. As far as I know, that is strictly mand
--- Comment #12 from tkoenig at gcc dot gnu dot org 2007-05-11 19:16
---
This is a regression WRT g77.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Othe
--- Comment #2 from pcarlini at suse dot de 2007-05-11 19:09 ---
This is known and we decided time ago not to do anything about it (you can find
something either in Bugzilla or in the libstdc++ mailing list): a portable use
of fstream with anything != char and wchar_t requires in general
--- Comment #1 from batterseapower at hotmail dot com 2007-05-11 19:04
---
Created an attachment (id=13541)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13541&action=view)
Preprocessed C++ source code for my test application
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=319
--- Comment #21 from pcarlini at suse dot de 2007-05-11 19:03 ---
And of course please check also whether __LDBL_HAS_INFINITY__ is 1 or 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836
When I try and "copy" a basic_ifstream into a vector I
recieve a bad cast exception. If the uint8_t is replaced with "unsigned char"
explicitly the problem persists, but if it is replaced with "char" the problem
goes away.
This has been confirmed not only on my system (GCC 4.1.1), but an Ubuntu sy
--- Comment #20 from pcarlini at suse dot de 2007-05-11 19:02 ---
(In reply to comment #19)
> Subject: Re: [4.3 Regression] FAIL:
> 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
>
> > Using some printf (actually, std::cerr) debugging, I've found that
> > the failu
--- Comment #2 from fang at csl dot cornell dot edu 2007-05-11 18:58
---
Ooops, strike that last comment, forgot -gdwarf-2:
g++-4 -gdwarf-2 -c pr31899.cc -o pr31899.o
ICEs with:
internal compiler error: in reference_to_unused, at dwarf2out.c:10010
(same compiler version, 4.2 RC2)
--
--- Comment #1 from fang at csl dot cornell dot edu 2007-05-11 18:53
---
On your test case,
$ g++-4 -g -c pr31899.cc -o pr31899.o
also works for me with 4.2.0 20070430 (prerelease), which was 4.2's RC2.
Configured with: ../gcc-4.2.0-20070430/configure --prefix=/sw
--prefix=/sw/lib/gcc
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2007-05-11
18:32 ---
Subject: Re: [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
> Using some printf (actually, std::cerr) debugging, I've found that
> the failure occurs for the fl
--- Comment #18 from pcarlini at suse dot de 2007-05-11 18:28 ---
(In reply to comment #17)
> Using a compiler based on gcc version 4.2.0 20070317 (prerelease),
> i686-pc-linux-gnu X arc-elf32, I see execution failures for
> 27_io/basic_istream/extractors_arithmetic/char/12.c .
> Using
--- Comment #6 from steven at gcc dot gnu dot org 2007-05-11 18:28 ---
Note that with SVN gcc 4.3 (20070506) lreg actually _does_ tie reg 58 and reg
21 in lreg:
;; Register 58 in 21.
;; Register 59 in 5.
But we then fail due to the confict, I think.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #5 from steven at gcc dot gnu dot org 2007-05-11 18:26 ---
For gcc 3.4, same function convert, lreg:
;; Register 60 in 5.
;; Register 62 in 0.
(note:HI 2 0 27 NOTE_INSN_DELETED)
;; Start of basic block 0, registers live: 5 [di] 6 [bp] 7 [sp] 16 [argp] 20
[frame]
(note:HI 2
--- Comment #4 from steven at gcc dot gnu dot org 2007-05-11 18:22 ---
For "convert" the issue is caused by a decision that reload makes, but I don't
understand why. The .lreg dump is this:
;; Start of basic block 2, registers live: 5 [di] 6 [bp] 7 [sp] 16 [argp] 20
[frame]
;; Pred edg
--- Comment #17 from amylaar at gcc dot gnu dot org 2007-05-11 17:36
---
(In reply to comment #4)
> Created an attachment (id=13514)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13514&action=view) [edit]
> Draft
>
> For this last issue (which we have to tackle anyway, irrespecti
Compile this program with gcj -g:
public class jmain
{
public static void main (String[] args)
{
return;
}
}
There are five constructs with line numbers in the readelf -wi output (search
for decl_line). The class jmain, the method main, and the synthetic
constructor all have li
--- Comment #4 from kkojima at gcc dot gnu dot org 2007-05-11 14:09 ---
__sdivsi3_i4 can't be called via PLT in the first place. See the audit
trails of PR target/26636. I'd like to close this PR as WONTFIX.
--
kkojima at gcc dot gnu dot org changed:
What|Removed
--- Comment #22 from ubizjak at gmail dot com 2007-05-11 14:09 ---
Alternative patch to emit_move_change_mode() to take push_operand away from
change_address():
Index: expr.c
===
--- expr.c (revision 124612)
+++ expr.c
The following code, compiled with -g, causes an ICE on 4.2.0 RC3 (20070501) and
on my most recent 4.3.0 snapshot build (20070427):
-
namespace NS {
int x = 0;
int &ref = x;
}
using NS::ref;
-
test/ice.cc:6: internal compiler error: in reference_to_unus
--- Comment #7 from kkojima at gcc dot gnu dot org 2007-05-11 14:08 ---
The testcase fails with 3.4.6, but doesn't fail with 4.0 and later
compilers. So I'd like to close this PR as WONTFIX because 3.4 was
frozen.
--
kkojima at gcc dot gnu dot org changed:
What|Remov
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-11 13:16 ---
*** This bug has been marked as a duplicate of 30282 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-11 13:16 ---
*** Bug 31898 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pault at gcc dot gnu dot org 2007-05-11 13:13 ---
(In reply to comment #6)
> So I suspect that the problem lies in the interfacing around
> gfc_conv_function_call but I just don't see it yet.
Indeed this is the case:
In Tobias' #5, changing the declaration for 'wor
--- Comment #4 from pcarlini at suse dot de 2007-05-11 12:50 ---
Added for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from paolo at gcc dot gnu dot org 2007-05-11 12:49 ---
Subject: Bug 31852
Author: paolo
Date: Fri May 11 11:49:29 2007
New Revision: 124617
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124617
Log:
2007-05-11 Paolo Carlini <[EMAIL PROTECTED]>
PR other/
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-11 12:48 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #11 from pault at gcc dot gnu dot org 2007-05-11 12:47 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #10 from pault at gcc dot gnu dot org 2007-05-11 12:47 ---
Subject: Bug 30876
Author: pault
Date: Fri May 11 11:46:47 2007
New Revision: 124616
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124616
Log:
2007-05-11 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/3
--- Comment #5 from pault at gcc dot gnu dot org 2007-05-11 12:43 ---
Subject: Bug 30878
Author: pault
Date: Fri May 11 11:42:56 2007
New Revision: 124615
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124615
Log:
2007-05-11 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/30
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-11 12:09 ---
This gives the correct result:
pure integer function lensum (words, sep)
character (len=*), intent(in):: words(:), sep
lensum = (size (words)-1) * len (sep) + sum (len_trim (words))
end function
module ut
gcc accesses elements of a stack-frame after having destructed it.
Source-File:
---
typedef unsigned char uint8;
typedef unsigned short uint16;
typedef unsigned long uint32;
#define completeHeaderCRC(nHeaderCRC) \
--- Comment #5 from manu at gcc dot gnu dot org 2007-05-11 11:38 ---
(In reply to comment #4)
> So obviously it knows, at the level of the code generator, it's just a
> question
> of propagating that information back to the frontend.
I wrote: "yes, as far as GCC knows when it emits the
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-05-11 09:52
---
Actually shouldn't has_volatile_ops be set? I am thinking something is not
setting that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31797
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-05-11 09:34
---
Instead of inventing your own variant you can add an additional flag
OEP_SAME_SIDEEFFECTS or such to operand_equal_p. I wouldn't have a problem
with that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31797
--- Comment #3 from madcoder at debian dot org 2007-05-11 09:32 ---
Subject: Re: Please provide an "inout" attribute for function parameters.
On Thu, May 10, 2007 at 10:00:51PM -, pinskia at gcc dot gnu dot org wrote:
> --- Comment #2 from pinskia at gcc dot gnu dot org 2007-0
--- Comment #2 from raeburn at raeburn dot org 2007-05-11 08:05 ---
Subject: Re: bad warning converting qualified void* to qualified array pointer
On May 10, 2007, at 19:00, pinskia at gcc dot gnu dot org wrote:
> I think only "void*" can be done with an implicat cast so we go
> from
76 matches
Mail list logo
