Mark Mitchell wrote:
> 1. Move the ChangeLog entries on the 4.0 branch to accurately reflect
> the released bits.
>
> 2. Modify Bugzilla to reset the target milestone for the three PRs in
> question.
>
> 3. Modify gcc_release to prevent this situation in future.
These steps have now been taken.
Dear Amazon member,
Due to concerns we have for the safety and integrity of the Amazon community we
have issued this warning.
Per the User Agreement, Section 9, we may immediately issue a warning,
temporarily suspend, indefinitely suspend or terminate your membership and
refuse to provide ou
Eric Botcazou wrote:
> Agreed. But I'm requesting a "caveat" note about the Solaris regression here:
> http://gcc.gnu.org/gcc-4.0/changes.html#4.0.2
> mentioning the workaround (g++ -pthreads) and the link:
> http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00984.html
Done.
Thanks,
--
Mark Mitche
On Saturday 01 October 2005 01:02, George White wrote:
> Frankly, I don't care what standards say is no longer acceptable
> syntax.
I think this is a nice summary of your mail.
Fortunately, most of our users do care about this.
Gr.
Steven
> Done.
Thank you very much.
--
Eric Botcazou
Hello,
I am an embedded software developer and I am interested in using GCC as a
cross-compiler on the Cygwin/Windows platform. I would like to know which
lists I should subscribe to in order to discuss this effort.
Thank you,
--
Brian
On 10/1/05, Brian Rose <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I am an embedded software developer and I am interested in using GCC as a
> cross-compiler on the Cygwin/Windows platform. I would like to know which
> lists I should subscribe to in order to discuss this effort.
you might want to ha
Laurent GUERBY wrote:
However I see no reason why Osint body elaboration must be done
before Osint.M body elaboration, it seems to me that the
binder could perfectly choose to elaborate Osint.M body
before Osint body, and this would leave Running_Program
with the "wrong" value Rainer observes wh
(I indeed forgot about the static model which is the default for GNAT)
On Sat, 2005-10-01 at 08:37 -0400, Robert Dewar wrote:
> [...] You can of course check the order of elaboration by
> looking at it. I would be surprised if there were a
> bug in the statid elab model for such a simple case,
> a
To recap the current state as far as I know it:
The disclaimers I sent in for both Asher Langton and myself
were the same wording as the one from Christoper Michael Chambreau.
We did that to make it easier to get the GNU Assignment. :-)
Secondly, the letter I sent to the copyright clerk containe
On Monday 26 September 2005 10:38, Paolo Bonzini wrote:
> Right now, I am thinking more
> about shuffling the pass order. One possibility that comes to mind is
> GCSE+fwprop+CSE, where GCSE could work out the common code for loading
> the address, and fwprop/CSE could do the addressing mode select
> On Fri, Sep 30, 2005 at 04:31:59PM -0700, Dale Johannesen wrote:
> > No, there isn't, but it might be a smaller change to add a new
> > constraint
> > having constraints tied to specific constants is pretty ugly, and so is
> > having (if (constant value==0)) in a lot of patterns..,,
>
> Tha
Richard Guenther <[EMAIL PROTECTED]> writes:
> Hi!
>
> On current mainline-gcc install-pkglibLTLIBRARIES fails re-linking
> libjawtgnu:
>
> make[5]: Entering directory
> `/usr/src/packages/BUILD/gcc-4.1.0-20050929/obj-i586-suse-linux/i586-suse-linux/libjava/classpath/native/jawt'
> test -z "/usr/
Laurent GUERBY wrote:
If I'm reading it correctly, osint body is elaborated after osint.m one,
so there seem to be a bug.
I agree, looks like a bug
May be it doesn't trigger because in some
condition/platform no code is needed at runtime for the default
initialization of integer variables b
On Sep 30, 2005, Benjamin Redelings <[EMAIL PROTECTED]> wrote:
> Recently I've been getting strange errors on ill-formed code. It looks
> as if the compiler is not stopping after an error, but running the
> assembler anyway:
Are you compiling with -pipe, by any chance?
--
Alexandre Oliva
int f(int *);
int verbosity;
int *arr;
int last;
void g ()
{
int i;
if (last < 4000) {
if (verbosity >= 4) f(&verbosity);
for (i = 0; i <= last; i++) arr[i] = i;
}
}
If last != 0, arr+i cannot point to last for any i,
as last is not part
Snapshot gcc-4.1-20051001 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20051001/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 CVS branch
with the following options: -D2005-10-01 17:43 UTC
You'll
> "Andreas" == Andreas Jaeger <[EMAIL PROTECTED]> writes:
Andreas> So, the problem should be reproducable in the following cases: Using
Andreas> DESTDIR and having no libgtkpeer installed in a standard path. Tom,
Andreas> this still appears with todays sources and worked before the classpath
This used to always be off, but the email preferences code in the new
bugzilla actually works properly, so i let it take care of it.
To disable getting emails about this, uncheck the boxes for
"Any field not mentioned above changes" in your email preferences.
Andreas Jaeger <[EMAIL PROTECTED]> writes:
> Looking closer at this, it seems to be a problem with DESTDIR that you
> use. libgtkpeer is installed - but it's installed in
> /var/tmp/gcc-mainline-4.1.0_20050929-build/usr/lib/classpath/ - and
> that path is not added to the Link line.
That's due t
In C++, when we have an automatic array with variable initializers:
void bar(char[4]);
void foo(char a, char b, char c, char d) {
char x[4] = { a, b, c, d };
bar(x);
}
the C++ FE generates 32-bit store(s) of 0 for the entire array,
followed by stores
of the individual elements. In the case
On Fri, Sep 30, 2005 at 09:21:01PM -0400, Andrew Pinski wrote:
> On Sep 30, 2005, at 8:46 PM, Neil Booth wrote:
> >nmake Technical Support wrote:-
> >
> >>This is to request reinstatement of the -I- command line directory
> >>search option. Sorry for the late request, we only recently became
> >>a
George White wrote:
Frankly, I don't care what standards say is no longer acceptable
syntax.
The standards have existed for quite some time, giving you plenty of
time to get acquainted with the rules. Standards exist for a reason, and
if you choose not to follow them, it is not the fault of t
On Thursday 29 September 2005 17:29, Segher Boessenkool wrote:
> >int f(int *);
> >int verbosity;
> >int *arr;
> >int last;
> >
> >void g ()
> >{
> > int i;
> > if (last < 4000) {
> > if (verbosity >= 4) f(&verbosity);
> > for (i = 0; i <= last;
On Oct 1, 2005, at 5:54 PM, Dale Johannesen wrote:
In C++, when we have an automatic array with variable initializers:
void bar(char[4]);
void foo(char a, char b, char c, char d) {
char x[4] = { a, b, c, d };
bar(x);
}
Testsuite passes with this but I can believe improvements are
possibl
C++ would be a better language if the boolean type did not implicitly
convert from int. For example, many novice programmers make the
mistake.
if (i = j) dosomething(); // Should be i == j
If conversion to boolean required explicit this would all be solved. It
would mean all the old code with
>
> C++ would be a better language if the boolean type did not implicitly
> convert from int. For example, many novice programmers make the
> mistake.
>
>if (i = j) dosomething(); // Should be i == j
>
> If conversion to boolean required explicit this would all be solved. It
> would mean all
On Oct 1, 2005, at 7:29 PM, Andrew Pinski wrote:
I don't think this will work for the following code:
void foo(char a, char b) {
char x[4] = { a, b } ;
if (x[3] != 0)
abort ();
}
Duh. I thought that was too easy.
But better fix would be not call split_nonconstant_init_1 for
local de
Andrew Pinski wrote:
But any thing else would just be a violation of the C and C++ standards.
I don't see that at all, optional switches/pragmas/directives that
subset the language are in no ways violation of the standards. THe
standard only requires that you have a mode in which the standard
Hi Andrew,
I was hoping was that we could at least have a compile option. So we could
turn it on if required. I would definitely mandate it in our organization
at least. I am sure others would too.
We have a prepared list of common errors C++ novices make and the
accidental boolean is always
On Oct 1, 2005, at 11:10 PM, Dale Johannesen wrote:
But better fix would be not call split_nonconstant_init_1 for
local decls and have the front-end produce a CONSTRUCTOR which is
just like what the C front-end produces.
I'll try it.
This patch should fix the problem and also fixes FSF PR
31 matches
Mail list logo
