Re: Defining a common plugin machinery
Chris Lattner wrote:
Is the plugin machinery intended to eventually allow new (GPL
compatible) backends to be used? It would be nice to make llvm-gcc be a
plugin.
From what I remember of the plugin BOFS & the Steering Committee Q&A
sessions at last GCC summit permitting GPL-ed plugins is one of the
intent of plugins.
AFAIK, the concern is -on the opposite of your intents- how to make
GPL-ed plugins (legally) easy, and proprietary plugins (legally)
impossible, but I am not a lawyer, I know nothing about US law, and I
don't know what is happening inside the steering committee or the FSF
regarding plugins.
The technical questions about how to make plugin practicals are
precisely the scope of the current thread on the gcc@ mailing list.
Regards
--
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: C/C++ FEs: Do we really need three char_type_nodes?
On Fri, Sep 19, 2008 at 6:56 PM, Diego Novillo <[EMAIL PROTECTED]> wrote: > On Fri, Sep 19, 2008 at 12:55, Jakub Jelinek <[EMAIL PROTECTED]> wrote: >> On Fri, Sep 19, 2008 at 12:36:12PM -0400, Diego Novillo wrote: >>> When we instantiate char_type_node in tree.c:build_common_tree_nodes >>> we very explicitly create a char_type_node that is signed or unsigned >>> based on the value of -funsigned-char, but instead of make >>> char_type_node point to signed_char_type_node or >>> unsigned_char_type_node, we explicitly instantiate a different type. >> >> C++ e.g. requires that char (c) is mangled differently from unsigned char >> (h) and signed char (a), it is a distinct type. > > Thanks, that answer my question. I suggest that we move these kind of "special" types creation to the frontends and stream out the declaration for LTO to pick it up (so we can LTO between CUs that have different -fsigned/unsigned-char flags). Likewise we need to do this for sizetype if we ever LTO Ada and C CUs for example. Richard.
Etiquette when pinging patches?
I don't want to waste everyone's time with protocol, but I was wondering: what's the etiquette when pinging patches? Should the ping be a reply to the original message (i.e. should it be in the same thread), or should it be a new thread? I was once asked to use new threads instead of the old one, so that's what I've been doing, but there have been two cases recently in which people responded to the original message after the new thread developed. Richard
Re: m32c: pointer math vs sizetype again
On Sat, Sep 20, 2008 at 1:52 AM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> m32c-elf-gcc -mcpu=m32c (16 bit ints, 24 bit pointers) miscompiles
> this:
>
> int *foo (int *a, int b)
> {
> return a-b;
> }
>
> as this:
>
> _foo:
>enter #0 ; 30prologue_enter_24
>pushm r1,r3,a0; 31pushm
>; end of prologue ; 32prologue_end
>mov.w 12[fb],r0 ; 27movhi_op/1
>sha.w #1,r0 ; 7 ashlhi3_i/1
>neg.w r0 ; 8 neghi2/1
>mov.w r0,a0 ; 10zero_extendhipsi2
>mov.l 8[fb],r3r1 ; 28movpsi_op/2
>add.l a0,r3r1 ; 16addpsi3/3
>mov.l r3r1,mem0 ; 29movpsi_op/2
>; start of epilogue ; 35epilogue_start
>popmr1,r3,a0; 36popm
>exitd ; 37epilogue_exitd_24
>
> The key instructions are - neg, zero_extend, add. This breaks if the
> original value is, say, 2. Neg gives 0xfffe, zero_extend gives
> 0x00fffe, and you end up adding 65534 to the pointer.
>
> If I change sizetype to "long unsigned int", it's bigger than a
> pointer, and the front end leaves an unexpected nop_convert in various
> expressions, which causes ICEs.
>
> There is no standard integer type the same size as pointers (24 bit,
> PSImode). IIRC, last time I tried to shoehorn in a PSImode sizetype,
> gcc wanted a full set of math operators for it, which the chip doesn't
> have (they have to be done in HI or SI mode)
>
> I tried making sizetype signed, that ICEd too.
>
> What's the right thing to do?
>
> If the front end either sign extended, or had a POINTER_MINUS_EXPR,
> things would just work.
I think this is one of the reasons sizetype constants(!!) are always
sign-extended.
Of course this makes less sense if non-constants are not ;)
Does the following fix it?
Index: expr.c
===
--- expr.c (revision 140433)
+++ expr.c (working copy)
@@ -8336,8 +8336,12 @@ expand_expr_real_1 (tree exp, rtx target
{
tree op0type = TREE_TYPE (TREE_OPERAND (subsubexp0, 0));
enum machine_mode innermode = TYPE_MODE (op0type);
- bool zextend_p = TYPE_UNSIGNED (op0type);
+ bool zextend_p;
bool sat_p = TYPE_SATURATING (TREE_TYPE (subsubexp0));
+ if (code == POINTER_PLUS_EXPR)
+ zextend_p = false;
+ else
+ zextend_p = TYPE_UNSIGNED (op0type)
if (sat_p == 0)
this_optab = zextend_p ? umadd_widen_optab : smadd_widen_optab;
else
This would affect only targets where the precision of sizetype is not equal to
that of a pointer where it would now sign-extend instead of zero-extending for
C and sign-extending for Ada.
Richard.
> DJ
>
Re: no symbol in current context problem when debug the program in gdb
Please don't crosspost between gcc and gcc-help. Thanks. On Sat, Sep 20, 2008 at 02:48, Peng Yu <[EMAIL PROTECTED]> wrote: > On Mon, Sep 15, 2008 at 2:54 PM, Peng Yu <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> I have the following program. When I step in to test's constructor, I >> would be able to print the variable three. It says >> (gdb) n >> 7 T three = 3; >> (gdb) n >> 8 std::cout << three << std::endl; >> (gdb) p three >> No symbol "three" in current context. >> >> According to gdb mailing list, this is a bug in GCC. I'm wondering if >> this issue has been resolved in the later versions of GCC. Isn't this a case of the stuff that the var-tracking-assignments-branch (http://gcc.gnu.org/wiki/Var_Tracking_Assignments) tries to fix?
Re: C/C++ FEs: Do we really need three char_type_nodes?
Diego Novillo wrote: > On Fri, Sep 19, 2008 at 12:55, Jakub Jelinek <[EMAIL PROTECTED]> wrote: >> On Fri, Sep 19, 2008 at 12:36:12PM -0400, Diego Novillo wrote: >>> When we instantiate char_type_node in tree.c:build_common_tree_nodes >>> we very explicitly create a char_type_node that is signed or unsigned >>> based on the value of -funsigned-char, but instead of make >>> char_type_node point to signed_char_type_node or >>> unsigned_char_type_node, we explicitly instantiate a different type. >> C++ e.g. requires that char (c) is mangled differently from unsigned char >> (h) and signed char (a), it is a distinct type. > > Thanks, that answer my question. But does it need to be streamed out differently? I mean, char_type_node could be streamed out as signed_char_type_node or unsigned_char_type_node, because the mangling has already been done. Paolo
Re: cpp found limits.h in FIXED_INCLUDE_DIR, but not in STANDARD_INCLUDE_DIR
Hi Ho! --- On Fri, 9/19/08, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > Eus <[EMAIL PROTECTED]> writes: > > >> In this case the end result is an x86-build > native-MIPS compiler. > >> This requires first building an x86-x-MIPS > copmiler. Of course in > >> practice it matters whether x86 here is Windows or > GNU/Linux; I can't > >> remember whether the OP said. > > > > Are you saying that there are two steps involved? > > > > I mean: > > 1. Building x86-x-MIPS Compiler > > 2. Building native-MIPS Compiler with the previously > built x86-x-MIPS Compiler > > Yes, that is normally required. Oh, I got it! Thanks for explaining :) > Ian Best regards, Eus
Re: C/C++ FEs: Do we really need three char_type_nodes?
On Sat, Sep 20, 2008 at 04:41, Richard Guenther <[EMAIL PROTECTED]> wrote: > On Fri, Sep 19, 2008 at 6:56 PM, Diego Novillo <[EMAIL PROTECTED]> wrote: >> On Fri, Sep 19, 2008 at 12:55, Jakub Jelinek <[EMAIL PROTECTED]> wrote: >>> On Fri, Sep 19, 2008 at 12:36:12PM -0400, Diego Novillo wrote: When we instantiate char_type_node in tree.c:build_common_tree_nodes we very explicitly create a char_type_node that is signed or unsigned based on the value of -funsigned-char, but instead of make char_type_node point to signed_char_type_node or unsigned_char_type_node, we explicitly instantiate a different type. >>> >>> C++ e.g. requires that char (c) is mangled differently from unsigned char >>> (h) and signed char (a), it is a distinct type. >> >> Thanks, that answer my question. > > I suggest that we move these kind of "special" types creation to the > frontends and > stream out the declaration for LTO to pick it up (so we can LTO between > CUs that have different -fsigned/unsigned-char flags). Likewise we need to do > this for sizetype if we ever LTO Ada and C CUs for example. This is not really possible because when lto1 runs, it needs to have a unique version of char_type_node and the multiple .o files will potentially have different versions of it. In essence, char_type_node needs not exist in GIMPLE or we have to standardize it to either signed_char_type_node or unsigned_char_type_node. So, when we go into GIMPLE, all the instances of char_type_node need to be converted into unsigned_char_type_node or signed_char_type_node. This way different CUs can have different notions of char signedness explicitly outlined in the IL. Ideally, we would do this very early (as soon as the whole CU is in GIMPLE form). In practice, mangling gets in the way and other FE interactions are causing random build failures, so for now I will probably push this fairly late (when GIMPLE is being streamed out). Diego.
Re
ïîðíî ññûëêè ïîðíî íàñèëèå
GCC 4.3.3 Status Report (2008-09-20)
Status == The GCC 4.3 branch is open for regression and documentation fixes. The 4.3 branch has nicely stabilized and the number of new serious regressions is low. There are quite a number of bugs which unclear status as of if they are valid or not. I have put them into WAITING state and CCed relevant maintainers. Likewise missed-optimization regressions are piling up, with low chance of being fixed on a release branch. The 4.3 release schedule asks for the 4.3.3 release to happen around the beginning of November which is when the trunk will enter the post-stage3 regression and documentation fixes only state. Quality Data Priority # Change from Last Report --- --- P12 + 2 P2 121 - 1 P34 +- 0 --- --- Total 127 + 1 Previous Report === http://gcc.gnu.org/ml/gcc/2008-08/msg00463.html The next report for the 4.3 branch will be sent by Jakub. Richard. -- Richard Guenther <[EMAIL PROTECTED]> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
Re: Defining a common plugin machinery
Chris Lattner <[EMAIL PROTECTED]> writes: > On Sep 19, 2008, at 3:25 PM, Ian Lance Taylor wrote: > >> Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes: >> >>> I am much more worried about passes and plugins (and I am very >>> surprised to be almost the only one mentioning passes in plugin >>> discussions). I feel it is a major issue (not a matter of coding, >>> much >>> more a matter of convention & understanding). So far, I have (in MELT >>> branch) a very unsatisfactory bad solution. I defined a few passes, >>> which may (or not) be enabled by some plugins. What I would dream is >>> some machinery to be able to have the plugin ask 'insert my pass >>> foo_pass after the last pass which construct the IPA SSA tuple >>> representation' and this is not achievable today. >> >> I think we also need that for general backend use, not only for >> plugins. E.g., bt-load.c should move to config/sh, and at startup >> time the SH backend should register the pass with the pass manager. > > Is the plugin machinery intended to eventually allow new (GPL > compatible) backends to be used? It would be nice to make llvm-gcc be > a plugin. As this point it seems likely that distributing a gcc plugin will effectively put the distributed code under the GPL. Of course this would not affect other versions of the code which were not distributed as a gcc plugin. I think the main focus of the plugin efforts is to permit inserting extra passes into gcc for various different types of analysis. But I don't see any reason that it would be impossible to insert an entirely new backend. The llvm-gcc plugin could more or less take the GIMPLE structures it had access to, do whatever it liked, and then exit. Ian
Re
ïîðíî ïèçäà ôîòî ïîðíî ïðèêîëû
Re: Etiquette when pinging patches?
Honestly? You should use whatever gets a response. If you are at the point you have to ping a patch, it obviously has fallen through the cracks, and you should do whatever is necessary to make sure it gets attention. To that end, I would just use new threads, as they make it clear it is not part of an ongoing discussion, and something that needs attention. I assume you are already also CC'ing the maintainers you want to review it (I find this is the #1 best way to get a response). On Sat, Sep 20, 2008 at 4:50 AM, Richard Sandiford <[EMAIL PROTECTED]> wrote: > I don't want to waste everyone's time with protocol, but I was wondering: > what's the etiquette when pinging patches? Should the ping be a reply > to the original message (i.e. should it be in the same thread), or should > it be a new thread? I was once asked to use new threads instead of the > old one, so that's what I've been doing, but there have been two cases > recently in which people responded to the original message after the new > thread developed. > > Richard >
Adding to G++: Adding a warning on throwing unspecified exceptions.
I have been following the development of C++0x and ConceptGCC and it has got me interested in developing for G++. I've haven't yet dived far into the G++ code, but I have just been reading the GCC internals documentation at http://gcc.gnu.org/onlinedocs/gccint/index.html. (Of course I was horrified to see it's not written in C++, and it's loaded with macros --- why??). I must admit I'm very slow at reading other people's code. However, I think it might be a good thing to try and add something to G++, mainly as it would be a great learning experience. What I'd like to add is something that I've seen many people request, and something I really want to use: Adding a -W option to check that all function calls and throws comply with the throw() clause of the function they are launched from. This means that if you have a function "void foo() throw(bar);", a warning will be produced if: - foo's source calls "bam() throw(zug);", unless inside a try block that with an associated catch(zug). - foo's source calls any function declared without a finite set of throwable exceptions. ie "void fub();" - if it throws anything except a bar, unless inside a try block with an appropriate catch. - if it calls a function pointer whose throw clause is anything except throw(bar) or throw(). - if it casts a function pointer to another function pointer type whose throw clause is less restrictive. Ignores explicit casts (unless specified by an additional warning specifier). I would expect that using this warning would cause a few annoyances. Namely: A) Common third party code (perhaps even standard library code) is likely to not follow the throw() clause rigidly. However, they probably should. B) Every function called inside a function with a throw clause (unless called from a within a try block with a catch(...)) would also have to have a restricting throw clause, and catch(...)es are not universally approved. C) typedef'd function pointer types cannot have throw() clauses, meaning you can't cast them to throwing function pointer variables without generating my warning. This pretty much prevents use of typedef'd function pointers wherever throw restrictions exist. My questions are: 1) Is my task a sensible one? Is there anything I have got fundamentally wrong? 2) Is there anyone currently doing this? I'd hate to simply duplicate their effort. 3) I've just been taking a glance at the GCC code. Unfortunately I don't have a guide that shows how g++ works or what files I should be reading so it might take some time to figure out. I can't find much readable documentation about the source. Does anyone have any good documentation links about the overall program flow through g++, files/functions etc? I need a primer. Back to the problem: I'm thinking of using -Wthrow-comply and -Wthrow-comply-explicit (which checks explicit function pointer casts). Additional useful warning flags will be: -Wthrow-dtor when a destructor isn't declared to throw nothing. -Wthrow-move for c++0x, when a move constructor isn't declared to throw nothing[#1]. -Wthrow-all: Same as -Wthrow-comply -Wthrow-dtor -Wthrow-move -Wthrow-all-explicit: Same as -Wthrow-comply-explicit -Wthrow-dtor -Wthrow-move 4) Is this too complex? Should I just stick with one or two? Or does this sound appropriate. Now, I'm starting right from the beginning so this is probably a bit of an ambitious task. My guess is that these are the steps I should go through: Step 1: Examine how, in GCC, to add and test for a parameter GCC: -Wthrow-except Step 2: Learn how to emit a warning, eg: "Warning: using -Wthrow-test flag." Step 3: Learn about how the (generic?) tree of statements inside a function is built. http://gcc.gnu.org/onlinedocs/gccint/Trees.html Learn about these objects and macros: Throw statements: ?? Function calls: CALL_EXPR Function pointers: TYPE_PTRFN_P try/catch blocks: TRY_BLOCK and HANDLER. Step 4: Write a quick (generic?) tree output to text routine that lists as much of the tree as is relevant. This tool probably already exists, but it would be good to learn how to do it. Step 5: Learn about how to query a functions' throw() clause with TREE_RAISES_EXCEPTIONS. Step 6: For each function, step through all statements and sub-statements checking for: - throw statements - function calls - try/catch blocks. And for each of these, test their exception(s) vs the allowed exceptions in the throw() clause of the function or in the catch() parameters. Also test for function pointer assignments. If any fail, emit appropriate warnings. 5) Does this sound accurate? Am I missing anything? 6) Should a test like what is done in Step 5 be built as a standalone function that is called once after the tree has been assembled (like a separate compilation step), or should I fit my per element tests beside other per-element operations, such as (I'm guessing) the code that might enforce access permissions (private, protected)? 7) To someone new to the g++ source the include
