--- Comment #4 from taschna at uni-muenster dot de 2006-07-31 06:32 ---
(In reply to comment #3)
Steve,
> Thanks for the patch, but I think it is only covering up the real
> problem. It's more a question of "why is it a NULL pointer?" not
> whether we can work around the NULL pointer.
--- Comment #30 from dave at hiauly1 dot hia dot nrc dot ca 2006-07-31
02:09 ---
Subject: Re: [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c
execution, -O3 -fomit-frame-pointeRO
> no, this seems correct to me. In cfglayout mode (that is used in the loop
> optimizati
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2006-07-31 02:02
---
Fixed on 4.1 and 4.2. Please accept my apologies.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-07-31 01:57
---
Subject: Bug 28335
Author: jvdelisle
Date: Mon Jul 31 01:57:25 2006
New Revision: 115837
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115837
Log:
2006-07-30 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-31 01:41 ---
I wonder if this is a memset only problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-07-31 01:36
---
Subject: Bug 28335
Author: jvdelisle
Date: Mon Jul 31 01:36:44 2006
New Revision: 115836
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115836
Log:
2006-07-30 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-07-31 01:32
---
Subject: Bug 28335
Author: jvdelisle
Date: Mon Jul 31 01:32:38 2006
New Revision: 115835
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115835
Log:
2006-07-30 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #10 from gnb at sgi dot com 2006-07-31 01:18 ---
Ian: understood and agreed.
FYI: the copyright assignment arrived in this morning's mail.
I'll need to run it past my lawyer (as I do any legal document)
but I don't expect that will take long. The bottleneck is
likely to be
--- Comment #3 from kargl at gcc dot gnu dot org 2006-07-31 00:23 ---
Andrew, I think it is a bug. The language in section 12.4.1.5 is somewhat
convoluted and the description of PRESENT() suggest that PRESENT is special.
>From 12.4.1.5:
An optional dummy argument that is not presen
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-07-31 00:15
---
Subject: Bug 28335
Author: jvdelisle
Date: Mon Jul 31 00:15:08 2006
New Revision: 115829
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115829
Log:
2006-07-30 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-07-31 00:09
---
Subject: Bug 28335
Author: jvdelisle
Date: Mon Jul 31 00:09:16 2006
New Revision: 115828
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115828
Log:
2006-07-30 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-30 23:53 ---
>From reading the error message, it looks correct as the types are different.
HJL can you first read the pointed to part of the standard and see if this is
true if so then gfortran is correct.
--
http://gcc.g
--- Comment #1 from hjl at lucon dot org 2006-07-30 23:29 ---
It is caused by
http://gcc.gnu.org/ml/fortran/2006-07/msg00115.html
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #23 from hjl at lucon dot org 2006-07-30 23:27 ---
Tonto failed to build again.
--
hjl at lucon dot org changed:
What|Removed |Added
BugsThisDependsOn|
This is extracted from Tonto in SPEC CPU 2006:
[EMAIL PROTECTED] cpu2006-465g]$ cat foo.f90
SUBROUTINE foo(p, translate)
real(kind=kind(1.0d0)), dimension(3) :: p
integer(kind=kind(1)), dimension(3), optional :: translate
if (present(translate)) p = p + translate
END SUBROUTINE
[EMAIL PR
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Summary|[4.1 only] flush() / write()|[4.2 Regression] fl
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
--- Comment #9 from steven at gcc dot gnu dot org 2006-07-30 23:12 ---
Shame on us for following the gut feeling instead of the Standard.
As Steve Kargl pointed out on the mailing list:
F95 standard, Section 9.3.5, page 143, lines 6 an 7.
Execution of a CLOSE statement specify a uni
--- Comment #1 from pbrook at gcc dot gnu dot org 2006-07-30 22:53 ---
Created an attachment (id=11976)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11976&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28547
The attached code shows a large (between 2x and 10x) increase in compile time
when compiled with -g.
With gcc head "-g -O" -ftime-report says:
symout: 14.26 (59%) usr 0.09 (24%) sys 15.35 (59%) wall
13879 kB (17%) ggc
variable tracking : 0.86 ( 4%) usr 0.03 ( 8%) sy
--- Comment #3 from kargl at gcc dot gnu dot org 2006-07-30 22:46 ---
(In reply to comment #2)
> I'm an absolute beginner in programming gfortran, but the following
> patch seems to solve this bug by inserting an if-block into the code
> in order to prevent the access to the NULL pointer
--- Comment #13 from eedelman at gcc dot gnu dot org 2006-07-30 21:38
---
Created an attachment (id=11975)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11975&action=view)
Latest version
Fixed a bunch of problems, added some documentation, and moved MOVE_ALLOC to a
file of it's o
--- Comment #3 from toa at pop dot agri dot ch 2006-07-30 21:06 ---
Subject: Re: [4.2 Regression] ./java/lang/Thread.h:31:
error: using typedef-name '_Jv_Thread_t' after 'class'
dave at hiauly1 dot hia dot nrc dot ca wrote:
> --- Comment #2 from dave at hiauly1 dot hia dot nrc dot
dave at hiauly1 dot hia dot nrc dot ca wrote:
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-07-30
20:51 ---
Subject: Re: [4.2 Regression] ./java/lang/Thread.h:31: error: using
typedef-name '_Jv_Thread_t' after 'class'
This is in include/no-threads.h.
Ah, that's co
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-07-30
20:51 ---
Subject: Re: [4.2 Regression] ./java/lang/Thread.h:31: error: using
typedef-name '_Jv_Thread_t' after 'class'
> This is in include/no-threads.h.
Ah, that's correct since I see I specified '--enable-thread
--- Comment #6 from echristo at apple dot com 2006-07-30 20:50 ---
Fixed thusly:
2006-07-30 Eric Christopher <[EMAIL PROTECTED]>
PR target/27543
* doc/extend.texi (i386 Variable Attributes): Add anchor.
(PowerPC Variable Attributes): New section.
--
echris
--- Comment #5 from echristo at gcc dot gnu dot org 2006-07-30 20:50
---
Subject: Bug 27543
Author: echristo
Date: Sun Jul 30 20:50:00 2006
New Revision: 115827
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115827
Log:
2006-07-30 Eric Christopher <[EMAIL PROTECTED]>
--- Comment #1 from andreast at gcc dot gnu dot org 2006-07-30 20:21
---
This is in include/no-threads.h.
So, we either have a posix-thread detection issue on hppa2.0w-hp-hpux11.00 or
posix threads are not supported here.
Just for the record, hppa2.0w-hp-hpux11.11 does work.
If the f
--- Comment #4 from ben at decadentplace dot org dot uk 2006-07-30 20:11
---
Works on a 2006-02-18 snapshot of 4.2
Fails on a 2005-11-24 snapshot of 4.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-30 19:05 ---
This works on the mainline. I can reproduce it on the 4.1 branch though. I
don't know if this is a regression or not.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from ben at decadentplace dot org dot uk 2006-07-30 19:02
---
This code appears to be compiled correctly with a 2006-07-21 snapshot. This
doesn't necessarily mean the underlying bug has gone away, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|./java/lang/Thread.h:31:|[4.2 Regression]
|error: using typedef-name |./ja
/xxx/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/xxx/gnu/gcc/objdir/./gcc
-nostd
inc++ -L/xxx/gnu/gcc/objdir/hppa2.0w-hp-hpux11.00/libstdc++-v3/src
-L/xxx/gnu/gc
c/objdir/hppa2.0w-hp-hpux11.00/libstdc++-v3/src/.libs
-B/opt/gnu/gcc/gcc-4.2.0/h
ppa2.0w-hp-hpux11.00/bin/ -B/opt/gnu/gcc/gcc-4.2.0/hppa2
--- Comment #1 from ben at decadentplace dot org dot uk 2006-07-30 18:46
---
Created an attachment (id=11974)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11974&action=view)
test case
Test case.
It should produce the output "Difficulty rating: Extreme (complex non-recursive
tech
I have some code that calls
memset(p, cr+1, cr*cr);
inside a loop. (Will attach this later.)
gcc 4.1.2 (snapshot from 20060715) appears to attempt to calculate cr*cr
outside the loop and then load it when needed. However, the generated code uses
the wrong register for one the multiplicands:
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-07-30 14:45 ---
Even without the volatile, it ICEs:
typedef unsigned long int ulong;
typedef struct
{
int counter;
}atomic_t;
static ulong Cversion = 0;
void
sp_cache_invalidate ()
{
atomic_t * v1 = (atomic_t *)& Cversion;
ato
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-30 14:44 ---
Confirmed (reduced C and C++ testcases:
typedef unsigned long int ulong;
typedef struct
{
volatile int counter;
}atomic_t;
static ulong volatile Cversion = 0;
void
sp_cache_invalidate ()
{
atomic_t * v1 = (atomic
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-30 14:26 ---
Oh, yes it is unrelated to that PR. In fact I think the aliasing violating
causes the problem.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #29 from rakdver at gcc dot gnu dot org 2006-07-30 14:04
---
(In reply to comment #28)
> I've been trying to figure out why we end up with the strange intialization
> for
> the
> parity loop. I see this rtl in the loop2 dump:
>
> (jump_insn 69 68 71 7 (set (pc)
>
--- Comment #3 from tbm at cyrius dot com 2006-07-30 13:59 ---
Reproducible with gcc 4.2.0 way back to 20060325. I've nothing older around
right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28544
--- Comment #2 from tbm at cyrius dot com 2006-07-30 13:55 ---
(In reply to comment #1)
> First I like to say this is violating C++ aliasing rules but that is a
> different story.
>
> Second this is most likely a dup of bug 28479.
Are you sure you got that bug number right? I'm seeing
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-30 13:53 ---
First I like to say this is violating C++ aliasing rules but that is a
different story.
Second this is most likely a dup of bug 28479.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
I get the following gcc 4.2 regression:
11031:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O2
mysql-sp_cache.cc
mysql-sp_cache.cc: In function 'void sp_cache_invalidate()':
mysql-sp_cache.cc:20: internal compiler error: in add_virtual_operand, at
tree-ssa-operands.c:1309
Please submit a
--- Comment #7 from vda dot linux at googlemail dot com 2006-07-30 13:43
---
Created an attachment (id=11973)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11973&action=view)
Random tester
Randomly chooses a/b and compares "gcc patch code" results with code which was
previously v
--- Comment #6 from vda dot linux at googlemail dot com 2006-07-30 13:38
---
Patched versus stock gcc-4.1.1 on this code
unsigned v;
void f9188_mul365384439_shift27(unsigned A) { v = A/(unsigned)1577682821; }
is:
# diff -u suboptimal-411-O2.s suboptimal-411-O2-fixed.s
--- suboptimal-
--- Comment #5 from vda dot linux at googlemail dot com 2006-07-30 13:37
---
Created an attachment (id=11972)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11972&action=view)
Test program
Compile with -O2 -S to see the assembly.
Compile with -Os and run to check the correctness.
--- Comment #4 from vda dot linux at googlemail dot com 2006-07-30 13:35
---
Created an attachment (id=11971)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11971&action=view)
Use alternative algorithm if it gives better results
New algorithm lives in separate function gcc_fastdiv
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-07-30 13:31
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #11 from sayle at gcc dot gnu dot org 2006-07-30 13:22 ---
Subject: Bug 28473
Author: sayle
Date: Sun Jul 30 13:21:59 2006
New Revision: 115821
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115821
Log:
PR middle-end/28473
Backport from mainline.
--- Comment #8 from rsandifo at gcc dot gnu dot org 2006-07-30 10:56
---
Subject: Bug 28126
Author: rsandifo
Date: Sun Jul 30 10:56:07 2006
New Revision: 115819
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115819
Log:
gcc/
2006-07-25 Atsushi Nemoto <[EMAIL PROTECTED]>
--- Comment #10 from steven at gcc dot gnu dot org 2006-07-30 10:52 ---
Please ping the patch. Add DJ Delorie to the CC: list, he is a build system
maintainer. You can find his email in MAINTAINERS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
I've logged a binutils bug for this as bug id 2979. There is more info with
the binutils bug report. I've been able to build older snapshots on this
system.
[EMAIL PROTECTED] objdir]#
../gcc-4.2-20060513/configure --prefix=/usr/local/gcc-4.2 --enable-shared --enable-threads=posix
--disable-ch
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-30 10:28 ---
Can you show the command line which you used to invoke gcc?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-30 10:24 ---
*** Bug 28539 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-07-30 10:24 ---
*** This bug has been marked as a duplicate of 25863 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-07-30 09:53 ---
*** Bug 28543 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-07-30 09:53 ---
This is the whole point of -ftemplate-depth is to limit the depth so you don't
run into an huge depth.
Yes you code is defined, just a huge depth.
*** This bug has been marked as a duplicate of 27052 ***
--
pin
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-30 09:49 ---
You want:
template
typename A::blah A::foo()
{
return 0;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
$ cat fac.cpp
#include
template struct f;
template<> struct f<0> { enum { value = 1 }; };
template<> struct f<1> { enum { value = 1 }; };
template struct f { enum { value = n * f::value }; };
int main()
{
printf("%u\n", f<-10>::value);
return 0;
}
$ LANG=en_EN g++ -ftemplate-
--- Comment #2 from henrik at johome dot net 2006-07-30 09:15 ---
*** Bug 28541 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28542
--- Comment #1 from henrik at johome dot net 2006-07-30 09:15 ---
*** This bug has been marked as a duplicate of 28542 ***
--
henrik at johome dot net changed:
What|Removed |Added
--
--- Comment #1 from henrik at johome dot net 2006-07-30 09:09 ---
Created an attachment (id=11970)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11970&action=view)
Source of the file that triggers the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28542
I got a segmentation fault when trying to compile the GDAL library.
Here is the result of compiling the preprocessed source:
gdal_crs.c: In function 'calccoef':
gdal_crs.c:700: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See
I got a segmentation fault when trying to compile the GDAL library.
Here is the result of compiling the preprocessed source:
gdal_crs.c: In function 'calccoef':
gdal_crs.c:700: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See
/*
In the code snippet below the definition of foo fails with the following error
foo.cc:11: error: expected constructor, destructor, or type conversion before
A
But the definition of foo2 triggers no error. I think both should be compiled
but it might be a language idiosyncrasy. Thanks.
*/
templ
65 matches
Mail list logo
