--- Comment #7 from dorit at il dot ibm dot com 2006-11-17 06:46 ---
(In reply to comment #6)
> This patch should fix the problem:
indeed it does, thanks!
are you going to submit it to mainline?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29779
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #2 from vapier at gentoo dot org 2006-11-17 06:24 ---
ideally this shouldnt have happened since the only things added between
4.1.1-r1 and 4.1.1-r2 were patches cut from the gcc-4.1 branch to address
specific PR's in gcc-4.1.1 ... but yes, this is something that should be
ha
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-11-17 05:15
---
This also compiles fine or you can use -fno-range-check
SUBROUTINE ACFI(X,ARG,VAL,Y,NDIM,EPS,IER)
REAL(KIND=8) Y
IF(Q3)11,12,11
11 Y=P3/Q3
12 Y=1.E75_8
END
This is not a gfortran bu
--- Comment #13 from sergstesh at yahoo dot com 2006-11-17 02:23 ---
(In reply to comment #11)
> I'm only a bug master and don't do any work on the compiler anyway, so my
> say isn't worth much, but here's my take:
>
> You propose that you can give us 15,000 lines of obfuscated code thr
--- Comment #12 from bangerth at dealii dot org 2006-11-17 02:12 ---
(In reply to comment #11)
> down, or to make the code significantly slower. Typically, the bug reports
^^ smaller, sorry W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #11 from bangerth at dealii dot org 2006-11-17 02:09 ---
I'm only a bug master and don't do any work on the compiler anyway, so my
say isn't worth much, but here's my take:
You propose that you can give us 15,000 lines of obfuscated code through which
we will have to dig ou
--- Comment #10 from sergstesh at yahoo dot com 2006-11-17 02:03 ---
(In reply to comment #9)
> (In reply to comment #8)
> > Please see
> >
>
> Can you try the patch mentioned in:
> http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01005.html
>
> (I am about to submit a new version of the
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-11-17 01:45 ---
(In reply to comment #8)
> Please see
>
Can you try the patch mentioned in:
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01005.html
(I am about to submit a new version of the patch but it does not change
functiona
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-11-17 01:41
---
*** Bug 29875 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-17 01:41 ---
*** This bug has been marked as a duplicate of 26504 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from sergstesh at yahoo dot com 2006-11-17 01:27 ---
Please see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29874
- another proof that gcc-3.4.6 generates better SSE code than gcc-4.1.1, and
the
proof uses only widely available and well known GPL'ed code.
--
http://
The build of gcc-4.1.1 for the avr platform on an x86_64 fails.
../configure --prefix=$PREFIX --target=avr --enable-languages=c --disable-nls
--disable-libssp --with-dwarf2
make
/root/avr_toolchain/gcc-4.1.1/obj-avr/./gcc/xgcc
-B/root/avr_toolchain/gcc-4.1.1/obj-avr/./gcc/ -B/usr/local/avr/avr/bi
Hello,
this is in a sense continuation of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
, the discussion on performance.
Here I'll present performance numbers obtained with widely available GPL'ed
code - fftw-3.1.2.
I did the following:
1) built gcc-3.4.6;
2) ran 10 times this command lin
--
jbuck at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29129
--
jbuck at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25438
--- Comment #5 from geoffk at gcc dot gnu dot org 2006-11-17 00:04 ---
I mean, see rejects-valid example in bug 29873.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7221
--- Comment #2 from geoffk at gcc dot gnu dot org 2006-11-17 00:04 ---
Yes, this is a duplicate of 7221 as well. (This is the rejects-valid case.)
*** This bug has been marked as a duplicate of 7221 ***
--
geoffk at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from geoffk at gcc dot gnu dot org 2006-11-17 00:04 ---
*** Bug 29873 has been marked as a duplicate of this bug. ***
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
-
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||patch
Known to fail||4.1.2 4.2.0
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.2 |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
--- Comment #3 from geoffk at gcc dot gnu dot org 2006-11-16 23:47 ---
See rejects-valid example in 29356.
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from geoffk at gcc dot gnu dot org 2006-11-16 23:46 ---
Yes, it definitely is. Thank you!
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-16 22:15 ---
This is a gentoo specific bug since it worked in one version of gentoo's 4.1.1
but did not in another. Also this works fine for me with the trunk as of
today.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-16 22:13 ---
I think this is really a dup of bug 7221.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29873
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
CC||aldot at gcc dot gnu dot org
AssignedTo|unassigned at gcc dot g
GCC rejects this code:
template struct pp
{
static void (*the_p)();
};
template void (* pp::the_p )() = p;
typedef struct
{
static void f() { }
struct pp mypp;
} f_struct;
void g()
{
pp::the_p = 0;
}
with
t9.cc:10: error: '::f' is not a valid template argument for
type 'void (*)()
Problem occurs when using gdb. All works fine with GNU Fortran 95 (GCC) 4.1.1
(Gentoo 4.1.1-r1) but not with GNU Fortran 95 (GCC) 4.1.1 (Gentoo 4.1.1-r2).
(I'm assuming the bug was not introduced by Gentoo.) Get failure like this
test.f
i = 1
print '(''i='', i1)', i
end
gfortra
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-16 21:46 ---
You should look at the stack limit which is set by either ulimit or limit
depending on which shell you use.
This is not a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-11-16 21:34
---
Fixed in 4.1.2 and later.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2006-11-16 21:30
---
Subject: Bug 26306
Author: ebotcazou
Date: Thu Nov 16 21:30:22 2006
New Revision: 118902
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118902
Log:
PR middle-end/26306
* gimplify.c (gimpl
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-11-16 21:27
---
Subject: Bug 26306
Author: ebotcazou
Date: Thu Nov 16 21:27:32 2006
New Revision: 118901
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118901
Log:
PR middle-end/26306
* gimplify.c (gimpl
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2006-11-16 21:25
---
Subject: Bug 26306
Author: ebotcazou
Date: Thu Nov 16 21:25:16 2006
New Revision: 118900
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118900
Log:
PR middle-end/26306
* gimplify.c (gimpl
If the following tiny program is built, the resulting executable will seg fault
upon the construction of a.
class a {
public:
a() {}
~a() {}
char c[(8*1024*1024)];
};
int main(void) {
a _a;
return 0;
}
I've got this to occur in Suse Enterprise 10 32-bit, but g
--- Comment #2 from burnus at gcc dot gnu dot org 2006-11-16 19:49 ---
Created an attachment (id=12632)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12632&action=view)
ACFI.FOR
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29870
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-16 19:43 ---
If we change "12 Y=1.E75" to "12 Y=1.E7" we don't get an extra error.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
SUBROUTINE ACFI(X,ARG,VAL,Y,NDIM,EPS,IER) ACFI 730
IF(Q3)11,12,11
ACFI1320
11 Y=P3/Q3
ACFI1330
12 Y=1.E75
Eric Noulard wrote:
I shall maintain
an HW/SW configuration
running Linux 2.2.14 / glibc 2.1.2 / LinuxThread 0.8
I have a C++ application compiled using gcc 2.95.2
which has several thread that may throw exception.
I experience weird and not 100% repeatable mis-behaviour of
the application whic
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-11-16 17:14
---
Subject: Bug 29788
Author: pinskia
Date: Thu Nov 16 17:14:27 2006
New Revision: 118897
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118897
Log:
2006-11-16 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #5 from patchapp at dberlin dot org 2006-11-16 17:10 ---
Subject: Bug number PR29837
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01186.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-16 16:38 ---
This is a bug in your instation of GMP/MPFR. It is causing gfortran to crash.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from Jean-pierre dot vial at wanadoo dot fr 2006-11-16
15:36 ---
(In reply to comment #1)
> This is because of the C99 inline changes and your glibc.
>
>
> Please provide your stdlib.h header and/or glibc
> version.
>
glibc-2.4-31.1
(Suse/Novell 10.1, x86_64)
--
--- Comment #7 from jakub at gcc dot gnu dot org 2006-11-16 15:30 ---
Testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unass
--- Comment #3 from Jean-pierre dot vial at wanadoo dot fr 2006-11-16
15:27 ---
Created an attachment (id=12631)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12631&action=view)
stdlib.h and bits/stdlib.h Linux Suse 10.1 amd64
from linux Suse/Novell 10.1, amd64 version
--
h
--- Comment #2 from mkuvyrkov at gcc dot gnu dot org 2006-11-16 15:20
---
The patch for this bug was posted in
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01138.html
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from jpvial at nerim dot net 2006-11-16 15:19 ---
Subject: Re: building libgfortran fails because of
multiple definitions gcc-4.3-2006
rguenth at gcc dot gnu dot org wrote:
> --- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-16 11:50
> ---
> This
--- Comment #6 from mkuvyrkov at gcc dot gnu dot org 2006-11-16 15:17
---
Fixed by the above commits.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2006-11-16 15:11
---
Subject: Bug 29201
Author: mkuvyrkov
Date: Thu Nov 16 15:10:57 2006
New Revision: 118893
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118893
Log:
2006-11-16 Maxim Kuvyrkov <[EMAIL PROTECTED]>
--- Comment #6 from jakub at gcc dot gnu dot org 2006-11-16 14:45 ---
This has nothing to do with overflows, there are none.
Here is a simplified testcase:
extern void *foo1 (void);
extern void foo2 (void);
extern void foo3 (void *, void *);
extern int foo4 (void);
void
bar (void)
{
--- Comment #2 from rearnsha at gcc dot gnu dot org 2006-11-16 14:16
---
(In reply to comment #0)
> cstore patterns are recognized by genopinit, but
> cause a compiler crash their presence influences code generation.
>
Cstore operations should now work after the patch I committed yest
I shall maintain
an HW/SW configuration
running Linux 2.2.14 / glibc 2.1.2 / LinuxThread 0.8
I have a C++ application compiled using gcc 2.95.2
which has several thread that may throw exception.
I experience weird and not 100% repeatable mis-behaviour of
the application which is hogging all CPU-
--- Comment #2 from jzhang918 at gmail dot com 2006-11-16 13:44 ---
I narrowed the cause to this change
2006-06-04 Mark Mitchell <[EMAIL PROTECTED]>
PR c++/27819
* decl.c (cp_finish_decl): Process initializers for static data
members with non-dependent initial
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-11-16 13:08
---
Ping. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25514
I'm trying to run Tomcat 5.5 with gij. It tries to load a log manager through
the java.util.logging.manager property. Apparently the class loading code in
java.util.logging.LogManager fails to load the correct class, even though it is
on the classpath. The exact same invocation with Sun JDK works c
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-11-16 12:53 ---
Well, for integers i < 0x7fff is equal to i != 0x7fff as 0x7fff is
the most positive number, any other bit-pattern will be less than that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29868
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2006-11-16 12:25
---
Subject: Bug 29391
Author: fxcoudert
Date: Thu Nov 16 12:25:11 2006
New Revision: 11
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=11
Log:
PR fortran/29391
PR fortran/29489
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-11-16 12:25
---
Subject: Bug 29489
Author: fxcoudert
Date: Thu Nov 16 12:25:11 2006
New Revision: 11
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=11
Log:
PR fortran/29391
PR fortran/29489
--- Comment #3 from michael dot chapman at cortus dot com 2006-11-16 11:52
---
Subject: Re: Incorrect code generated for comparison
rguenth at gcc dot gnu dot org wrote:
> --- Comment #2 from rguenth at gcc dot gnu dot org 2006-11-16 11:42
> ---
> This is invalid. Adding 0x
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-16 11:50 ---
This is because of the C99 inline changes and your glibc.
2006-11-07 Richard Guenther <[EMAIL PROTECTED]>
* inclhack.def (glibc_c99_inline_2): Adjust for glibc 2.3
systems.
* fixincl.x: Re
--- Comment #8 from patchapp at dberlin dot org 2006-11-16 11:50 ---
Subject: Bug number PR29122
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01140.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-11-16 11:42 ---
This is invalid. Adding 0x1001 to 7 * 0x1001 invokes undefined
behavior
(so you get the wrapped result, which is negative and you abort).
--
rguenth at gcc dot gnu dot org changed:
What|R
--- Comment #1 from michael dot chapman at cortus dot com 2006-11-16 11:24
---
Created an attachment (id=12630)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12630&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29868
Incorrect code is generated for the following program which I believe should
finish with "return 0" and not abort.
This was compiled with
gcc test.c
(no options).
I believe this bug is also present in gcc 4.0.3
int f(int x) __attribute__((noinline));
int f(int x)
{
if (x < 0)
abor
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-16 09:54 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
linking libgfortran fails becaus of multiple definitions.
Here are le last lines of error messages. there are several hundred such lines
/usr/include/stdlib.h:342: multiple definition of `strtoul'
.libs/environ.o:/usr/include/stdlib.h:342: first defined here
.libs/in_unpack_generic.o: In function
/bin/sh ../.././libgfortran/mk-kinds-h.sh
Here is the last message displayed by make:
'/home/jp/src/gcc-4.2-20061114/host-x86_64-unknown-linux-gnu/gcc/gfortran
-B/home/jp/src/gcc-4.2-20061114/host-x86_64-unknown-linux-gnu/gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown
In Funktion expand_float the libcall generated for a conversion from unsigned
long long to float gets a wrong EQUIV note. See line optabs.c:4712 in the
4.3-2006 snapshot. The equiv note is set to gen_rtx_FLOAT regardless of the
unsignedp flag. When that flag is set, it should be a gen_rtx_UNSIG
--- Comment #4 from pault at gcc dot gnu dot org 2006-11-16 08:01 ---
This is due to a trivial error in:
Index: /svn/trunk/gcc/fortran/interface.c
===
*** /svn/trunk/gcc/fortran/interface.c (revision 118704)
--- /svn/trunk
69 matches
Mail list logo
