Ian Lance Taylor wrote:
Sounds like a bug.
May I code a patch on this?
Yes, please.
One way to fix this would be to convert those directories to use
automake, but it would be fine to just add config.cache to the list in
the distclean targets in {intl,fixincludes}/Makefile.in.
Ian
Than
Jonathan Turkanis <[EMAIL PROTECTED]> writes:
> I'm getting tired of this. You assumed I'm must have meant something
> else than what I plainly asked; once I mentioned that I was writing a
> book, you realized I really meant what I said.
That's pretty much it, yes.
Many years of experience have
Geoffrey Keating wrote:
> Jonathan Turkanis <[EMAIL PROTECTED]> writes:
>
>> Geoffrey Keating wrote:
>>
>>> Jonathan Turkanis <[EMAIL PROTECTED]> writes:
If you tell us what the real question is, maybe we can answer that one.
>>
>>
>> To me, that sounds like an insult: why do you think I w
Richard Henderson <[EMAIL PROTECTED]> writes:
> * builtin-types.def (BT_PTR_LONG, BT_PTR_PTR, BT_FN_BOOL, BT_FN_INT,
> BT_FN_VOID_PTRPTR, BT_PTR_FN_VOID_PTR, BT_FN_VOID_UINT_UINT,
> BT_FN_BOOL_LONGPTR_LONGPTR, BT_FN_VOID_OMPFN_PTR_UINT,
> BT_FN_VOID_OMPFN_PTR_UINT_UINT,
>
Mike Stump wrote:
> On Friday, September 16, 2005, at 10:19 AM, Jonathan Turkanis wrote:
>
>> > I think I can give you an answer which is completely correct and yet
>> > completely useless: -fvisibility=default is supported on every platform.
>>
>> Thank you -- it's not completely useless.
>
Giovanni Bajo wrote:
> Mark Mitchell <[EMAIL PROTECTED]> wrote:
>
>
>>1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting
>> on my disk.)
>>
>>2. Apply the patch, respin the release, and release it.
>>
>>3. Apply the patch, spin RC3, and go through another testing cycle.
>
>
Tom Tromey wrote:
I'm finally ready to do another classpath import,
Do you plan on another classpath import before the 4.1 release?
David Daney.
Correlating the stacktrace with CVS revealed that this was fixed a few
hours after I updated. The bug was 23929.
Ranjit, thanks for the help getting the debugger going.
TJ
> Incidentally, any time I've done this, I wanted labels on warnings
> as to what option was responsible
-fdiagnostics-show-option
[EMAIL PROTECTED] (Per Abrahamsen) wrote on 19.09.05 in <[EMAIL PROTECTED]>:
> Robert Dewar <[EMAIL PROTECTED]> writes:
>
> > Per Abrahamsen wrote:
> >
> >> The idea was that you would be sure to get all the (boolean) warnings
> >> that are relevant for your project, and can give an explicit reas
[EMAIL PROTECTED] (Joseph S. Myers) wrote on 16.09.05 in <[EMAIL PROTECTED]>:
> C++ requires (A) and provides examples of valid programs where it can be
> told whether a normalisation of UCNs is part of the implementation-defined
> phase 1 transformation. As I gave in a previous discussion,
>
>
I'm finally ready to do another classpath import, and near the last
minute I realized that the import may temporarily break the build, due
to an unfortunate interaction between the classpath Makefile and the
way cvs import works. FWIW I'd prefer to continue using cvs import
since it does seem to h
Yao Qi <[EMAIL PROTECTED]> writes:
> Make distclean can not remove intl/config.cache and fixincludes/config.cache.
>
> The configure commandline I used in GCC building is
> ../gcc-dfp-cvs-Aung-10/configure --enable-languages=c --enable-shared
> --enable-threads=posix --enable-checking --with-syst
L.S.,
The host of my domain has been forcefully upgraded to an HP zv6025,
sporting an Athlon 64 processor, 512 Mbyte of memory and 60 Gbytes
of disk.
The upgrade took so long (2.5 months) because I was determined to
run Debian AMD64 on it (the hardware was delivered next day).
Coming weekend I'l
On Wed, Sep 21, 2005 at 10:54:56AM -0400, Robert Dewar wrote:
> Daniel Jacobowitz wrote:
> >
> >I'm not 100% sure what #3 means for enumerators whose value does not
> >fit in the range of "int", but it's pretty clear that the
> >implementation is not allowed to change the type of enumerators.
>
>
Rainer Emrich <[EMAIL PROTECTED]> writes:
> /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.1-test/gcc-4.0.1-test/gcc/xgcc
> -
> -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.1-test/gcc-4.0.1-test/gcc/
> - -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/mips-sgi-irix6.5/bin/
> - -B/
I was wondering if I could get some help/advice from a testsuite expert.
I have a patch that I want to submit that makes sure elements of an
array are not given an alignment greater than their size.
See http://gcc.gnu.org/ml/gcc/2005-03/msg00729.html
This test was causing a bunch of regressions,
As a follow up to http://gcc.gnu.org/ml/gcc/2005-04/msg00461.html
I would like to improve SMS by passing data dependencies information
computed in tree-level to rtl-level SMS. Currently data-dependency graph
built for use by SMS has an edge for every two data references (i.e. it's
too conserva
Mark Mitchell <[EMAIL PROTECTED]> wrote:
> 1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting
>on my disk.)
>
> 2. Apply the patch, respin the release, and release it.
>
> 3. Apply the patch, spin RC3, and go through another testing cycle.
My feeling is that these 4.0 rele
Mark Mitchell wrote:
1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting
on my disk.)
2. Apply the patch, respin the release, and release it.
3. Apply the patch, spin RC3, and go through another testing cycle.
I vote for option 3., not 1. and also not 2. (sorry ;)
Pao
"Gaurav Gautam, Noida" <[EMAIL PROTECTED]> writes:
> Does -fshort-enum guides the size of enumeration type or the size of
> enumerator constant ?
An enumerator constant is not an object, thus it has no size of its own.
Since the enumerator constants are of type int, not the enum type,
-fshort-enu
> 1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting
>on my disk.)
Let's drop-kick this sucker to the ftp server already.
>Has Benjamin applied his patch on the 4.0 branch?
I have. I am awaiting solaris test details.
-benjamin
Daniel Jacobowitz wrote:
I'm not 100% sure what #3 means for enumerators whose value does not
fit in the range of "int", but it's pretty clear that the
implementation is not allowed to change the type of enumerators.
Of course an implementation can do whatever it likes in response
to switches,
> So, my options are:
>
> 1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting
>on my disk.)
>
> 2. Apply the patch, respin the release, and release it.
>
> 3. Apply the patch, spin RC3, and go through another testing cycle.
>
> My current plan is (2) because I think that this
On Wed, 2005-09-21 at 16:40 +0800, Eric Fisher wrote:
> Hi,
>
> There is a little progress. I find it's concerned with gcc optimize.
> When I change the option -O2 to -O0, it passes the make. Of
> course, I'd like to say there are something wrong in my backend.
> But, can somebody give me any clue
On Wed, Sep 21, 2005 at 07:03:49PM +0530, Gaurav Gautam, Noida wrote:
> Thanks for the reply,
>
> But why is there a difference in the output of same tc, with an old gcc
> compiler and a new version of compiler.
>
> Was there a bug in the earlier gcc.
>
> I have a doubt.
>
> Gcc manual says th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
TJ Laurenzo wrote:
> I'm getting a segmentation fault in the GCC build from today's CVS
> HEAD. I am building the suite for mingw using a cross compiler from
> Linux. This setup was working fine prior to updating to the latest
> CVS head today. My o
I'm soliciting feedback regrading a problem in the 4.0.2 release.
PR 23993 is a rejects-valid C++ PR that represents a regression from
GCC 4.0.1. That's particularly unfortunate; we really want to avoid
introducing new breakage on the release branch.
It is, sadly, more fallout from my static d
Thanks for the reply,
But why is there a difference in the output of same tc, with an old gcc
compiler and a new version of compiler.
Was there a bug in the earlier gcc.
I have a doubt.
Gcc manual says that
"-fshort-enums
Allocate to an enum type only as many bytes as it needs for the
dec
On Wed, Sep 21, 2005 at 05:46:58PM +0530, Gaurav Gautam, Noida wrote:
> int main()
> {
> enum aa {
> a = 0, b =127 , c
> };
>
> printf("size = %d %d %d\n", sizeof(a),sizeof(b), sizeof(c));
> printf("value= %d %d %d\n", a,b,c);
> return 0;
> }
>
Hi,
I have compiled a testcase
int main()
{
enum aa {
a = 0, b =127 , c
};
printf("size = %d %d %d\n", sizeof(a),sizeof(b), sizeof(c));
printf("value= %d %d %d\n", a,b,c);
return 0;
}
On gcc (GCC) 4.1.0 20050915 (experimental) with the followi
On Wed, 2005-09-21 at 10:51 +0200, Paolo Bonzini wrote:
> Ernest L. Williams Jr. wrote:
> > Hi,
> >
> > The following code fragment is now causing problems under gcc 4.0.1
> > Everything is perfect under "gcc version 3.4.3"
> > Any recommended work-arounds?
> > = code fragment=
Ernest L. Williams Jr. wrote:
Hi,
The following code fragment is now causing problems under gcc 4.0.1
Everything is perfect under "gcc version 3.4.3"
Any recommended work-arounds?
= code fragment==
#ifndef __LOC_PV_FACTORY_H__
#define __LOC_PV_
Hi,
There is a little progress. I find it's concerned with gcc optimize.
When I change the option -O2 to -O0, it passes the make. Of
course, I'd like to say there are something wrong in my backend.
But, can somebody give me any clue?
Thanks.
Eric
Andrew Pinski <[EMAIL PROTECTED]> wrote on 20/09/2005 18:09:20:
>
> On Sep 20, 2005, at 3:01 AM, Dorit Naishlos wrote:
>
> > We've had the testcase below in autovect-branch for a while, testing
> > that
> > the 3 loops get vectorized. On mainline the third loop now gets
> > eliminated
> > by DC
35 matches
Mail list logo
