On 2005-06-16 17:54:03 -0400, Robert Dewar wrote:
> As you well know, not everyone agrees this is a bug, and this does
> not have to do with performance. Saying over and over again that you
> think it is a bug does not make it so.
I haven't seen any correct argument why it could not be a bug.
Sayi
On Thursday, June 16, 2005, at 03:16 AM, [EMAIL PROTECTED] wrote:
I'm a new guy in gcc mailing list I've been studying gcc for 2 months.
Why?
My problem is there are so much symbol/function/API in gcc.
You have two choices ignore what you aren't interested in learning, or
learn it all. Y
On Thursday, June 16, 2005, at 10:26 AM, Roberto Bagnara wrote:
OK, you did not have time to check the standard... perhaps it is the
word "bugmaster" that generates unreasonable expectations.
Think of them as BugMonkeys if it helps. :-)
On Friday, June 17, 2005, at 05:59 PM, Paul Schlie wrote:
- If the semantics of an operation are "undefined", I'd agree; but if
control is returned to the program, the program's remaining specified
semantics must be correspondingly obeyed, including the those which
may utilize the resultin
On Friday, June 17, 2005, at 07:13 AM, Sergei Organov wrote:
The first thing I'd like to get some advice on is which codebase do I
use, gcc-4_0-branch?
No, mainline. If it doesn't work there, is won't work anyplace else.
:-( Once you get it working there, you can then ask for the patches,
On Tue, Jun 14, 2005 at 10:08:16PM -0700, Richard Henderson wrote:
> I suspect that one could get quite a lot of milage out of parsing
> the assembly code and turning most of it into straight GIMPLE, rather
> than into ASM_EXPRs. A great many examples of VC++ inline asms that
> I've seen were comp
Paul Schlie wrote:
(As there's nothing in the standard which enables an implementation
to subsequently disregard the resulting value of an implementation
specific operation from the best I can tell; although would welcome
someone pointing out where specifically it's allowed. As unless
On Jun 17, 2005, at 5:59 PM, Paul Schlie wrote:
From: Andrew Pinski <[EMAIL PROTECTED]>
On Jun 17, 2005, at 8:20 PM, Paul Schlie wrote:
["undefined" only provides liberties within the constrains of what
is specifically specified as being undefined, but none beyond
that.]
That is not tr
> From: Andrew Pinski <[EMAIL PROTECTED]>
> On Jun 17, 2005, at 8:20 PM, Paul Schlie wrote:
>
>> ["undefined" only provides liberties within the constrains of what
>> is specifically specified as being undefined, but none beyond that.]
>
> That is not true. Undefined means it can run "rm /"
On Jun 17, 2005, at 8:20 PM, Paul Schlie wrote:
["undefined" only provides liberties within the constrains of what
is specifically specified as being undefined, but none beyond that.]
That is not true. Undefined means it can run "rm /" if you ever invoke
the undefined code.
Thanks,
Andr
> From: Diego Novillo <[EMAIL PROTECTED]>
> On Fri, Jun 17, 2005 at 02:28:58PM -0400, Paul Schlie wrote:
>
>> int x;
>> volatile int v;
>>
>> x = (v ? 0 : INT_MAX) + 1; // [1, INT_MAX] (without -fwrapv)
>>
>> if (x <= 0) // Which may be erroneously
>> printf("%i is <= 0.",
Nathan,
I see some failures in the testsuite which appear to be related by your recent
changes to rtti.c (VECification). For instance:
FAIL: obj-c++.dg/basic.mm (test for excess errors)
Excess errors:/home/rasky/gcc/mainline/gcc/libstdc++-v3/libsupc++/exception:55:
internal compiler error: vector
GCC 4.0.1 RC2 is now available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050616
This version has the libstdc++ versioning changes, and most of the PO
file updates. The PO file that Joseph checked in today is not included,
but will be in the final release.
Please test this version
On Fri, Jun 17, 2005 at 02:28:58PM -0400, Paul Schlie wrote:
> int x;
> volatile int v;
>
> x = (v ? 0 : INT_MAX) + 1; // [1, INT_MAX] (without -fwrapv)
>
> if (x <= 0) // Which may be erroneously
> printf("%i is <= 0.", x); // optimized away, with this.
> else
> print
Paul Schlie wrote:
They need not wrap around. People that are actually on the C standards
committee have told you this multiple times.
Yes, and may clearly produce erroneous results if the value ranges
are not consistent with the factual behavior of an implementation, i.e.:
Are you li
> They need not wrap around. People that are actually on the C standards
> committee have told you this multiple times.
Yes, and may clearly produce erroneous results if the value ranges
are not consistent with the factual behavior of an implementation, i.e.:
int x;
volatile int v;
x = (v ?
Hi,
The gcc-2.95.x seems to be the last GCC version that have usable support
for small data sections (.sdata & .sdata2) on PowerPC, see PRs 9571,
17337(resolved), and finally 21571.
As my embedded project heavily relies on the advantages of using small
data sections, it makes it impossible for me
I'm running the keysigning again at GCC Summit this year. Please check
the signup sheet [1] to see if you're on it. I added people to it
if they filled in their key details on the registration form. I also
added Mark and Gaby [2]. If you want to participate and aren't currently
listed, please
On Fri, 17 Jun 2005 [EMAIL PROTECTED] wrote:
Does this look familiar to anyone? It certainly was happening
a few days ago. Shouldn't a bootstrap and regression of all
frontend be required before someone checks in a patch to the
back-end?
Indeed. The last working GCC-4.1 compiler for both M
On 6/17/05, Volker Reichelt <[EMAIL PROTECTED]> wrote:
> >
> > For two consecutive days, I have been unable to
> > build GCC mainline on i686-pc-linux-gnu:
[...]
> > I build with "--with-arch=pentium4 --disable-checking" and that
> > might explain why no one has apparently reported it yet.
>
>
--- Ian Lance Taylor wrote:
> Sanjiv Kumar Gupta <[EMAIL PROTECTED]> writes:
>
> > >>I couldn't understand why the insns 620 and 621
> are
> > >>being generated here as DI moves.
> > > I'm not sure specifically why it got a DI move
> here, but it doesn't
> > > look wrong. It's treating the st
On Fri, Jun 17, 2005 at 12:27:55AM -0400, Paul Schlie wrote:
> Upon a potential integer overflow of either it's min or max range,
> shouldn't the result be set to [min:type-min-value, max:type-max-value],
> without the necessity of any further designations?
>
If you want this behaviour, use -fwra
> Does this look familiar to anyone? It certainly was happening
> a few days ago. Shouldn't a bootstrap and regression of all
> frontend be required before someone checks in a patch to the
> back-end?
>
Indeed. The last working GCC-4.1 compiler for both MIPS and i686
was back on 20050604. The bu
[#1] The signed C integer types int, long, long long and the
corresponding unsigned types are compatible with LIA-1. If an
implementation adds support for the LIA-1 exceptional values
integer_overflow and undefined, then those types are LIA-1
co
> Hi,
>
> For two consecutive days, I have been unable to
> build GCC mainline on i686-pc-linux-gnu:
> /home/ranmath/src/gcc/gcc-20050617/gcc/config/i386/i386.c: In function
> 'ix86_expand_vector_init':
> /home/ranmath/src/gcc/gcc-20050617/gcc/config/i386/i386.
These patches
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02319.html
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00466.html
are needed (the former in at least a rudimentary backport form) in order to be
able to build a 3.4.x tree with an overlaid binutils 2.16 or newer tree. Are
there any p
> Paolo Bonsini wrote:
>> Upon a potential integer overflow of either it's min or max range,
>> shouldn't the result be set to [min:type-min-value, max:type-max-value],
>> without the necessity of any further designations?
>
> No.
>
> [10, INT_MAX] + [ 1, 1 ] == [ 11, INT_MAX ] because of the famo
Paul Schlie wrote:
Upon a potential integer overflow of either it's min or max range,
shouldn't the result be set to [min:type-min-value, max:type-max-value],
without the necessity of any further designations?
No.
[10, INT_MAX] + [ 1, 1 ] == [ 11, INT_MAX ] because of the famous signed
int ov
28 matches
Mail list logo
