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
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
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_
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=
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, 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;
> }
>
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
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
-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
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
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
> 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
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,
> 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
"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
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
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
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
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,
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/
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.
>
>
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
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
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
[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,
>
>
[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
> Incidentally, any time I've done this, I wanted labels on warnings
> as to what option was responsible
-fdiagnostics-show-option
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
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.
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.
>
>
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.
>
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,
>
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
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
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
35 matches
Mail list logo
