James E Wilson <[EMAIL PROTECTED]> wrote:
>> I would like to still get hold of the information that used to be present
at
>> that page because they were in fact very useful.
>
> This is what web search engines are for. Going to yahoo, typing gcc
> visibility, and then clicking on the "cached" lin
I have an immediate problem and a general frustration.
The immediate problem is that my lexer patches causes a test
failure in gcc.dg/cpp/direct2.c, because an error that used to
be on line 15 ("expected '=', ',', ';', 'asm' or '__attribute__'
before string constant") is now on line 13. Since the
On Thu, 10 Mar 2005 19:30:40 -0800, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Greg Schafer wrote:
>
> > This is rather critical, yet a bugmaster saw fit to remove the 4.0.0 target
> > milestone on this bug:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20166
> >
> > Any chance of making t
On Fri, 11 Mar 2005 10:07:33 +0100, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> On Thu, 10 Mar 2005 19:30:40 -0800, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> > Greg Schafer wrote:
> >
> > > This is rather critical, yet a bugmaster saw fit to remove the 4.0.0
> > > target
> > > milestone on this
* Joe Buck:
> If it is only Debian on non-shipped platforms, it would be reasonable to
> ask the Debian x64-64 people to apply the one-line patch to glibc pointed
> to by the PR. It could be a hassle for them now because of the sarge
> freeze, though, so maybe fixincludes would be the way to go.
James E Wilson <[EMAIL PROTECTED]> wrote:
>> I would like to still get hold of the information that used to be present
at
>> that page because they were in fact very useful.
>
> This is what web search engines are for. Going to yahoo, typing gcc
> visibility, and then clicking on the "cached" lin
Original Message
>From: Giovanni Bajo
>Sent: 11 March 2005 08:02
> James E Wilson <[EMAIL PROTECTED]> wrote:
>
>>> I would like to still get hold of the information that used to be
>>> present at that page because they were in fact very useful.
>>
>> This is what web search engines are f
Hello,
Thanks for the response.
Please provide more information (template disclaimer text etc) on how the
assignment should be performed.
Thanks,
Swami
On Mon, 28 Feb 2005, Ted Teah via RT wrote:
> Hello Swami,
>
>
> You can either assign the work through the process of each indivudal who
>
Hello,
Thanks for the response.
Please provide more information (template disclaimer text etc) on how the
assignment should be performed.
Thanks,
Swami
On Mon, 28 Feb 2005, Ted Teah via RT wrote:
> Hello Swami,
>
>
> You can either assign the work through the process of each indivudal who
>
Hello,
Thanks for the response.
Please provide more information (template disclaimer text etc) on how the
assignment should be performed.
Thanks,
Swami
On Mon, 28 Feb 2005, Ted Teah via RT wrote:
> Hello Swami,
>
>
> You can either assign the work through the process of each indivudal who
>
On Fri, 11 Mar 2005, Giovanni Bajo wrote:
> (notice: I use the Wiki because otherwise I'll have to wait weeks for the
> approval, and I don't have the time nor the willing of pushing a patch for
> weeks just for this. I believe we should either be more liberal with the
> contents of our website, o
On Fri, 11 Mar 2005, Per Bothner wrote:
> So the immediate question is: how should the testcase be fixed?
Specify a line number in the second dg-error to tell dejagnu what line to
expect the error on.
{ dg-error "expected regexp" "test name" { target *-*-* } line-number }
or
{ dg-error "expecte
Joseph S. Myers <[EMAIL PROTECTED]> wrote:
>> (notice: I use the Wiki because otherwise I'll have to wait weeks for the
>> approval, and I don't have the time nor the willing of pushing a patch
for
>> weeks just for this. I believe we should either be more liberal with the
>> contents of our websi
Per Bothner <[EMAIL PROTECTED]> wrote:
> The general frustration is: where is dg-error documented?
> I looked in:
> - the README* files in gcc/testsuite and in gcc.dg;
> - the Test Suites chapter of the internals manual
> (which mentions "special idioms" but not the basics);
> - the "Testsuite Con
Will not this test fail during execution for callee stack cleanup
calling convention?
Fix attached.
--
Øyvind Harboe
http://www.zylin.com
Index: 20001117-1.c
===
RCS file: /cvsroot/gcc/gcc/gcc/testsuite/gcc.dg/20001117-1.c,v
retriev
On Fri, Mar 11, 2005 at 02:48:35AM +0100, Hans-Peter Nilsson wrote:
> > Isn't a compiler option -fglobalize-symbol also a form of source-level
> > instrumentation? Either way, you need the source, and you get different
> > code emitted.
>
> This isn't a source-level modification, by definition.
> From: James E Wilson <[EMAIL PROTECTED]>
> Date: Thu, 10 Mar 2005 21:51:12 -0800
> On Thu, 2005-03-10 at 20:14, Hans-Peter Nilsson wrote:
> > That question isn't applicable or maybe I should say "by
> > identity mapping". To wit, SYMNAME refers to whatever has
> > "static" in front of it *in th
> My personal feeling I think the success of the Wiki is that it does not
> require review, rather than the fact that the Wiki syntax is partially
> lighter than HTML. The 48-hrs rule I propose seems sensible to me. The worst
> thing that can happen is that something incorrect goes live on the sit
I formatted the infomation from Giovanni Bajo's patch and put it in the
Wiki: http://gcc.gnu.org/wiki/HowToPrepareATestcase
Michael Cieslinski
On Fri, Mar 11, 2005 at 11:52:25AM +, Joseph S. Myers wrote:
> On Fri, 11 Mar 2005, Per Bothner wrote:
>
> > So the immediate question is: how should the testcase be fixed?
>
> Specify a line number in the second dg-error to tell dejagnu what line to
> expect the error on.
>
> { dg-error "e
Michael Cieslinski <[EMAIL PROTECTED]> wrote:
> I formatted the infomation from Giovanni Bajo's patch and put it in the
> Wiki: http://gcc.gnu.org/wiki/HowToPrepareATestcase
Many thanks!
--
Giovanni Bajo
Janis Johnson wrote:
There's some information about test directives in the GCC Internals
manual in the Testsuites section.
Google was not my friend ...
I searched for "dg-error gcc tests" and near the top was a link
to the internals manual. But it was some random copy covering 3.4
which did not i
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> Per Bothner <[EMAIL PROTECTED]> writes:
>> The general frustration is: where is dg-error documented?
>
> It ought to be in the dejagnu manual (i.e., that's where documentation
> should best be contributed) since dg-error is part of base dejagnu.
The
Section 9.4.2 of c++ standard "Static data members" does not directly
address this issue. But there is
a dejagnu c++ test case which explicitly disallows (by issuing a
link-time error) taking address of a static
const data member. Test case is const2.C.
This question has come up because, g++-4.
Steve Kargl wrote:
On Thu, Mar 10, 2005 at 01:10:49PM -0800, James E Wilson wrote:
You can't choose any name for front-end options. There are complicated
rules for determining whether an option is for the gcc driver or
preprocessor or front-end or back-end or assembler or linker or collect
or
On Mar 11, 2005, at 2:16 PM, Fariborz Jahanian wrote:
So, is g++ correct in rejecting this seemingly good user code?
Yes you need a place to store the data.
So for an example in your original testcase, you need:
const int Foo::foo;
Which fixes the problem and yes 9.4.2 explains this (I cannot find
Again I got a reaction of accepting write after approval (this time for
Feng Wang) as "processed by: None".
This is not encouraging - is someone reading these acceptances (despite
the "processed by: None" part) ?
FYI, Feng Wang's copyright assignment papers date from September, 2003.
Thanks in
Thanks Andrew. Yes, standard actually mentions this that I missed.
- fariborz
On Mar 11, 2005, at 11:25 AM, Andrew Pinski wrote:
On Mar 11, 2005, at 2:16 PM, Fariborz Jahanian wrote:
So, is g++ correct in rejecting this seemingly good user code?
Yes you need a place to store the data.
So for an ex
On Friday, March 11, 2005, at 03:52 AM, Joseph S. Myers wrote:
On Fri, 11 Mar 2005, Per Bothner wrote:
So the immediate question is: how should the testcase be fixed?
Specify a line number in the second dg-error to tell dejagnu what line
to
expect the error on.
{ dg-error "expected regexp" "test
Currently, I believe, GCC combines various calls to abort in a single
function, because it knows that none of them returns.
If the goal is simply to make the compiled code as small as possible,
this is the way to do it. But that is not the best goal when
compiling free software. Merging the vari
[EMAIL PROTECTED] (James E Wilson) wrote on 10.03.05 in <[EMAIL PROTECTED]>:
> On Thu, 2005-03-10 at 17:48, Hans-Peter Nilsson wrote:
> > This isn't a source-level modification, by definition.
>
> And I could argue that my suggestion isn't a source-level modification
> either, or I could argue th
On Fri, Mar 11, 2005 at 10:30:00AM +0200, Kai Henningsen wrote:
> [EMAIL PROTECTED] (James E Wilson) wrote on 10.03.05 in <[EMAIL PROTECTED]>:
>
> > On Thu, 2005-03-10 at 17:48, Hans-Peter Nilsson wrote:
> > > This isn't a source-level modification, by definition.
> >
> > And I could argue that m
On Mon, 07 Mar 2005 11:49:05 -0800, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> IMO, if these are C++-only, it's relatively easy to deprecate these
> extension -- but I'd like to hear from Jason and Nathan, and also the user
> community before we do that. Of all the extensions we've had, this one
Toon Moene wrote:
Ditto. Jim, are you reading from some documentation about this option
processing that I couldn't find ? I've spend hours and hours to try to
deduce the option processing rules from debugging various parts of the
gcc driver, with no success.
I doubt that this stuff is well doc
Snapshot gcc-3.4-20050311 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050311/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050311
You'll
Toon Moene wrote:
Again I got a reaction of accepting write after approval (this time for
Feng Wang) as "processed by: None".
System adminstration work is performed by [EMAIL PROTECTED]
You should ask them. Checking the overseers mailing list archive, I
see that the last message is an automate
On Fri, Mar 11, 2005 at 03:57:02PM -0800, James E Wilson wrote:
> System adminstration work is performed by [EMAIL PROTECTED]
[EMAIL PROTECTED] works just as well, since it's the same machine by
a different name. On this list we should be advertising the gcc.gnu.org
name, I think.
I've usually
On Friday, March 11, 2005, at 03:42 PM, James E Wilson wrote:
If you do need to extend the system, then it is best to use option
names similar to existing ones. For instance, -z and -Z are assumed
to be linker options, so if you need a new linker option then
something like -zthis or -Zthat mig
On Fri, 2005-03-11 at 16:01, Joe Buck wrote:
> [EMAIL PROTECTED] works just as well, since it's the same machine by
> a different name. On this list we should be advertising the gcc.gnu.org
> name, I think.
True. But if you want to look at the mailing list archive, you have to
use the non GNU na
James E Wilson <[EMAIL PROTECTED]> writes:
> On Fri, 2005-03-11 at 16:01, Joe Buck wrote:
> > [EMAIL PROTECTED] works just as well, since it's the same machine by
> > a different name. On this list we should be advertising the gcc.gnu.org
> > name, I think.
>
> True. But if you want to look at
On Fri, 2005-03-11 at 08:12, Hans-Peter Nilsson wrote:
> I don't really understand what you mean: if a thing is called
> "foo" in the source, then -fglobalize-symbol=foo would work.
My main concern is that we have a long history of adding flawed features
that have to be later removed. So I want y
Toon Moene wrote:-
> >Thanks for the detailed explanation of how
> >GCC options work. I'm currently thinking
> >of proposing a RFC with recommendations on
> >how to address this problem with gfortran.
>
> Ditto. Jim, are you reading from some documentation about this option
> processing that I
Vincent Lefevre <[EMAIL PROTECTED]> writes:
| On 2005-03-10 15:54:03 +0100, Gabriel Dos Reis wrote:
| > The C standard is not the holy bible and certainly does not define
| > everything. We're talking about compiler construction, here.
|
| This isn't just compiler construction. __builtin_cpow is
David Carlton <[EMAIL PROTECTED]> writes:
| On Thu, 10 Mar 2005 15:54:03 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]> said:
| > Vincent Lefevre <[EMAIL PROTECTED]> writes:
| > | On 2005-03-10 01:01:18 +0100, Gabriel Dos Reis wrote:
|
| > | > The asseryion that 0^0 is mathematically undefined is no
Vincent Lefevre <[EMAIL PROTECTED]> writes:
| On 2005-03-10 15:29:49 +0100, Paolo Carlini wrote:
| > Vincent Lefevre wrote:
| > >What is powi()? I couldn't find it in the C standard. It isn't
| > >in the Linux man pages either.
| > >
| > ;) It's just a new builtin that we have in mainline, very us
On Fri, 2005-03-11 at 17:48, Ian Lance Taylor wrote:
> All true, but I want to note that the preferred non-GNU name is
> sourceware.org.
What about the trademark status? Last I heard, the trademark holder had
asked us to stop using the name. That is when and why the machine got
renamed away from
On Sat, Mar 12, 2005 at 11:04:22AM +0900, Neil Booth wrote:
> Toon Moene wrote:-
>
> > >Thanks for the detailed explanation of how
> > >GCC options work. I'm currently thinking
> > >of proposing a RFC with recommendations on
> > >how to address this problem with gfortran.
> >
> > Ditto. Jim, ar
James E Wilson <[EMAIL PROTECTED]> writes:
> On Fri, 2005-03-11 at 17:48, Ian Lance Taylor wrote:
> > All true, but I want to note that the preferred non-GNU name is
> > sourceware.org.
>
> What about the trademark status? Last I heard, the trademark holder had
> asked us to stop using the name.
Steve Kargl wrote:-
> Yeah, tell us something we did not know! The problem, until
> Jim explained option handling, is *why* these were not passed
> to gfortran. Finding the info is/was non-obvious. What is
> even more appalling is that there is no way to inhibit the
> swallowing of the options.
Hello,
I have received the confirming mail for my application on "write after
approval". Thanks, all.
p.s. Steve, I think I can commit the patch for PR18827 myself. If you reviewed,
please notify me.
Best Regards,
Feng Wang
_
Do You Yahoo!
> Gabriel Dos Reis wrote:
> You probably noticed that in the polynomial expansion, you are using
> an integer power -- which everybody agrees on yield 1 at the limit.
>
> I'm tlaking about 0^0, when you look at the limit of function x^y
Out of curiosity, on what basis can one conclude:
lim{|x|==
Paul Schlie <[EMAIL PROTECTED]> writes:
| > Gabriel Dos Reis wrote:
| > You probably noticed that in the polynomial expansion, you are using
| > an integer power -- which everybody agrees on yield 1 at the limit.
| >
| > I'm tlaking about 0^0, when you look at the limit of function x^y
|
| Out of
On Fri, Mar 11, 2005 at 04:01:51PM -0800, Joe Buck wrote:
>On Fri, Mar 11, 2005 at 03:57:02PM -0800, James E Wilson wrote:
>>System adminstration work is performed by overseers AT sources PERIOD redhat
>>PERIOD com
>
>overseers AT gcc PERIOD gnu PERIOD org works just as well, since it's the same
On Fri, Mar 11, 2005 at 09:54:09PM -0500, Ian Lance Taylor wrote:
>James E Wilson writes:
>
>> On Fri, 2005-03-11 at 17:48, Ian Lance Taylor wrote:
>> > All true, but I want to note that the preferred non-GNU name is
>> > sourceware.org.
>>
>> What about the trademark status? Last I heard, the tr
_On 11-Mar-2005 02:48, James E Wilson san wrote_:
Note that in this case finding the target means indirecting through a
memory address, and hence we would have to track the attributes of all
memory locations which is a difficult and perhaps unsolvable problem.
As I said before, I think what you
55 matches
Mail list logo
