--- Comment #4 from duncan_roe at acslink dot net dot au 2006-06-25 05:53
---
HJ's patch can still be applied to expect-5.43 (but I wasted some time before I
realised you must use --ignore-whitespace). This *does* reduce the number of
errors reported, but one error remains:
FAIL: gcc.d
--- Comment #14 from duncan_roe at acslink dot net dot au 2006-06-25 05:31
---
This problem is still displayed at gcc-4.1.1 using expect 5.43 and tcl 8.4.13.
The patch above requires that one uses patch's --ignore-whitespace option
because tab/space information is no longer present. See
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-24 23:53 ---
*** Bug 28159 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 2006-06-24 23:53 ---
*** This bug has been marked as a duplicate of 28058 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from vapier at gentoo dot org 2006-06-24 23:19 ---
Created an attachment (id=11742)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11742&action=view)
PR28159-ice.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28159
when building gdl with gcc-4.1.1 or gcc-4.2, gcc ICEs:
datatypes.cpp: In constructor 'Data_< >::Data_(const
dimension&, BaseGDL::InitType) [with Sp = SpDObj]':
datatypes.cpp:3545: internal compiler error: Segmentation fault
gcc-4.0.3 compiles the code just fine
validated on Gentoo and Debian
--- Comment #20 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-24
23:08 ---
Subject: Re: [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c
execution, -O3 -fomit-frame-pointeRO
> The transformations in the invariant motion pass look correct to me, as well
> as
> th
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-06-24 22:16
---
(In reply to comment #3)
> I believe the segfault is appropriately fixed by the following patch
I still think this patch is the right thing, and I've been looking through the
other transformational function to se
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-06-24 22:00
---
(In reply to comment #1)
> Index: config/i386/i386.md
> ===
> --- config/i386/i386.md (revision 114974)
> +++ config/i386/i386.md (working copy)
> @@
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-24 21:41 ---
Confirmed. Fix:
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 114974)
+++ config/i386/i386.md (working copy)
@@ -9913,7 +9913,7 @@
The following Fortran testcase exhibits a failure with -O(>=1) -msse:
$ cat foo.f90
subroutine yhalf(z)
complex cdexpj,z
z=cdexpj((0.d0,1.d0)*z)
end
$ gfortran -c -O3 -msse -mfpmath=sse,387 foo.f90
foo.f90: In function yhalf:
foo.f90:3: error: unrecognizable insn:
(insn 13
--- Comment #2 from schwab at suse dot de 2006-06-24 21:27 ---
You need to tell the compiler that std::map::const_iterator is a type by
prefixing it with typename.
--
schwab at suse dot de changed:
What|Removed |Added
--
--- Comment #1 from jaybny at gmail dot com 2006-06-24 21:22 ---
$ g++ -c utilities.cpp -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose --prefix=/usr
--exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --l
#include
template
int testit(const std::map & m) {
std::map::const_iterator iter = m.begin();
return 0;
}
This code does not compile using G++ on cygwin
$ g++ -c utilities.cpp
utilities.cpp: In function `int testit(const std::map,
std::allocator > >&)':
utilities.cpp:6: error
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-24 20:52 ---
Fixed in 4.2.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|
Hi,
$ cat try.cc
#include
static void foo() {
std::cout << "hello, world\n";
}
int main() {
extern void foo();
foo();
}
$ g++-4.1.0 -Wall try.cc
try.cc:3: warning: `void foo()' defined but not used
$ ./a.out
hello, world
foo() is clearly used there so why does g++ warn about it?
--- Comment #2 from rleigh at debian dot org 2006-06-24 19:21 ---
Sorry, the testcase is broken. This isn't a bug.
--
rleigh at debian dot org changed:
What|Removed |Added
---
--- Comment #1 from rleigh at debian dot org 2006-06-24 19:16 ---
Created an attachment (id=11741)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11741&action=view)
Test codecvt roundtrip from narrow->wide->narrow.
Testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28155
std::codecvt has in and out methods. These are used to convert from one
codeset to another. They return a status:
std::codecvt_base::ok || std::codecvt_base::partial
on success or success where the conversion was only partially done
std::codecvt_base::noconv
if no conversion is nec
This is not a bug (I don't think the code is legal), but surely we could do
better than this:
$ cat zero_spread_2.f90
real,allocatable :: bar(:,:),foo(:)
allocate(foo(0))
bar = spread(foo,dim=1,ncopies=1)
print *, allocated(bar)
end
$ gfortran zero_spread_2.f90 && ./a.out
T
Same goes
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-06-24 19:00
---
Don't hold your breath.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-06-24 18:24
---
Janis could you do a regression hunt with the testcase in comment #6?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-06-24 18:10
---
Subject: Bug 28081
Author: fxcoudert
Date: Sat Jun 24 18:10:47 2006
New Revision: 114972
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114972
Log:
PR fortran/28081
* resolve.c (resolve_s
--- Comment #15 from whaley at cs dot utsa dot edu 2006-06-24 18:10 ---
Hi,
Can someone tell me if anyone is looking into this problem with the hopes of
fixing it? I just noticed that despite the posted code demonstrating the
problem, and verification on: Pentium Pro, Pentium III, Pent
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-24 17:49 ---
How did you configure GCC becase having TFmode there sounds like you configured
to have 128bit long double to be default.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28150
I had some problems when I tried to compile a JNI-example from wikipedia:
http://en.wikipedia.org/wiki/JNI
I compiled the Java-source containing the native function
with 'gcj -C' (gcc version 3.4.2 (mingw-special)):
public native void sayHello();
I passed the class-file to 'gcjh -jni' and it
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-06-24 16:06
---
Subject: Bug 23862
Author: fxcoudert
Date: Sat Jun 24 16:06:28 2006
New Revision: 114970
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114970
Log:
PR fortran/23862
* lang-specs.h (f95-cpp
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-06-24 14:54
---
> The problem appears to be caused by the change of semantics of const_binop in
> this patch:
>
> 2005-11-16 Eric Botcazou <[EMAIL PROTECTED]>
>
> * fold-const.c (const_binop): Don't constant fold the
--- Comment #6 from pault at gcc dot gnu dot org 2006-06-24 14:26 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pault at gcc dot gnu dot org 2006-06-24 14:25 ---
Subject: Bug 28118
Author: pault
Date: Sat Jun 24 14:25:24 2006
New Revision: 114965
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114965
Log:
2006-06-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #8 from steven at gcc dot gnu dot org 2006-06-24 14:20 ---
Another test case:
_Complex float b;
int
main (void)
{
_Complex float a = __FLT_MAX__;
b = __FLT_MAX__ + a;
}
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #7 from steven at gcc dot gnu dot org 2006-06-24 14:15 ---
The problem appears to be caused by the change of semantics of const_binop in
this patch:
2005-11-16 Eric Botcazou <[EMAIL PROTECTED]>
* fold-const.c (const_binop): Don't constant fold the operation
--- Comment #6 from steven at gcc dot gnu dot org 2006-06-24 14:13 ---
The code that causes this "regression" is actually in the first ever checkin of
fold-const.c (r330).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
#x27;__complex__'
$ ./cc1 --version
GNU C version 4.2.0 20060624 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE Linux).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
$
--
Summary: Diagnostic a
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-24 13:55 ---
Confirmed a regression from 4.0.2, here is a C testcase:
_Complex float b;
int main(void)
{
_Complex float a = 1.9E19;
b = 1/a;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from steven at gcc dot gnu dot org 2006-06-24 13:53 ---
Uhm, Richi is right. Ignore comment #4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
--- Comment #3 from steven at gcc dot gnu dot org 2006-06-24 13:50 ---
We ICE in fold-const.c line 1691 (r114961):
= const_binop (PLUS_EXPR,
const_binop (MULT_EXPR, r2, r2, notrunc),
const_binop (MULT_EXPR, i2, i2,
--- Comment #4 from pault at gcc dot gnu dot org 2006-06-24 13:04 ---
Subject: Bug 28118
Author: pault
Date: Sat Jun 24 13:04:37 2006
New Revision: 114964
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114964
Log:
2006-06-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-06-24 11:40 ---
So the fix is simply to watch for failed folding from const_binop in itself.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-24 11:37 ---
Confirmed.
We have
Breakpoint 3, const_binop (code=RDIV_EXPR, arg1=0xa7bc6708, arg2=0xa7bc6690,
notrunc=0) at /home/richard/src/trunk/gcc/fold-const.c:1691
(gdb) call debug_generic_expr (arg1)
__complex__ (1.0e
--- Comment #6 from pault at gcc dot gnu dot org 2006-06-24 10:55 ---
The patch did not apply to 4.1, so I will have to submit a back port.
Watch this space!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
The following Fortran source cause an ICE in fold-const.c (indirectly called
from within tree-ssa-propagate.c) when compiling at -O1 or higher. We have
reasons to believe it's not front-end dependent (same problem happens with g95,
which is significantly different from gfortran), but I can't make a
--- Comment #1 from pluto at agmk dot net 2006-06-24 09:23 ---
Created an attachment (id=11740)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11740&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28150
$ gcc lib_delegate.i -c -Wall -O
lib_delegate.c: In function 'PackDelegateInvokeParams':
lib_delegate.c:273: error: insn does not satisfy its constraints:
(insn 205 104 105 9 (set (mem/c/i:TF (pre_inc:SI (reg/v/f:SI 29 29 [orig:119
ptr ] [119])) [0 nativeFloat+0 S16 A64])
(reg:TF 45 13)) 2
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.2.0 4.1.2 |4.1.2
Known to work||4.2.0
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-06-24 08:27
---
Subject: Bug 28094
Author: fxcoudert
Date: Sat Jun 24 08:27:32 2006
New Revision: 114961
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114961
Log:
PR fortran/28094
* trans-intrinsic.c (g
--- Comment #1 from jserv at kaffe dot org 2006-06-24 07:52 ---
Created an attachment (id=11739)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11739&action=view)
Fix build errors in libjava when target = arm-elf simulation
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28149
While testing GCC on a simulator[1], there are some build errors causing the
process failed. The files are involving in:
(1) libjava/java/util/natVMTimeZone.cc
(2) libjava/classpath/native/fdlibm/mprec.c
Attachment attempts to fix the issue and drive testing GCC on simulation
continue.
[1] Refere
49 matches
Mail list logo
