The code
MODULE test
TYPE vertex
INTEGER :: k
END TYPE vertex
CONTAINS
SUBROUTINE S1()
TYPE(vertex) :: a
vertex : DO i=1,2
ENDDO vertex
END SUBROUTINE
END MODULE test
is invalid Fortran code,
--- Comment #34 from pinskia at physics dot uc dot edu 2006-09-26 04:56
---
Subject: Re: [4.0/4.1/4.2 Regression] alias
bug with cast and call clobbered
On Tue, 2006-09-26 at 04:44 +, acahalan at gmail dot com wrote:
>
> Although it wouldn't work for the example code, ext
On Tue, 2006-09-26 at 04:44 +, acahalan at gmail dot com wrote:
>
> Although it wouldn't work for the example code, extending the aliasing
> behavior
> of (char*) to (void*) would fix the problem for LOTS of code out in the wild.
> People normally use a (void*) when they want a generic pointe
--- Comment #33 from acahalan at gmail dot com 2006-09-26 04:44 ---
(In reply to comment #28)
> If you exclude strict type-based rules, the answer to "what can foo
> clobber" in the example is the same as asking "what can the first
> argument of foo access in foo and its callees". Becau
--- Comment #2 from acahalan at gmail dot com 2006-09-26 04:31 ---
(In reply to comment #1)
> A quick question here. Why not use a .s file instead?
REASON #1
Sometimes people want to use --combine -fwhole-program, but the documentation
for -fwhole-program starts with this:
"Assume th
--- Comment #3 from acahalan at gmail dot com 2006-09-26 04:06 ---
(In reply to comment #2)
> If you tried the page-of-functions idea, what would you do if you'd used all
> the functions on the page and needed another one?
>
You'd do the same as if you'd used up all the stack space.
Th
--- Comment #4 from pcarlini at suse dot de 2006-09-26 01:01 ---
Fixed for 4.1.2.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #3 from paolo at gcc dot gnu dot org 2006-09-26 01:00 ---
Subject: Bug 29224
Author: paolo
Date: Tue Sep 26 00:59:53 2006
New Revision: 117223
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117223
Log:
2006-09-26 Howard Hinnant <[EMAIL PROTECTED]>
PR libst
--- Comment #2 from paolo at gcc dot gnu dot org 2006-09-26 00:59 ---
Subject: Bug 29224
Author: paolo
Date: Tue Sep 26 00:59:37 2006
New Revision: 117222
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117222
Log:
2006-09-26 Howard Hinnant <[EMAIL PROTECTED]>
PR libst
--- Comment #2 from geoffk at gcc dot gnu dot org 2006-09-26 00:44 ---
If you tried the page-of-functions idea, what would you do if you'd used all
the functions on the page and needed another one?
--
geoffk at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-25 23:53 ---
Really there is no way to fix this without compiler help.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
[forwarded from http://bugs.debian.org/382746]
reported for 4.1 SVN 20060608,
Matthias
__trampoline_setup in /lib/libgcc_s.so.1 puts code on the stack.
This contributes to insecurity on powerpc.
A half-way fix is to mmap a page for this evil crud.
This still violates good practice, needing t
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-25 22:58 ---
Not enough information.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from pinskia at gcc dot gnu dot org 2006-09-25 22:54
---
*** Bug 29229 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-09-25 22:54 ---
You are incorrect. This code is invalid because argument dependent namelookup
does not have an effect on fundumental types.
This sentence is where it goes wrong:
Name lookup (3.4, 3.4.2) does not distinguish be
[forwarded from http://bugs.debian.org/385505]
sorry for the vague report, didn't reproduce that report yet.
gcc-4.1 fails to build openmsx 0.6.1 from source when compiled with -O3.
Experimenting with debian/ARM installed in qemu revealed that
compiling with -O2 -funswitch-loops -fgcse-after-rel
[forwarded from http://bugs.debian.org/385992]
Matthias
bug submitter writes:
It appears that g++ no longer finds a dependent name when it is the
template function itself.
$cat -n test.cpp
1 template void f(C *p)
2 { f(*p); }
3
4 void f(int i)
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-25 22:47 ---
*** Bug 29228 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-09-25 22:47 ---
This is a dup of bug 27096. Read the end for why this is not to be fixed for
4.1.x.
*** This bug has been marked as a duplicate of 27096 ***
--
pinskia at gcc dot gnu dot org changed:
What|Remov
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27096
[forwarded from http://bugs.debian.org/387222]
found in current 4.1 branch on i486-linux, building tonto-2.3.1
the tonto
package (quantum chemistry). Compilation stops with an internal compiler
error:
internal compiler error: in gfc_trans_deferred_array, at
fortran/trans-array.c:4514
A websearch
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-25 22:44 ---
This is an old problem really.
This is a dup of bug 19430.
*** This bug has been marked as a duplicate of 19430 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-09-25 22:44
---
*** Bug 29227 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
[forwarded from http://bugs.debian.org/386174]
bug submitter writes (4.1 and trunk):
In the following program, gcc fails to recognize that "n" is
uninitialized, unless the "sscanf" line is commented out. I expected
no change at all, since sscanf() is called after foo(). Since the
compiler is re
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-25 22:36 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29225
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-25 22:32 ---
Confirmed.
sizeof (int [w]));
is causing it.
--
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 #2 from debian-gcc at lists dot debian dot org 2006-09-25
22:25 ---
sorry, doesn't work in 3.4.6, but in 3.3 and 2.95
Matthias
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
--
--- Comment #1 from debian-gcc at lists dot debian dot org 2006-09-25
22:23 ---
Created an attachment (id=12328)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12328&action=view)
preprocess source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29226
[forwarded from http://bugs.debian.org/388263]
works, in 3.4.6, not in 4.0, 4.1, trunk SVN.
$ g++ -c 388626.ii
gcc-4-bug.cc: In function 'int label(int) [with bool neighb8 = true]':
gcc-4-bug.cc:21: internal compiler error: in make_decl_rtl, at varasm.c:886
Please submit a full bug report,
with p
--- Comment #1 from debian-gcc at lists dot debian dot org 2006-09-25
22:19 ---
Created an attachment (id=12327)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12327&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29225
[forwarded from http://bugs.debian.org/388626]
Attached preprocessed source. removing the template op< near the end
(introduced to find the types of lhs and rhs in the error message that
results) makes the ICE go away.
$ g++ -c 388263.ii
/home/marc/KDAB/CVS/SWG/trinav/ascshared/util/stl_util.h:
--- Comment #21 from debian-gcc at lists dot debian dot org 2006-09-25
22:05 ---
bug should be reopened, or should a new report be filed?
Matthias
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
--
--- Comment #20 from debian-gcc at lists dot debian dot org 2006-09-25
22:03 ---
Created an attachment (id=12326)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12326&action=view)
test case
[forwarded from http://bugs.debian.org/388626]
testcase ICEs with 3.4.6, 4.0 CVS, 4.1 CVS
--- Comment #2 from pcarlini at suse dot de 2006-09-25 21:58 ---
Working on it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at g
--- Comment #1 from pcarlini at suse dot de 2006-09-25 21:55 ---
Thanks Howard.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
The following test.cpp:
#include
struct A
{
void foo() {}
};
int main()
{
std::tr1::mem_fn(&A::foo);
}
compiled with:
g++ -Wshadow test.cpp
causes:
/usr/include/c++/4.0.0/tr1/functional_iterate.h: In constructor
'std::tr1::_Mem_fn<_Res (_Class::*)()>::_Mem_fn(_Res (_Class::*)()) [wi
--- Comment #4 from _vi at list dot ru 2006-09-25 21:32 ---
Also posted by mistake.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29221
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-25 21:28 ---
*** Bug 29223 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29221
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-25 21:28 ---
Are you having issues of filing bugs over and over again?
*** This bug has been marked as a duplicate of 29221 ***
*** This bug has been marked as a duplicate of 29221 ***
--
pinskia at gcc dot gnu dot org cha
--- Comment #1 from _vi at list dot ru 2006-09-25 21:28 ---
Posted by mistake.
--
_vi at list dot ru changed:
What|Removed |Added
Status|UNCONFIRMED
The ".hpp" suffix is not recognized and requires additional "-x c++-header"
specification.
[EMAIL PROTECTED]:~/code/test$ g++ -c -v test.hpp
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.1/configure --with-languages=c,c++,java
Thread model: posix
gcc version 4.1.1
g++
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-25 21:25 ---
*** Bug 29222 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29221
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-25 21:25 ---
*** This bug has been marked as a duplicate of 29221 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-25 21:24 ---
*** Bug 29220 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-09-25 21:24 ---
*** This bug has been marked as a duplicate of 27721 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from tromey at gcc dot gnu dot org 2006-09-25 21:22 ---
Fix checked in.
I'm not planning to back-port this to 4.1.
A 4.1 fix couldn't include the new methods, for binary compatibility.
But it could include the one hunk for the comparison, which would
suffice.
--
trome
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-25 21:22 ---
*** Bug 29221 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-09-25 21:22 ---
*** This bug has been marked as a duplicate of 13676 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
The ".hpp" suffix is not recognized and requires additional "-x c++-header"
specification.
[EMAIL PROTECTED]:~/code/test$ g++ -c -v test.hpp
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.1/configure --with-languages=c,c++,java
Thread model: posix
gcc version 4.1.1
g++
The ".hpp" suffix is not recognized and requires additional "-x c++-header"
specification.
[EMAIL PROTECTED]:~/code/test$ g++ -c -v test.hpp
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.1/configure --with-languages=c,c++,java
Thread model: posix
gcc version 4.1.1
g++
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-09-25 21:11
---
*** Bug 29219 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-25 21:11 ---
This is not a bug.
THis is a dup of bug 20547.
*** This bug has been marked as a duplicate of 20547 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from tromey at gcc dot gnu dot org 2006-09-25 21:04 ---
Subject: Bug 29178
Author: tromey
Date: Mon Sep 25 21:04:01 2006
New Revision: 117209
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117209
Log:
PR libgcj/29178:
* gnu/java/nio/charset/US_ASCI
When function names will be used as lvalues (typo), not the correct error
message will be displayed.
(It appeared when misspelling sent).
#include /* only for a valid funcion name */
void main(void){
printf += 1;
}
# gcc -o nil gcc.bug.c
gcc.bug.c:10 internal compiler error: in defa
--- Comment #1 from etienne dot clement at autodesk dot com 2006-09-25
20:19 ---
Created an attachment (id=12325)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12325&action=view)
Program causing the problem.
1- Compile using the following command:
> g++ -v -save-temps -O3 -c bug
If you compile the attached code using g++ 4.0.x using the following command:
> g++ -v -save-temps -O3 -c bug.cpp
and look at the list of symbols in the bug.o file using the following command:
> nm bug.o
You will see that g++ generates a symbol for
'PxlMonoLimit<(PxlFormat)0>::limit'. IMHO, the
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-09-25 19:59
---
Fixed in 4.2.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
Assigned
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-09-25 19:58
---
Subject: Bug 27667
Author: lmillward
Date: Mon Sep 25 19:58:10 2006
New Revision: 117206
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117206
Log:
PR c++/27667
* cp-tree.h (begin_speciali
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-09-25 19:47
---
Fixed in 4.2.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
Assigned
--- Comment #8 from lmillward at gcc dot gnu dot org 2006-09-25 19:46
---
Fixed in 4.2.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
Summa
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|00
--- Comment #7 from lmillward at gcc dot gnu dot org 2006-09-25 19:45
---
Subject: Bug 27329
Author: lmillward
Date: Mon Sep 25 19:45:34 2006
New Revision: 117205
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117205
Log:
PR c++/27329
PR c++/26938
* cp-t
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-09-25 19:45
---
Subject: Bug 26938
Author: lmillward
Date: Mon Sep 25 19:45:34 2006
New Revision: 117205
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117205
Log:
PR c++/27329
PR c++/26938
* cp-t
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-25 19:38 ---
This looks like a duplicated of PR 11407.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17359
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-25 19:29 ---
(In reply to comment #6)
> After consulting the oracle (In the this case ANSI X3.159-1989,) and being
> unable to find any information to support the claim that char is always
> different type than unsigned char or s
--- Comment #1 from cvs-commit at developer dot classpath dot org
2006-09-25 19:20 ---
Subject: Bug 29178
CVSROOT:/cvsroot/classpath
Module name:classpath
Changes by: Tom Tromey 06/09/25 19:19:47
Modified files:
gnu/java/nio/charset: ISO_8859_1.java US_ASC
--- Comment #1 from jjowdy at levanta dot com 2006-09-25 18:55 ---
Created an attachment (id=12324)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12324&action=view)
Test case to reproduce the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29217
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
I'm setting the global locale by taking the current locale (C) and overriding
the collate and ctype categories with the en_US.UTF-8 locale:
locale::global(locale(locale(),"en_US.UTF-8",locale::collate|locale::ctype))
When I actually view the resulting locale with locale().name() or
setlocale(LC_A
--- Comment #6 from mf dot danger at gmail dot com 2006-09-25 18:47 ---
After consulting the oracle (In the this case ANSI X3.159-1989,) and being
unable to find any information to support the claim that char is always
different type than unsigned char or signed char, I'd like to have th
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-25 17:03 ---
(In reply to comment #8)
> I think the real problem is in this example a is written to the stack and not
> optimised away. For the original test case the lazy stack cleanup would
> explain
> the multiple assignments
--- Comment #8 from joerg at netbsd dot org 2006-09-25 16:57 ---
> Second this is just a memcpy issue, short testcase:
> #include
>
> char buf[21];
>
> int main(void)
> {
> int a = 0x;
> memcpy(buf, &a, 4);
This creates two movl, one for a and one to buf. When
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-25 16:55 ---
(In reply to comment #5)
> It is not violating aliasing rules (since a character string can alias with
> everything, 6.5p7) nor does it affect this problem.
No you are reading it the wrong way; accessing via the char
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-25 16:53 ---
Confirmed, Note I think this should wait until 4.3.0 to be fixed on the tree
level.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from joerg at netbsd dot org 2006-09-25 16:48 ---
It is not violating aliasing rules (since a character string can alias with
everything, 6.5p7) nor does it affect this problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29215
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-25 16:43 ---
Second this is just a memcpy issue, short testcase:
#include
char buf[21];
int main(void)
{
int a = 0x;
memcpy(buf, &a, 4);
buf[4] = '\0';
puts(buf);
return 0;
}
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-25 16:37 ---
First not you are violating C aliasing rules:
*(int *)"abcd"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29215
--- Comment #1 from pault at gcc dot gnu dot org 2006-09-25 16:29 ---
Yup, does it for me too! Confirmed.
As soon as I am near no an F95 standard, I will confirm that a function result
should indeed be initialized; logic suggests that it should!
Paul
$ /irun/bin/gfortran --version
GNU
--- Comment #1 from pault at gcc dot gnu dot org 2006-09-25 16:21 ---
I have had to fix this to get on with the allocatable component patch. As soon
as I can (~24hrs), I will clear the tree and do a clean diff for this PR.
The principle is simple;
generate_loop_for_rhs_to_temp and gene
The derived type components of function results are not initialised according
to their initialisation statements. This follows from the following code:
program test
implicit none
type A
integer, pointer:: p => null()
integer:: i=3
end type A
type(A):: x,y
print *,associated(x%p)
--- Comment #1 from steven at gcc dot gnu dot org 2006-09-25 15:04 ---
Either show that it is a regression, or dont put the regression marker in the
subject.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from joerg at netbsd dot org 2006-09-25 14:46 ---
Created an attachment (id=12323)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12323&action=view)
Assembly output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29215
--- Comment #1 from joerg at netbsd dot org 2006-09-25 14:46 ---
Created an attachment (id=12322)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12322&action=view)
C source to compile with -O2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29215
The attached file and the output of gcc -O2 -S illustrate the problem.
The inlining of logarg seems to have resulted in a second buffer, which is only
ever written to.
--
Summary: Unnecessary use of stack space
Product: gcc
Version: 4.1.2
Status: UNCO
--- Comment #2 from micis at gmx dot de 2006-09-25 14:17 ---
By checking older compiler versions I found:
snapshots gcc-4.2-20060819 and before are working,
snapshots gcc-4.2-20060826 and later are ICEing
Michael Cieslinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29212
--- Comment #1 from micis at gmx dot de 2006-09-25 13:16 ---
Created an attachment (id=12321)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12321&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29212
With snapshot gcc-4.2-20060923 I get an ICE when I use the -fipa-pta option.
Michael Cieslinski
g++42c -O -fipa-pta -S in.ii
in.ii: In static member function 'static void ClassO::MetN(ClassC*, const
T2&) [with T2 = StructB]':
in.ii:18: internal compiler error: in process_constraint, at
tree-ssa-
--- Comment #11 from pcarlini at suse dot de 2006-09-25 13:00 ---
(In reply to comment #10)
> > We should have -std=c++2003 and -std=c++0x. However, care must be
> > exercise about what is included in both options.
> >
> > -- Gaby
>
> So what will "-ansi -pedantic-errors" use? c++98,
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
|
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-09-25 12:04 ---
WONTFIX on 4.0/4.1 branches.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
$ cat forall.f90
character(12), dimension(2) :: a, b
a= (/"abcdefghijkl","mnopqrstuvwx"/)
! OK because it uses gfc_trans_assignment
forall (i=1:2) b(i) = a(i)
! Broken - gfc_trans_assign_need_temp has no handling of string lengths
forall (i=1:2) a(3-i) = a(i)
end
$ /irun/bin/gfortran forall.f90
fo
--- Comment #8 from pcarlini at suse dot de 2006-09-25 10:07 ---
Fixed for 4.1.2.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #7 from paolo at gcc dot gnu dot org 2006-09-25 10:05 ---
Subject: Bug 29179
Author: paolo
Date: Mon Sep 25 10:05:43 2006
New Revision: 117194
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117194
Log:
2006-09-25 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #6 from paolo at gcc dot gnu dot org 2006-09-25 10:05 ---
Subject: Bug 29179
Author: paolo
Date: Mon Sep 25 10:05:27 2006
New Revision: 117193
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117193
Log:
2006-09-25 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #29 from fxcoudert at gcc dot gnu dot org 2006-09-25 09:19
---
Subject: Bug 21203
Author: fxcoudert
Date: Mon Sep 25 09:19:36 2006
New Revision: 117191
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117191
Log:
PR fortran/21203
* error.c (show_loci):
The following code is legal F2003 but I believe it's not legal F95. It should
be diagnosed as such.
$ cat a.f90
real,parameter :: foo = 1.7
complex,parameter :: bar = (foo, foo)
end
--
Summary: Name parameter in complex constant not allowed in F95
Product: gcc
--- Comment #1 from michael dot haubenwallner at salomon dot at 2006-09-25
09:02 ---
Two ICE's while building one source file, first one is from Bug#29182.
--
michael dot haubenwallner at salomon dot at changed:
What|Removed |Added
---
Another ICE with long double, now with optimization only:
$ cat aa.cc
class DataEncoder {
public:
virtual void put_longdouble(long double) = 0;
};
class DataOutputStream {
public:
virtual void write_longdouble(long double value) = 0;
};
class DataOutputStream_impl : virtual publi
1 - 100 of 103 matches
Mail list logo
