On Wed, 13 Jun 2007, Kenneth Zadeck wrote:
> Richard Guenther wrote:
> > On Tue, 12 Jun 2007, Richard Guenther wrote:
> >
> >
> >> On ia64 SPEC2000 I see fma3d and applu now miscompare.
> >>
> >
> > On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
> >
> > /gcc/spec/sb-haydn-fdo-64/
Hi,
between r125680 and r125703 bootstrap is broken on trunk for at least
i686-pc-liunx-gnu.
checking whether gcc supports -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings... no
configure: error: unknown check category release,yes
make[2]: *** [configure-stage1-g
I am pleased to announce that the GCC Steering Committee has
appointed Ian Taylor as non-algorithmic Blanket/Global Write Privileges
maintainer.
Please join me in congratulating Ian on his
new role. Please update your listings in the MAINTAINERS file.
Happy hacking!
David
I am pleased to announce that the GCC Steering Committee has
promoted Diego Novillo to middle-end maintainer and appointed him
non-algorithmic Blanket/Global Write Privileges maintainer.
Please join me in congratulating Diego on his
new role. Please update your listings in the MAI
Hi *,
binary search revealed that r125698 breaks bootstrap on trunk for
i686-pc-linux-gnu.
Best regards,
Thomas
Sorry, I committed the wrong version of the patch.
2007-06-14 Paolo Bonzini <[EMAIL PROTECTED]>
* configure.ac: Fix earlier checkin.
* configure: Regenerate.
Index: configure.ac
===
--- configure.ac(revisi
On 6/14/07 6:37 AM, David Edelsohn wrote:
> Please update your listings in the MAINTAINERS file.
Thanks. Committed.
* MAINTAINERS: Add self as middle-end maintainer and
non-algorithmic global write maintainer.
Index: MAINTAINERS
=
Basile STARYNKEVITCH wrote:
Hello all,
While trying to compile the trunk gcc (svn rev 125703) on my
Debian/Sid/AMD64, I got the following problem,
Sorry for the noise. This is being discussed on the gcc-patch list.
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00940.html
http://gcc.gnu.org
Hello all,
While trying to compile the trunk gcc (svn rev 125703) on my
Debian/Sid/AMD64, I got the following problem, which happens even when
configuring in an empty build directory _Obj/
cd /usr/src/Lang/gcc-trunk/_Obj
/usr/src/Lang/gcc-trunk/configure '--disable-multilib'
'--program-suff
We are ready to submit a patch for Intel BID library. We have 3 small
patches and a 2.4MB bz2 tar file for Intel BID library itself. I can
1. Send a 2.4MB bz2 tar file to gcc-patches.
2. Create a bid branch in svn.
3. Put it on kernel.org.
Which one is preferred?
With Intel BID library, we got 2
David Edelsohn <[EMAIL PROTECTED]> writes:
> I am pleased to announce that the GCC Steering Committee has
> appointed Ian Taylor as non-algorithmic Blanket/Global Write Privileges
> maintainer.
>
> Please join me in congratulating Ian on his
> new role. Please update your listings in
On 6/14/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
On Wed, 13 Jun 2007, Kenneth Zadeck wrote:
> Richard Guenther wrote:
> > On Tue, 12 Jun 2007, Richard Guenther wrote:
> >
> >
> >> On ia64 SPEC2000 I see fma3d and applu now miscompare.
> >>
> >
> > On x86_64 186.wupwise ICEs with -O2 -ffas
Hello!
There was no response from libc maintainers about changing the type of
soft-fp compares into CMPtype. This type should be defined to mode(word)
or at least we should be able to redefine it outside the soft-fp, in
target dependent sfp-target.h. As this is major obstacle in further
devel
Andrew Pinski wrote:
> If you could review the C++ front-end changes, that would be nice.
Would you please point me at a URL for those changes?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
On Thu, 14 Jun 2007, Uros Bizjak wrote:
> There was no response from libc maintainers about changing the type of soft-fp
> compares into CMPtype. This type should be defined to mode(word) or at least
Take that matter with the glibc maintainers directly to RMS.
> we should be able to redefine it
On Thu, Jun 14, 2007 at 06:10:52PM +0200, Uros Bizjak wrote:
> There was no response from libc maintainers about changing the type of
> soft-fp compares into CMPtype. This type should be defined to mode(word)
> or at least we should be able to redefine it outside the soft-fp, in
> target depende
I'm still seeing two testsuite regressions for Xtensa compared to last
Friday:
gcc.c-torture/execute/920501-6.c
gcc.c-torture/execute/930921-1.c
Both tests fail at -O3 with "internal compiler error: in get_biv_step,
at loop-iv.c:792". Neither the Xtensa port nor the loop-iv.c code has
changed s
On Thu, 2007-06-14 at 06:30 -0700, H. J. Lu wrote:
> With Intel BID library, we got 2 failures in unmodified DFP tests,
> fe-convert-1.c and fe-convert-2.c, due to different exceptions
> in Intel BID library vs. libdecnumber. The differences are
Go ahead and make those test changes.
Janis
On 6/14/07, Joe Buck <[EMAIL PROTECTED]> wrote:
On Thu, Jun 14, 2007 at 06:10:52PM +0200, Uros Bizjak wrote:
> There was no response from libc maintainers about changing the type of
> soft-fp compares into CMPtype. This type should be defined to mode(word)
> or at least we should be able to redef
On Thu, Jun 14, 2007 at 10:13:49AM -0700, Janis Johnson wrote:
> On Thu, 2007-06-14 at 06:30 -0700, H. J. Lu wrote:
>
> > With Intel BID library, we got 2 failures in unmodified DFP tests,
> > fe-convert-1.c and fe-convert-2.c, due to different exceptions
> > in Intel BID library vs. libdecnumber.
On Thu, Jun 14, 2007 at 09:36:46AM -0700, Joe Buck wrote:
> The FSF has objected in the past to any discussions of forking glibc. RMS
> would (I believe) argue that what you're talking about is a glibc bug and
> glibc should fix it, we shouldn't fork the routine to work around it.
It can hardly b
Jakub Jelinek wrote:
On Thu, Jun 14, 2007 at 09:36:46AM -0700, Joe Buck wrote:
The FSF has objected in the past to any discussions of forking glibc. RMS
would (I believe) argue that what you're talking about is a glibc bug and
glibc should fix it, we shouldn't fork the routine to work around
On Thu, Jun 14, 2007 at 08:07:32PM +0200, Uros Bizjak wrote:
> > It can hardly be considered a glibc bug when GCC changed this incompatibly
> > a year ago, up to GCC 4.1.x inclusive __eqtf2 etc. used SItype (i.e. int on
> > all architectures glibc cares about).
> >
> > That said, as none of the rou
On Thu, Jun 14, 2007 at 08:07:32PM +0200, Uros Bizjak wrote:
> I belive that by changing mentioned typedef line of soft-fp.h into
>
> #ifndef CMPtype
> #define CMPtype int
> #endif
>
> would satisfy everybody. Is this acceptable for glibc?
Yes.
Though, please use CMPtype not only for ret
Jakub Jelinek wrote:
On Thu, Jun 14, 2007 at 08:07:32PM +0200, Uros Bizjak wrote:
I belive that by changing mentioned typedef line of soft-fp.h into
#ifndef CMPtype
#define CMPtype int
#endif
would satisfy everybody. Is this acceptable for glibc?
Yes.
Though, please use CMPty
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> It seems like SItype would be sufficient everywhere, and I can't see
> any obvious reason it would be slower.
What about 16-bit targets?
(Because this concerns policy rather than code, I've cc'ed it to the
main gcc list rather than the patches list.)
FX Coudert wrote:
I noticed in MAINTAINERS that there is a new category of "Non-
Autopoiesis Maintainers" (I certainly missed the original
announcement), for maintainers who canno
On Thu, Jun 14, 2007 at 08:48:22PM -0700, Brooks Moses wrote:
>
> I have no objection to this as a custom for GFortran, certainly -- I
> think it's a very good idea, and as a custom I very much support it.
> However, there have historically been reasonable exceptions to it. In
> particular, I'
At 09:40 PM 6/14/2007, Steve Kargl wrote:
On Thu, Jun 14, 2007 at 08:48:22PM -0700, Brooks Moses wrote:
> I have no objection to this as a custom for GFortran, certainly -- I
> think it's a very good idea, and as a custom I very much support it.
> However, there have historically been reasonable
On Thu, Jun 14, 2007 at 10:28:58PM -0700, Brooks Moses wrote:
> At 09:40 PM 6/14/2007, Steve Kargl wrote:
> >On Thu, Jun 14, 2007 at 08:48:22PM -0700, Brooks Moses wrote:
> >> I have no objection to this as a custom for GFortran, certainly -- I
> >> think it's a very good idea, and as a custom I ve
Mostly what I want is some discussion about what we expect this to
mean as a formal rule, and how strictly we're expecting to
interpret it. For values of "we" meaning both the GFortran
maintainers, and the wider GCC maintainer community.
I agree with your intrepretation of this rule exactl
31 matches
Mail list logo
