Jan Hubicka <[EMAIL PROTECTED]> writes:
>> Jan Hubicka <[EMAIL PROTECTED]> writes:
>>
>> >> On Mon, Aug 21, 2006 at 05:25:09PM -0400, Andrew Pinski wrote:
>> >> > >
>> >> > > On Aug 21, 2006, at 11:59 AM, Andreas Jaeger wrote:
>> >> > > > Trunk fails to build for me with:
>> >> > >
>> >> > > Ma
Is it the expected behavior for dejagnu to always report warnings
as errors in the "test for excess errors" check? Is this a design
decision or just how dejagnu currently works? I ask because the
current output of "test for excess errors" when a FAIL occurs can
be inaccurate. With -m64 on Darwin
On 23 August 2006 13:58, Jack Howarth wrote:
>Is it the expected behavior for dejagnu to always report warnings
> as errors in the "test for excess errors" check?
To be precise, what it checks for is excess messages output to stderr. It
doesn't discriminate whether they are errors, warning
On Wed, Aug 23, 2006 at 02:04:23PM +0100, Dave Korn wrote:
> > I ask because the
> > current output of "test for excess errors" when a FAIL occurs can
> > be inaccurate. With -m64 on Darwin we currently get a significant number
> > of false positives in the fortran testsuite due to linker warnings
On 23 August 2006 14:13, Daniel Jacobowitz wrote:
> On Wed, Aug 23, 2006 at 02:04:23PM +0100, Dave Korn wrote:
> There is a prune routine in the test harness for warnings we do not
> care about.
Which reminds me, one slight omission from my earlier post:
> Is this a design decision or just ho
Daniel,
I assume the prune routine in the test harness is in dejagnu and
not in any gcc provided files that dejagnu uses? The actual warnings
that we are seeing with ld64 on Darwin are described in...
http://gcc.gnu.org/ml/fortran/2006-08/msg00250.html
These warnings (which are of unknown orig
On Wed, Aug 23, 2006 at 09:21:45AM -0400, Jack Howarth wrote:
> Daniel,
>I assume the prune routine in the test harness is in dejagnu and
> not in any gcc provided files that dejagnu uses?
I don't know; you're welcome to look for it. It's probably named
prune_warnings or something like that.
Daniel,
Thanks. I'll take a stab at finding the harness routine tonight.
Currently on Darwin, we have 38 errors at '-m64 -O3 -g' which are
likely all due to the linker warnings issued when common blocks are
involved in the fortran testsuite...
http://gcc.gnu.org/ml/fortran/2006-08/msg00214.htm
On Wed, Aug 23, 2006 at 08:47:32AM +0200, Mark Wielaard wrote:
> On Tue, 2006-08-22 at 16:33 -0400, Carlos O'Donell wrote:
> > Has the 'make html' target been fixed? I would like to enable this
> > target so that html support doesn't bitrot.
>
> No sorry. I didn't know it was broken. I see that it
Pat Haugen <[EMAIL PROTECTED]> wrote on 08/21/2006 01:22:25 PM:
> Jan Hubicka <[EMAIL PROTECTED]> wrote on 08/19/2006 07:51:42 PM:
>
> > Hi,
> > this patch at least hides the ugly details within some abstraction so
we
> > can eventally go for propagating reliability information across CFG if
> >
My simulator now segfaults for every single execution test built with
mainline; when I try gdb, it also segfaults,
somewhere in the dwarf handling code.
Unless someone comes up with a viable concept how to maintain sh64
support in gcc, I think we have to deprecate
it now, since at the time of th
On 23 August 2006 14:23, Daniel Jacobowitz wrote:
> On Wed, Aug 23, 2006 at 09:21:45AM -0400, Jack Howarth wrote:
>> Daniel,
>>I assume the prune routine in the test harness is in dejagnu and
>> not in any gcc provided files that dejagnu uses?
>
> I don't know; you're welcome to look for it.
Hey, just cause SoC is over doesn't mean i'm not happy to answer your
questions to the degree I can, so please, keep cc'ing me.
That's great, thanks :)
> I'd like to get your feedback about design of frontend-specific type
> tag infrastructure in gengtype.
>
> First of all, how things are done
Dave,
I noticed this in the gcc/libmudflap/ChangeLog...
* testsuite/lib/libmudflap.exp (libmudflap-init): Add extra libraries.
(prune_gcc_output): Add glibc static linking warnings.
which makes me think I can just add a line like...
regsub -all {(^|\n)[^\n]*can't find atom fo
On Wed, Aug 23, 2006 at 12:21:08PM -0400, Jack Howarth wrote:
> Dave,
> I noticed this in the gcc/libmudflap/ChangeLog...
>
> * testsuite/lib/libmudflap.exp (libmudflap-init): Add extra libraries.
> (prune_gcc_output): Add glibc static linking warnings.
>
> which makes me thin
Laurynas Biveinis wrote:
>> Hey, just cause SoC is over doesn't mean i'm not happy to answer your
>> questions to the degree I can, so please, keep cc'ing me.
>
> That's great, thanks :)
>
>>> I'd like to get your feedback about design of frontend-specific type
>>> tag infrastructure in gengtype.
Hello Jack,
I has been almost a week since you mailed your question. I hope my
answer is still relevant.
Jack Howarth wrote:
Has anyone tried building python 2.4.3 using gcc trunk? The current gcc 4.2
seems to introduce a new regression in the Python testsuite...
test_builtin
test test_bu
I went through the ChangeLog (2006 only so far) to identify command
line options that should be documented in the GCC 4.2 changes page at
http://gcc.gnu.org/gcc-4.2/changes.html
It would be nice if people listed below could submit patches for the
command line options they added/removed during the
Michael,
If I build python 2.4.3 with the default compiler flags under gcc trunk
on MacOS X 10.4.7, I get the following...
Python 2.4.3 (#1, Aug 23 2006, 17:39:08)
[GCC 4.2.0 20060822 (experimental)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import s
> So your analysis appears to be correct. Even more interesting is
> that if I build python 2.4.3 with Apple's gcc from Xcode 2.3, the
> correct results are obtained without the need to resort to the
> -fwrapv flag. So either we have a regression in gcc trunk or
> Apple has a patch in their branch
>
>
> Pat Haugen <[EMAIL PROTECTED]> wrote on 08/21/2006 01:22:25 PM:
>
> > Jan Hubicka <[EMAIL PROTECTED]> wrote on 08/19/2006 07:51:42 PM:
> >
> > > Hi,
> > > this patch at least hides the ugly details within some abstraction so
> we
> > > can eventally go for propagating reliability informati
On Aug 23, 2006, at 3:27 PM, Jack Howarth wrote:
The only difference I can see between the builds with gcc trunk and
Apple's gcc is that I have to remove the -Wno-long-double -no-cpp-
precomp flags the build with gcc trunk (because they don't exist).
My only comment would be to remove -Wno-lo
Janis,
Thanks for the pointers. Adding the following patch
--- gcc-4.2-20060822/gcc/testsuite/lib/prune.exp.org2006-08-23
18:33:56.0 -0400
+++ gcc-4.2-20060822/gcc/testsuite/lib/prune.exp2006-08-23
18:41:28.0 -0400
@@ -43,6 +43,7 @@
regsub -all "(^|\n)\[^\
Mike,
I managed to suppress the linker warnings which occur with "-m64 -g" with
COMMON blocks
by applying the following patch...
--- gcc-4.2-20060822/gcc/testsuite/lib/prune.exp.org2006-08-23
18:33:56.0 -0400
+++ gcc-4.2-20060822/gcc/testsuite/lib/prune.exp2006-08-23
18:
Jack Howarth wrote:
import sys
divmod(-sys.maxint-1, -1)
(0, -2147483648)
If I add the -fwrapv flag to BASECFLAGS in the Makefile, I get...
(2147483648L, 0L)
So your analysis appears to be correct. Even more interesting is
that if I build python 2.4.3 with Apple's gcc fro
Sorry for the formatting weirdness. I should be more careful with
Thunderbird's auto-conversion to plain text. Here is the correct
version:
Jack Howarth wrote:
import sys
divmod(-sys.maxint-1, -1)
(0, -2147483648)
If I add the -fwrapv flag to BASECFLAGS in the Makefile, I get...
On Aug 23, 2006, at 4:57 PM, Jack Howarth wrote:
...which is quite nice since it is the same number of failures as
with -m32 with three additional unexpected passes.
Excellent. Nice to hear.
What I found was that I could set a breakpoint at assign.f90:1 but
when I tried to run the program
Michael,
I submitted a bug report to the python developers. Do you
have a suggestion on how...
/* (-sys.maxint-1)/-1 is the only overflow case. */
if (y == -1 && x < 0 && x == -x)
return DIVMOD_OVERFLOW;
...should be reworked? Since I am tickling the bug at the
x < 0 && x == -x
That is the issue right there really, doing x == -x will never be true
because -x will overflow for INT_MIN.
Doing "((unsigned)x) == -(unsigned)x" should fix the issue.
Note this is unrelated to Darwin or any processor really too.
-- Pinski
Andrew,
Thanks. The change...
--- Python-2.4.3/Objects/intobject.c.org2006-08-23 23:49:33.0
-0400
+++ Python-2.4.3/Objects/intobject.c2006-08-23 23:52:01.0 -0400
@@ -479,7 +479,7 @@
return DIVMOD_ERROR;
}
/* (-sys.maxint-1)/-1 is the
Jack Howarth wrote:
Andrew,
Thanks. The change...
--- Python-2.4.3/Objects/intobject.c.org2006-08-23 23:49:33.0
-0400
+++ Python-2.4.3/Objects/intobject.c2006-08-23 23:52:01.0 -0400
@@ -479,7 +479,7 @@
return DIVMOD_ERROR;
}
/* (-s
Paolo Bonzini wrote:
Jack Howarth wrote:
+ if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x)
return DIVMOD_OVERFLOW;
or just a much clearer
if (y == -1 && x == INT_MIN)
return DIVMOD_OVERFLOW;
(possibly with a #include at the top).
Nit picking -
"x" i
32 matches
Mail list logo
