While Looking into PR 21485, I noticed this. This might come up more with the
array references for pointers patch.
Testcase:
typedef long dtype;
typedef dtype longarray[];
int g (longarray *array1, unsigned long i, dtype j)
{
if ((*array1)[i] < (*array1)[i + 1])
++i;
if (j < (*array1)[i
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-03-10 04:41
---
Hmm, I see a missed optimization here (I want to say a PRE one too).
D.1521_32 = k_4 * 4;
D.1525_37 = (long int *) D.1521_32;
D.1526_38 = D.1525_37 + array_9;
D.1527_39 = D.1526_38 + 4B;
# VUSE ;
D.1
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-03-10 03:23
---
Subject: Bug 26499
Author: jvdelisle
Date: Fri Mar 10 03:23:28 2006
New Revision: 111925
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111925
Log:
2006-03-09 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-03-10 03:15
---
Subject: Bug 26499
Author: jvdelisle
Date: Fri Mar 10 03:15:36 2006
New Revision: 111924
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111924
Log:
2006-03-09 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-10 02:52 ---
Use --disable-multilib.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I've been trying to build the official 4.1.0 release on my G3 and G4 MacOS
10.4.5 systems with the configure command:
$ ../gcc-4.1.0/configure --prefix=/Users/malcolmp/prefix/gcc-4.1-world
This eventually fails when trying to build libstdc++-v3. The last few lines of
output are:
---
--- Comment #9 from dtemirbulatov at gmail dot com 2006-03-10 02:31 ---
s/retested on x86_86/retested on another x86_86
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21169
--- Comment #8 from dtemirbulatov at gmail dot com 2006-03-10 02:25 ---
>I have noticed a few regressions with that patch on x86_86.
those regressions were due to a linux kernel problem, retested on x86_86 target
and no regressions observed
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #10 from sayle at gcc dot gnu dot org 2006-03-10 01:26 ---
Subject: Bug 26524
Author: sayle
Date: Fri Mar 10 01:26:27 2006
New Revision: 111921
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111921
Log:
PR tree-optimization/26524
* tree-scalar-evolut
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2006-03-10
01:25 ---
Subject: Re: Default path for libgcc_s.sl is build directory
> > Attached. The diff is against libtool in binutils as about July 28, 2005.
>
> Similar changes have entered both branch-1-5 and HEAD Libto
--- Comment #14 from tromey at gcc dot gnu dot org 2006-03-10 00:48 ---
I checked in a patch using memcpy and memcmp.
This didn't yield as dramatic a speedup for me, but did do ok.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from tromey at gcc dot gnu dot org 2006-03-10 00:39 ---
Subject: Bug 23495
Author: tromey
Date: Fri Mar 10 00:39:49 2006
New Revision: 111919
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111919
Log:
PR libgcj/23495:
* java/lang/natString.cc (_Jv
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-03-10 00:39 ---
Subject: Re: [4.2 Regression] ICE in in
add_virtual_operand
On Thu, 2006-03-09 at 23:58 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-09 2
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-09 23:58 ---
Forgot to say we also get the following NOTEs in the copyprop dump:
NOTE: no flow-sensitive alias info for rv.0_2 in # VUSE ;
D.2364_4 = rv.0_2->d;
NOTE: no flow-sensitive alias info for rv.0_2 in # VUSE ;
D.2364
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-03-09 23:31 ---
Subject: Re: [4.2 Regression] ICE in in
add_virtual_operand
On Thu, 2006-03-09 at 22:54 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-09 2
On Thu, 2006-03-09 at 22:54 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-09 22:54
> ---
> The difference between copyprop and before is the following.
> Before:
> rv.0_3 = rv.0_2;
> # VUSE ;
> D.1900_4 = rv.0_3->d;
>
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-09 22:54 ---
The difference between copyprop and before is the following.
Before:
rv.0_3 = rv.0_2;
# VUSE ;
D.1900_4 = rv.0_3->d;
After:
rv.0_3 = rv.0_2;
# VUSE ;
D.1900_4 = rv.0_2->d;
--
http://gcc.gnu.org/bugzil
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-09 22:52 ---
Removing "throw ()" will also cause the code to be ICE'd and also with the C
front-end now too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from wotte at dre dot vanderbilt dot edu 2006-03-09 22:44
---
In some cases, this warning can also be impossible to address and may be
buggy/erroneous. Consider the following example:
struct A
{
A ();
};
struct B : virtual A
{
B ();
};
struct C : virtual
--- Comment #1 from mueller at gcc dot gnu dot org 2006-03-09 22:40 ---
reduce-min5.ii: In function ‘void kjs_strtod()’:
reduce-min5.ii:12: warning: ‘e1’ is used uninitialized in this
function
reduce-min5.ii:8: internal compiler error: in add_virtual_operand, at
tree-ssa-operands.c:979
P
following testcase ICEs with >= -O2 for a few days now:
=== Cut ===
extern int *__errno_location (void) throw () __attribute__ ((__const__));
typedef union {
double d;
unsigned L[2];
} U;
void kjs_strtod()
{
int rv,e1;
unsigned z;
if (e1 > 308) { ovfl: (*__errno_loca
--- Comment #27 from wilson at specifix dot com 2006-03-09 22:21 ---
Subject: Re: [4.2 Regression] Build failure: undefined
symbol __floatunsitf
fxcoudert at gcc dot gnu dot org wrote:
> Adding the maintainers of all those in Cc list. I don't know what
> US_SOFTWARE_GOFAST, but from t
--- Comment #3 from langel at redhat dot com 2006-03-09 22:09 ---
Fixed.
most widgets are fixed accordingly. I will be fixing the rest and creating
mauve tests for all AWT widgets.
--
langel at redhat dot com changed:
What|Removed |Added
--
We were modifying libjava/java/lang/Character.java and rebuilding, and
libgcj-4.2.0.jar wasn't being rebuilt. I didn't try to figure out why but I
thought I'd file the issue since others have seen it too.
--
Summary: libgcj-4.2.0.jar not rebuilt after a source file change
"make install" in libgcj is currently very slow compared to "make install-exec"
because of the number of CNI headers and how they are installed, that is one
install command per header. This should be sped up so that we can simply use
"make install" on rebuilds since this is most likely what the un
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-09 21:17 ---
This looks like another HWI being 32bit bug :( which is why it works on x86_64
with -m32.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-09 21:12 ---
Confirmed, reduced testcase:
unsigned char m_in4;
unsigned long long block_selfcycle3_v_L7_253_()
{
return ((long long)((m_in4 & 0x80) != 0)) << 7;
}
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #7 from tromey at gcc dot gnu dot org 2006-03-09 20:27 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-09 20:25 ---
Subject: Bug 24461
Author: tromey
Date: Thu Mar 9 20:25:23 2006
New Revision: 111871
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111871
Log:
PR libgcj/24461:
* java/util/zip/InflaterInputS
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-09 20:24 ---
But I can reproduce it on a real i686 machine. Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-09 20:22 ---
Subject: Bug 24461
Author: tromey
Date: Thu Mar 9 20:21:58 2006
New Revision: 111870
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111870
Log:
PR libgcj/24461:
* java/util/zip/InflaterInputS
--- Comment #6 from geoffk at gcc dot gnu dot org 2006-03-09 20:19 ---
darwin5.5 is not a viable host OS for GCC; you need to upgrade. It has, at
least, bugs in mmap. I think at this point you probably need Mac OS
10.3/darwin7.0 or later, but it's likely that 10.2 will work fairly well
--- Comment #3 from dnovillo at gcc dot gnu dot org 2006-03-09 20:07
---
> Diego, is this still an issue on mainline? I can look into the runtime error,
> though.
>
Works now. I can live with the LD_LIBRARY_PATH problem. Though I don't
remember how we handle other libraries like li
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-09 19:56 ---
This works for me on x86_64-linux with -m32.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
--- Comment #2 from apl at alum dot mit dot edu 2006-03-09 19:49 ---
/tools/linux/gcc-4.1.0/bin/g++ -c ice.i
tmp.f_00.cxx: In member function 'void
CarbonDesignSystems__design::c_top::f_$block_selfcycle3_v_L7_253_()':
tmp.f_00.cxx:26432: error: unrecognizable insn:
(insn 176 175
--- Comment #1 from apl at alum dot mit dot edu 2006-03-09 19:43 ---
Created an attachment (id=11014)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11014&action=view)
test causing ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
Test case is huge (26KLOC), but only takes a fraction of a second to compile
and die.
Just compile with
g++ -c ice.i
I'll append the test case momentarily
--
Summary: ICE in extract_insn, at recog.c:2084
Product: gcc
Version: 4.1.0
Status: U
--- Comment #12 from dnovillo at redhat dot com 2006-03-09 19:28 ---
Subject: Re: ICE (segfault) on C++ OpenMP code
On 03/09/06 14:17, pinskia at gcc dot gnu dot org wrote:
> If you had written a status on this bug before I closed it as a dup,
> I would not have closed it as a dup bec
--- Comment #12 from tromey at gcc dot gnu dot org 2006-03-09 19:17 ---
Fair enough. I'm handling this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-03-09 19:17
---
(In reply to comment #10)
> If you are so keen on closing PRs, close 26076 as a duplicate of this one.
If you had written a status on this bug before I closed it as a dup, I would
not have closed it as a dup becau
--- Comment #10 from dnovillo at redhat dot com 2006-03-09 19:10 ---
Subject: Re: ICE (segfault) on C++ OpenMP code
On 03/09/06 14:03, pinskia at gcc dot gnu dot org wrote:
> Then there are two issues, one for the reduced testcase which is PR 26076 and
> another issue. But please don
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-03-09 19:03 ---
(In reply to comment #8)
> Andrew, please do not close bugs if you do not understand the problem. You
> obviously have not even tried to understand the problem. This PR is related
> to
> 26076 but it is *not* a du
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-09 19:02 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--- Comment #8 from dnovillo at gcc dot gnu dot org 2006-03-09 19:01
---
Andrew, please do not close bugs if you do not understand the problem. You
obviously have not even tried to understand the problem. This PR is related to
26076 but it is *not* a duplicate.
The patch that I deve
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-09 18:53 ---
A little simplier testcase is:
struct A
{
~A();
};
void foo()
{
#pragma omp parallel
A a, b;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26076
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-09 18:49 ---
*** Bug 26084 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-03-09 18:49 ---
PR 26076 has a reducer testcase and I can reduce the testcase in here into that
one.
*** This bug has been marked as a duplicate of 26076 ***
--
pinskia at gcc dot gnu dot org changed:
What|Remov
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-09 18:43 ---
Confirmed, reduced testcase:
int t;
void search()
{
#pragma omp parallel for
for (int i = 0; i < 1000; ++i) try {
mm::print(t);
}catch(...){}
}
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-09 18:33 ---
Also happens on the mainline now. Reducing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-09 18:31 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-09 18:27 ---
Confirmed on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from _talyn_ at web dot de 2006-03-09 18:06 ---
Allocating the CVectorWrap variable dynamically removes the undefined reference
to TTypeWrapper::~TTypeWrapper. I guess that's because it is virtual, and a
dynamic instance of CVectorWrap will call CVectorWrap::~CVectorWrap v
--- Comment #14 from law at redhat dot com 2006-03-09 18:02 ---
Subject: Re: [4.2 Regression] three testsuite
failures in gcc.dg/tree-ssa/
On Thu, 2006-03-09 at 17:19 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #13 from pinskia at gcc dot gnu dot org 2006
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-03-09 17:19
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-09 16:49 ---
I don't think this is a bug. We are inlining CVectorWrap::~CVectorWrap into
main which causes the reference to TTypeWrapper::~TTypeWrapper and
TTypeWrapper::~TTypeWrapper is not used in instance.cc at all so it is n
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from _talyn_ at web dot de 2006-03-09 16:33 ---
Created an attachment (id=11013)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11013&action=view)
Test case consisting of a Makefile and three source files
The makefile runs a compilation and linking with -O2 and -O3,
On various architectures all the 4.0.X versions of g++ fail to properly
instanciate some members of a class template if optimisation is set to -O3. For
-O2 everything is fine.
A test case will be attached.
Versions tested:
g++ 4.0.3 20060212 (prerelease) (Debian 4.0.2-9) i686-pc-linux-gnu
g++
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-03-09 15:32
---
Thanks Roger!
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #14 from martin at mpa-garching dot mpg dot de 2006-03-09
15:11 ---
(In reply to comment #13)
> If it is DIRECT I/O you are doing, this is a different story and record sizes
> are fixed length.
Yes, that's what I'm talking about. Consider:
PROGRAM TESTRECL
IM
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-03-09 14:56
---
If you are doing sequential writes, the write truncates the file. So if you
write out 8 bytes where there were 4 before, it just overwrites and extends the
file length if necessary. All data after the last writ
--- Comment #7 from sayle at gcc dot gnu dot org 2006-03-09 14:54 ---
Subject: Bug 26561
Author: sayle
Date: Thu Mar 9 14:54:11 2006
New Revision: 111862
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111862
Log:
2006-03-09 Roger Sayle <[EMAIL PROTECTED]>
Eric Bot
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-09 14:22 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-09 14:21 ---
Reduced testcase:
int dev_alloc_name()
{
int i = 0;
f(&i);
if (__builtin_constant_p(i))
g();
}
--
This is fixed in 4.0.0 and above by the tree-ssa merge and cannot be invoked in
4.0.0 and above because
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-09 14:03 ---
If you want to use r5 the correct way is to do:
register int *foo asm("r5") = 0;
void t1(void)
{
*foo = 1;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26619
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-09 14:02 ---
local register variables don't do what you think they do. Hint they only work
with inline-asm.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dave dot mueller at gmx dot ch 2006-03-09 14:01 ---
Created an attachment (id=11011)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11011&action=view)
ARM .s file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26619
--- Comment #2 from dave dot mueller at gmx dot ch 2006-03-09 14:00 ---
Created an attachment (id=11010)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11010&action=view)
PowerPC .s file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26619
--- Comment #1 from dave dot mueller at gmx dot ch 2006-03-09 13:59 ---
Created an attachment (id=11009)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11009&action=view)
PowerPC .i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26619
GCC 4.1.0 initializes another register than the one specified in the
definition.
I'm not sure it this has also something to do with bug 21596.
The same testcase built with GCC 3.4.4 is correct.
--
Summary: Compiler fails to correctly initialize global reg
variabl
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-09 13:32 ---
One more thing, 3.4.6 (which has not been announced yet but it is on the ftp
server) is the last 3.4.x release.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26616
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-09 13:28
---
*** Bug 25449 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-09 13:28 ---
*** This bug has been marked as a duplicate of 20256 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from orenskl at lipman dot co dot il 2006-03-09 11:17
---
Bug happens also on GCC 3.4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26616
--- Comment #2 from orenskl at lipman dot co dot il 2006-03-09 11:17
---
Created an attachment (id=11008)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11008&action=view)
bug test case
Bug happens also on GCC 3.4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26616
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-09 10:39 ---
Try a more recent release from the 3.4 series first, please. Otherwise, just
attach the preprocessed source to the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26616
--- Comment #5 from RonnyPeine at gmx dot de 2006-03-09 10:37 ---
(In reply to comment #4)
> Is there a testcase other than just compile and run nbench with
> -ftree-loop-linear?
>
Yes, see PR20256: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20256
This is just a duplicate bugreport.
--- Comment #3 from multix at gmail dot com 2006-03-09 10:22 ---
If I compile 3.4.5 using --disable-shared the problem goes away, thus it is a
problem with the shared library.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26541
GCJ allows classes in named packages to see classes in unnamed packages.
For example:
./Snafu.java
public class Snafu { }
--
./foo/Bar.java
package foo;
// import Snafu;
public class Bar
{
Snafu junk;
}
Note that GCJ accepts the
--- Comment #2 from pluto at agmk dot net 2006-03-09 10:10 ---
(In reply to comment #1)
> ooops, it's invalid c++ (returning an array) code.
>
> the better testcase is:
>
> template < typename T, std::size_t N >
> char[N]& sizer( T (&array)[N] );
>
> the `char (&)[15]` can be
--- Comment #1 from pluto at agmk dot net 2006-03-09 09:43 ---
ooops, it's invalid c++ (returning an array) code.
the better testcase is:
template < typename T, std::size_t N >
char[N]& sizer( T (&array)[N] );
the `char (&)[15]` can be returned by function.
--
http://gcc.
I get an ICE when compiling net/core/dev.o from the linux kernel 2.6.11.6, this
does not happen if I remove the "-Os" option or when compiling for ARM (not
thumb)
The dev.i file is 510K, how do I upload it ?
output :
Reading specs from /cygdrive/c/gccarm/lib/gcc/arm-elf/3.4.0/specs
Configured wi
#include
template < typename T, std::size_t N >
char[N] sizer( T (&array)[N] ); <=== gcc error:
expected unqualified-id before ‘[’
token
int main()
{
int t[15];
printf("%Zd\n", sizeof(sizer(t)));
return 0;
}
--
Summary: compute size of
84 matches
Mail list logo
