On Aug 5, 2005, at 9:24 PM, Canqun Yang wrote:
Hi,
Patch from Michael Matz
(http://gcc.gnu.org/ml/fortran/2005-07/msg00331.html) may partly fixes
the multiple decls problems.
That will only help with the fortran problem, the C++ front-end have
the same
issue. The C front-end have still
I have seen random "make check" failures in gcc on Linux/x86-64 SMP
machines. The log file doesn't say much except for compiler exit
status 1. When I ran the failed command by hand, it was OK.
I think the problem is in lib/remote.exp:
expect {
-i $spawn_id -timeout $timeout -re ".+" {
I finally got 4.0.1 built in msys. I must have screwed up my msys/gcc
setup because a clean install of msys and gcc-3.4.1 worked. I started
with a simple test:
main.cpp:
~~
#include
int main()
{
cout << "Hello\n";
return 0;
}
then I try and build it:
~~
Hi,
Patch from Michael Matz (http://gcc.gnu.org/ml/fortran/2005-07/msg00331.html)
may partly fixes
the multiple decls problems.
I've tested and tuned this patch. It works, small functions can be inlined
after DECL_INLINE
flags (build_function_decl in trans-decl.c) have been set for them. The
We observed that certain large C++ applications perform worse
in gcc-3.x and gcc-4.x than they did in gcc-2.95.3.
On the theory that at least some of the cause
would show up in microbenchmarks, we tried running
bench++ with both old and new toolchains.
Because we suspect that part of the regressio
Christian Joensson wrote:
warning: ./cc1-checksum.o differs
warning: ./cc1obj-checksum.o differs
warning: ./cc1plus-checksum.o differs
what does that mean?? the compare passes... and the build continues...
The checksums are used for PCH validatation. We generate md5 checksums
for each cc1 bin
Both ARM 13.9.1 and the GNAT User Guide (in Section 3.2.4 Validity
Checking) require that such reads are NOT erroneous.
It depends what "such reads" mean. 13.9.1(12) clearly says that the
result of an Unchecked_Conversion is erroneous if it isn't a valid
representation. There are some
* Richard Kenner:
> This is simply not true for Ada. Look at the definition of the 'Valid
> attribute in the standard:
>
>3. X'Valid
>
> Yields True if and only if the object denoted by X is normal
> and has a valid representation. The value of this attribute
Well, perhaps yes, perhaps no. What I don't know is if it is
actively illegal to assign 0 to an enumeration that doesn't
contain 0 as a member.
It's not "illegal", but there's no way to do it in the language without using
an Unchecked_Conversion (or similar sorts of punning). And
This is simply not true for Ada. Look at the definition of the 'Valid
attribute in the standard:
3. X'Valid
Yields True if and only if the object denoted by X is normal
and has a valid representation. The value of this attribute
is of the predefined
* Richard Henderson:
> On Fri, Aug 05, 2005 at 10:15:04PM +0200, Florian Weimer wrote:
>> TYPE_MIN_VALUE (gnu_scalar_type)
>> = gnat_to_gnu (Type_Low_Bound (gnat_entity));
>> TYPE_MAX_VALUE (gnu_scalar_type)
>> = gnat_to_gnu (Type_High_Bound (gnat_entity));
>>
>> This is wro
Giovanni Bajo wrote:
Mark,
- with your commit for PR 20142, you also committed a hunk to name-lookup.c
which is not described in the ChangeLog. It is also unclear whether it is
effectively need for that PR or not, but nonetheless it went in, so the entry
should probably be fixed.
Thanks for sp
On Fri, Aug 05, 2005 at 10:15:04PM +0200, Florian Weimer wrote:
> TYPE_MIN_VALUE (gnu_scalar_type)
> = gnat_to_gnu (Type_Low_Bound (gnat_entity));
> TYPE_MAX_VALUE (gnu_scalar_type)
> = gnat_to_gnu (Type_High_Bound (gnat_entity));
>
> This is wrong (as discussed before) and
* Richard Kenner:
> No, the language (or, more precisely, GNAT) defines them as 0 and
> 2**size - 1. Otherwise the 'Valid attribute doesn't work. Necessary
> range checks will be optimized away, too.
>
> No, enumeration types are defined as having precisely the set of
> values spe
No, the language (or, more precisely, GNAT) defines them as 0 and
2**size - 1. Otherwise the 'Valid attribute doesn't work. Necessary
range checks will be optimized away, too.
No, enumeration types are defined as having precisely the set of
values specifically listed. In the pres
* Richard Kenner:
> This is wrong (as discussed before) and is likely the cause of PR21573
> (not VRP-related, the expanders for SWITCH_EXPR look at these
> attributes, too). I'm not sure if it is safe to delete these
> assignment statmeents because TYPE_MIN_VALUE/TYPE_MAX_VAL
This is wrong (as discussed before) and is likely the cause of PR21573
(not VRP-related, the expanders for SWITCH_EXPR look at these
attributes, too). I'm not sure if it is safe to delete these
assignment statmeents because TYPE_MIN_VALUE/TYPE_MAX_VALUE are used
quite exte
* Richard Henderson:
> For the record, I believe we've addressed these issues sometime
> within the last year or two. The TYPE_MIN/MAX_VALUE for an enum
> should be set to the range truely required by the relevant language
> standards (different between C and C++).
>
> I don't know for a fact tha
The TYPE_MIN/MAX_VALUE for an enum should be set to the range truely
required by the relevant language standards (different between C and
C++).
I don't know for a fact that Ada has been adjusted for this though.
But if an Ada developer can verify that enumerations are cor
On Fri, Aug 05, 2005 at 11:57:45AM -0600, Jeffrey A Law wrote:
> IIRC the C standard does not guarantee that an object stay within
> the bounds of its enumerated type. You'll have to do some digging
> in the relevant standards.
For the record, I believe we've addressed these issues sometime
withi
On Aug 5, 2005, at 2:22 PM, James Widman wrote:
Hi all,
Something about GCC's instantiation stack messages seems curious to
me: for a given stack layer, the location in the message is not
that of the template instance name that appears in the same
message, but instead the point of insta
Hi all,
Something about GCC's instantiation stack messages seems curious to
me: for a given stack layer, the location in the message is not that
of the template instance name that appears in the same message, but
instead the point of instantiation of a template instance named in
the imme
On Fri, 2005-08-05 at 09:59 -0400, Diego Novillo wrote:
> In PR 23046 we ICE inside tree-vrp.c because fold() does not
> realize that for
>
> enum enumtype { ENUM1, ENUM2 } x;
>
> the predicate 'if (x > 1)' is always false. This causes VRP to
> create the impossible range [2, 1] for that predica
Debian GNU/Linux 3.1 using a custom-built 2.4.27 smp kernel and glibc
2.3.2.ds1-22:
$ config.guess
alphaev68-unknown-linux-gnu
$ gcc -v
Using built-in specs.
Target: alphaev68-unknown-linux-gnu
Configured with: ../gcc-4.0.1/configure --prefix=/opt/gcc-4.0.1
Thread model: posix
gcc version 4.0.1
Original Message
>From: Nicholas Nethercote
>Sent: 05 August 2005 17:15
> On Fri, 5 Aug 2005, Dave Korn wrote:
>
>>> Hallo,
>>> what must I do for becomming the GNU Fortran Compiler?
>>> Sincerely, Hans.
>>
>> To become the compiler, you must _think_ like the compiler.
>
> It's an easy
Hi Diego,
On Fri, 5 Aug 2005, Diego Novillo wrote:
> In PR 23046 we ICE inside tree-vrp.c because fold() does not
> realize that for
>
> enum enumtype { ENUM1, ENUM2 } x;
>
> the predicate 'if (x > 1)' is always false. This causes VRP to
> create the impossible range [2, 1] for that predicate.
>
On Fri, 5 Aug 2005, Dave Korn wrote:
Hallo,
what must I do for becomming the GNU Fortran Compiler?
Sincerely, Hans.
To become the compiler, you must _think_ like the compiler.
It's an easy mistake to make for Germans speaking English, because the
German verb "bekommen" means "to get, obtain
On 8/5/05, Carl Whitwell <[EMAIL PROTECTED]> wrote:
> On 8/4/05, Shaun Jackman <[EMAIL PROTECTED]> wrote:
> > Are you using an x86 host and an arm target?
>
> Actually no, my major concern at the time was the large quantity of
> legacy code with packed structures that we have on an embedded linux
Original Message
>From: [EMAIL PROTECTED]
>Sent: 05 August 2005 16:52
> Hallo,
> what must I do for becomming the GNU Fortran Compiler?
> Sincerely, Hans.
To become the compiler, you must _think_ like the compiler.
cheers,
DaveK
--
Can't think of a witty .sigline today
On Fri, Aug 05, 2005 at 05:52:20PM +0200, [EMAIL PROTECTED] wrote:
> what must I do for becomming the GNU Fortran Compiler?
>
If you are running a recent Linux distribution that includes GCC
4, you should already have it. Try 'gfortran'.
If not, you can find binaries at http://gcc.gnu.org/instal
Hallo,
what must I do for becomming the GNU Fortran Compiler?
Sincerely, Hans.
BEGIN:VCARD
VERSION:2.1
N:Karl;Hans-Volker;;;
FN:Hans-Volker Karl
BDAY:1955-11-30
ORG:Paris-Lodron-Universität Salzburg;
NOTE:Dipl. Phil. Dr. rer. nat. Präparator f. Geowissenschaften u. Medizin;
TEL;HOME;VOICE:+493616
On Fri, 5 Aug 2005, Jan Hubicka wrote:
>> I guess the web pages should be updated with something like the attached?
Yes...
> This looks fine to me. Thanks! Perhaps even cvs.html should mention
> that tree-profiling was almost fully merged and retired?
...and, yes. ;-)
Minor comments for the o
In PR 23046 we ICE inside tree-vrp.c because fold() does not
realize that for
enum enumtype { ENUM1, ENUM2 } x;
the predicate 'if (x > 1)' is always false. This causes VRP to
create the impossible range [2, 1] for that predicate.
While it would be trivial for VRP to paper over this problem, the
I haven't bootstrapped gcc on cygwin for a while now... but, using gcc cvs trunk
LAST_UPDATED: Fri Aug 5 09:05:37 UTC 2005, I get comparison warnings...:
warning: ./cc1-checksum.o differs
warning: ./cc1obj-checksum.o differs
warning: ./cc1plus-checksum.o differs
what does that mean?? the compare
On 8/4/05, Shaun Jackman <[EMAIL PROTECTED]> wrote:
> Are you using an x86 host and an arm target?
>
Actually no, my major concern at the time was the large quantity of
legacy code with packed structures that we have on an embedded linux
x86 system. I was just testing that we didn't have an issue
> On Thursday 04 August 2005 19:12, Jan Hubicka wrote:
> > > Hi,
> > > I've branches the IPA branch yesterday and re-directed current SPEC
> > > testers running tree-profiling branch (now officially retired ;) to it.
> > > ( http://www.suse.de/~aj/SPEC/amd64 ).
> > > The branch should be used for i
36 matches
Mail list logo
