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
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
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 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'
(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
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?
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
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
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
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 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
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 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, 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
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, 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
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
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
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
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
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
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
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
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
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
=
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
Hi *,
binary search revealed that r125698 breaks bootstrap on trunk for
i686-pc-linux-gnu.
Best regards,
Thomas
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
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
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
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/
31 matches
Mail list logo
