--- Comment #9 from beckmann dot maik at googlemail dot com 2008-07-01
06:29 ---
Thank you Ira.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36648
--- Comment #8 from irar at il dot ibm dot com 2008-07-01 06:12 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-07-01 05:43
---
Patch:
Index: list_read.c
===
--- list_read.c (revision 137236)
+++ list_read.c (working copy)
@@ -2922,8 +2922,8 @@ find_nml_name:
goto find
--- Comment #7 from irar at gcc dot gnu dot org 2008-07-01 05:32 ---
Subject: Bug 36648
Author: irar
Date: Tue Jul 1 05:31:55 2008
New Revision: 137308
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137308
Log:
PR tree-optimization/36648
* tree-vect-transform.c
Unconformable array operations are not being picked up in the following:
[EMAIL PROTECTED] Stoopid]$ cat badness.f90
program fred
implicit none
real,dimension(:,:),allocatable::A
real,dimension(5)::v
allocate(A(5,5))
A=5
v=5
A=A/spread(v,2,3)
write(*,*)A(1,:)
write(*,*)A(2,:)
write(*,*)A(3,:)
wri
Hello,
I do not have a login to submit a bug via bugzilla, so I use the
second method in http://gcc.gnu.org/bugs.html#where and attach all the
required info.
In short, compiling w/ g++-4.3
==
template Comparable max (Comparable x, Comparable y)
{
--- Comment #17 from hjl dot tools at gmail dot com 2008-07-01 04:07
---
(In reply to comment #16)
> So the question is whether we should break programs compiled by 4.3.0 and
> 4.3.1
> (acknowledging that there may not be any actual programs that break) in order
> to use consistent ver
--- Comment #16 from ian at airs dot com 2008-07-01 03:31 ---
So the question is whether we should break programs compiled by 4.3.0 and 4.3.1
(acknowledging that there may not be any actual programs that break) in order
to use consistent version numbers?
> 1. What version should x86-64
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-07-01 01:54 ---
*** Bug 36682 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-07-01 01:54 ---
*** This bug has been marked as a duplicate of 36671 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36682
--- Comment #2 from hp at gcc dot gnu dot org 2008-07-01 01:36 ---
(In reply to comment #1)
> mentioned line makes it fail.
Doh: "makes it pass", of course.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from hp at gcc dot gnu dot org 2008-07-01 01:34 ---
Created an attachment (id=15837)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15837&action=view)
somewhat shrunk test-case, the last abort in the program being called, use -O1.
It's the "if (.not.associated(a, x(a
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-07-01 00:51
---
Confirmed.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status|
With r137251, this test passed. From r137253 onwards, this test fails as
follows:
Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/associated_1.f90 -O1 execution test
with gfortran.log saying:
PASS: gfortran.dg/associated_1.f90 -O1 (test for excess error
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-06-30 23:50
---
Bug confirmed on trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36676
--- Comment #5 from hutchinsonandy at gcc dot gnu dot org 2008-06-30 22:39
---
Subject: Bug 36598
Author: hutchinsonandy
Date: Mon Jun 30 22:38:34 2008
New Revision: 137298
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137298
Log:
PR target/36598
* gcc.dg/memcpy-1.c: Mark test
program test
logical(kind=1),parameter :: t=.true.,f=.false.
logical(kind=1),dimension(9) :: hexa,hexb
data hexa/f,f,t,t,f,f,f,t,f/,hexb/f,t,f,f,f,t,t,f,f/
isum=count(hexa(1:9).eqv.hexb(1:9))
print*, isum
end program
with gfortran from gcc 4.3.1 above code produces:
test.f90:10.1
--- Comment #4 from jakub at gcc dot gnu dot org 2008-06-30 20:52 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jakub at gcc dot gnu dot org 2008-06-30 20:50 ---
Subject: Bug 36662
Author: jakub
Date: Mon Jun 30 20:49:51 2008
New Revision: 137289
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137289
Log:
PR c++/36662
* decl2.c (is_late_template_attribut
--- Comment #2 from jakub at gcc dot gnu dot org 2008-06-30 20:42 ---
Subject: Bug 36662
Author: jakub
Date: Mon Jun 30 20:41:29 2008
New Revision: 137287
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137287
Log:
PR c++/36662
* decl2.c (is_late_template_attribut
--- Comment #15 from hjl dot tools at gmail dot com 2008-06-30 19:50
---
(In reply to comment #13)
> The three symbols __gttf2, __lttf2, and __netf2 are part of the standard
> libgcc
> interface at version GCC_3.0. The fact that they are not supported by all
> instances of libgcc on a
--- Comment #2 from mariah dot lenox at gmail dot com 2008-06-30 19:32
---
Fixed in gcc-4.4-20080627
--
mariah dot lenox at gmail dot com changed:
What|Removed |Added
--- Comment #14 from joseph at codesourcery dot com 2008-06-30 19:30
---
Subject: Re: Wrong versioning for __float128
On Mon, 30 Jun 2008, ian at airs dot com wrote:
> The three symbols __gttf2, __lttf2, and __netf2 are part of the standard
> libgcc
> interface at version GCC_3.0.
--- Comment #13 from ian at airs dot com 2008-06-30 19:12 ---
The three symbols __gttf2, __lttf2, and __netf2 are part of the standard libgcc
interface at version GCC_3.0. The fact that they are not supported by all
instances of libgcc on all platforms seems to me to be irrelevant. Whe
--- Comment #12 from hjl dot tools at gmail dot com 2008-06-30 18:30
---
Since config/i386/libgcc-x86_64-glibc.ver will be removed in
gcc 4.4 when __float128 is enabled for ia32, gcc 4.3 branch
will need a different patch if we want to fix it. Otherwise,
we can leave those symbols alone
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-30 17:59 ---
No -fschedule-insns is not included for x86 because of register pressure.
See PR 27001 also. There are many others due to the RA being dumb.
--
pinskia at gcc dot gnu dot org changed:
What|Remove
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-06-30 17:56
---
This may have been fixed with a recent patch. I will check and report back
this evening.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #13 from dseketel at redhat dot com 2008-06-30 17:54 ---
@Jon Grant: thanks for cheering ! :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31754
The code snippet below compiles on FCFLAGS="-O1" and FCFLAGS="-O2", but gives
an ICE on FCFLAGS="-O1 -fschedule-insns". The additional option is supposed to
be part of -O2, according to [1].
The problem seems to be target-related as I could not reproduce it on
i686-pc-linux-gnu.
Code is reduced,
--- Comment #2 from shemminger at vyatta dot com 2008-06-30 17:53 ---
The problem turned out to be an out of bounds array reference.
The number of fields (fps->num) was 71, and on 64 were allocated.
This caused out of bounds reference to corrupt stack variables. Since
stack variables ar
--- Comment #12 from dseketel at redhat dot com 2008-06-30 17:52 ---
Created an attachment (id=15836)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15836&action=view)
better column number in error patch [2/2]
This is a rebase of the patch [2/2] against trunk of 2008-06-30.
It has
--- Comment #11 from dseketel at redhat dot com 2008-06-30 17:51 ---
Created an attachment (id=15835)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15835&action=view)
better column number in error patch [1/2]
This is a rebase of the patch [1/2] against trunk from 2008-06-30.
--
--- Comment #11 from joseph at codesourcery dot com 2008-06-30 17:22
---
Subject: Re: Wrong versioning for __float128
On Mon, 30 Jun 2008, hjl dot tools at gmail dot com wrote:
> Joseph, my current patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01942.html
>
> changes it to
--- Comment #1 from shemminger at vyatta dot com 2008-06-30 17:16 ---
Created an attachment (id=15834)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15834&action=view)
Compiler tree for lnstat compile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36679
The GCC optimizer generates code that cause a segmentation violation in
snprintf if the lnstat command from iproute2 utilities is build with -O1 or
-O2.
System: Intel Core Duo (64 bit)
Version: gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
Backtrace:
]$ gdb ./lnstat
GNU gdb 6.8-debian
Copyright (C) 20
--- Comment #10 from hjl dot tools at gmail dot com 2008-06-30 17:08
---
Joseph, my current patch:
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01942.html
changes it to @@GCC_4.3.0 and adds
+%inherit GCC_4.4.0 GCC_4.3.0
+GCC_4.4.0 {
+}
to cc/libgcc-std.ver. I can also close it as WO
$ gcc -c p-c.adb
+===GNAT BUG DETECTED==+
| 4.4.0 20080630 (experimental) (x86_64-unknown-linux-gnu) Storage_Error heap
exhausted|
| Error detected at p-c.adb:1:1|
| Please submit a bug report; see http
--- Comment #4 from jason dot hoos at syclo dot com 2008-06-30 16:32
---
(In reply to comment #1)
> Fix:
>
> Do not overload a function before and after a template class
> using it.
>
Another workaround (if rearranging the definitions isn't feasible): before any
of the function defin
--- Comment #2 from laurent dot deniau at cern dot ch 2008-06-30 16:01
---
Subject: Re: va_list argument breaks inlining (ambiguous warning).
rguenth at gcc dot gnu dot org wrote:
>
> --- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-30 15:46
> ---
> The inlining i
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-30 15:46 ---
The inlining is prohibited by the use of va_start, va_next and va_end, not
by merely passing around va_list.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
I'm having a failure on reading in a namelist in gfortran. The version
information is below:
bash-3.2$ gfortran -v
Using built-in specs.
Target: powerpc-apple-darwin9.3.0
Configured with: /var/tmp/gfortran-20080530/ibin/../gcc/configure
--prefix=/usr/local/gfortran --enable-languages=c,fortran
--w
--- Comment #8 from dfranke at gcc dot gnu dot org 2008-06-30 14:17 ---
In PR35248, Richard wrote:
> libgcc_s goes into slibdir which is set as
>
> AC_ARG_WITH(slibdir,
> [ --with-slibdir=DIR shared libraries in DIR [[LIBDIR]]],
> slibdir="$with_slibdir",
> if test "${enable_versio
If it's not a bug (the code run correctly), I suggest that the first warning
below should say "can never be inlined because it uses va_list argument". But I
do not understand why an argument of type va_list forbid inlining (not observed
in previous version AFAIK) while I understand why ellipsis can
--- Comment #9 from joseph at codesourcery dot com 2008-06-30 13:39 ---
Subject: Re: Wrong versioning for __float128
On Mon, 30 Jun 2008, hjl dot tools at gmail dot com wrote:
> > > BTW, it turns out that gcc 4.3 has those __float128 functions in libgcc.a.
> > > That means all __float
--- Comment #8 from hjl dot tools at gmail dot com 2008-06-30 13:38 ---
(In reply to comment #7)
> Ok, so if we already shipped the "broken" version we cannot do anything here
> (WONTFIX), otherwise we can fix it.
>
That is my opinion.
BTW, I consider __float128 as experimental until
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-06-30 13:35 ---
Ok, so if we already shipped the "broken" version we cannot do anything here
(WONTFIX), otherwise we can fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36669
--- Comment #6 from hjl dot tools at gmail dot com 2008-06-30 13:34 ---
(In reply to comment #3)
> Subject: Re: Wrong versioning for __float128
>
> On Mon, 30 Jun 2008, hjl dot tools at gmail dot com wrote:
>
> > BTW, it turns out that gcc 4.3 has those __float128 functions in libgcc.
--- Comment #5 from hjl dot tools at gmail dot com 2008-06-30 13:29 ---
(In reply to comment #4)
> HJ, why do you think they should be @@GCC_4.3.0? They got introduced with
>
> 2001-05-25 Richard Henderson <[EMAIL PROTECTED]>
>
>* libgcc-std.ver: Export XFmode and TFmode ver
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |irar at gcc dot gnu dot org
|dot org
--- Comment #6 from irar at gcc dot gnu dot org 2008-06-30 11:44 ---
Subject: Bug 36648
Author: irar
Date: Mon Jun 30 11:43:55 2008
New Revision: 137272
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137272
Log:
PR tree-optimization/36648
* tree-vect-transform.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-30 11:40 ---
Subject: Bug 36671
Author: rguenth
Date: Mon Jun 30 11:39:53 2008
New Revision: 137271
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137271
Log:
2008-06-30 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-30 11:40 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-30 11:36 ---
I guess this was honza. I see this as well on x86_64.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-30 11:34 ---
HJ, why do you think they should be @@GCC_4.3.0? They got introduced with
2001-05-25 Richard Henderson <[EMAIL PROTECTED]>
* libgcc-std.ver: Export XFmode and TFmode versions of symbols.
--
rguenth at
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-30 09:51 ---
The problem is that the function x has the MALLOC flag. Why is this so? This
causes the use of the argument memory to be missed.
I see in generic trans-decl.c code
/* Get a basic decl for an external function. *
--- Comment #3 from joseph at codesourcery dot com 2008-06-30 09:40 ---
Subject: Re: Wrong versioning for __float128
On Mon, 30 Jun 2008, hjl dot tools at gmail dot com wrote:
> BTW, it turns out that gcc 4.3 has those __float128 functions in libgcc.a.
> That means all __float128 func
--- Comment #2 from aldot at gcc dot gnu dot org 2008-06-30 08:23 ---
CC'ing Vladimir.
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
CC|
59 matches
Mail list logo
