Basile STARYNKEVITCH wrote:
> But what about the trunk, which uses tuples?
I know nothing about the tuples and the trunk and whether tuples might
affect the way plugins work. Maybe others can comment...
To be honest i was more worried about how plugins will work with the
garbage collector and pre-
* Brendon Costa wrote on Fri, Sep 19, 2008 at 02:42:19AM CEST:
> What platforms do we want to support? I can think of the following
> categories:
> * Windows (cygwin/mingw)
> As i understand the issue (I am not very familiar with this) you can't
> have unresolved references in a plugin back to the
Hello,
On C structures, for attributes like "const", it is enough to consider
that each field inherit the attribute of the structure.
But for the volatile attribute, is it valid to treat each field as
volatile like GCC does it now?
I mean:
volatile struct { unsigned char a,b,c,d; } volstruct;
voi
Etienne Lorrain wrote:
> On C structures, for attributes like "const", it is enough to consider
> that each field inherit the attribute of the structure.
> But for the volatile attribute, is it valid to treat each field as
> volatile like GCC does it now?
"An object that has volatile-qualified ty
> > On C structures, for attributes like "const", it is enough to
> > consider that each field inherit the attribute of the structure.
> > But for the volatile attribute, is it valid to treat each field as
> > volatile like GCC does it now?
>
> "An object that has volatile-qualified type may be
>
Etienne Lorrain wrote:
>>> On C structures, for attributes like "const", it is enough to
>>> consider that each field inherit the attribute of the structure.
>>> But for the volatile attribute, is it valid to treat each field as
>>> volatile like GCC does it now?
>> "An object that has volatile-qu
I have created a new branch, alias-improvements, which will host work
to transition us to a leaner virtual-operand representation and to
fix the fallout in the optimizers.
The branch is maintained by me, patches should be marked with [alias].
Thanks,
Richard.
Hi Ho!
On Tue, 9/16/08, "Ian Lance Taylor" <[EMAIL PROTECTED]> wrote:
> HOST-x-TARGET == cross-compiler
> native-HOST == native compiler
> BUILD-build native-HOST == native compiler built by cross-compiler
> BUILD-build HOST-x-TARGET == cross-compiler built by cross-compiler
>
> The BUILD-build
Ralf Wildenhues wrote:
> > * Windows (cygwin/mingw)
> > As i understand the issue (I am not very familiar with this) you can't
> > have unresolved references in a plugin back to the GCC executable. I.e.
> > Building GCC with -rdynamic will not work on this platform. Do we move
> > most of the GCC
On Fri, Sep 19, 2008 at 15:30, Brian Dessent <[EMAIL PROTECTED]> wrote:
> Ralf Wildenhues wrote:
> Is it really that far fetched to have the plugin not directly access
> anything from the executable's symbol table but instead be passed a
> structure that contains a defined set of interfaces and ca
Hello All,
(a meta question: do we need to reply-to all, or should the gcc@ list be
enough to discuss plugins, and the only destination of this interesting
discussion?).
Brendon Costa wrote:
Basile STARYNKEVITCH wrote:
But what about the trunk, which uses tuples?
I know nothing about the t
There is a very simple function:
/ func.c **/
#include
uint16_t my_htons(uint16_t hostshort)
{
return htons(hostshort);
}
/**/
$ cc func.c -Wconversion -Werror -c -o func.o
Exit 0
$ cc func.c -O1 -Wconversion -Werror -c -o func.o
cc1: warnings b
On Fri, Sep 19, 2008 at 5:03 PM, Andriy Gapon <[EMAIL PROTECTED]> wrote:
>
> There is a very simple function:
> / func.c **/
> #include
>
> uint16_t my_htons(uint16_t hostshort)
> {
>return htons(hostshort);
> }
> /**/
>
> $ cc func.c -Wconversion -W
void f(int x)
{
char c = x ? '|' : '/';
}
$ cc1: warnings being treated as errors
char.c: In function 'f':
char.c:3: error: conversion to 'char' from 'int' may alter its value
Exit 1
If I replace 'x' with a constant (0 or 1) in the condition, then the
code compiles.
I think gcc shoul
Brian Dessent <[EMAIL PROTECTED]> writes:
> Is it really that far fetched to have the plugin not directly access
> anything from the executable's symbol table but instead be passed a
> structure that contains a defined set of interfaces and callbacks?
Yes, that is pretty far fetched. Simply writ
Basile STARYNKEVITCH wrote:
> (a meta question: do we need to reply-to all, or should the gcc@ list be
> enough to discuss plugins, and the only destination of this interesting
> discussion?).
Reply-to-all is the common standard on the list. If you don't want a
personal copy then set the "Reply-
2008/9/19 Richard Guenther <[EMAIL PROTECTED]>:
>
> The computation __x) >> 8) & 0xff) | (((__x) & 0xff) << 8)) is promoted
> to int as of C language standards rules and the store to __v truncates it.
>
> The warning isn't clever enough to see that this doesn't happen due to
> the masking appl
2008/9/19 Andriy Gapon <[EMAIL PROTECTED]>:
>
> If I replace 'x' with a constant (0 or 1) in the condition, then the code
> compiles.
> I think gcc should be smarter here.
This should be fixed in any recent GCC 4.4. snapshot. But I cannot
test it myself to be sure, if someone would be so kind to c
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
> "Ben" == Ben Elliston <[EMAIL PROTECTED]> writes:
Ben> Do you think that the current order of .exps should be preserved
Ben> in the resultant .sum and .logs?
I personally don't have a use for this.
I just think that the order ought to be stable across checks of the
same build.
Tom
Yes char, unsigned char and signed char are three distant types.
Unlike the other interger types in C/C++. That is they are
incompatable types.
Thanks,
Andrew Pinski
Sent from my iPhone
On Sep 19, 2008, at 9:36 AM, "Diego Novillo" <[EMAIL PROTECTED]>
wrote:
When we instantiate char_typ
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
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 v
Brian Dessent wrote:
Basile STARYNKEVITCH wrote:
I'm not sure that pre-compiled headers (pch) should even work with
plugins. The reasonable solution is to disable them when any plugin is
used [...]
There's already an existing requirement that the compiler options used
when precompiling the .
On Fri, 19 Sep 2008, Brendon Costa wrote:
> 1) Dont allow additional search paths for plugins
I think we do want to allow the user to specify such a path on the
compiler command line, in addition to searching the standard libsubdir or
libexecsubdir location.
> 3) Somehow embed something in all
Brendon Costa wrote:
Joseph S. Myers wrote:
I think this is a bad idea on grounds of predictability.
I can understand this view and was initially reluctant to suggest the
auto-load feature for this same reason. However i can not see another
solution that can be used instead of this to
Taras wrote:
However, I do think it's awesome to be able to store plugin results in
the resulting binary to do LTO-style analyses. How well is that working
for you?
I would be delighted if that would be easily possible, but I remember
having asked at some LTO related session or meeting if LTO
Brendon Costa wrote:
* Automatically loaded plugins as well as explicit user requested plugins
I would like to propose that we allow automatic loading of certain
plugins in addition to the explicit request for loading of plugins using
the -fplugin= command line option.
I think we agree that au
On Fri, Sep 19, 2008 at 13:16, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:
> I would be delighted if that would be easily possible, but I remember having
> asked at some LTO related session or meeting if LTO can be extended to add
> some additional data, and the answer was "we don't want to do
> I think 'make -j' is the way to go, since it lets the user easily
> control the amount of parallelism.
As I said before, make -j is a complete non-starter for me, as it restricts
the paralelism to a single machine and thus would actually reduce the
parallelism from what I have now with multilibs
On Fri, 19 Sep 2008, Manuel López-Ibáñez wrote:
> This should be fixed in any recent GCC 4.4. snapshot. But I cannot
> test it myself to be sure, if someone would be so kind to check this
> for me, I would appreciate it.
Confirmed on i386-unknown-freebsd6.3 using soures as of 20 hours ago.
Gerald
Hello all,
I am looking for a boiled down version of the ia64/32 instruction set
which I could extract instruction/flag dependencies from. As a last
resort I will use the Intel Software Developer PDFs. Based on my
understanding, the ia64.md and i386.md don't exactly give this information.
A
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
On Fri, 2008-09-19 at 18:32 +0100, Joern Rennecke wrote:
> > I think 'make -j' is the way to go, since it lets the user easily
> > control the amount of parallelism.
>
> As I said before, make -j is a complete non-starter for me, as it restricts
> the paralelism to a single machine and thus would
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
> Sorry to nitpick, but there is nothing Mozilla-specific in
> dehydra/treehydra. There are users outside of Mozilla.
Sorry, i didn't realise this.
> However, I do think it's awesome to be able to store plugin results in
> the resulting binary to do LTO-style analyses. How well is that working
>
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
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
38 matches
Mail list logo
