Hi,
I'm trying to build (natively) GCC 4.3.2 on a
powerpc-yellowdog-linux-gnu. I have not yet managed to build it all
('make bootstrap') but I found out that each of the following changes
(applied in the order specified) takes me further on:
-- clear the LIBRARY_PATH variable, i.e. build with
Hello,
I'm a young developer, with very strong knowledge about programming, especially
C++. I am working to one of my greatest projects. I'm building up a framework
that can create native Win32 applications, console applications, and
provides intelligent and efficient classes to manage
All,
dbx has a feature called 'trace' where it outputs your program
execution, a line at a time, and I've found it very useful for
debugging/figuring out programs (you run it once, make a change, run
it again, and do a diff to see exactly how your change affects the
programming run).
However, it
Cristian Harja wrote:
Hello,
I'm a young developer, with very strong knowledge about programming, especially
C++. I am working to one of my greatest projects. I'm building up a framework
that can create native Win32 applications, console applications, and provides
intelligent and efficient
I'm trying to build (natively) GCC 4.3.2 on a
powerpc-yellowdog-linux-gnu. I have not yet managed to build it all
('make bootstrap') but I found out that each of the following changes
(applied in the order specified) takes me further on:
-- insert '#include limits.h' in
Snapshot gcc-4.3-20081030 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20081030/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thu, Oct 30, 2008 at 06:09:28PM -0400, Robert Dewar wrote:
Cristian Harja wrote:
Hello,
I'm a young developer, with very strong knowledge about programming,
especially C++. I am working to one of my greatest projects. I'm building
up a framework that can create native Win32
Michael Meissner wrote:
If you are including GCC in your program, your program needs to be licensed
such to allow this (typically gplv3). If you are just providing the compiler
as a separate package without modifications, then this is a much simpler matter
(this is allowed under section 4 of
On Thu, 2008-10-30 at 20:15 -0400, Robert Dewar wrote:
Michael Meissner wrote:
If you are including GCC in your program, your program needs to be licensed
such to allow this (typically gplv3). If you are just providing the
compiler
as a separate package without modifications, then
Hi,
I am currently having my first patch to gfortran accepted, but was not
able to manipulate the PR in bugzilla. A helpful soul on the gfortran
list then pointed me to this address to ask whether I need a
gcc.gnu.org account to work with bugzilla. Is that right? If it is,
where can I get one of
For m32c-elf with gcc.c-torture/execute/980707-1.c, global seems to be
deleting a set that's needed to set the exit code - i.e. it's the
first argument to exit(). There's also this suspicious message in the
global dump:
changing reg in insn 95
I can't tell if they're changing the pseudo (ok)
--- Comment #3 from alon dot barlev at gmail dot com 2008-10-30 06:45
---
Created an attachment (id=16587)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16587action=view)
sample2.c
Maybe the complete source will be better...
$ x86_64-pc-mingw32-gcc -O3 -c sample2.c
e_aep.c: In
--- Comment #5 from cnstar9988 at gmail dot com 2008-10-30 06:57 ---
fixed in gcc 4.3 branch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37879
--- Comment #6 from jakub at gcc dot gnu dot org 2008-10-30 09:15 ---
Not fixed there yet.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from pault at gcc dot gnu dot org 2008-10-30 11:08 ---
(In reply to comment #11)
Well, may patch is made against trunk, so I will leave it as is for now.
If Daniel commits his patch for PR35861, I can provide an updated patch.
I quickly looked at it, and it should be
--- Comment #3 from pault at gcc dot gnu dot org 2008-10-30 11:13 ---
(In reply to comment #2)
Created an attachment (id=16585)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16585action=view) [edit]
proposed patch, regression tested
This patch solves the problem by going
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-30 12:49 ---
Subject: Bug 37730
Author: jakub
Date: Thu Oct 30 12:49:31 2008
New Revision: 141461
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141461
Log:
PR middle-end/37730
* expr.c (store_constructor):
--- Comment #6 from jakub at gcc dot gnu dot org 2008-10-30 12:51 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from jifl-bugzilla at jifvik dot org 2008-10-30 13:10
---
Hi Benjamin, the copyright assignment is definitely sorted, and can be seen on
copyright.list on fencepost.gnu.org now.
Any reason for this not to go in (although I don't have commit perms)? Would it
better for
--- Comment #2 from jifl-bugzilla at jifvik dot org 2008-10-30 13:15
---
In case it helps someone to look at this, I do have a copyright assignment for
GCC (although no commit access) so if this fix is acceptable, you can just
commit it.
--
--- Comment #2 from grosser at gcc dot gnu dot org 2008-10-30 13:51 ---
Created an attachment (id=16588)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16588action=view)
Add POINTER_PLUS_EXPR - Improvement?
It seems we miss the POINTER_PLUS_EXPR. In most cases in tree-scalar-evol.c
--
grosser at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |grosser at gcc dot gnu dot
|dot org
--- Comment #1 from tsyvarev at ispras dot ru 2008-10-30 14:22 ---
Created an attachment (id=16589)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16589action=view)
reproduce bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37957
There are some examples in the description of member function of the num_get
facet
iter_type do_get(iter_type in, iter_type end, ios_base str, ios_base::iostate
err, bool val) const
for the case when (str.flags() ios_base::boolalpha) != 0, that clarify the
algorithm that the function implements
--- Comment #3 from mitul dot thakkar at amd dot com 2008-10-30 14:43
---
(In reply to comment #2)
Under FreeBSD x68 this works in trunk and branch.
I've tested it from my side and it works with current graphite branch.
Thanks,
Mitul Thakkar.
--
--- Comment #18 from dje at gcc dot gnu dot org 2008-10-30 14:49 ---
GCC no longer generates branch on count instructions on PowerPC.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
There are some examples in the description of member function of the num_get
facet
iter_type do_get(iter_type in, iter_type end, ios_base str, ios_base::iostate
err, bool val) const
for the case when (str.flags() ios_base::boolalpha) != 0, that clarify the
algorithm that the function implements
g++ -g does not emit DW_AT_explicit for explicit constructors.
It should; I think it is impossible to correctly parse
some expressions without this information.
--
Summary: g++ does not emit DW_AT_explicit
Product: gcc
Version: 4.4.0
Status:
--- Comment #4 from eric dot weddington at atmel dot com 2008-10-30 16:03
---
See also WinAVR bug #2209796 on SourceForge:
https://sourceforge.net/tracker/?func=detailatid=520074aid=2209796group_id=68108
--
eric dot weddington at atmel dot com changed:
What|Removed
--- Comment #1 from paolo dot carlini at oracle dot com 2008-10-30 16:07
---
(In reply to comment #0)
It seems that implementation always set str.eofbit when after call of the
function (in == end).
But standard states(22.2.2.1.2, p16) that this flag should be set only when:
if,
--- Comment #2 from paolo dot carlini at oracle dot com 2008-10-30 16:15
---
Maybe now I see, what's behind your report: you believe that, when val is set,
eofbit should be set only when seeking another character to match. But that
would essentially boil down to *never* set it, in that
--- Comment #19 from rguenth at gcc dot gnu dot org 2008-10-30 16:30
---
Can someone please specify a Known-to-work version?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from janis at gcc dot gnu dot org 2008-10-30 16:46 ---
To add to comment #18, after r128272 GCC for powerpc-linux no longer generates
bdnz for:
int reg_values[1024];
void
clear_table (unsigned int n)
{
unsigned int i;
for (i = 0; i n; i++)
reg_values[i] = 0;
}
--- Comment #3 from paolo dot carlini at oracle dot com 2008-10-30 16:51
---
Ok, now I see, weird.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #21 from rguenth at gcc dot gnu dot org 2008-10-30 16:55
---
Known-to-work for whatever testcase you want to see this PR as a regression.
As it sounds that this problem comes and goes for different testcases in
different releases more testing coverage in the testsuite
--- Comment #1 from jamborm at gcc dot gnu dot org 2008-10-30 17:43 ---
Well, yes, we do generate that code. However, the loop is unrolled
later on and the IR code on which the vrp complains later on actually is:
main ()
{
unsigned int ivtmp.27;
unsigned int pretmp.17;
int
--- Comment #2 from manu at gcc dot gnu dot org 2008-10-30 18:43 ---
So what is this? Is the warning logic wrong or is the IR wrong? It seems to me
that IR is valid.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
FAIL: gcc.dg/pr11492.c (test for bogus messages, line 8)
New regression test from bug 11492 fails for AVR with:
Executing on host: /usr/local/avrdev/gcc/build/gcc/xgcc
-B/usr/local/avrdev/gcc/build/gcc/
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr11492.c -Wsign-compare
-DSTACK_SIZE=2048
--- Comment #1 from eric dot weddington at atmel dot com 2008-10-30 18:56
---
Bug caused by:
2008-10-29 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR 11492
* gcc.dg/pr11492.c: New.
* g++.dg/warn/pr11492.C: New.
Manuel, could you take a look at this?
--
eric
--- Comment #2 from manu at gcc dot gnu dot org 2008-10-30 19:04 ---
I don't know how to compile/test AVR. Is it in the CompileFarm?
To anyone with more knowledge on AVR, any suggestion what could cause this? Is
there any special about signed/unsigned multiplication on AVR?
--
manu
--- Comment #3 from eric dot weddington at atmel dot com 2008-10-30 19:57
---
(In reply to comment #2)
I don't know how to compile/test AVR. Is it in the CompileFarm?
To anyone with more knowledge on AVR, any suggestion what could cause this? Is
there any special about
Fortran 2003 allows all kinds for arguments (- please re-check).
For i8 the library already contains: random_seed_i8. How to handle i16?
Note: One still needs to support calls with different integer types, esp. if
one needs to modify the variable (- convert back). [Unless there can be only
one
--- Comment #4 from manu at gcc dot gnu dot org 2008-10-30 20:17 ---
(In reply to comment #3)
I don't know if it is in the Compile Farm, or not. But I can test for you.
I need a way to debug this. I have no idea what the issue is.
Note that AVR has 8-bit chars, 16-bit ints and
--- Comment #1 from kargl at gcc dot gnu dot org 2008-10-30 20:20 ---
(In reply to comment #0)
Fortran 2003 allows all kinds for arguments (- please re-check).
Not according to my draft of F2003.
SIZE (optional) shall be scalar and of type default integer. It is an
INTENT (OUT)
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37962
The following code snippet triggers an ICE on mainline:
void foo()
{
(auto) { 0 };
}
bug.cc: In function 'void foo()':
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
The bug appeared with the
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37963
--- Comment #5 from manu at gcc dot gnu dot org 2008-10-30 20:27 ---
(In reply to comment #3)
Note that AVR has 8-bit chars, 16-bit ints and pointers, 32-bit longs.
Just a guess, given the above: for unsigned char b, b*1000 is signed integer
and it may overflow, so probably this is
The following code snippet triggers an ICE on mainline:
struct A
{
operator auto();
};
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
The bug appeared with the patches for the new 'auto'
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37964
The following code snippet triggers an ICE on mainline:
int i = *(auto*)0;
bug.cc:1: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_type_parm in lookup_conversions,
at cp/search.c:2459
The following code snippet triggers an ICE on mainline:
templateint struct A
{
auto i;
};
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
The bug appeared with the patches for the new 'auto'
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37965
The following code snippet triggers an ICE on mainline:
==
struct A {};
bool b = (auto (A::*)())0;
==
bug.cc:3: internal compiler error: in type_contains_placeholder_1, at
tree.c:2600
Please submit a full bug report, [etc.]
The bug
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37966
--- Comment #6 from eric dot weddington at atmel dot com 2008-10-30 20:42
---
(In reply to comment #5)
(In reply to comment #3)
Note that AVR has 8-bit chars, 16-bit ints and pointers, 32-bit longs.
Just a guess, given the above: for unsigned char b, b*1000 is signed integer
--- Comment #4 from pault at gcc dot gnu dot org 2008-10-30 20:47 ---
Subject: Bug 37749
Author: pault
Date: Thu Oct 30 20:45:09 2008
New Revision: 141467
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141467
Log:
2008-10-30 Mikael Morin [EMAIL PROTECTED]
PR
--- Comment #14 from pault at gcc dot gnu dot org 2008-10-30 20:47 ---
Subject: Bug 37903
Author: pault
Date: Thu Oct 30 20:45:09 2008
New Revision: 141467
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141467
Log:
2008-10-30 Mikael Morin [EMAIL PROTECTED]
PR
The following code snippet triggers an ICE on mainline:
==
auto foo();
==
bug.cc:1: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
The bug appeared with the patches for the new 'auto' semantics.
--
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37967
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-30 20:58 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-30 20:58 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-30 20:59 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Using auto as template parameter triggers ICEs in lots of different
places on mainline, e.g.
==
templatetypename struct A
{
enum { e };
};
Aauto a;
==
bug.cc: In instantiation of 'Aauto':
bug.cc:6: instantiated from here
bug.cc:2:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37968
CFLAGS=-O2 -funswitch-loops for OpenOffice.org build cause this:
# LC_ALL=C g++ -Wreturn-type -fmessage-length=0 -c -O2 -fno-strict-aliasing
-Wuninitialized -DENABLE_LAYOUT=0 -I. -I../../unxlngx6.pro/inc/base3d
-I../inc -I../../inc/pch -I../../inc -I../../unx/inc -I../../unxlngx6.pro/inc
-I.
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-30 21:00 ---
Confirmed. (This maybe artificially raises the regression count - can we group
the auto related ICEs, that may be even similar?)
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-30 21:00 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-30 21:00 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #30 from rguenth at gcc dot gnu dot org 2008-10-30 21:04
---
i686-apple-darwin is still a primary target, so P1.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-30 21:05 ---
So, is this a target issue or a register allocator issue now? Has the costs
fix
been applied?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-30 21:06 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from manu at gcc dot gnu dot org 2008-10-30 21:17 ---
Eric,
Could you modify the testcase to use 100 instead of 1000 and run it under AVR?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37960
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-30 21:20 ---
We need preprocessed source as a testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37969
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-10-30 21:41
---
I think the problems due to the 'auto' keyword are scattered through the whole
compiler since the TEMPLATE_TYPE_PARM can propagate through the whole frontend.
Therefore these bugs merit different PRs IMHO.
--
--- Comment #31 from pinskia at gcc dot gnu dot org 2008-10-30 22:18
---
This really happens on all targets.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from spop at gcc dot gnu dot org 2008-10-30 22:41 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #7 from manu at gcc dot gnu dot org 2008-10-30 22:44 ---
The location info seems to be fixed in mainline. Nonetheless, I agree
completely with Richard. This warning belongs in the front-end. Moreover we
fail to diagnose:
const char *s = 'x' + y;
in both C and C++. Also,
--- Comment #32 from howarth at nitro dot med dot uc dot edu 2008-10-30
22:47 ---
Since the problem is that libintl.h can't be found, shouldn't we have a
toplevel check for libintl and a configure option to set the directory with
--with-libintl=%p or such? The INCL_LIBINTL set in the
--- Comment #6 from hjl dot tools at gmail dot com 2008-10-30 22:51 ---
(In reply to comment #5)
So, is this a target issue or a register allocator issue now? Has the costs
fix
been applied?
It is an IRA issue since -fno-ira is still faster with -mtune=generic.
IRA should be
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
CC||rguenther at suse dot de
Keywords|
--- Comment #3 from spop at gcc dot gnu dot org 2008-10-30 22:54 ---
Tobias, your patch looks good.
Please test with bootstrap and make check and then commit to trunk.
Thanks,
Sebastian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37943
--- Comment #2 from h dot mth at web dot de 2008-10-30 23:14 ---
Too big to attach. See:
http://geki.ath.cx/hacks/b3dgeom.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37969
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-30 23:22 ---
Created an attachment (id=16590)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16590action=view)
unincluded testcase
Fails with -O2 -funswitch-loops -m64
--
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-30 23:26 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37969
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2008-10-30
23:27 ---
Subject: Re: [4.4 Regression] libgcj linkage failure:
Incorrect library ABI version detected
On AIX, _Jv_CheckABI is invoked with version argument of 0 instead of 404000
GCC version constant.
This code (for better or worse) appeared to have built with 4.0.1. By adding
the class stuff in the template specialization the static member was actually
instantiated. With just no instantiation occurred.
g++ -v -save-temps -c tmp.cc
Using built-in specs.
Target: i486-linux-gnu
Configured with:
--- Comment #1 from keenan dot forbes at gmail dot com 2008-10-30 23:35
---
Created an attachment (id=16591)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16591action=view)
preprocessed file for ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37970
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-30 23:48 ---
Created an attachment (id=16592)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16592action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37969
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-30 23:51 ---
Confirmed. I cannot reproduce this with 4.2 or 4.4 (but maybe that just
requires a more reduced testcase).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Take:
struct foo
{
private:
templatetypename U
static bool func(const U x) {}
static bool func1(const int x) {}
public:
unsigned int Find(const int x, bool (*pFunc) (const int) = func) const {}
unsigned int Find1(const int x, bool (*pFunc) (const int) = func1) const {}
};
foo b;
void
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37971
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-31 00:13 ---
This is valid code via 8.3.6/5:
The names in the expressions are bound, and the semantics constraints are
checked, at the point where the default argument expression appears.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-31 00:35 ---
Caused by the patch which fixes PR 28588.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-31 00:38 ---
Explictly by the following new code:
{
mark_used (fn);
/* We could not check access when this expression was originally
created since we did not know at that time to which function
[EMAIL PROTECTED] tmp]cat test.cc
template typename T
class Base
{
static int foo;
};
template int Baseint::foo;
template int Basefloat::foo = 0;
[EMAIL PROTECTED] tmp]g++ -c test.cc
[EMAIL PROTECTED] tmp]nm --demangle test.o
B Basefloat::foo
[EMAIL PROTECTED] tmp]g++ -v
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu
2008-10-31 01:02 ---
Subject: Re: [F2003] random_seed - allow integer(8) for the arguments
I just checked the F2008 draft for the next standard. It says
13.7.95 RANDOM SEED ([SIZE, PUT, GET])
Description.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-31 01:04 ---
For some reason, Baseint::foo is not emitted.
Because that is only a specialization and not an instatulation.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2008-10-31
01:24 ---
Subject: Ada testsuites lack multilib support
While testing the fix for PR ada/37681, I tried to test both multilibs
(default and amd64) on i386-pc-solaris2.10, and found that I had to make
the following
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-10-31 01:40
---
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 120 matches
Mail list logo
