--- Comment #6 from burnus at gcc dot gnu dot org 2007-04-19 07:44 ---
> Nevertheless, the accepts-invalid is also an embarassing problem (unless we
> collectively misunderstand Fortran rules :)
Well, we do.
if (any (Up ("AbCdEfGhIjKlM") .ne. (/"ABCDEFGHIJKLM"/))) stop 'ERROR'
compile
--- Comment #5 from dorit at il dot ibm dot com 2007-04-19 07:27 ---
(In reply to comment #4)
> (In reply to comment #3)
> > But then I wonder why we don't see the same failure on ia64?
> Because the failing part of the testcase is only done on ilp32 targets:
> ! { dg-final { scan-tree-d
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-19 06:32 ---
(In reply to comment #1)
Move use sort_box_module up to module level and it compiles fine. This is yet
another derived type association regression that I would swear is identical to
one of the testcases:)
It's mine.
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-04-19 05:11 ---
(In reply to comment #3)
> But then I wonder why we don't see the same failure on ia64?
Because the failing part of the testcase is only done on ilp32 targets:
! { dg-final { scan-tree-dump-times "Alignment of access
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-04-19 04:49 ---
(In reply to comment #3)
> It looks like this platform has different error messages for a given error.
Yes that's correct. I ran open_errors.exe under the solaris truss command and
saw this:
open64("./", O_RDWR|O_CR
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-04-19 04:05
---
It looks like this platform has different error messages for a given error. I
suggest that this test case be either marked as expected to fail for this
platform or we could delete the test case altogether.
Anot
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-04-19 03:47
---
Confirming. g77 does not do it right either. :)
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-19 02:27 ---
This is the same problem as referenced in PR 27442.
*** This bug has been marked as a duplicate of 27442 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-19 02:27 ---
*** Bug 31622 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from tobi at gcc dot gnu dot org 2007-04-18 23:56 ---
For the record, the problem Richard is pointing out is in the body of the
function Up, namely in the expression for MERGE, probably caused by TRANSFER.
Nevertheless, the accepts-invalid is also an embarassing problem (
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-04-18 23:01
---
Closing this. We should really open new PRs for different intrinsics, when we
have code and perf measurements.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-04-18 22:59
---
(In reply to comment #13)
> The tree stuff is hard, btw. Still trying :-)
Tree stuff? Do we generate inline code?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-04-18 22:56
---
And this is the bug:
# SFT.0_29 = V_MAY_DEF ;
# SFT.1_30 = V_MAY_DEF ;
this_7->elems[0] = 1;
the following is supposed to read it.
# VUSE ;
D.2148_18 = *D.2147_17;
it's interesting that
Points-
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-04-18 22:47
---
Code in comment #19 is perfectly correct. I can reproduce the difference with
the attached testcase and -O -fstrict-aliasing -finline-functions.
-fno-strict-aliasing fixes it.
--
http://gcc.gnu.org/bugzilla/
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-04-18 22:40
---
It's a 4.3 regression, because it compiles with 4.2 (although I haven't looked
at the generated code).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
The following code (original code courtesy of Mike Zingale, reduced by yours
truly) gives an ICE with current mainline:
module box_module
type box
integer :: m = 0
end type box
end module box_module
module sort_box_module
contains
subroutine heapsort_box(cmp)
interface
subro
--- Comment #5 from rth at gcc dot gnu dot org 2007-04-18 22:14 ---
Reproducing the problem requires -maccumulate-outgoing-args,
as implied by i686 tuning.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #20 from hjl at lucon dot org 2007-04-18 22:11 ---
build_array_ref calls
return build_indirect_ref (cp_build_binary_op (PLUS_EXPR, ar, ind),
"array indexing");
with ar as pointer and ind as integer. cp_build_binary_op turns ind into
pointe
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-04-18 21:57 ---
1469tree size_of_op0_points_to = TYPE_SIZE_UNIT (TREE_TYPE
(op0type));
and size_of_op0_points_to is a zero constant.
Reduced testcase:
struct polynomial {
~polynomial ();
};
void spline_rep1
--- Comment #19 from hjl at lucon dot org 2007-04-18 21:47 ---
For
for(unsigned i=0;i<1;i++) result += a.begin[i];
x.ii.004t.gimple looks like
const int * D.2454;
long unsigned int D.2455;
long unsigned int D.2456;
const int * D.2457;
const int * D.2458;
D.2455 = (long u
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-04-18 21:38 ---
13207 return integer_zerop (int_const_binop (TRUNC_MOD_EXPR,
13208top, bottom, 0));
(gdb) p debug_generic_expr (top)
4
$1 = void
(gdb) p debug_generic_expr (bo
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #7 from mueller at gcc dot gnu dot org 2007-04-18 21:10 ---
Fixed in 4.3.
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #6 from mueller at gcc dot gnu dot org 2007-04-18 21:09 ---
Subject: Bug 31227
Author: mueller
Date: Wed Apr 18 21:09:21 2007
New Revision: 123958
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123958
Log:
2007-04-18 Dirk Mueller <[EMAIL PROTECTED]>
PR diag
--- Comment #3 from kargl at gcc dot gnu dot org 2007-04-18 21:03 ---
(In reply to comment #2)
> Subject: Re: Inability to read ascii text with generic 'f' format
>
> read(10,*) doesn't work. I have access to two other compilers
> (SGI and Portland Group) and both of them accepted the
I prefer (but the Fortran standard does NOT require) that all module entities
used outside the module should be explicitly declared
PUBLIC.
g95 has an option -fmodule-private such that
g95 -fmodule-private for the code
module foo_mod
implicit none
! public :: i
integer :: i
end module foo_mod
p
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-04-18 20:16 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-18 20:04 ---
gprof is not part of GCC, it is part of binutils.
The problem is that gprof is not stripping out the dot part of the symbol.
Report this to the binutils folks.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #18 from hjl at lucon dot org 2007-04-18 20:02 ---
(In reply to comment #17)
> Testcase in comment #16 failed on ia32, x86-64 and ia64 with -O3. 051t.alias3
> dump looks strange. 102t.final_cleanup dump is:
>
> [EMAIL PROTECTED] bad]$ cat x.cc.102t.final_cleanup
>
> ;; Func
--- Comment #17 from hjl at lucon dot org 2007-04-18 20:00 ---
Testcase in comment #16 failed on ia32, x86-64 and ia64 with -O3. 051t.alias3
dump looks strange. 102t.final_cleanup dump is:
[EMAIL PROTECTED] bad]$ cat x.cc.102t.final_cleanup
;; Function int main() (main)
int main() ()
--- Comment #12 from jb at gcc dot gnu dot org 2007-04-18 19:49 ---
> The reason why the patch is in limbo (besides me being busy with real life :(
> )
> is that while it worked fine under Linux, it turned out that it doesn't work
> on
> many other platforms since on those platforms th
--- Comment #3 from marcus at jet dot franken dot de 2007-04-18 19:46
---
the interesting part is that the declaration is just slightly incompatible
with the actual definition. If I remove the prototype the problem goes away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31628
--- Comment #2 from marcus at jet dot franken dot de 2007-04-18 19:45
---
i bisected gcc to find the regression and it was apparently introduced by
revision 123146.
2007-03-22 Richard Henderson <[EMAIL PROTECTED]>
* config/i386/i386.c (ix86_function_regparm): Early exit for 6
--- Comment #1 from marcus at jet dot franken dot de 2007-04-18 19:44
---
Created an attachment (id=13389)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13389&action=view)
reg.i
gcc -fPIC -O2 -m32 reg.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31628
Testcase is extracted from Wine.
/home/marcus/projects/gcc/BIN/bin/gcc -m32 -fPIC -O2 -o reg reg.i
./reg
Segmentation fault
(I did not try the i586 version of the compiler.)
Looking at the disassembly the stdcall function is compiled as:
foo:
pushl %ebp
movl%esp, %ebp
--- Comment #18 from dfranke at gcc dot gnu dot org 2007-04-18 19:39
---
> It happens when you compile and link statically a Fortran code
> that uses GETLOG().
Confirmed. But if and only if it uses GETLOG(). Thus, it's not too bad. From
comment #13, I assumed that the warning is issue
--- Comment #4 from tobi at gcc dot gnu dot org 2007-04-18 19:29 ---
The segfault is present with r123923, so it's not my patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
--- Comment #23 from pinskia at gcc dot gnu dot org 2007-04-18 19:21
---
(In reply to comment #22)
> and wait another years for 4.3 release. it sux.
GCC 4.3 is the one of the few compilers to do this optimization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19431
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2007-04-18 19:21
---
(In reply to comment #16)
> nor while compiling/linking
> a binary (a hello-world in this case, glibc-2.5)
It happens when you compile and link statically a Fortran code that uses
GETLOG().
I've ended up convin
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
The following code should tell us we have an out-of-bounds access at runtime:
$ cat a.f90
subroutine foo(a)
integer a(*), i
i = 0
a(i) = 42
end subroutine foo
program test
integer x(42)
call foo(x)
end program test
$ gfortran a.f90 -fbounds-check && ./a.out
--
Summary: -b
--- Comment #22 from pluto at agmk dot net 2007-04-18 19:18 ---
(In reply to comment #21)
> Ha, sure not ;)
>
and wait another years for 4.3 release. it sux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19431
--- Comment #16 from dfranke at gcc dot gnu dot org 2007-04-18 19:15
---
FX, which version of glibc do you have installed?
I applied your patch to an otherwise unpatched tree and do not get any
warnings, neither at compile time of libgfortran(*) nor while compiling/linking
a binary (a
--- Comment #11 from jb at gcc dot gnu dot org 2007-04-18 19:05 ---
(In reply to comment #10)
> > What happend to this? I can't find the patch in the tracker anymore, but
> > there's no indication in the ChangeLog(s) that is was applied.
>
> The last patch was applied, i.e. gfortran use
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-04-18 18:48
---
I certainly agree that we should have an option to ask the driver to link
libgfortran statically.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-04-18 18:47
---
*** Bug 31604 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-04-18 18:47
---
*** This bug has been marked as a duplicate of 30471 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from echristo at apple dot com 2007-04-18 18:44 ---
As a note, this is due to the make install bit of libgcc when putting things
back into the gcc build dir we set $(slibdir) to null and then the darwin
install name ends up being set to $(slibdir)/libgcc_s.1.dylib which en
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||missed-optimization
Summary|decimal float comparison|[
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-18 18:19 ---
This is not a GCC bug, please read: http://gcc.gnu.org/gcc-3.4/changes.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from burnus at gcc dot gnu dot org 2007-04-18 18:19 ---
> What happend to this? I can't find the patch in the tracker anymore, but
> there's no indication in the ChangeLog(s) that is was applied.
The last patch was applied, i.e. gfortran uses now _gfortran_ prefixes to f
--- Comment #2 from Catherine dot M dot Moroney at jpl dot nasa dot gov
2007-04-18 18:16 ---
Subject: Re: Inability to read ascii text with generic 'f' format
read(10,*) doesn't work. I have access to two other compilers
(SGI and Portland Group) and both of them accepted the
read(10,
--- Comment #1 from tromey at gcc dot gnu dot org 2007-04-18 18:12 ---
Are you sure you are using gcj 4.3?
I see a SEGV with 4.1 and 4.2. But with 4.3 I see an error:
opsy. gcj -C Fail.java
Fail.java:5: error: Cannot invoke toString() on the primitive type long
r=(a-b).toStri
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2007-04-18 17:57
---
(In reply to comment #14)
> As FX kindly provided a patch in comment #13, are there any plans to pick it
> up
> and commit it?
As I said, I'm not sure it's the best thing to do, because it gives a warning
for s
Test gcc.dg/dfp/convert-dfp-fold.c started failing on powerpc-linux with this
patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=123719
r123719 | dnovillo | 2007-04-11 16:14:06 + (Wed, 11 Apr 2007)
The test, which is compiled with -O, converts between decimal and binary
floating types, c
--- Comment #14 from dfranke at gcc dot gnu dot org 2007-04-18 17:26
---
As FX kindly provided a patch in comment #13, are there any plans to pick it up
and commit it?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dfranke at gcc dot gnu dot org 2007-04-18 17:06 ---
What happend to this? I can't find the patch in the tracker anymore, but
there's no indication in the ChangeLog(s) that is was applied. The ML
discussion went somewhat off track after a while. Any indication to pursu
Problem description
===
Function names are mangled in gprof output. Such name mangling in gprof
output only occurs when compiling with g++ under 64 bit modes
Compiler output
===
The name HelloWorld is mangled.
Flat profile:
Each sample counts as 0.01 seconds.
no time
The following code (simplified for clarity), does not compile on GCC versions
past 4.0, but compiles fine with gcc-3.3 and other non-GCC compilers (MSVC++,
etc):
#include
template
class VectorBase
{
protected:
char * memory;
public:
VectorBase()
{
memo
CONTEXT:
- GCC version: 4.3.0.
- Front end: gcj.
- Operating System: Linux Debian, kernel 2.6.17-2-686.
- Hardware: CPU Intel Pentium 4 Xeon, 3 GHz, 16 KB cache L1, 2 MB cache L2.
RAM: 1 GB.
There is a segment violation error when compiling the following code:
public class Fail
{
public stat
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-18 15:59 ---
You just happen to overflow the stack. The stack limit is too low for your
array. This is not a GCC bug, either use limit or ulimit depening on the shell
you use to figure out the stack limit.
--
pinskia at gcc
--- Comment #3 from tobi at gcc dot gnu dot org 2007-04-18 15:56 ---
(In reply to comment #2)
> 2053 need_interface_mapping = ((sym->ts.type == BT_CHARACTER
My patch from r123924 (the one about magic numbers) touched
gfc_add_interface_mapping. Can you try reverting it, otherwise I
--- Comment #2 from schwab at suse dot de 2007-04-18 15:27 ---
Reopening since it's a problem with libstdc++ configure.
--
schwab at suse dot de changed:
What|Removed |Added
--
--- Comment #1 from schwab at suse dot de 2007-04-18 15:24 ---
Either use g++ or link with -lstdc++.
--
schwab at suse dot de changed:
What|Removed |Added
Sta
--- Comment #2 from ian at airs dot com 2007-04-18 15:14 ---
Yes, the warning is happening because gcc relies on undefined signed overflow
when assuming that it will execute the loop at least once. Of course when
using -fwrapv the loop should not be executed at all when num > INT_MAX -
$ echo 'int main(){return 0;}' >tmp.c && gcc -xc++ tmp.c
/tmp/ccGESvie.o:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
libstdc++'s configure missdetects in this way the -Wl,--gc-sections
support in the linker.
(...)
configure:8405: checking for ld that supports -Wl,--gc-sections
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-04-18 15:01
---
hmm, I will investigate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31618
--- Comment #10 from zingale at gmail dot com 2007-04-18 14:58 ---
Thanks for the help. I'll put together a tarball and pass it to you privately
as instructed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31551
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-04-18 14:51
---
output.tar attachment should go to pr31409
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31207
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-04-18 14:45
---
Ha, sure not ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19431
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2007-04-18 14:35
---
> The bootstrap works fine with all flags equal to '-O2'
Great, thanks for the confirmation.
> Still worrysome, because somewhere in the installation instructions, it is
> recommended to bootstrap the compiler w
--- Comment #13 from arcangelpip at hotmail dot com 2007-04-18 14:34
---
I'm going to try again since it seems my last post was just ignored.
The test case works fine on 4.2 but it still occurs under some circumstances.
As I stated in my previous post Gettext is where it dies but I can
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-04-18 14:25 ---
$> cat pr31620.f90
program test_assign
type my_type
integer :: a
integer :: b
end type my_type
type(my_type), dimension(1) :: mine! note that MINE is an array
mine%b=4
mine%a=1
print *,
--- Comment #7 from anirkko at insel dot ch 2007-04-18 14:24 ---
(In reply to comment #2)
> Can you try without setting the CFLAGS, etc. because what might be happening
> is
> the base compiler miscompiling the new compiler?
>
The bootstrap works fine with all flags equal to '-O2'
Sti
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-04-18 14:09 ---
Strange, indeed.
Can confirm this behaviour for 4.3 (20070417), neither 4.1.1 nor 4.2 (20070417)
exhibit the problem.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |
If an array of a derived type is declared and one component is set to zero then
all the components are set to zero. The following program illustrates the
problem:
program test_assign
type my_type
integer :: a
integer :: b
end type my_type
type(my_type), dimension(1) :: mine
m
The following error occured when I try to run the c program after compiling
with gcc
Segmentation fault
The C program is as follows
//testr.c
#include
main () {
float rd[9331200];
int jd = 5;
printf("jd = %d\n",jd);
}
//Compile command
gcc testr.c
The output of the c
--- Comment #20 from pluto at agmk dot net 2007-04-18 13:02 ---
(In reply to comment #19)
> Fixed.
>
will it be backported to 4.2?
it improves perf. of big stl-based apps.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19431
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-04-18 12:48
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-04-18 12:46
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-04-18 12:45
---
Subject: Bug 19431
Author: rguenth
Date: Wed Apr 18 12:45:09 2007
New Revision: 123946
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123946
Log:
2007-04-18 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-04-18 12:45 ---
Subject: Bug 21463
Author: rguenth
Date: Wed Apr 18 12:45:09 2007
New Revision: 123946
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123946
Log:
2007-04-18 Richard Guenther <[EMAIL PROTECTED]>
PR
14 ) and z( 17 ) and LocalTimeStep( 17 )
reading again x and z in foo
x ( 17 ) and z( 8 ) and LocalTimeStep( 0 )
STOP OK
--
Summary: backspace intrinsic is not working on an unformatted
file
Product: gcc
--- Comment #7 from dfranke at gcc dot gnu dot org 2007-04-18 11:14 ---
See also: PR30471, PR30613 and PR31400 :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31604
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-18 10:54
---
Hey, this has turned into an ICE on today's trunk. Cool, it's gonna be easier
to work on! :)
As I pointed out in http://gcc.gnu.org/ml/fortran/2007-04/msg00295.html, this
makes it a potential double regression, w
--- Comment #4 from pault at gcc dot gnu dot org 2007-04-18 10:44 ---
(In reply to comment #2)
Changing the comparison to
if (Up ("AbCdEfGhIjKlM") .ne. "ABCDEFGHIJKLM") call abort ()
gets rid of the problem.
I have clearly exposed something extremely unpleasant in ANY or the compar
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-18 10:21 ---
(In reply to comment #1)
>
> if (any (Up ("AbCdEfGhIjKlM") .ne. (/"ABCDEFGHIJKLM"/))) call abort ()
> contains
> Character (len=20) Function Up (string)
>
>
> It looks like it's comparing a CHARACTER*20 (= Up's
--- Comment #3 from dorit at il dot ibm dot com 2007-04-18 10:18 ---
> Created dump file using -fdump-tree-vect-details
thanks. So I don't understand why we expect to version for 3 different
data-references, since there are only 2 in the loop that is vectorized. But
then I wonder why we
--- Comment #5 from burnus at gcc dot gnu dot org 2007-04-18 10:18 ---
(In reply to comment #4)
Another thing which needs to be supported:
use mod, only: operator(foo) => operator(.op.), &
operator(bar) => operator(.op.), &
operator(op), &
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-04-18 10:00 ---
Micha, this one should be catched by your conditional store patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-04-18 09:53
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-04-18 09:53
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-18 09:47
---
Subject: Bug 31296
Author: fxcoudert
Date: Wed Apr 18 09:47:28 2007
New Revision: 123944
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123944
Log:
PR libfortran/31286
PR libfortran/31296
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-18 09:47
---
Subject: Bug 31286
Author: fxcoudert
Date: Wed Apr 18 09:47:28 2007
New Revision: 123944
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123944
Log:
PR libfortran/31286
PR libfortran/31296
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-18 09:36 ---
(In reply to comment #1)
> Adding pault, as he's the likely culprit :)
>
Richard and Tobi,
I am a bit trapped right now, as chairman of a review meeting; I'll try to look
at it this evening.
On the face of it, chara
95 matches
Mail list logo
