IainS develo...@sandoe-acoustics.co.uk writes:
that's really neat indeed - I should have spotted the potential looking at
the code in contrib
... although the site.exp is hardwired in btest.sh at present ;
I guess one might be able to use .dejagnurc - just need to check on the
order that
On 10 Mar 2010, at 09:12, Rainer Orth wrote:
IainS develo...@sandoe-acoustics.co.uk writes:
that's really neat indeed - I should have spotted the potential
looking at
the code in contrib
... although the site.exp is hardwired in btest.sh at present ;
I guess one might be able to use
On 10 Mar 2010, at 09:22, IainS wrote:
Far easier: just set the DEJAGNU environment variable to the absolute
path to the size.exp file. runtest knows about that.
the DEJAGNU env. var is set in btest.sh
my mistake.
duh - that's what comes of working with code that was forked a long
time
IainS develo...@sandoe-acoustics.co.uk writes:
Far easier: just set the DEJAGNU environment variable to the absolute
path to the size.exp file. runtest knows about that.
the DEJAGNU env. var is set in btest.sh
It's not:
$ grep DEJAGNU contrib/regression/btest-gcc.sh
# DEJAGNU: should point
On 03/06/2010 12:03 AM, Joseph S. Myers wrote:
On Fri, 5 Mar 2010, Ian Lance Taylor wrote:
Dave Korn dave.korn.cyg...@googlemail.com writes:
I think you'll probably have to use plain old iswalpha. Looking at opts.c,
I'm guessing you're trying to extend the help string format to allow
2010/3/9 Marcin Baczyński marb...@gmail.com:
Hi,
the following piece of code produces different output on svn trunk and
gcc-4_4-branch:
#include stdio.h
int main()
{
struct { unsigned bar:1; } foo;
foo.bar = 0x1;
printf(%08x\n, (unsigned char)(foo.bar * 0xfe));
Hello,
I'm having some problem with compiling OpenCV code on Solaris SPARC with GCC
4.4.3, I don't know whether it is an OpenCV bug (I have posted on their mailing
list too) or a gcc bug. I was hoping someone may be able to shed some light on
the error and provide some ideas on what I could
On Wed, Mar 10, 2010 at 01:30:36PM +, Nick Fielding wrote:
The first syntax error the compiler complains about I think is the main
problem:
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:673: error: expected ',' or '...'
before numeric constant
However, when I look at the line of code it's
We have a problem with arguments passing in memory.
The caller puts the arguments in memory relative to the sp:
add sp, 4 // allocate space for the argument. stack grows up
store r1, (sp-4) // store the argument on the stack
call xxx// call the function.
In xxx the result
Hi,
this code
---
template typename _T
struct A
{
template int _N, int _M
struct B;
template int _N
struct B_N, _T::m
{
static void f();
};
};
struct C
{
static const int m = 4;
};
void m()
{
AC::B1, 4::f();
}
--
causes the following ICE
On 03/10/2010 09:02 AM, Frank Isamov wrote:
How can I tell GCC that that the callee should load from the
original offset + 4?
You'll want to set FIRST_PARM_OFFSET and INCOMING_FRAME_SP_OFFSET.
r~
FWIW;
the bus errors were consistently coming from expect in a strcpy [about
100 tcl levels down]
the actual fault was a corrupted dejagnu installation - it's not clear
how that happened - nothing present in syslogs to indicate disk
problems.
a clean install of dejagnu appears to have
Hi -
This is a test for gcc.gnu.org's listarch for this mailing list,
which has interrupted.
- FChE
Hello All,
Sylvestre Ledru is very nicely trying to package MELT as a packaged
debian plugin for GCC 4.5 - MELT can be compiled either as an entire GCC
branch, or as a GCC 4.5 -i.e. trunk- plugin.
However, we seems to have found some difficult issue. As Diego added
into the documentation:
On Wed, Mar 10, 2010 at 07:04:20PM +0100, Roger Ferrer Ibáñez wrote:
Is this a known bug or I should fill a PR?
I see that you have just filed a PR for this at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43327
Thanks.
Dodji
I am porting gcc 4.3.2 to my own micro-controller.
For below piece of code, the instruction clr.w a15 obviously doesn't
belong to the inner loop. Compiler should be smart enough to move it
to the beginning of the function.
How I can hoist the constant out of loops?
Maybe the costs functions have
Basile Starynkevitch wrote:
In other words, would a gt-melt-runtime.h generated on
Debian/Linux/AMD64 would be ok for a Debian/Linux/x86 or
Debian/Linux/ARM? I blindly guess that probably not, but I am not sure.
Apparently, the constraint that gengtype requires availability of both
the
--- Comment #4 from michele at focuseek dot com 2010-03-10 08:05 ---
Yesterday I filed the suspiciously similar bug 42143 with a really simple test
case that fails on gcc 4.4.3 and used to work with gcc 4.2.2. As I wrote in the
description for that bug I suspect it's actually a
--- Comment #18 from jakub at gcc dot gnu dot org 2010-03-10 08:07 ---
Created an attachment (id=20073)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20073action=view)
gcc45-pr43290.patch
Updated patch. This one includes testcases, and also fixes for -O+, when
optimizing we
--- Comment #5 from michele at focuseek dot com 2010-03-10 08:09 ---
(In reply to comment #4)
[...] suspiciously similar bug 42143 [...]
I meant bug 43302...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42143
--- Comment #2 from michele at focuseek dot com 2010-03-10 08:30 ---
Experimenting with -save-temps I noticed that the .dummy resource is in the
.jar generated by ecj which seems to point to it as the main suspect.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43302
--- Comment #10 from pault at gcc dot gnu dot org 2010-03-10 09:29 ---
In preparing a testcase, I foolishly decided to check the original for correct
execution.
The following gives the wrong result:
module m1
type :: t1
contains
procedure :: sizeof
end type
contains
--- Comment #2 from redi at gcc dot gnu dot org 2010-03-10 10:14 ---
In the latest draft (n3035) [temp.deduct.type] 14.9.2.5 paragraph 22 has an
example of a case where a non-variadic template is more specialized than
variadic templates. I'm not entirely sure if that's relevant though.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43317
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-10 10:49 ---
Works for me on x86_64 and i?86 with various GCC versions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43313
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-10 10:52 ---
(In reply to comment #7)
current 4.4.x generates 'movdqa (%rdi), %xmm0' in both cases.
4.2 branch is closed, 4.3 is near to close.
can we close this bug as fixed?
GCC 4.4 creates movdqu (%rdi), %xmm0 for load_2
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-03-10 10:54 ---
Actually it does with the fixed aligned attribute. Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-10 10:55 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from abel at gcc dot gnu dot org 2010-03-10 11:09 ---
Subject: Bug 42859
Author: abel
Date: Wed Mar 10 11:08:48 2010
New Revision: 157337
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157337
Log:
PR middle-end/42859
* tree-eh.c: Include pointer-set.h.
--- Comment #11 from abel at gcc dot gnu dot org 2010-03-10 11:09 ---
Fixed.
--
abel at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-03-10
11:17 ---
Machine-independent templates are described in gccint.info, in the Output
Templates and Operand Substitution section. Online documentation is here:
http://gcc.gnu.org/onlinedocs/gccint/Output-Template.html.
---
Running 200.sixtrack ref base default-linux default
Commands to run:
-u /gcc/spec/cpu2000/benchspec/CFP2000/200.sixtrack/run/0003
-i inp.in -o inp.out -e inp.err ../0003/sixtrack_base.default-linux
Specinvoke: /gcc/spec/cpu2000/bin/specinvoke
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-10 12:35 ---
Last known good rev. 157294, first known bad rev. 157328 (x86_64).
Last known good rev. 157304, first known bad rev. 157331 (ia64).
Points at:
Index: libgfortran/ChangeLog
--- Comment #2 from burnus at gcc dot gnu dot org 2010-03-10 12:40 ---
Richard, how new is this regression? That is: Which check-ins could have causes
this?
Assuming that CPU SPEC is run every day, I assume that it is the patch for PR
43265; namely commit
--- Comment #15 from burnus at gcc dot gnu dot org 2010-03-10 12:42 ---
This patch causes a regression in SPEC CPU 2000 (200.sixtrack), see PR 43320.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43265
--- Comment #9 from amonakov at gcc dot gnu dot org 2010-03-10 12:54
---
Subject: Bug 43236
Author: amonakov
Date: Wed Mar 10 12:53:51 2010
New Revision: 157339
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157339
Log:
PR tree-optimization/43236
*
--- Comment #10 from amonakov at gcc dot gnu dot org 2010-03-10 12:57
---
Both issues are fixed with above commit.
--
amonakov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from paul dot richard dot thomas at gmail dot com
2010-03-10 13:20 ---
Subject: Re: [4.5 Regression] 200.sixtrack fails setup
Dear All,
Paul, I think you are the only gfortraner, which has access to SPEC CPU 2000.
Can you have a look?
I am still recuperating from
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
CC||hjl dot tools at gmail dot
|
--- Comment #11 from sezeroz at gmail dot com 2010-03-10 14:17 ---
The testcase fails with 4.4 with -Ox -ftree-loop-distribution and the patch
does not apply to 4.4. Will there be a gcc-4.4 backport of this?
--
sezeroz at gmail dot com changed:
What|Removed
--- Comment #4 from burnus at gcc dot gnu dot org 2010-03-10 14:31 ---
The SixTrack souce code can be found at
http://lhc-collimation-project.web.cern.ch/lhc-collimation-project/code-tracking.htm
Namely:
http://lhc-collimation-project.web.cern.ch/lhc-collimation-project/SixPack.zip
--- Comment #5 from burnus at gcc dot gnu dot org 2010-03-10 14:39 ---
Reproduce using:
1. Grab SixTrack.zip (see comment 4)
2. Change in track.f, line 4411 in (i,1x,... the i into an i0
3. Grab the input file
--- Comment #3 from ramana at gcc dot gnu dot org 2010-03-10 14:49 ---
Confirmed but do we expect this to be done in CSE . IIUC, shouldn't this be a
part of fwprop handling addresses rather than doing this in CSE ?
--
ramana at gcc dot gnu dot org changed:
What
--- Comment #6 from burnus at gcc dot gnu dot org 2010-03-10 14:52 ---
Reduced test case: Reading from a completely empty line should produce an EOF
status. As soon as there is a \n or or 0, ifort, NAG f95 and gfortran
4.3/4.5 also succeed (i.e. have no EOF error.)
That's kind of the
I hope it's a valid auto. the code works if I write int instead of auto.
It might be related to Bug 43281
internal compiler error: in type_unification_real, at cp/pt.c:13486
template typename T
void shuffle(const T first, const T last)
{
auto w = *first;
}
int main()
{
int b[5];
Mac gcc -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5646.1~2/src/configure --disable-checking
--enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib
When compiled with gcc 4.4.[34] The following code prints fe 01, while it
should fe ff. Current svn trunk produces correct results.
No flags needed to reproduce.
extern int printf(const char * __restrict, ...);
int main()
{
struct { unsigned bar:1; } foo;
foo.bar = 0x1;
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-03-10 15:40 ---
Patch posted
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jason at gcc dot gnu dot org 2010-03-10 15:43 ---
Yes, that's valid.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-03-10 15:52 ---
dyld: Library not loaded: /usr/local/lib/libmpfr.1.dylib
Referenced from: /usr/local/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/f951
Reason: Incompatible library version: f951 requires version 4.0.0 or later,
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-10 15:55 ---
Confirmed.
extern void abort (void);
int main()
{
struct { unsigned bar:1; } foo;
foo.bar = 0x1;
if ((unsigned char)(foo.bar * 0xfe) != 0xfeu)
abort ();
if ((unsigned char)(foo.bar * 0xff) != 0xffu)
--- Comment #6 from giese025 at umn dot edu 2010-03-10 16:07 ---
(In reply to comment #5)
(In reply to comment #4)
Not all valid FORTRAN 95 programs will compile properly when using this
option. If you want to ensure compliance with one of the FORTRAN standards,
please see
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-10 16:19 ---
Downgrading to P2. Target maintainers think this is not a serious bug and are
happy with not fixing it for 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40761
--- Comment #4 from steven at gcc dot gnu dot org 2010-03-10 16:21 ---
Another arm_arm_address_cost problem, dup of something I'm not even going to
try to find.
Until ARM or an ARM maintainer cares (or Google folks stop filing and start
fixing bugs), we don't need more reports of the
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.4.3
Known to work||4.3.4
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-10 16:26 ---
dsymutil bug
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-10 16:26 ---
Mine anyway.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43265
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43280
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43288
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43300
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43303
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43305
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-03-10 16:31 ---
Even though this is Fortran being able to build run SPEC is release critical.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from krebbel at gcc dot gnu dot org 2010-03-10 16:31 ---
Created an attachment (id=20074)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20074action=view)
Experimental patch
This patch fixes the problem for me. Testsuites are still running.
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Known to work|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.5.0
--- Comment #19 from rguenth at gcc dot gnu dot org 2010-03-10 16:33
---
Fixed (I assume).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from doko at gcc dot gnu dot org 2010-03-10 16:34 ---
Subject: Bug 40050
Author: doko
Date: Wed Mar 10 16:32:56 2010
New Revision: 157345
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157345
Log:
Use the host compiler instead of the target compiler to build
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|GCC 4.4 / 4.5 generates |[4.4/4.5 Regression]
|larger code for a
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-03-10 16:36 ---
Created an attachment (id=20075)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20075action=view)
Potential (preliminary) fix
After much tinkering I have came up with this patch do create an
ABSTRACT_ORIGIN for
--- Comment #23 from paolo dot carlini at oracle dot com 2010-03-10 16:36
---
At the end of a further discussion today, apparently there is a strong
consensus to add additional signatures returning void, Boost-style.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||rejects-valid
Priority|P3 |P2
--- Comment #7 from kargl at gcc dot gnu dot org 2010-03-10 17:17 ---
(In reply to comment #6)
(In reply to comment #5)
(In reply to comment #4)
Not all valid FORTRAN 95 programs will compile properly when using this
option. If you want to ensure compliance with one of
--- Comment #6 from hjl dot tools at gmail dot com 2010-03-10 17:50 ---
(In reply to comment #5)
Created an attachment (id=20074)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20074action=view) [edit]
Experimental patch
This patch fixes the problem for me. Testsuites are still
--- Comment #13 from jakub at gcc dot gnu dot org 2010-03-10 18:17 ---
Subject: Bug 36728
Author: jakub
Date: Wed Mar 10 18:17:10 2010
New Revision: 157363
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157363
Log:
PR debug/43290
* reg-notes.def
--- Comment #19 from jakub at gcc dot gnu dot org 2010-03-10 18:17 ---
Subject: Bug 43290
Author: jakub
Date: Wed Mar 10 18:17:10 2010
New Revision: 157363
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157363
Log:
PR debug/43290
* reg-notes.def
$uname -a
SunOS sigvmec2 5.11 snv_111b i86pc i386 i86xpv Solaris
$g++ -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../configure CC=gcc --prefix=/usr/local2
--build=i386-pc-solaris2.11 --with-gnu-as --with-as=/usr/local/bin/as
--without-gnu-ld --with-ld=/usr/ccs/bin/ld
--- Comment #1 from lwestermann at gams dot com 2010-03-10 18:24 ---
Created an attachment (id=20076)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20076action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43324
--- Comment #1 from janis at gcc dot gnu dot org 2010-03-10 18:35 ---
GCC 3.4 also has this bug.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2010-03-10 18:57 ---
Subject: Bug 43303
Author: burnus
Date: Wed Mar 10 18:56:46 2010
New Revision: 157364
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157364
Log:
2010-03-10 Tobias Burnus bur...@net-b.de
PR
namespace S
{
int f ()
{
int i = 42;
{
extern int i;
return i;
}
}
}
generates DWARF:
# Grossly simplified.
12d: Abbrev Number: 2 (DW_TAG_namespace)
2e DW_AT_name: S
236: Abbrev Number: 3 (DW_TAG_subprogram)
37
--- Comment #3 from hubicka at gcc dot gnu dot org 2010-03-10 19:33 ---
Subject: Bug 43288
Author: hubicka
Date: Wed Mar 10 19:33:37 2010
New Revision: 157366
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157366
Log:
PR c/43288
* ipa.c
--- Comment #4 from hubicka at gcc dot gnu dot org 2010-03-10 19:36 ---
Fixed.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2010-03-10 19:39
---
Created an attachment (id=20077)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20077action=view)
Proposed patch
Richard,
Thank you for the great pointers how to fix this bug. Here is the proposed
patch to
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-03-10 19:44
---
I will get on this tonight.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-03-10 20:05 ---
It is fixed on trunk on revision 148631:
http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00613.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-03-10 20:21
---
I am fairly sure its the hit_eof I removed from next_record_r in transfer.c.
When I get to my work machine I will fix either by reverting or otherwise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320
--- Comment #18 from foom at fuhm dot net 2010-03-10 20:32 ---
Sorry for the extreme delay in responding. I can confirm that applying that
patch on top of:
gcc-4.5 (Debian 4.5-20100227-1) 4.5.0 20100227 (experimental) [trunk revision
157109]
*does* make my issue go away, and my program
--- Comment #11 from janus at gcc dot gnu dot org 2010-03-10 20:46 ---
(In reply to comment #6)
If all appears to be well with the regtest and I do not hear back from you,
I
will commit the patch to trunk tonight.
The patch clobbers dynamic_dispatch_4.f03.
Hm, funny. For me
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-10 20:54 ---
This is tracer duplicating the basic block.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43204
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-10 20:54 ---
And really at -O3 you can expect bigger code in general.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43204
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-03-10 20:56 ---
Actually this is PPRE at -O3 so this is expected.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Spin-off from PR 43291 comment #10 ...
The following gives the wrong result:
module m1
type :: t1
contains
procedure :: sizeof
end type
contains
integer function sizeof(a)
class(t1) :: a
sizeof = 1
end function sizeof
end module
module m2
use m1
type, extends(t1) ::
--- Comment #12 from janus at gcc dot gnu dot org 2010-03-10 21:04 ---
(In reply to comment #10)
In preparing a testcase, I foolishly decided to check the original for correct
execution.
The following gives the wrong result:
I guess this is worth a separate PR. It's PR43326 now.
--- Comment #5 from ghazi at gcc dot gnu dot org 2010-03-10 21:15 ---
Subject: Bug 38163
Author: ghazi
Date: Wed Mar 10 21:15:16 2010
New Revision: 157370
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157370
Log:
Backport:
2008-12-12 Uros Bizjak
--- Comment #1 from janus at gcc dot gnu dot org 2010-03-10 22:06 ---
Here is a simple-minded patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 157366)
+++ gcc/fortran/resolve.c
The following code
---
template typename _T
struct A
{
template int _N, int _M
struct B;
template int _N
struct B_N, _T::m
{
static void f();
};
};
struct C
{
static const int m = 4;
};
void m()
{
AC::B1, 4::f();
}
--
causes the following
--- Comment #3 from boostcpp at gmail dot com 2010-03-10 22:30 ---
I'm not sure about this.
Maybe gcc is right.
Even though it take zero parameter, it's still there.
I don't know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43315
1 - 100 of 120 matches
Mail list logo
