Re: gcc- 4.6.0 20100416 rtmutex.c:1138:1: internal compiler error
On 04/18/2010 11:57 PM, Jie Zhang wrote: On 04/19/2010 02:43 PM, Justin P. Mattock wrote: I couldn't resist..(had to play), anyways I looked through the reports but didn't see anything that was familiar. so I went and created an entry: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791 Thanks. Please add a preprocessed source file so people can reproduce your issue. as for the preprocessed source file, not that yet skilled at code.(one day) I added my .config, and the CFLAGS I used for building gcc. In regards to 4.6.0 everything seems o.k. i.g. glibc builds with no errors all of the xserver no errors, even firefox builds.. seems the kernel was the only real problem I ran into(which isn't really a problem given this version of gcc is experimental). maybe something todo with building modules (but could be wrong). Justin P. Mattock
Re: GCC 4.5.0 Released
On Mon, Apr 19, 2010 at 7:04 AM, Basile Starynkevitch wrote: > Mark Mitchell wrote: >> >> The Free Software Foundation and the GNU Compiler Collection (GCC) >> development team have released GCC 4.5.0. [...] > > > It is really unfortunate the annoucement did not mention plugins, another > major feature of GCC. Why ? I see plugins as a new feature for GCC developers. There is little value in announcing "we have plugin support" to our users if you can't name at least one that is supported out-of-the-box (and obviously we don't support plugins at all). How would you have announced the plugin parts to GCC users? Richard.
Re: GCC 4.5.0 Released
On Mon, Apr 19, 2010 at 10:50:48AM +0200, Richard Guenther wrote:
> On Mon, Apr 19, 2010 at 7:04 AM, Basile Starynkevitch
> wrote:
> > Mark Mitchell wrote:
> >>
> >> The Free Software Foundation and the GNU Compiler Collection (GCC)
> >> development team have released GCC 4.5.0. [...]
> >
> >
> > It is really unfortunate the annoucement did not mention plugins, another
> > major feature of GCC. Why ?
>
> I see plugins as a new feature for GCC developers. There is little
> value in announcing "we have plugin support" to our users if
> you can't name at least one that is supported out-of-the-box
I respectfully but strongly disagree with that statement. There is a
lot of value in announcing we have plugin support, because that simple
fact enable GCC users (at least those who use GCC to compile code
there are contributing to develop) to develop their simple plugins or
ask somebody else to develop plugins for them. This makes a major
difference for the few power users needing extra features in their GCC
Compiler (previously, the only way was to fork their own private
branch, a much larger and fragile effort than developping a plugin,
with the tremendous burden that users of such a branch have to build
it by their own).
> (and obviously we don't support plugins at all).
I also disagree with and even don't understand that sentence. GCC 4.5
does support plugins (since plugins exist in 4.5 but not in previous
releases), and I am sure that several companies selling GCC support
will be delighted to be suitably paid to develop plugins.
Besides, GCC users have a pecularity. Since they are using a compiler
(obviously GCC), they understand better than others what software
source code is, and probably what software development means. So there
are more chances that some GCC power users would want to develop a
plugin.
Of course, plugins development from outside the GCC community will
increase very progressively. But plugin is a *major* feature of 4.5,
[in my eyes] as important as link-time-optimization.
>
> How would you have announced the plugin parts to GCC users?
I am not a native english speaker, but something like the following
paragraph [to be added after the paragraph: GCC 4.5.0 is now capable
of "link-time optimization". ... and equally significant reductions in
code size.]
GCC 4.5.0 accept plugins (on some host systems, in particular
Linux, if configured appropriately). This permits advanced users to
customize or extend their GCC compiler with specific code provided
in plugins enabling extra features -such as new specific
optimization or diagnostic passes, etc.- suitable for their
particular needs. Plugins should be GPLv3 compatible.
Also, in practice, at least in the Linux and some embedded software
worlds, new releases of GCC diffuse very slowly... So it is ok if some
power users just start developping their plugin now.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Is this maybe PR43776 again?
On Mon, Apr 19, 2010 at 02:13:52AM +0100, Dave Korn wrote: > > /gnu/gcc/gcc/libjava/classpath/javax/swing/plaf/basic/BasicLookAndFeel.java:483:0: > > note: variable tracking size limit exceeded with > > -fvar-tracking-assignments, retrying without > > Re-running the build command manually spins CPU quite hard for about a > minute or just over before it gives up on vta and then takes about another ten > seconds to complete. Comment #2 in the PR talks about some "usual KDE > var-tracking issue", but this suggests it's a more general problem, perhaps? This is just to inform you that due to very large size of the routine the debug info for it will be less precise. It is not a warning nor error, just a note. Jakub
Combine or peephole?
Hi, My architecture supports instructions with two parallel side effects. For example, addition and subtraction can be done in parallel: (define_insn "assi6" [(parallel [ (set (match_operand:SI 0 "register_operand" "=r") (minus:SI (match_operand:SI 1 "register_operand" "r") (match_operand:SI 2 "register_operand" "r"))) (set (match_operand:SI 3 "register_operand" "=r") (plus:SI (match_operand:SI 4 "register_operand" "r") (match_operand:SI 5 "register_operand" "r"))) ])] "" "as\t%5, %4, %3, %2, %1, %0 %!" ) This instruction is not chosen at ‘combine’ time even if ‘plus’ and ‘minus’ instructions are located one after other. That it is, probably, there is no data dependency between them. In attempt to resolve the problem, I am providing a peephole optimization: (define_peephole2 [ (set (match_operand:SI 0 "register_operand") (minus:SI (match_operand:SI 1 "register_operand") (match_operand:SI 2 "register_operand"))) (set (match_operand:SI 3 "register_operand") (plus:SI (match_operand:SI 4 "register_operand") (match_operand:SI 5 "register_operand"))) ] "" [(parallel [ (set (match_dup 0) (minus:SI (match_dup 1) (match_dup 2))) (set (match_dup 3) (plus:SI (match_dup 4) (match_dup 5))) ])] "" ) This works for some cases, but I wanted to ask experts whether this is the way to go. Repeating the same pattern for a peephole might be not the best way to resolve the problem. Did you observe something similar? What would be the best way to resolve such situation? Thank you, Frank
finding an original typedef decl from a reference
consider : typedef int INT1 ; int func (INT1 x) ; now if I am in grokparms() parsing "INT1 x " and I want to issue a nice diagnostic for x... I can't seem to find the right magic that gets me back to that DECL for INT1 (I actually want any attributes attached to it and an expand_location).. any pointers to the correct macro or chain to follow...? Iain
Re: finding an original typedef decl from a reference
On Mon, Apr 19, 2010 at 3:03 PM, IainS wrote: > > consider : > > typedef int INT1 ; > > int func (INT1 x) ; > > > > now if I am in grokparms() parsing "INT1 x " and I want to issue a nice > diagnostic for x... > > I can't seem to find the right magic that gets me back to that DECL for INT1 > (I actually want any attributes attached to it and an expand_location).. > > any pointers to the correct macro or chain to follow...? TYPE_NAME will be a TYPE_DECL. Richard. > Iain > >
Re: finding an original typedef decl from a reference
On 19 April 2010 15:03, IainS wrote: > > consider : > > typedef int INT1 ; > > int func (INT1 x) ; > > > > now if I am in grokparms() parsing "INT1 x " and I want to issue a nice > diagnostic for x... Can I ask what you mean by a nice diagnostic? and what you want to use this for? Just out of curiosity. Manuel.
Re: GCC 4.5.0 Released
On Mon, Apr 19, 2010 at 11:23:35AM +0200, Basile Starynkevitch wrote:
>
...
> I am not a native english speaker, but something like the following
> paragraph [to be added after the paragraph: GCC 4.5.0 is now capable
> of "link-time optimization". ... and equally significant reductions in
> code size.]
>
>GCC 4.5.0 accept plugins (on some host systems, in particular
>Linux, if configured appropriately). This permits advanced users to
>customize or extend their GCC compiler with specific code provided
>in plugins enabling extra features -such as new specific
>optimization or diagnostic passes, etc.- suitable for their
>particular needs. Plugins should be GPLv3 compatible.
>
Basile,
The annoucement should probably note that targets which lack
objdump currently can't build plugins. I've had about as much
luck getting the patch to fix this...
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00610.html
...reviewed as you are likely to get this feature announced.
>From the responses in the "dragonegg in FSF gcc?" thread, it
is clear that the plugin feature is viewed more as a necessary
evil than a clear win for FSF gcc in some quarters.
Jack
...
>
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
>
Re: finding an original typedef decl from a reference
On 19 Apr 2010, at 14:18, Manuel López-Ibáñez wrote: On 19 April 2010 15:03, IainS wrote: consider : typedef int INT1 ; int func (INT1 x) ; now if I am in grokparms() parsing "INT1 x " and I want to issue a nice diagnostic for x... Can I ask what you mean by a nice diagnostic? and what you want to use this for? nice ; including the expand_loc for INT1 and any attributes attached to the decl. use ; I'm working on __attribute__((deprecated)) issues ... (at the moment the diagnostic for x does not include the declaration location). http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43778 and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43797 and the earlier thread on patches. http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01037.html and a followup: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01092.html All this as a prelude to trying to introduce __attribute__((unavailable)) which is needed to progress ObjC to Version 1. Iain
Re: GCC 4.5.0 Released
Basile Starynkevitch wrote: > It is really unfortunate the annoucement did not mention plugins, > another major feature of GCC. Why ? I consider plug-ins an important feature for the future of GCC. I gave a talk this past week as the Linux Foundation Collaboration Summit in which I made the case for modularity of GCC, including plug-ins. I (assisting David Edelsohn, who lead the effort) worked with the FSF to get acceptance for plug-ins for a long time. So, it's not that I don't like plug-ins. But, I don't think that plug-ins are yet a useful thing to announce in what is essentially a "marketing" context. Most users won't be able to use them yet. We have some infrastructure; we don't have a lot of use of that infrastructure yet. More broadly, there are lots of things that didn't make the announcement. There have been many important improvements since GCC 4.4.x; they don't all fit in an announcement. Of course, you're entirely free to publicize plug-ins as you like in any forum you find appropriate. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Plan for gc-improv merge
Hi, Now that GCC is in the stage1 and gc-improv branch work is finished as I see it, I propose to merge it to mainline. The goal of the branch is to make the type of GC-allocated objects known to GC at allocation time, by changing the allocation interface from foo *x = (foo *)ggc_alloc (sizeof (x)); to foo *x = ggc_alloc_foo (); Having this enables further work on GC. Note that it has been prototyped before: http://gcc.gnu.org/ml/gcc/2004-01/msg01081.html It should not cause any changes in the compiler behavior whatsoever (except some ggc-zone fixes, see below), except perhaps that GC-to-obstack changes might improve data locality by a tiny epsilon. It comes with a few free extras: 1) Completes the ggc_alloc* to GGC_NEW* interface transition by moving away from both. 2) Partly fixes zone allocator, especially in the presence of PCH. I am content with "partly" here as I didn't break it and apparently nobody uses it anyway. 2) It shakes out a few places where GC shouldn't have been used in the first place, replaced with obstack allocation. 3) A few ggc.h and gengtype cleanups. A few points of note: 1) For some types (tree, rtx) it is required to specify allocation size explicitly. I have introduced a new GTY attribute variable_size for that. 2) To handle param_is options, libiberty needs to know how to allocate using GC interface. Thus I have extended a few libiberty functions to accept additional memory allocator callback parameters. So, if this work is accepted in principle, I will submit to mainline as follows: First the independent parts, which are beneficial without the rest merged. I will submit them shortly. 1) In the loop optimizer, move from GC to obstrack the types struct lambda_loop_s, lambda_body_vector, lambda_matrix, lambda_trans_matrix. Needs loop maintainer review. 2) In the C parser, use obstack for braced initializer list parsing, moving structs constructor_range_stack, init_node out of GC. Needs C frontend maintainer review.. 3) Debugging dump of the structures that gengtype builds and some minor gengtype cleanups. Right now it is a debugging aid, later it could be used to do gengtype dump/load that Basile wants for plugins. Needs global maintainer review. And the merge itself. None of the following makes sense without the rest. 1) New API in libiberty for creating of hash tables and splay trees with user-specified callbacks for allocation. Needs libiberty maintainer review. 2) Make gengtype accept variable_size GTY option and output typed GC allocators to gtype-desc.h. Needs global maintainer review. 3) Split ggc.h into ggc.h and ggc-internal.h, introduce internal interface for gengtype output to use, fix MEM_STAT accounting, partly fix zone allocator, partly fix zone allocator interaction with PCH, and related minor ggc-*.c and stringpool.c changes. It is basically a ggc.h rewrite from scratch. Needs global, or, I dunno, middle-end maintainer review. 4) Annotate several types with variable_size option. Needs all the front-end maintainers' and middle-end maintainer review, or, maybe easier, global maintainer review together with the next patch. 5) Change all the allocation sites. Touches all the frontends, significant parts of middle ends, and probably all the backends too. The changes here are mechanical, so it would be easiest to get a global approval from a global maintainer instead of specific area maintainers. 6) GTY documentation update in GCC internals manual. Comments? Thanks. -- Laurynas
Re: Combine or peephole?
On 04/19/10 06:58, Frank Isamov wrote: Hi, My architecture supports instructions with two parallel side effects. For example, addition and subtraction can be done in parallel: (define_insn "assi6" [(parallel [ (set (match_operand:SI 0 "register_operand" "=r") (minus:SI (match_operand:SI 1 "register_operand" "r") (match_operand:SI 2 "register_operand" "r"))) (set (match_operand:SI 3 "register_operand" "=r") (plus:SI (match_operand:SI 4 "register_operand" "r") (match_operand:SI 5 "register_operand" "r"))) ])] "" "as\t%5, %4, %3, %2, %1, %0 %!" ) This instruction is not chosen at ‘combine’ time even if ‘plus’ and ‘minus’ instructions are located one after other. That it is, probably, there is no data dependency between them. combine requires a data dependency, so for this situation, combine isn't going to help. The easy solution is to create a peephole.You can also create a machine dependent reorg pass to detect more of these opportunities. Jeff
Re: Plan for gc-improv merge
Laurynas Biveinis wrote:
Hi,
Now that GCC is in the stage1 and gc-improv branch work is finished as
I see it, I propose to merge it to mainline.
The goal of the branch is to make the type of GC-allocated objects
known to GC at allocation time, by changing the allocation interface
from
foo *x = (foo *)ggc_alloc (sizeof (x));
to
foo *x = ggc_alloc_foo ();
Will the name of the marking routines, such as gt_ggc_mx_tree_node for
tree, change?
The MELT branch needs to know them (but can adapt easily to a name
change). And any other plugins using PLUGIN_GGC_MARKING probably wants
to know the naming convention (& the signature) for the marking routine,
so we might also document it.
Also, I believe that
foo* y = ggc_alloc_foo ();
should behave like the 4.5.0
foo* y = (foo *)ggc_alloc_cleared(sizeof(foo));
that it, that it should *clear* allocated memory. Clearing memory is
cheap, and allocating uninitialized memory could lead to hard to find bugs.
Having this enables further work on GC. Note that it has been prototyped before:
http://gcc.gnu.org/ml/gcc/2004-01/msg01081.html
It should not cause any changes in the compiler behavior whatsoever
(except some ggc-zone fixes, see below), except perhaps that
GC-to-obstack changes might improve data locality by a tiny epsilon.
It comes with a few free extras:
1) Completes the ggc_alloc* to GGC_NEW* interface transition by moving
away from both.
2) Partly fixes zone allocator, especially in the presence of PCH. I
am content with "partly" here as I didn't break it and apparently
nobody uses it anyway.
2) It shakes out a few places where GC shouldn't have been used in the
first place, replaced with obstack allocation.
3) A few ggc.h and gengtype cleanups.
A few points of note:
1) For some types (tree, rtx) it is required to specify allocation
size explicitly. I have introduced a new GTY attribute variable_size
for that.
How is that handled by their ggc_alloc_tree? As a size argument?
Also, it would be nice if the new ggc.h could define some preprocessor
flags specific to the change, eg #define GGC_ALLOC_IS_TYPED 1, to enable
coding plugins which could work on both 4.5 & 4.6
2) To handle param_is options, libiberty needs to know how to allocate
using GC interface. Thus I have extended a few libiberty functions to
accept additional memory allocator callback parameters.
So, if this work is accepted in principle, I will submit to mainline as follows:
I like it very much...
First the independent parts, which are beneficial without the rest
merged. I will submit them shortly.
1) In the loop optimizer, move from GC to obstrack the types struct
lambda_loop_s, lambda_body_vector, lambda_matrix, lambda_trans_matrix.
Needs loop maintainer review.
2) In the C parser, use obstack for braced initializer list parsing,
moving structs constructor_range_stack, init_node out of GC. Needs C
frontend maintainer review..
3) Debugging dump of the structures that gengtype builds and some
minor gengtype cleanups. Right now it is a debugging aid, later it
could be used to do gengtype dump/load that Basile wants for plugins.
Needs global maintainer review.
It is hopefully not only me. As Diego wrote once, the current gengtype
for plugins is quite a hack, and we need to improve that.
And the merge itself. None of the following makes sense without the rest.
1) New API in libiberty for creating of hash tables and splay trees
with user-specified callbacks for allocation. Needs libiberty
maintainer review.
2) Make gengtype accept variable_size GTY option and output typed GC
allocators to gtype-desc.h. Needs global maintainer review.
3) Split ggc.h into ggc.h and ggc-internal.h, introduce internal
interface for gengtype output to use, fix MEM_STAT accounting, partly
fix zone allocator, partly fix zone allocator interaction with PCH,
and related minor ggc-*.c and stringpool.c changes. It is basically a
ggc.h rewrite from scratch. Needs global, or, I dunno, middle-end
maintainer review.
4) Annotate several types with variable_size option. Needs all the
front-end maintainers' and middle-end maintainer review, or, maybe
easier, global maintainer review together with the next patch.
5) Change all the allocation sites. Touches all the frontends,
significant parts of middle ends, and probably all the backends too.
The changes here are mechanical, so it would be easiest to get a
global approval from a global maintainer instead of specific area
maintainers.
6) GTY documentation update in GCC internals manual.
Yes, these are important, especially since the plugin interface expose a
bit more of ggc.h ...
Thanks for the good work!
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Plan for gc-improv merge
2010/4/19 Basile Starynkevitch : > Laurynas Biveinis wrote: >> The goal of the branch is to make the type of GC-allocated objects >> known to GC at allocation time, by changing the allocation interface >> from >> foo *x = (foo *)ggc_alloc (sizeof (x)); >> to >> foo *x = ggc_alloc_foo (); > > Will the name of the marking routines, such as gt_ggc_mx_tree_node for tree, > change? No. At this time, only the allocation interface changes. The markers remain the same. > Also, I believe that > foo* y = ggc_alloc_foo (); > should behave like the 4.5.0 > foo* y = (foo *)ggc_alloc_cleared(sizeof(foo)); > that it, that it should *clear* allocated memory. Clearing memory is cheap, > and allocating uninitialized memory could lead to hard to find bugs. There are separate ggc_alloc_cleared_foo () allocators too. I am not sure about clearing everything though. As I did the conversion I was looking for alloc followed by memset to 0 patterns or struct fields that were forgotten to unitialize, but did not find any bugs of this kind. Clearing memory could be expensive for large blocks of memory, if allocator does not page them in, but GCC does not have anything approaching that, I think. >> A few points of note: >> 1) For some types (tree, rtx) it is required to specify allocation >> size explicitly. I have introduced a new GTY attribute variable_size >> for that. > > How is that handled by their ggc_alloc_tree? As a size argument? Yes, reusing the same size argument that is passed currently. > Also, it would be nice if the new ggc.h could define some preprocessor flags > specific to the change, eg #define GGC_ALLOC_IS_TYPED 1, to enable coding > plugins which could work on both 4.5 & 4.6 Why? Thank you for your comments and support, -- Laurynas
Re: GCC 4.5.0 Released
Mark Mitchell wrote:
Basile Starynkevitch wrote:
It is really unfortunate the annoucement did not mention plugins,
another major feature of GCC. Why ?
I consider plug-ins an important feature for the future of GCC. I gave
a talk this past week as the Linux Foundation Collaboration Summit in
which I made the case for modularity of GCC, including plug-ins. I
(assisting David Edelsohn, who lead the effort) worked with the FSF to
get acceptance for plug-ins for a long time. So, it's not that I don't
like plug-ins.
But, I don't think that plug-ins are yet a useful thing to announce in
what is essentially a "marketing" context. Most users won't be able to
use them yet. We have some infrastructure; we don't have a lot of use
of that infrastructure yet.
My feeling is that the simple availability of this plugin infrastructure
is a significant *marketing* argument for GCC. We don't need useful
plugin to reliably exist to use that advertising argument.
And while I agree that most ordinary users won't be able to use plugins
[*] they will probably be able to ask for plugins (e.g. to pay
consultant or GCC centered companies to do so).
I am not sure that as soon as modules or plugins have been added to
other big software projects (like Linux Kernel, GTK, ...), most users of
these projects have been able to use plugins immediately. Plugins are
always a long term effort, because they are an invitation for people
*outside* the community to participate in development, and this takes
time & effort.
Note [*]: are we sure that other announced features, like Link Time
Optimization, are *easily* usable by *ordinary* GCC users? I don't know,
and I am not sure... Perhaps most ordinary users only know about -O1 or
-O3...
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: GCC 4.5.0 Released
On 19 April 2010 18:34, Basile Starynkevitch wrote: > > Note [*]: are we sure that other announced features, like Link Time > Optimization, are *easily* usable by *ordinary* GCC users? I don't know, and > I am not sure... Perhaps most ordinary users only know about -O1 or -O3... Well, yes, because they can enable it by passing an extra command-line flag. To use plugins they need to write a plugin. That is more useful in the long-term, once useful plugins are available. You spend a lot of time on this mailing list saying "maybe this will happen" or "perhaps most users only know" ... stop speculating. Besides which, the full "changes" page explains that plugins are now supported, so users who want to dig further than the release announcement will find out about it. Do we really need to have a long discussion on this mailing list about what should have been in the announcement? Can I complain that my contributions weren't announced? I feel they were significant, and noone consulted me on the release announcement. Let's move on.
Re: gcc- 4.6.0 20100416 rtmutex.c:1138:1: internal compiler error
On 19 April 2010 08:20, Justin P. Mattock wrote: > On 04/18/2010 11:57 PM, Jie Zhang wrote: >> >> On 04/19/2010 02:43 PM, Justin P. Mattock wrote: >>> >>> I couldn't resist..(had to play), >>> anyways I looked through the reports >>> but didn't see anything that was >>> familiar. so I went and created an entry: >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791 >>> >> Thanks. Please add a preprocessed source file so people can reproduce >> your issue. >> >> > > > as for the preprocessed source file, > not that yet skilled at code.(one day) See the "how to report" link on the gcc front page: http://gcc.gnu.org/bugs/ It's not hard.
Re: gcc- 4.6.0 20100416 rtmutex.c:1138:1: internal compiler error
On 04/19/2010 02:17 PM, Jonathan Wakely wrote: On 19 April 2010 08:20, Justin P. Mattock wrote: On 04/18/2010 11:57 PM, Jie Zhang wrote: On 04/19/2010 02:43 PM, Justin P. Mattock wrote: I couldn't resist..(had to play), anyways I looked through the reports but didn't see anything that was familiar. so I went and created an entry: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791 Thanks. Please add a preprocessed source file so people can reproduce your issue. as for the preprocessed source file, not that yet skilled at code.(one day) See the "how to report" link on the gcc front page: http://gcc.gnu.org/bugs/ It's not hard. the info from jie, worked, as well as: make kernel/rtmutex.i (from joe perches) Justin P. Mattock
Re: GCC 4.5.0 Released
On 19/04/2010 15:31, Mark Mitchell wrote: > But, I don't think that plug-ins are yet a useful thing to announce in > what is essentially a "marketing" context. Most users won't be able to > use them yet. We have some infrastructure; we don't have a lot of use > of that infrastructure yet. Well, to be fair, LTO is in somewhat the same position: works, but isn't a great deal of use /yet/, until people start getting to grips with and using the _potential_ it provides. > More broadly, there are lots of things that didn't make the > announcement. There have been many important improvements since GCC > 4.4.x; they don't all fit in an announcement. But I agree with this: a release announcement is just an email someone sends out after a new release is uploaded, it is not a major PR effort nor a statement of policy nor even something from which to attempt to infer the relative priority of different features. It's just a non-comprehensive brief precis. So if there's a discussion to be had here, it's about how GCC should be "marketed", and the extent to which a release announcement should be part of that effort. cheers, DaveK
