> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
> Behalf Of Abe
> Sent: Wednesday, July 22, 2015 4:20 AM
>
> [Abe wrote:]
> >> The preceding makes me wonder: has anybody considered adding an
> optimization
> >> profile for GCC, […] that optimizes for the amount of energy
> consumed
Hi,
Current email address for Xuepeng Guo is terry@arm.com
Best regards,
Thomas
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
> Behalf Of Eric S. Raymond
> Sent: Thursday, August 27, 2015 10:38 PM
> To: gcc@gcc.gnu.org
> Subject: Repository for
statements.
Best regards,
Thomas Preud'homme
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, June 10, 2014 5:16 PM
>
> In general this is impossible to do. I don't have a good answer on
> how to determine whether (unaligned) load + bswap is faster than
> doing sth else - but there is a very good chance that the
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Wednesday, June 11, 2014 4:09 PM
> >
> > Oh I see. Doing it there would mean instead of two independent
> > operations you'd do the best combination possible, is that right?
>
> Yes (but probably it's not worth the trouble).
I un
o just one conversion
completely in fold_nonarray_ctor_reference but somehow I feel it is
not the right place to do it. As anybody a better advice?
Best regards,
Thomas Preud'homme
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Friday, June 27, 2014 5:32 PM
> > 4) Cast value stored in a according to the size of b by removing bits of
> > highest weight (via VIEW_CONVERT_EXPR).
>
> Fact is that 4) already is not working.
>
> /* We are at the end of walk,
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Friday, June 27, 2014 6:23 PM
>
> Yes - I was specifically looking for an early out to avoid wrong-code.
> So, is size % BITS_PER_UNIT != 0 a working fix to avoid the wrong-code
> issues with bitfields (on big-endian targets)?
I'm
> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
> Sent: Thursday, August 14, 2014 4:52 PM
>
> Newlib also has an integer-only printf implementation, but in this case,
> the default is the other way round - you have to use functions with
> nonstandard
> names to use the integer-only imp
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Wilco Dijkstra
>
> One could hack this a bit further and set flag_omit_frame_pointer = 2 to
> differentiate between a
> user setting and the override hack, but that's just making things even worse.
> So I see 3 possible
>
> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
> Sent: Thursday, August 14, 2014 4:52 PM
>
> So my idea is to make the compile emit special calls when there are no
> floating
> point arguments. A library that provides the floating point enabled
> *printf/*scanf
> precedes libc in lin
> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
> Sent: Tuesday, August 26, 2014 6:44 PM
>
> Due to the library order defined in the specs, the float-enbled printf
> definition will
> be picked up from libprintf_flt.a .
It seems to me that it relies heavily on how symbol resolution wo
> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
> Sent: Wednesday, August 27, 2014 6:13 PM
>
> I don't see how it can be any other way. We want to be able to compile
> translation units individually, and then let the linker sort out if we need
> the
> floating point enabled implement
> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
> Sent: Wednesday, August 27, 2014 7:54 PM
>
> Well, my goal was to have the selection be automatic for most use cases.
> That you can do a manual selection by providing -u / -l arguments to the
> linker is pretty much a given.
> Hmm, ins
> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
> Sent: Thursday, August 28, 2014 9:48 PM
> >
> > Right now I'm having trouble to define stdio_altname in newlib-c.c since
> this would
> > require it to be a C target hook but such a hook cannot be called from
> middle end.
>
> Hmm, yes,
> From: Grissiom [mailto:chaos.pro...@gmail.com]
> Sent: Friday, August 29, 2014 11:51 PM
>
> Yes, it does. The namespace reserved for the implementation is _[_A-Z].
> The namespace _[a-z] is still available for the user. Which means the
> user can declare their own _printf_float, and WE (as th
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
> Of Thomas Preud'homme
> Sent: Saturday, August 30, 2014 12:27 PM
> Mmmh indeed. I checked C99 and section 7.1.3 paragraph 1 third clause
> states:
>
> "
> From: Joseph S. Myers [mailto:jos...@codesourcery.com]
> Sent: Tuesday, September 02, 2014 11:29 PM
>
> Identifiers beginning with a single underscore are reserved with file
> scope. This means an application cannot provide an external definition of
> them, because such an external definition w
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Ian Grant
>
> And can anyone tell me what are the 'non-vanilla' sources?
"Vanilla source" refers to unmodified source (as distributed on gcc.gnu.org for
the case of gcc). This is in contrast to modified source from distr
Hi all,
I changed the target hook somehow so that more code run in the backend since
depending on the target (avr-libc Vs newlib) two different schemes are used:
printf -> iprintf renaming or defining _printf_float as a global symbol.
I thus renamed the target hook to match such a usage.
The pr
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
> Behalf Of Joseph S. Myers
>
> I'm not clear if you're proposing such a patch for review, but note:
Yep but not yet for inclusion as I'm waiting to see if this would suit the use
case of avr people.
>
> (a) you mean DEF_EXT_LIB_B
> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
> Sent: Sunday, November 02, 2014 4:34 PM
>
> Sorry for the late reply, I was on vacation, and then I meant to flesh
> out a suitable
> solution for the macro/hook problem to test it, but the more I think
> about it, the more
> questions
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
> Behalf Of James Greenhalgh
Hi James,
>
> The stages, timings, and exact rules for which patches are acceptable
> and when, seem to have drifted quite substantially from that page.
> Stage 2 has been missing for 7 years now, Stages
> From: Thomas Preud'homme
> [Since I can now send emails without disclaimers, I registered to the mailing
> list with my work email. Thus no need to CC me anymore.]
Failed in the previous 2 emails. Sorry about that.
[Since I can now send emails without disclaimers, I registered to the mailing
list with my work email. Thus no need to CC me anymore.]
My apologize for the line length, the MUA says it all I think. It seems to
ignore my word wrap setting
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> S
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Yeah, that'd be great. The checking that MIPS's -mno-float should do
> (but doesn't do) would be a superset of what you need, since the MIPS
> case would include internal uses of floats. But it would definitely
> make sense to share
, it
shouldn't be a problem. Of course, all this is only true for ARM, things would
be
different for avr for instance (backend generates call to __mul* functions).
Best regards,
Thomas Preud'homme
loat code
does not need to be linked. For program where this
automatic detection is too conservative it would then
still be possible to use the switch to force the float code
to be left out.
Best regards,
Thomas Preud'homme
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
>
> "Thomas Preud'homme" writes:
>
> -mno-float causes gcc to define the macro __mips_no_float, which the
> implementation can use when deciding whether to bother handling %f, etc.
> I'm afr
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
>
> Yes. The configurations that support -mno-float have separate -mno-float
> multilibs. In a sense, the point of -mno-float instead of -msoft-float is
> to select these cut-down libraries.
IIRC, glibc loads some code on demand to a
in correct code. Think for
instance at unused variables. I think this is the same kind of situation here:
the construct is valid but for many (or at least some) users it's not something
they are likely to use and might indicate an error. I think the rationale
provided
by Daniel is sound.
Thomas Preud'homme
work just to shut the compiler up, and this often
> IME leads to inadvertent code breakage.
Sure, I would be again enabling it by default. This means it should *not* be
enabled by Wall or even Wextra.
Best regards,
Thomas Preud'homme
Hi everybody,
When playing with a toolchain built with --with-newlib switch, I recently
noticed that libgcc.a includes __eprintf among its objects. However,
gcc/doc/install.texi states that --with-newlib switches "causes
@code{__eprintf} to be omitted from @file{libgcc.a} on the assumption that
> From: Ian Lance Taylor [mailto:i...@google.com]
>
> I don't think anything uses __eprintf any more. The function has been
> left behind for very very very old systems. Actually we could
> probably remove it now. Probably the old support for not building
> __eprintf when --with-newlib was spec
> From: Andrew Pinski [mailto:pins...@gmail.com]
>
> I think your patch is broken since the object file (_eprintf.o) should
> not be pulled in unless it is used and it is part of an archive and
> for archives cause the linker to only bring in object files which have
> things referenced to them.
I
35 matches
Mail list logo
