> Given the current limitations of Gimple, another area to focus on could be
> task parallelism (rather than data parallelism). In that case a language
> like [Google] Go (via GCC) might make a better talking point than C or
> Fortran.
An even better starting point would be Ada which has built-in
2010/9/14 Diego Novillo :
> Incidentally, this is an issue I would like to address. We need
> someone interested in maintaining the GC machinery. Any volunteers?
> Laurynas?
Thanks for the suggestion. In fact, I was meaning to apply. But I can
see a few things that need to be considered:
- Most
> The GCC middle end use is for me mandatory (since it is contractual). I
> am expecting to work on Gimple to OpenCL translation, whatever that
> means. The saling point it that starting from GCC & gimple gives the
> hypothetical enduser all the power of GCC.
Given the current limitations of Gimp
David Weiser writes:
> I am looking at bug number 99 on
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=99 and I am adding a test
> case for it.
> The testcase looks like this:
> //---start test case
> /*
> {do-run compile}
> */
This should be
/* { dg-do compile } */
or, equivalently fo
Howdy,
I am looking at bug number 99 on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=99 and I am adding a test
case for it.
The testcase looks like this:
//---start test case
/*
{do-run compile}
*/
template class X {};
template int f(X, X);
template int f(X, X);
int main(void) {
Snapshot gcc-4.4-20100914 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100914/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Tue, 14 Sep 2010, Diego Novillo wrote:
> On Tue, Sep 14, 2010 at 06:09, Richard Guenther
> wrote:
> > On Tue, Sep 14, 2010 at 12:33 AM, Ian Lance Taylor wrote:
> >> Manuel López-Ibáñez writes:
> >>
> >>> In the same sense that adding clang->gcc means that there is less
> >>> motivation for d
On Tue, Sep 14, 2010 at 9:47 PM, Ian Lance Taylor wrote:
> So far my best guess is that your definition is
> "warn about implicit conversions from float to double except for those
> conversions caused by default argument promotion applied to arguments
> passed to unnamed parameters." Is that what
On Tue, Sep 14, 2010 at 06:09, Richard Guenther
wrote:
> On Tue, Sep 14, 2010 at 12:33 AM, Ian Lance Taylor wrote:
>> Manuel López-Ibáñez writes:
>>
>>> In the same sense that adding clang->gcc means that there is less
>>> motivation for developers to improve the current C/C++ FEs.
>>
>> From th
On Tue, Sep 14, 2010 at 16:48, Basile Starynkevitch
wrote:
> Is it becoming a GC or gengtype reviewer?
Yes.
Diego.
On Tue, 14 Sep 2010 16:40:59 -0400
Diego Novillo wrote:
>
> Incidentally, this is an issue I would like to address. We need
> someone interested in maintaining the GC machinery. Any volunteers?
> Laurynas?
What do you mean by "maintaining the GC machinery"?
What is not working in the current
On Tue, Sep 14, 2010 at 15:22, Basile Starynkevitch
wrote:
> I'm just trying to figure out what are the features in 4.6 which will
> be useful to my work. I know that in a couple of weeks, they are frozen
> (since 4.6 is ending stage 1). The gengtype patch series
No. End of October.
> http://g
Andrew Pinski writes:
> On Tue, Sep 14, 2010 at 11:47 AM, Uday P. Khedker wrote:
>> Attached please find two dumps t.c.032t.mergephi1 and t.c.033t.cddce1.
>> The assignment is present in the former while it disappears in the
>> latter. The latter dump is the output of the dead code elimination
>
tbp writes:
> On Tue, Sep 14, 2010 at 8:44 PM, Ian Lance Taylor wrote:
>> Let me put it a different way: what is it that you want, expressed in
>> terms of C/C++ code? What should the compiler be warning about?
> Hmm. I think the provided example captures most of what i care about,
> float ar
On 14/09/2010 19:47, Uday P. Khedker wrote:
> But may be you are right, what facilitate dead code elimination
> be based on modification of read-only data. However, if that is
> the case, I wonder what is the reason why change happens when s is
> an array...
Because the array, unlike the string
On Tue, 14 Sep 2010 11:21:51 -0600
Marcus Daniels wrote:
> On 9/14/10 10:58 AM, Basile Starynkevitch wrote:
> >> It seems to me a "source to source" compiler should definitely retain
> >> high level constructs like array operators, DO ALL, OpenMP directives, etc
> > One can use #pragma-s& buil
On Tue, Sep 14, 2010 at 8:44 PM, Ian Lance Taylor wrote:
> Let me put it a different way: what is it that you want, expressed in
> terms of C/C++ code? What should the compiler be warning about?
Hmm. I think the provided example captures most of what i care about,
float area(float radius) { ret
On Tue, Sep 14, 2010 at 2:35 PM, Ian Lance Taylor wrote:
>
> I think this is simply a bug. It doesn't happen with current gcc. With
> gcc 4.4.3 the assignment is being eliminated because it is considered to
> be dead code.
>
> I agree that it is an error for gcc to simply eliminate this assignme
You got me there :-)
Yes you are right. The reason I gave for dead code elimination is not
sound! Should have thought a bit before writing :-(
Uday.
Axel Freyn wrote, On Wednesday 15 September 2010 12:05 AM:
Hello Uday,
On Tue, Sep 14, 2010 at 11:50:11PM +0530, Uday P. Khedker wrote:
[..]
The
On Tue, Sep 14, 2010 at 11:47 AM, Uday P. Khedker wrote:
> Attached please find two dumps t.c.032t.mergephi1 and t.c.033t.cddce1.
> The assignment is present in the former while it disappears in the
> latter. The latter dump is the output of the dead code elimination
> pass pass_cd_dce. So this is
Attached please find two dumps t.c.032t.mergephi1 and t.c.033t.cddce1.
The assignment is present in the former while it disappears in the
latter. The latter dump is the output of the dead code elimination
pass pass_cd_dce. So this is indeed an instance of dead code elimination.
But may be you are
tbp writes:
> On Tue, Sep 14, 2010 at 7:14 PM, Ian Lance Taylor wrote:
>> What is it that you want?
> I'd like to have a warning for when a value of type float is
> implicitly promoted to double, for performance reasons (on x86).
Let me put it a different way: what is it that you want, expresse
Hello Uday,
On Tue, Sep 14, 2010 at 11:50:11PM +0530, Uday P. Khedker wrote:
> [..]
> The point is: in your program is is only a pointer. When you pass s
> as a parameter to printf, the compiler assumes that only s is being
> used so the (effective) assignment
>
>*s = 'H'
>
> is deleted as dead
Godmar Back writes:
> this may be a FAQ - in my class today when discussing how gcc
> generates code for x86, I was stumped when I showed an example of how
> gcc handles attempts to modify (read-only) string literals/constants.
> (I'm sending this to gcc rather than gcc-help because I'm asking fo
On Tue, Sep 14, 2010 at 7:14 PM, Ian Lance Taylor wrote:
> What is it that you want?
I'd like to have a warning for when a value of type float is
implicitly promoted to double, for performance reasons (on x86). Note
that in that context, caring about variadic functions makes little
sense to begin
On Tue, Sep 14, 2010 at 11:50:11PM +0530, Uday P. Khedker wrote:
> The point is: in your program is is only a pointer. When you pass s
> as a parameter to printf, the compiler assumes that only s is being
> used so the (effective) assignment
>
>*s = 'H'
>
> is deleted as dead code when optimi
On 9/14/2010 10:59 AM, Daniel Jacobowitz wrote:
>> printf("%f", f);
>> double.cc:5:7: warning: implicit conversion from 'float' to 'double'
> My two cents, but that looks exactly right to me. Passing the float
> to printf is going to convert it to a double and it will be printed as
> a dou
Interesting example indeed!
Replace the declaration of s to
char s[] = "hello";
and see "Hello" being printed :-)
The point is: in your program is is only a pointer. When you pass s
as a parameter to printf, the compiler assumes that only s is being
used so the (effective) assignment
Hi,
this may be a FAQ - in my class today when discussing how gcc
generates code for x86, I was stumped when I showed an example of how
gcc handles attempts to modify (read-only) string literals/constants.
(I'm sending this to gcc rather than gcc-help because I'm asking for a
design rationale - I
On 9/14/10 10:58 AM, Basile Starynkevitch wrote:
It seems to me a "source to source" compiler should definitely retain
high level constructs like array operators, DO ALL, OpenMP directives, etc
One can use #pragma-s& builtin-s& attributes for these. This is why I was
trying to push the idea
tbp writes:
> On Tue, Sep 14, 2010 at 4:58 PM, Ian Lance Taylor wrote:
>> This question is not appropriate for the mailing list g...@gcc.gnu.org.
>> ...
>> This is among the kinds of things which -Wdouble-promotion is documented
>> to warn about, so, yes, this is how it's meant to be.
> Honestly
On Tue, 14 Sep 2010 16:01:34 +0200
Richard Guenther wrote:
> > But is the overall idea enough, or did I misunderstood builtins?
>
> Builtins use a fixed code (in DECL_FUNCTION_CODE) and have
> a class (BUILT_IN_MD, BUILT_IN_NORMAL, etc.). Thus without
> making the code assigning dynamic this wo
On Tue, Sep 14, 2010 at 9:17 PM, Laurynas Biveinis
wrote:
> I have reproduced it and the patch below fixes the issue, sorry for
> breaking things. Dennis, could you see if it works for you?
>
> When gcc-core tarball is used without other frontends, gengtype does
> not get to see that lang_type is
On Tue, 14 Sep 2010 09:39:21 -0600
Marcus Daniels wrote:
> On 9/14/10 8:46 AM, Basile Starynkevitch wrote:
> > My current work aims to translate some Gimple into OpenCL source
> > code, thus providing GCC with the ability to take advantage of GPU
> > running their proprietary OpenCL compilers
> So I get in stderr:
> ,
> | g (nD.1176)
> | {
> | :
> | Invalid sum of outgoing probabilities 0.0%
> | goto ;
> |
> | Invalid sum of incoming frequencies 0, should be 4600
> | :;
> | f (&"1"[0]);
> | goto ;
> |
> | Invalid sum of incoming frequencies 0, should be 5400
> | :;
> | f (
Sebastian Pop writes:
> On Tue, Sep 14, 2010 at 10:52, Paulo J. Matos wrote:
>> mark_irreducible_loops is actually failing with a segmentation fault:
>
> It looks like you don't work at a level where the loops are built.
> So don't call mark_irreducible_loops, just use what Richi suggested:
>
>
On Tue, Sep 14, 2010 at 5:39 PM, Marcus Daniels wrote:
> On 9/14/10 8:46 AM, Basile Starynkevitch wrote:
>>
>> My current work aims to translate some Gimple into OpenCL source
>> code, thus providing GCC with the ability to take advantage of GPU
>> running their proprietary OpenCL compilers with
Richard Guenther writes:
> On Tue, Sep 14, 2010 at 5:36 PM, Sebastian Pop wrote:
>
> Just free them. All following users are required to eventually
> compute them anyway. Thus,
>
>free_dominance_info (CDI_DOMINATORS);
>
Thanks, it works! :)
--
PMatos
On Tue, Sep 14, 2010 at 10:52, Paulo J. Matos wrote:
> mark_irreducible_loops is actually failing with a segmentation fault:
It looks like you don't work at a level where the loops are built.
So don't call mark_irreducible_loops, just use what Richi suggested:
free_dominance_info (CDI_DOMINATORS
On Tue, Sep 14, 2010 at 5:55 PM, Chris Lattner wrote:
>
> On Sep 14, 2010, at 7:22 AM, David Edelsohn wrote:
>
>> On Mon, Sep 13, 2010 at 6:33 PM, Ian Lance Taylor wrote:
>>> Manuel López-Ibáñez writes:
>>>
In the same sense that adding clang->gcc means that there is less
motivation fo
On Sep 14, 2010, at 7:22 AM, David Edelsohn wrote:
> On Mon, Sep 13, 2010 at 6:33 PM, Ian Lance Taylor wrote:
>> Manuel López-Ibáñez writes:
>>
>>> In the same sense that adding clang->gcc means that there is less
>>> motivation for developers to improve the current C/C++ FEs.
>>
>> From the
Sebastian Pop writes:
> On Tue, Sep 14, 2010 at 10:19, Paulo J. Matos wrote:
>> How can I automatically update dominators? Or do I have to do it for
>> each new basic_block I create with recompute_dominator?
>
> /* Free and compute again all the dominators information. */
>
> static inline void
On Tue, Sep 14, 2010 at 4:58 PM, Ian Lance Taylor wrote:
> This question is not appropriate for the mailing list g...@gcc.gnu.org.
> ...
> This is among the kinds of things which -Wdouble-promotion is documented
> to warn about, so, yes, this is how it's meant to be.
Honestly i've pondered not sen
On Tue, Sep 14, 2010 at 5:36 PM, Sebastian Pop wrote:
> On Tue, Sep 14, 2010 at 10:19, Paulo J. Matos wrote:
>> How can I automatically update dominators? Or do I have to do it for
>> each new basic_block I create with recompute_dominator?
>
> /* Free and compute again all the dominators informat
On 9/14/10 8:46 AM, Basile Starynkevitch wrote:
My current work aims to translate some Gimple into OpenCL source
code, thus providing GCC with the ability to take advantage of GPU
running their proprietary OpenCL compilers without asking the user to
learn OpenCL.
My understanding is that Gimpl
On Tue, Sep 14, 2010 at 10:19, Paulo J. Matos wrote:
> How can I automatically update dominators? Or do I have to do it for
> each new basic_block I create with recompute_dominator?
/* Free and compute again all the dominators information. */
static inline void
recompute_all_dominators (void)
{
On Tue, Sep 14, 2010 at 4:51 PM, Ian Lance Taylor wrote:
> Please do file a PR if there isn't one already. Thanks.
I have no idea if that could happen outside C++ and couldn't find
anything relevant, thus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45668
That's the best i can do.
And thanks for y
Hello,
My pass is now generating a correct CFG structure (statements are in the
right place and edges between bbs are ok), however in the end due TODO,
it fails.
Here's the pass definition:
,
| struct tree_opt_pass pass_clusterswt =
| {
|"clusterswt", /* name */
|
tbp writes:
> I could really use -Wdouble-promotion but, atm, it appears quite impractical,
> $ cat double.cc
> #include
> void foo(...);
> int main() {
> float f = 1;
> foo(f);
> printf("%f", f);
> }
> $ /usr/local/gcc-4.6-20100913/bin/g++ -Wdouble-promotion double.cc
> double
On Tue, Sep 14, 2010 at 04:30:09PM +0200, tbp wrote:
> Hello,
> I could really use -Wdouble-promotion but, atm, it appears quite impractical,
> $ cat double.cc
> #include
> void foo(...);
> int main() {
> float f = 1;
> foo(f);
> printf("%f", f);
> }
> $ /usr/local/gcc-4.6-201009
tbp writes:
> Would it be possible to have some clarifications? Shall i file a PR
> for a warning? Sacrifice a goat?
Please do file a PR if there isn't one already. Thanks.
Ian
On Tue, Sep 14, 2010 at 10:12:18AM -0400, Diego Novillo wrote:
> On Tue, Sep 14, 2010 at 09:36, Basile Starynkevitch
> wrote:
>
> > I was thinking of adding a new plugin hook for builtins.
> Plugin hooks should only be added when an actual need arises. Adding
> hooks for the sake of adding hook
On 09/14/2010 04:29 PM, Joseph S. Myers wrote:
> INTMAX_TYPE is not currently defined for any target to use an extended
> integer type.
>
Thanks Joseph. Then I guess we can implement the proposed resolution
rather easily ;)
Paolo.
Hello,
I could really use -Wdouble-promotion but, atm, it appears quite impractical,
$ cat double.cc
#include
void foo(...);
int main() {
float f = 1;
foo(f);
printf("%f", f);
}
$ /usr/local/gcc-4.6-20100913/bin/g++ -Wdouble-promotion double.cc
double.cc: In function 'int m
On Tue, 14 Sep 2010, Paolo Carlini wrote:
> long long, by specifying that adds overloads for intmax_t
> only when the latter is an actual extended integer type, thus does not
> boil down to any standard integer type.
>
> I'm looking for help in figuring out whether this situation can really
> ha
Hi everyone,
I'm analyzing the proposed resolution of this issue:
http://wiki.dinkumware.com/twiki/pub/Wg21batavia/LibraryWorkingGroup/incomplete_spec_of_cinttypes.html
which tries to resolve a conflict with the abs and div overloads for
long long, by specifying that adds overloads for intm
On Mon, Sep 13, 2010 at 6:33 PM, Ian Lance Taylor wrote:
> Manuel López-Ibáñez writes:
>
>> In the same sense that adding clang->gcc means that there is less
>> motivation for developers to improve the current C/C++ FEs.
>
> From the perspective of gcc, I think the goal of clang->gcc would be to
Hello,
i know it's no good form to reply to self, or be that insistent, but
i've been hit again.
In the bug report discussion, i've been told by A. Pinski that, as of
now, forward declarations shall have matching attributes. That's fine,
i suppose. What's not is that:
. that new behavior, as far
Hello All
See also my message http://gcc.gnu.org/ml/gcc/2010-09/msg00270.html
about plugin hooks for plugin-provided builtins?
I was thinking of adding a new plugin hook for plugin-provided
additional macros.
The intuition is that some plugins would be delighted if they could
add their own prede
On Tue, Sep 14, 2010 at 3:36 PM, Basile Starynkevitch
wrote:
> I was thinking of adding a new plugin hook for builtins.
Shouldn't there be a final consensus about the existing hooks, and
actual users of them, before adding more and more and more plugin
hooks?
Ciao!
Steven
On Tue, Sep 14, 2010 at 09:36, Basile Starynkevitch
wrote:
> I was thinking of adding a new plugin hook for builtins.
We need to have a good use case before adding any more plugin hooks.
In the case of this proposal, you also need a fixed code and a class
for the builtins to work.
In general, p
On Tue, Sep 14, 2010 at 3:36 PM, Basile Starynkevitch
wrote:
> Hello All,
>
> I was thinking of adding a new plugin hook for builtins.
>
> The intuition is that some plugins could be pleased if they could add
> their own plugins (much like today's plugins can add their own pragmas
> or attributes)
Hello All,
I was thinking of adding a new plugin hook for builtins.
The intuition is that some plugins could be pleased if they could add
their own plugins (much like today's plugins can add their own pragmas
or attributes).
I imagine several use cases for such a feature, for example
* a buil
I have reproduced it and the patch below fixes the issue, sorry for
breaking things. Dennis, could you see if it works for you?
When gcc-core tarball is used without other frontends, gengtype does
not get to see that lang_type is in fact variable_size and when the
frontends are present, their vari
/home/andrew/builder/gcj/./prev-gcc/xgcc
-B/home/andrew/builder/gcj/./prev-gcc/
-B/home/andrew/build/gcj/x86_64-unknown-linux-gnu/bin/
-B/home/andrew/build/gcj/x86_64-unknown-linux-gnu/bin/
-B/home/andrew/build/gcj/x86_64-unknown-linux-gnu/lib/ -isystem
/home/andrew/build/gcj/x86_64-unknown-linux-g
14.9.2010 11:29, Dennis, CHENG Renquan kirjoitti:
For anyone could succeed compiling gcc-4.6, could you paste a correct
ggc_alloc_cleared_lang_type macro ?
just run this grep command under your build directory,
gcc-4.6-build$ grep -RsInw ggc_alloc_cleared_lang_type gcc/
gcc/gtype-desc.h:2451:#
Richard Guenther writes:
> On Tue, Sep 14, 2010 at 11:08 AM, Paulo J. Matos wrote:
>>
>> Hello all,
>>
>> I am moving basic blocks around and currently the cfg is getting very,
>> very awkward. My guess is that I am doing something I shouldn't [as
>> usual].
>>
>> For each SWITCH_EXPR I found on
On Tue, Sep 14, 2010 at 11:08 AM, Paulo J. Matos wrote:
>
> Hello all,
>
> I am moving basic blocks around and currently the cfg is getting very,
> very awkward. My guess is that I am doing something I shouldn't [as
> usual].
>
> For each SWITCH_EXPR I found on the code I generate a CFG which I ha
On Tue, Sep 14, 2010 at 12:33 AM, Ian Lance Taylor wrote:
> Manuel López-Ibáñez writes:
>
>> In the same sense that adding clang->gcc means that there is less
>> motivation for developers to improve the current C/C++ FEs.
>
> From the perspective of gcc, I think the goal of clang->gcc would be to
Hello all,
I am moving basic blocks around and currently the cfg is getting very,
very awkward. My guess is that I am doing something I shouldn't [as
usual].
For each SWITCH_EXPR I found on the code I generate a CFG which I have
to replace with the SWITCH_EXPR. The switch is always the last stat
For anyone could succeed compiling gcc-4.6, could you paste a correct
ggc_alloc_cleared_lang_type macro ?
just run this grep command under your build directory,
gcc-4.6-build$ grep -RsInw ggc_alloc_cleared_lang_type gcc/
gcc/gtype-desc.h:2451:#define ggc_alloc_cleared_lang_type() ((struct
lang_ty
71 matches
Mail list logo