Hi All,
I am not able compile my project with GCC 4.3.3 C++. My project
was compiled by GCC 4.1.x.
Is there any flags to disable warning and/or errors given by GCC
4.3.3?
or
I should remove and/or change code to eliminate warning and/or er
Basile STARYNKEVITCH:
> So my point is that I want to put inside the GTY-ed struct
basilysroutine_st
> an ignored (I mean GTY((skip))-ed) field called routaddr which is
a function
> pointer
> (function of type basilysroutfun_t - which is typedef-ed above).
>
> How can I achieve that, in the c
On Sat, Mar 21, 2009 at 07:37:10PM -0700, Daniel Berlin wrote:
> "The steering committee was founded in 1998 with the intent of
> preventing any particular individual, group or organization from
> getting control over the project. Its primary purpose is to make major
> decisions in the best interes
Ian Lance Taylor wrote:
Jerry Quinn writes:
2009-03-21 Jerry Quinn
* config/i386/i386.c (ix86_function_specific_save): Don't check
range of enum values.
I still don't know why I don't see this, but this is OK for the
gcc-in-cxx branch.
Do I need to take any actions befo
Jerry Quinn writes:
> 2009-03-21 Jerry Quinn
>
>* config/i386/i386.c (ix86_function_specific_save): Don't check
>range of enum values.
I still don't know why I don't see this, but this is OK for the
gcc-in-cxx branch.
Thanks.
Ian
Jerry Quinn wrote:
Joseph S. Myers wrote:
On Sat, 21 Mar 2009, Ian Lance Taylor wrote:
../.././gcc/config/i386/i386.c:3282: error: comparison is always true
due to limited range of data type
#define IN_RANGE(VALUE, LOWER, UPPER) \
((unsigned HOST_WIDE_INT) (VALUE) - (unsigned HOST_
On Sat, Mar 21, 2009 at 8:46 PM, Mark Mitchell wrote:
> David Edelsohn wrote:
>
>> I do not believe that Mark is asserting that he and the other release
>> managers have to follow the requests of the FSF. The question is not
>> what the GCC community or the release managers *can* do, the question
David Edelsohn wrote:
> I do not believe that Mark is asserting that he and the other release
> managers have to follow the requests of the FSF. The question is not
> what the GCC community or the release managers *can* do, the question
> is what we *should* do. Ignoring a direct, polite request
On Sun, Mar 22, 2009 at 1:44 AM, Richard Kenner
wrote:
>> I think the community of GCC consumers also doesn't care which sandbox
>> the developers play in, as long as they're all playing in the same
>> sandbox. But maybe I'm wrong, and maybe that's why I've never been
>> able to understand why EG
> I think the community of GCC consumers also doesn't care which sandbox
> the developers play in, as long as they're all playing in the same
> sandbox. But maybe I'm wrong, and maybe that's why I've never been
> able to understand why EGCS merged back into the FSF GCC in the first
> place...
I t
On Sat, Mar 21, 2009 at 9:08 AM, Daniel Berlin wrote:
> Err, sorry, but no.
> They are certainly the legal owners of the code. That does not mean
> they can force you to do anything.
> Can we at least stop pretending that we simply have to do whatever the
> FSF says, all the time, and we are jus
On Sun, Mar 22, 2009 at 1:30 AM, Richard Kenner
wrote:
>> This is the FSF's official GCC repository. In the FSF's repository, I
>> think we have to honor FSF instructions. In a separate repository --
>> or, I suppose, if we explicitly told the FSF not to consider this their
>> official GCC repos
> This is the FSF's official GCC repository. In the FSF's repository, I
> think we have to honor FSF instructions. In a separate repository --
> or, I suppose, if we explicitly told the FSF not to consider this their
> official GCC repository -- the GPL of course gives us the freedom to do
> as w
Daniel Berlin wrote:
>>> The matters to which we defer to the FSF are any matters that they *ask*
>>> us to! They own the code. If RMS, for some reason, decides that he doesn't
>>> like the phrasing of a comment somewhere, we have to either convince RMS
>>> he's wrong or change the comment.
>>
Joseph S. Myers wrote:
On Sat, 21 Mar 2009, Ian Lance Taylor wrote:
../.././gcc/config/i386/i386.c:3282: error: comparison is always true
due to limited range of data type
#define IN_RANGE(VALUE, LOWER, UPPER) \
((unsigned HOST_WIDE_INT) (VALUE) - (unsigned HOST_WIDE_INT) (LOWER) \
On Sat, Mar 21, 2009 at 12:40 PM, Kai Tietz wrote:
> 2009/3/21 Joseph S. Myers :
>> Apart from new features, the x86_64 long double union ABI issue needs
>> mentioning in the caveats section. Are there any other ABI changes
>> missing from there?
>>
>> --
>> Joseph S. Myers
>> jos...@codesourcery
On Sat, 21 Mar 2009, Ian Lance Taylor wrote:
> > ../.././gcc/config/i386/i386.c:3282: error: comparison is always true
> > due to limited range of data type
>
> #define IN_RANGE(VALUE, LOWER, UPPER) \
> ((unsigned HOST_WIDE_INT) (VALUE) - (unsigned HOST_WIDE_INT) (LOWER) \
><= (unsigned HOS
Jerry Quinn writes:
> I just tried to bootstrap the gcc-in-cxx branch, but it fails in stage
> 2. If I expand the macros, the code looks OK to me.
>
> Any suggestions on how to go about tracking this down (if someone else
> doesn't get there first)?
Tobias Schlüter saw the same thing; I don't kn
Hi,
I just tried to bootstrap the gcc-in-cxx branch, but it fails in stage
2. If I expand the macros, the code looks OK to me.
Any suggestions on how to go about tracking this down (if someone else
doesn't get there first)?
Thanks,
Jerry Quinn
/home/jlquinn/gcc/dev/gcc/host-x86_64-unknown
2009/3/21 Joseph S. Myers :
> Apart from new features, the x86_64 long double union ABI issue needs
> mentioning in the caveats section. Are there any other ABI changes
> missing from there?
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>
The abi switching patch for x86_64 is still missing i
Hi,
I am interested in Posix C++ integration. Does this suggested idea
incorporates the integration of standard C interface of Posix thread
library by encapsulating C structure into the C++ class? Some Posix
and C-language functions are non-reentrant with respect to threads so
I would like to propo
On Thu, Mar 19, 2009 at 8:58 PM, Jerry DeLisle wrote:
> The fortran development branch has been created. The purpose is to allow
> continuation of development of new Fortran 95 and Fortran 2003 features. A
> primary objective will be testing these features before committing over to
> mainline, w
Richard Guenther wrote:
Just do it and fix whatever causes that not to work?!
Apparently, gengtype is behaving better w.r.t. function pointers.
I just wrote
struct basilysroutine_st GTY (()) {
basilysobject_ptr_t discr;
char routdescr[BASILYS_ROUTDESCR_LEN];
basilysroutfun_t* GTY ((skip))
Hi,
I've played a bit with the command line today to investigate the
results posted to gcc-testresults: For which compilers and which
targets did the list receive results between 2004-01-01 and
2009-03-21.
In total there are 110623 posted results that contain "Results .*
testsuite on". My scipt t
Apart from new features, the x86_64 long double union ABI issue needs
mentioning in the caveats section. Are there any other ABI changes
missing from there?
--
Joseph S. Myers
jos...@codesourcery.com
> "Richard" == Richard Kenner writes:
Richard> He's the President of the organization, so he has the
Richard> ultimate authority over any FSF project.
According to the FSF by-laws? Oh, wait, do you mean you actually had
access to them? You're much more lucky than most of us then :)
Sam
2009/3/21 Steven Bosscher :
> * New warnings: -Wdisallowed-function-list=, -Wframe-larger-than=,
> -Wmudflap, -Wtype-limits,
>
-Wtype-limits was mentioned in GCC 4.3 changes.
Cheers,
Manuel.
On Sat, Mar 21, 2009 at 2:19 PM, Basile STARYNKEVITCH
wrote:
> Hello All,
>
> Richard Guenther wrote:
>>
>> On Sat, Mar 21, 2009 at 1:17 PM, Basile STARYNKEVITCH
>> wrote:
>>
>>>
>>> Hello All,
>>>
>>> What is the politically correct way of having an ignored function pointer
>>> inside a GTY-ed s
Hello All,
Richard Guenther wrote:
On Sat, Mar 21, 2009 at 1:17 PM, Basile STARYNKEVITCH
wrote:
Hello All,
What is the politically correct way of having an ignored function pointer
inside a GTY-ed struct?
To be more precise, I have
typedef basilys_ptr_t basilysroutfun_t (basilysclo
On Fri, Mar 20, 2009 at 7:18 PM, Mark Mitchell wrote:
> Richard Kenner wrote:
>
>> The matters to which we defer to the FSF are any matters that they *ask*
>> us to! They own the code. If RMS, for some reason, decides that he doesn't
>> like the phrasing of a comment somewhere, we have to either
> > As a practical matter, the FSF *delegates* most of their responsibilities
> > to the maintainer of the package, but they can undo that delegation as to
> > any matter any time they want.
>
> By this, FSF == RMS ?
It's more like RMS => FSF.
He's the President of the organization, so he has th
Hello all,
The GCC 4.4 changes page is far from complete. It almost looks like
nothing happened, even some of the really big changes like IRA are not
mentioned on the changes page.
Things that are obviously missing from the changes page:
* IRA
* Selective scheduler
* The stack work from HJ and
I was planning to send this note next week, but I guess I should know
better than to put something on the wiki and think it won't be noticed,
even if it is in a crusty dark corner :-)
I see on #gcc that my debuglocus document has been discovered. It
describes the work Aldy and I are experiment
On Sat, Mar 21, 2009 at 1:17 PM, Basile STARYNKEVITCH
wrote:
> Hello All,
>
> What is the politically correct way of having an ignored function pointer
> inside a GTY-ed struct?
>
> Of course, the function pointer is obviously GTY ((skip))-ed.
>
> In the MELT branch (file gcc/basilys.h rev144985)
Steven Bosscher wrote:
On Sat, Mar 21, 2009 at 1:17 PM, Basile STARYNKEVITCH
wrote:
But last time I tried (more than a year ago) that didn't work because
gengtype is unhappy with GTY((skip))-ed fields of a type it does not
understand.
Why do you have to put that data structure in GC m
On Sat, Mar 21, 2009 at 1:17 PM, Basile STARYNKEVITCH
wrote:
> But last time I tried (more than a year ago) that didn't work because
> gengtype is unhappy with GTY((skip))-ed fields of a type it does not
> understand.
Why do you have to put that data structure in GC memory?
Ciao!
Steven
Hello All,
What is the politically correct way of having an ignored function
pointer inside a GTY-ed struct?
Of course, the function pointer is obviously GTY ((skip))-ed.
In the MELT branch (file gcc/basilys.h rev144985) I have
// notice that FLEXIBLE_DIM is a macro expanding to empty
#defin
Hi gcc'ers,
I was wondering if it would be a useful extension to Objective-C
expand the [] operator
to support array and hash references to NSArray and NSDictionary
classes directly to
greatly improve the readability of code:
NSArray *players = [NSArray arrayWithObjects:..., nil];
[players
On Fri, Mar 20, 2009 at 7:07 PM, Richard Kenner
wrote:
>> > The GCC maintainers work on behalf of the FSF and in some matters defer
>> > to the FSF. It's that simple.
>>
>> Yes, but it's not written anywhere that release and especially branching
>> policies are one of this matters.
>
> The matte
39 matches
Mail list logo
