On 10/09/13 04:44, Jeff Law wrote:
> On 09/09/2013 02:45 PM, Andrew MacLeod wrote:
>> A number of header files have inline functions declared in them. Some of
>> these functions are actually quite large, and I doubt that inlining them
>> is the right thing. For instance, tree-flow-inline.h has so
On Tue, Sep 10, 2013 at 10:06:04AM +0200, David Brown wrote:
> This last point is crucial. I haven't looked at the code in question,
> but one point to check is how the functions are called. If they are
> often called with constant values, then they may be very much simplified
> due to constant p
On 10/09/13 10:11, Jakub Jelinek wrote:
> On Tue, Sep 10, 2013 at 10:06:04AM +0200, David Brown wrote:
>> This last point is crucial. I haven't looked at the code in question,
>> but one point to check is how the functions are called. If they are
>> often called with constant values, then they ma
On Mon, 9 Sep 2013, Marc Glisse wrote:
> On Mon, 9 Sep 2013, Vidya Praveen wrote:
>
> > Hello,
> >
> > This post details some thoughts on an enhancement to the vectorizer that
> > could take advantage of the SIMD instructions that allows indexed element
> > as an operand thus reducing the need f
On Tue, Sep 10, 2013 at 10:11 AM, Jakub Jelinek wrote:
> On Tue, Sep 10, 2013 at 10:06:04AM +0200, David Brown wrote:
>> This last point is crucial. I haven't looked at the code in question,
>> but one point to check is how the functions are called. If they are
>> often called with constant valu
> On 10/09/13 10:11, Jakub Jelinek wrote:
> > On Tue, Sep 10, 2013 at 10:06:04AM +0200, David Brown wrote:
> >> This last point is crucial. I haven't looked at the code in question,
> >> but one point to check is how the functions are called. If they are
> >> often called with constant values, th
On Tue, 2013-09-10 12:01:34 +1200, Maxim Kuvyrkov wrote:
> On 7/09/2013, at 1:31 AM, Jan-Benedict Glaw wrote:
> > This however still seems to have issues in a current build:
> >
> > http://toolchain.lug-owl.de/buildbot/showlog.php?id=10520&mode=view
>
> Mn10300-linux does not appear to be su
On Tue, Sep 10, 2013 at 11:06 AM, Jan Hubicka wrote:
>> On 10/09/13 10:11, Jakub Jelinek wrote:
>> > On Tue, Sep 10, 2013 at 10:06:04AM +0200, David Brown wrote:
>> >> This last point is crucial. I haven't looked at the code in question,
>> >> but one point to check is how the functions are calle
>
> But then inlining / cloning is no longer cheap, no? And will be
> disabled at -O2?
If you declare it "inline" and not "static inline" it will be inlined pretty
much as before, only it will get unified if it ends up out of line in multiple
units.
Main difference in between static and non-s
> >
> > But then inlining / cloning is no longer cheap, no? And will be
> > disabled at -O2?
>
> If you declare it "inline" and not "static inline" it will be inlined pretty
> much as before, only it will get unified if it ends up out of line in multiple
> units.
>
> Main difference in betwee
On 09/10/2013 04:44 AM, Richard Biener wrote:
On Tue, Sep 10, 2013 at 10:11 AM, Jakub Jelinek wrote:
On Tue, Sep 10, 2013 at 10:06:04AM +0200, David Brown wrote:
This last point is crucial. I haven't looked at the code in question,
but one point to check is how the functions are called. If t
On Tue, Sep 10, 2013 at 07:01:26PM +0400, Michael V. Zolotukhin wrote:
> I continued playing with plugins for libgomp, and I have several questions
> regarding that:
>
> 1) Would it be ok, at least for the beginning, if we'd look for plugins in a
> folder, specified by some environment variable?
Hi Jakub,
I continued playing with plugins for libgomp, and I have several questions
regarding that:
1) Would it be ok, at least for the beginning, if we'd look for plugins in a
folder, specified by some environment variable? A plugin would be considered
as suitable, if it's named "*.so" and if d
> Trying to dlopen random libraries is bad, so when libgomp dlopens something,
> it better should be a plugin and not something else.
> I'd suggest that the name should be matching libgomp-plugin-*.so.1 or
> similar wildcard.
Ok, sounds reasonable.
> Why? If this is the plugin stuff, then IMNSHO
> I don't need that infrastructure for that, I meant just a hack that say for
> OMP_DEFAULT_DEVICE=257 I'd use this hackish device, and store the splay tree
> root and lock in a global var with a comment that that in the future will
> belong into the per-device structure.
Okay, hopefully I would ha
I am pleased to announce that the GCC Steering Committee has
appointed Caroline Tice as VTV (libvtv) maintainer.
Please join me in congratulating Caroline on her new role.
Please update your listing in the MAINTAINERS file.
Happy hacking!
David
I am pleased to announce that the GCC Steering Committee has
appointed DJ Delorie and Nick Clifton as maintainers for the MSP430 port
Please join me in congratulating DJ and Nick on their new role.
Please update your listing in the MAINTAINERS file.
Jeff
Hello Maintainers,
if you like to drop h8/300 support in linux kernel, thats OK for me.
But i like to see it still supported in gcc & binutils, at least i have some projects and know companies using this architecture in embedded applications, bare
metal without OS. These products have lifetime i
On 10/09/13 20:12, Jeff Law wrote:
I am pleased to announce that the GCC Steering Committee has
appointed DJ Delorie and Nick Clifton as maintainers for the MSP430 port
Please join me in congratulating DJ and Nick on their new role.
Please update your listing in the MAINTAINERS fil
On 09/09/2013 03:49 PM, Matthew Fortune wrote:
>
>> -Original Message-
>> From: Vladimir Makarov [mailto:vmaka...@redhat.com]
>> Sent: 08 September 2013 17:51
>> To: Matthew Fortune
>> Cc: gcc@gcc.gnu.org; ber...@codesourcery.com
>> Subject: Re: mips16 LRA vs reload - Excess reload register
On Tue, 10 Sep 2013, Maxim Kuvyrkov wrote:
> Mn10300-linux does not appear to be supporting linux. Mn10300-linux
> target specifier expands into mn10300-unknown-linux-gnu, where *-gnu
> implies using Glibc library, which doesn't have mn10300 port.
It's called am33, and the GCC port is also cal
On Tue, Sep 10, 2013 at 07:30:53PM +0400, Michael V. Zolotukhin wrote:
> > > 4) We'll need to store some information about available devices:
> > > - a search tree with data about mapping
> >
> > For the search tree, I was going to actually implement it myself, but got
> > interrupted this week
On 09/11/2013 03:55 AM, Michael Schewe wrote:
> Hello Maintainers,
>
> if you like to drop h8/300 support in linux kernel, thats OK for me.
OK, thanks.
> But i like to see it still supported in gcc & binutils, at least i have
> some projects and know companies using this architecture in embedded
Tobias Burnus writes:
>
> Those require -fcilkplus and -fopenmp, respectively, and activate much
> more. The question is whether it makes sense to provide a means to ask
> the compiler for SIMD vectorization without enabling all the other things
> of Cilk Plus/OpenMP. What's your opinion?
If you
24 matches
Mail list logo
