--- Comment #32 from choe dot hwanjin at gmail dot com 2006-12-14 07:30
---
(From update of attachment 12801)
Something similar happens when I use GCC option -fvisibility=hidden.
I made a DSO which uses basic_string<>.
And the main function created a basic_string instance with default
--- Comment #31 from choe dot hwanjin at gmail dot com 2006-12-14 07:29
---
Created an attachment (id=12801)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12801&action=view)
basic_string test code with visibility option
Something similar happens when I use GCC option -fvisibility
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-12-14 07:05 ---
(In reply to comment #5)
> one of the vectorizer testcases (vect-reduc-dot-u8b.c) still fails with
> modify.diff.txt on MODIFY_EXPR where the right hand side is a call to a
> builtin function (rs6000_builtin_mul_wid
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-12-14 06:53 ---
The spu-elf part of this bug is not a regression, the reason why we have CDI
here is because spu-elf supports subregs of TI mode for CDI so we get that
mode. Note the dataflow branch gets rid of this bug.
--
pin
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-14 06:51 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-14 06:50 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|regressions in the gfortran |[4.3 Regression] regressions
|testsuite with -ftree
--- Comment #7 from jv244 at cam dot ac dot uk 2006-12-14 06:41 ---
(In reply to comment #6)
> More information. I get Tobias bad result with -m64 on x86-64-Linux. The
> problem goes away with -m32.
>
> $ gfortran -m32 pr30200-2.f90
> $ ./a.out
> Axyz
> $ gfortran -m64 pr30200-2.f90
--- Comment #10 from ian at airs dot com 2006-12-14 06:04 ---
Will be fixed in gcc 4.3.
--
ian at airs dot com changed:
What|Removed |Added
CC|
--- Comment #9 from ian at airs dot com 2006-12-14 06:03 ---
Will be fixed in gcc 4.3.
--
ian at airs dot com changed:
What|Removed |Added
Status|NEW
--- Comment #8 from ian at gcc dot gnu dot org 2006-12-14 05:49 ---
Subject: Bug 19564
Author: ian
Date: Thu Dec 14 05:49:06 2006
New Revision: 119855
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119855
Log:
PR c++/19564
PR c++/19756
gcc/:
* c-typeck.c
--- Comment #9 from ian at gcc dot gnu dot org 2006-12-14 05:49 ---
Subject: Bug 19756
Author: ian
Date: Thu Dec 14 05:49:06 2006
New Revision: 119855
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119855
Log:
PR c++/19564
PR c++/19756
gcc/:
* c-typeck.c
Testcase:
_Complex float f(float x, float y)
{
_Complex float a = (_Complex float){x};
return a;
}
--
Summary: C++ front-end rejects valid compound literal (with
complex types)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-14 05:19 ---
Actually there are three seperate issues:
1) for my recent vector patch, it was a c-gimplifier issue with respect of not
setting GIMPLE_REG_P on the decls for the compount literals, this helps with
complex typed vari
--- Comment #3 from kargl at gcc dot gnu dot org 2006-12-14 05:03 ---
I have a patch/hack to fix this.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #109 from pinskia at gcc dot gnu dot org 2006-12-14 04:53
---
*** Bug 30208 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-12-14 04:53 ---
You are violating C aliasing rules.
C aliasing rules say you can only access a variable (or an array) by the
orginal type (signed or unsigned version) or a character type (or qualified
types of those).
You have an a
On such platforms:
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
gcc version 3.3.3 (SuSE Linux)
Source Code:
void func(unsigned char *buf)
{
unsigned short *p, a, b, c, d;
unsigned int *q, m, n;
unsigned int i1 = 0x;
unsigned int i2 = 0x;
unsign
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-14 03:59 ---
(In reply to comment #2)
> but only if we don't honor NaNs or signed zeros.
Some of these optimizations can be done even without worrying about NaNs
because of -fcx-limited-range .
--
http://gcc.gnu.org/bugzill
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|--- |4.1
--- Comment #2 from kargl at gcc dot gnu dot org 2006-12-14 03:28 ---
(In reply to comment #1)
> Confirmed, reduced testcase:
> IMPLICIT NONE
> REAL, DIMENSION(2) :: ZXLON
> WHERE(ZXLON < 0.0)
> ZXLON(:) = 1
> END WHERE
> END PROGRAM
>
A work
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-14 03:10 ---
Confirmed, reduced testcase:
IMPLICIT NONE
REAL, DIMENSION(2) :: ZXLON
WHERE(ZXLON < 0.0)
ZXLON(:) = 1
END WHERE
END PROGRAM
--
pinskia at gcc dot gnu dot org changed:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|ICE in gfc_dep_resolver |[4.
A trimmed down version of the code which produce the ice is below; The full
code once compile with version 4.1.0, I believe
>>
!
SUBROUTINE POSL(LAT,LON,JUL,HEURE,MIN,PAZ)
IMPLICIT NONE
!
REAL,SAVE :: XPI! Pi
REAL, DIMENSION(:), INTENT(IN):: LAT, LON, JUL, HEURE
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-14 02:54 ---
You should use -Wl,--demangle really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30205
--- Comment #12 from dnovillo at gcc dot gnu dot org 2006-12-14 02:50
---
(In reply to comment #11)
> I'll give the bitmaps a try for the operand scanner and see how it works.
>
OK. Hopefully that won't introduce a huge slowdown in the operand scanner.
Assigning back to you.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-14 02:49 ---
Can you test with -O1 or above?
As mentioned in comment #1, this should remove all advatages gained from the
"inlined" version.
> Also, that isn't really a fair timing comparison, as you've removed the
> function ca
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-14 02:47 ---
Can you test with -O1 or above?
As mentioned in comment #1, this should remove all advatages gained from the
"inlined" version.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-12-14 02:29
---
More information. I get Tobias bad result with -m64 on x86-64-Linux. The
problem goes away with -m32.
$ gfortran -m32 pr30200-2.f90
$ ./a.out
Axyz
$ gfortran -m64 pr30200-2.f90
$ ./a.out
Az'
I get a simila
--- Comment #7 from tobi at gcc dot gnu dot org 2006-12-14 01:18 ---
I have a patch, but it adds another ugly layer of code, I'll try to clean this
mess up and then submit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25392
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-12-14 01:11
---
Subject: Re: Compiling FreeFem3d uses unreasonable amount of time and memory
On 13 Dec 2006 23:50:17 -, dnovillo at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #9 from dnovillo at gcc
--- Comment #5 from jvdelisle at verizon dot net 2006-12-14 00:26 ---
Subject: Re: write(*,myfmt="(1X,a,'xyz')") "A" prints
Az' instead of Axyz
I wonder if this is not a case of the io.h dependency bug hitting yet again. I
would fix it if I knew how.
--
http://gcc.gnu.org/bugz
--- Comment #7 from jvdelisle at verizon dot net 2006-12-14 00:12 ---
Subject: Re: Namelist issues when reading in asterisk
preceeded arrays
Thanks for checking the latest 4.1, I just updated my 4.1 branch last night and
I had not had a chance to check it.
Also, the namelist I/O pre
--- Comment #10 from dnovillo at gcc dot gnu dot org 2006-12-13 23:54
---
(In reply to comment #9)
> The memory problem is quite simple: We just have a *lot* of pointers and a
> *lot* of addressable symbols. Here is a breakdown of what happens on the
> first
> call to compute_may_alia
--- Comment #9 from dnovillo at gcc dot gnu dot org 2006-12-13 23:50
---
The memory problem is quite simple: We just have a *lot* of pointers and a
*lot* of addressable symbols. Here is a breakdown of what happens on the first
call to compute_may_aliases:
During the first call to com
--- Comment #4 from kargl at gcc dot gnu dot org 2006-12-13 23:22 ---
You code compiles fine with newer versions of gfortran
troutmask:sgk[224] gfc --version
GNU Fortran 95 (GCC) 4.2.0 20060927 (experimental)
troutmask:sgk[225] gfc4x --version
GNU Fortran 95 (GCC) 4.3.0 20061211 (exper
--- Comment #10 from dnovillo at gcc dot gnu dot org 2006-12-13 22:37
---
(In reply to comment #9)
> (In reply to comment #8)
> > There must be. mem-ssa is @119760. If you can reproduce with @119760, then
> > let me know and I'll take a look.
>
> I can reproduce it at @119761 which i
--- Comment #3 from dmcr at Princeton dot EDU 2006-12-13 22:26 ---
Created an attachment (id=12800)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12800&action=view)
Source file that contains "USE CONSTANTS"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30206
--- Comment #2 from dmcr at Princeton dot EDU 2006-12-13 22:25 ---
Created an attachment (id=12799)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12799&action=view)
Module file created by gfortran from Constants.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30206
--- Comment #1 from dmcr at Princeton dot EDU 2006-12-13 22:24 ---
Created an attachment (id=12798)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12798&action=view)
The source file whose module file appears to be corrupt
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30206
This problem occurs after creating a module file with one compilation, and then
trying to use that module file in a second compilation, as shown below:
# gfortran -I/usr/local/openmpi-1.1.2-gcc/include -c -Wall -Jmod -I. -Imod -g
Source/Constants.f90 -o obj/Constants.o
# gfortran -I/usr/local/ope
g++ and gcj should take an --unmangle option (or some such). The effect would
be to tell ld to deliver its undefined symbols error messages with names that
have been unmangled by the algorithm appropriate to the language used.
Actually, I think this should be the default, and you should have to d
--- Comment #4 from John dot Tytgat at aaug dot net 2006-12-13 22:03
---
Just to avoid confusion, in comment #3 I was talking about patch with id 12793,
not mine. I've tested it and works equally well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30192
--- Comment #3 from John dot Tytgat at aaug dot net 2006-12-13 22:01
---
Proposed patch works fine. Interworking safeness isn't important for my target
so that's why didn't consider your approach. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30192
--- Comment #36 from tkoenig at gcc dot gnu dot org 2006-12-13 21:37
---
Fixed for trunk and 4.2. Will not backport to 4.1.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from burnus at gcc dot gnu dot org 2006-12-13 21:32 ---
ICE is gone, if one removes intent(out).
ICE is at gfc_conv_descriptor_data_addr:
gcc_assert (GFC_DESCRIPTOR_TYPE_P (type));
program class_scal_p
implicit none
type scal_p
real, allocatable :: b(:)
end ty
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-12-13 21:12 ---
(In reply to comment #3)
> CC: some more libgfortran/io experienced persons.
>
> There seems to go something wrong when one uses
> format = "(1X,a,'xyz')"
> write(*,fmt=trim(format)) "A"
> The result is:
> Az'
--- Comment #3 from tobi at gcc dot gnu dot org 2006-12-13 20:46 ---
Fixed by Ira in r119730, thanks.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jacob at math dot jussieu dot fr 2006-12-13 20:24
---
(In reply to comment #4)
> most likely not in 4.2. I think something could be done in 4.3 timeframe.
ah, ok. Thanks for the information.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
--- Comment #5 from jacob at math dot jussieu dot fr 2006-12-13 20:22
---
Nope... with -O3 -ffast-math I get 1.9 seconds in average (this is a laptop
with CPU frequency scaling, so it's difficult to get precise numbers). Adding
-funroll-loops in addition to -ffast-math doesn't seem to m
--- Comment #4 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-12-13 20:22 ---
Subject: Re: gcc doesn't unroll nested loops
> Not understanding much in compiler stuff, I tried what you said, namely
> replace
> the loop with
>
> for( int i = 0; i < 3; i++ )
>
--- Comment #3 from burnus at gcc dot gnu dot org 2006-12-13 20:11 ---
CC: some more libgfortran/io experienced persons.
There seems to go something wrong when one uses
format = "(1X,a,'xyz')"
write(*,fmt=trim(format)) "A"
The result is:
Az'
Expected:
Axyz
The values in write_co
--- Comment #2 from burnus at gcc dot gnu dot org 2006-12-13 19:47 ---
Simplified version (might not cover all problems):
character(len=20) myfmt
myfmt="(1X,a,'x')"
WRITE(*,fmt=trim(myfmt)) "y"
END
If one looks now at the dump:
_gfortran_string_trim (&len.2, (void * *) &
--- Comment #8 from amylaar at gcc dot gnu dot org 2006-12-13 19:47 ---
(In reply to comment #7)
Sorry, I misunderstood you. Now the test works - most of the time:
[EMAIL
PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$
/home/amylaar/bld/2006-11-27-29858/i6
--- Comment #8 from bergner at gcc dot gnu dot org 2006-12-13 19:34 ---
The offending patch has been reverted.
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
--
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bergner at gcc dot gnu dot
|dot org
--- Comment #1 from jv244 at cam dot ac dot uk 2006-12-13 19:28 ---
This problem seems to be at the root of most CP2K regtest failures described in
PR29975
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30200
--- Comment #7 from bergner at vnet dot ibm dot com 2006-12-13 19:25
---
Ok, the reload fix has been reverted until we can find another way to fix this.
Sorry for all of the trouble.
Author: bergner
Date: Wed Dec 13 19:19:03 2006
New Revision: 119844
URL: http://gcc.gnu.org/viewcvs?r
--- Comment #6 from bergner at gcc dot gnu dot org 2006-12-13 19:19 ---
Subject: Bug 30191
Author: bergner
Date: Wed Dec 13 19:19:03 2006
New Revision: 119844
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119844
Log:
PR middle-end/30191
Revert:
* reload1
--- Comment #3 from danglin at gcc dot gnu dot org 2006-12-13 18:58 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-13 18:56 ---
(In reply to comment #2)
> than the original 1.9 seconds, but still far from the 0.3 seconds I get
> manually unrolling the loop.
Try with -ffast-math, you should get the same speed. Again the problem is with
signe
--- Comment #2 from jacob at math dot jussieu dot fr 2006-12-13 18:54
---
Not understanding much in compiler stuff, I tried what you said, namely replace
the loop with
for( int i = 0; i < 3; i++ )
for( int j = 0; j < 3; j++ )
{
bool a = (i == j);
--- Comment #2 from danglin at gcc dot gnu dot org 2006-12-13 18:49 ---
Subject: Bug 30157
Author: danglin
Date: Wed Dec 13 18:49:16 2006
New Revision: 119843
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119843
Log:
PR testsuite/30157
* lib/target-supports.exp
--- Comment #1 from danglin at gcc dot gnu dot org 2006-12-13 18:47 ---
Subject: Bug 30157
Author: danglin
Date: Wed Dec 13 18:47:04 2006
New Revision: 119842
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119842
Log:
PR testsuite/30157
* lib/target-supports.exp
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-13
18:11 ---
Subject: Re: FAIL: gcc.dg/builtins-57.c scan-tree-dump trunc
> This is a testsuite failure as this testcase will fail on targets which don't
> have C99 math functions.
Target has trunc but not lfloor.
Da
--- Comment #1 from chris at bubblescope dot net 2006-12-13 18:08 ---
-O1 is enough to remove all advantages of this patch.
Also, that isn't really a fair timing comparison, as you've removed the
function call altogether (I still expect it to be faster, but possibly not by
10x)
--
c
--- Comment #1 from chris at bubblescope dot net 2006-12-13 18:07 ---
-O1 is enough to remove all advantages of this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30203
vector::operator[](size_type) in bits/stl_vector.h is currently implemented as
reference
operator[](size_type __n)
{ return *(begin() + __n); }
const_reference
operator[](size_type __n) const
{ return *(begin() + __n); }
A faster implementation would be:
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-12-13 17:59 ---
(In reply to comment #8)
> There must be. mem-ssa is @119760. If you can reproduce with @119760, then
> let me know and I'll take a look.
I can reproduce it at @119761 which is the same revision for the trunk as
1
--- Comment #8 from dnovillo at gcc dot gnu dot org 2006-12-13 17:49
---
(In reply to comment #2)
> Looks like the mem-ssa patches cause this.
> There are no other patches in that time frame.
>
There must be. mem-ssa is @119760. If you can reproduce with @119760, then
let me know and
--- Comment #7 from dnovillo at gcc dot gnu dot org 2006-12-13 17:41
---
(In reply to comment #6)
> (In reply to comment #5)
> > You completely misunderstood. It works for me on my *mainline* tree that
> > has
> > the mem-ssa patch applied.
> Then why does it fail for FX right after y
vector::size() in bits/stl_vector.h is currently implemented as
size_type
size() const
{ return size_type(end() - begin()); }
A faster implementation is
size_type
size() const
{ return _M_impl._M_finish - _M_impl._M_start; }
Which avoids the temporary iterato
--- Comment #8 from dnovillo at gcc dot gnu dot org 2006-12-13 17:32
---
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00959.html fixes the ICE in the
operand scanner.
The alias times should be back to saner values, but the memory consumption
problem is still there. Still looking into
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Last reconfirmed|2006-12-13 17:18:56 |2006-12-13 1
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-12-13 17:07 ---
Confirmed. Fails on trunk as well.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-12-13 16:59 ---
(In reply to comment #5)
> You completely misunderstood. It works for me on my *mainline* tree that has
> the mem-ssa patch applied.
Then why does it fail for FX right after your patch?
--
http://gcc.gnu.org/bu
--- Comment #5 from dnovillo at gcc dot gnu dot org 2006-12-13 16:50
---
(In reply to comment #4)
> Subject: Re: [4.3 Regression]
> gcc.dg/pr19633-1.c fails on the mainline
>
> On Wed, 2006-12-13 at 14:12 +, dnovillo at gcc dot gnu dot org
> wrote:
> > Works for me with @1
--- Comment #1 from sfilippone at uniroma2 dot it 2006-12-13 16:39 ---
Created an attachment (id=12797)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12797&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30202
The attached sample code (as usual, much reduced but possibly not yet minimal)
produces the subject error.
[EMAIL PROTECTED] BUGS]$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2-20061212/configure --prefix=/usr/local/gcc42
--with-mpfr=/home/sfilippo/COMPIL
--- Comment #4 from pinskia at gmail dot com 2006-12-13 16:37 ---
Subject: Re: [4.3 Regression]
gcc.dg/pr19633-1.c fails on the mainline
On Wed, 2006-12-13 at 14:12 +, dnovillo at gcc dot gnu dot org
wrote:
> Works for me with @119760 (mem-ssa) on all arches (x86, x86_64, i
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-13 16:33 ---
Actually there are two issues with this bug, one issue is that we change
(float)(CMP) into CMP?1.0:0.0 early on which in the end causes us to produce
three different versions of the inner loop. If we write the inner
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c++ |middle-end
h
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-12-13 16:24 ---
Created an attachment (id=12796)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12796&action=view)
patch
It unfortunately miscompares ... (but the testsuite is clean)
--
http://gcc.gnu.org/bugzilla/show_b
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
While developing a Free C++ library, I am facing what I think is a bug in gcc:
it doesn't unroll nested loops. Namely, in the example program that I paste
below, there is a nested loop like
for( int i = 0; i < 3; i++ )
for( int j = 0; j < 3; j++ )
do_something( i, j );
and only the inner lo
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Last reconfirmed|2006-12-13 16:21:54 |2006-12-13 1
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--- Comment #3 from debian-gcc at lists dot debian dot org 2006-12-13
15:58 ---
patch posted at
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00948.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28036
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-13 15:54 ---
I just exposed this on the mainline with my GIMPLE_REG vector patch for a lot
more cases so I am going to take it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #39 from jv244 at cam dot ac dot uk 2006-12-13 15:25 ---
I had a look at one of the failing testcases from CP2K testsuite, and under
valgrind there were a number of errors that could be reproduced in the small
testcase of PR30200
--
http://gcc.gnu.org/bugzilla/show_bug.c
[EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/tests/QS/regtest-gpw-2> gfortran
test.f90
[EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/tests/QS/regtest-gpw-2> ./a.out
[EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/tests/QS/regtest-gpw-2> valgrind
--tool=memcheck ./a.out
==16188== Memcheck, a memory
--- Comment #7 from lmillward at gcc dot gnu dot org 2006-12-13 14:29
---
Subject: Bug 28740
Author: lmillward
Date: Wed Dec 13 14:28:47 2006
New Revision: 119833
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119833
Log:
PR c++27316
* g++.dg/inherit/error3.C: N
The GCC compiler on FreeBSD does not handle #pragma pack(push, ) since
gcc/config/freebsd.h does not define HANDLE_PRAGMA_PACK_PUSH_POP. There is no
reason for this:
1. gcc/config/linux.h defines HANDLE_PRAGMA_PACK_PUSH_POP. No reason why Linux
and FreeBSD should be different here.
2. The 'native'
--- Comment #3 from dnovillo at gcc dot gnu dot org 2006-12-13 14:11
---
Works for me with @119760 (mem-ssa) on all arches (x86, x86_64, ia64 and
ppc64).
$ make check-gcc RUNTESTFLAGS=dg.exp=pr19633-1.c
[...]
Test Run By dnovillo on Wed Dec 13 09:05:53 2006
Native configuration is x86
--- Comment #38 from burnus at gcc dot gnu dot org 2006-12-13 14:03 ---
Hi Paul,
(In reply to comment #36)
> > input_cp2k_motion.f90:3122: internal compiler error: in fold_convert, at
>
> A reduced version of this one would be very nice - if I would guess, it will
> be an assignment in
--- Comment #37 from jv244 at cam dot ac dot uk 2006-12-13 14:01 ---
(In reply to comment #36)
well, this was reduced, filed as PR30147, and fixed. Tobias reduced another one
and filed it as PR30190 (see dependencies).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #7 from lmillward at gcc dot gnu dot org 2006-12-13 13:59
---
Subject: Bug 27316
Author: lmillward
Date: Wed Dec 13 13:58:43 2006
New Revision: 119831
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119831
Log:
PR c++/27316
* g++.dg/inherit/error3.C:
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-12-13 13:59
---
Subject: Bug 28740
Author: lmillward
Date: Wed Dec 13 13:58:43 2006
New Revision: 119831
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119831
Log:
PR c++/27316
* g++.dg/inherit/error3.C:
--- Comment #7 from aph at gcc dot gnu dot org 2006-12-13 13:42 ---
You wrote
../gij -classpath PR18699.class:../libgcj-4.3.0.jar PR18699.class
But I wrote:
../gij -classpath .:../libgcj-4.3.0.jar PR18699
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30119
1 - 100 of 124 matches
Mail list logo
