Hello,
In the file "libgcc/config/arm/t-elf", there is this block:
# Currently there is a bug somewhere in GCC's alias analysis
# or scheduling code that is breaking _fpmul_parts in fp-bit.c.
# Disabling function inlining is a workaround for this problem.
HOST_LIBGCC2_CFLAGS += -fno-inline
This
On Tue, Oct 29, 2013 at 10:41:56AM +0100, Richard Biener wrote:
> On Sun, Oct 27, 2013 at 1:50 AM, Hannes Frederic Sowa
> wrote:
> > On Sat, Oct 26, 2013 at 09:29:12PM +0200, Ondřej Bílka wrote:
> >> Hi, as I brainstormed how prevent possible overflows in memory allocation I
> >> came with heretic
On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
>>
> The reasons of adding builtins is performance. Without that one can
> write a simple template to generically check overflows like
>
> template class overflow {
> public:
> C val;
> overflow operator + (overflow &y) {
> overflow ret;
>
2013/10/30 Andrew Haley :
> On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
>
>>>
>> The reasons of adding builtins is performance. Without that one can
>> write a simple template to generically check overflows like
>>
>> template class overflow {
>> public:
>> C val;
>> overflow operator + (ov
On Wed, Oct 30, 2013 at 08:41:32AM +, Andrew Haley wrote:
> On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
>
> >>
> > The reasons of adding builtins is performance. Without that one can
> > write a simple template to generically check overflows like
> >
> > template class overflow {
> > publi
I am pleased to announce the release of ODB 2.3.0.
ODB is an open source object-relational mapping (ORM) system for C++. It
allows you to persist C++ objects to a relational database without having
to deal with tables, columns, or SQL and without manually writing any of
the mapping code. ODB is im
When GCC is installed using “make install”, why aren’t some of the installed
binaries stripped? (at least, as of 4.8.2)
On a x86_64-unknown-linux-gnu multilib install, stripping the following
binaries makes the overall size go down from 479 MB to 204 MB (57%):
$prefix/bin/*
$prefix/libexec/g
FX writes:
> When GCC is installed using “make install”, why aren’t some of the
> installed binaries stripped?
make install-strip
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely di
On 10/26/2013 09:29 PM, Ondřej Bílka wrote:
Hi, as I brainstormed how prevent possible overflows in memory allocation I
came with heretic idea:
For gcc -D_FORTIFY_SOURCE=2 we expand all multiplication with size_t
type by one that checks for integer overflow and aborts on it. This
would prevent m
> make install-strip
OK, great. Any reason why it should not be the “default” install?
FX
2013/10/30 FX :
> OK, great. Any reason why it should not be the “default” install?
Then we need "make install-nostrip" ;-)
FX writes:
>> make install-strip
>
> OK, great. Any reason why it should not be the “default” install?
The GNU Coding Standards explain this:
http://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets
Do not strip executables when installing them. This helps eventual
de
> The GNU Coding Standards explain this:
Pretty clear, thanks!
FX
On Wed, Oct 30, 2013 at 12:54:12PM +0100, Florian Weimer wrote:
> On 10/26/2013 09:29 PM, Ondřej Bílka wrote:
> >Hi, as I brainstormed how prevent possible overflows in memory allocation I
> >came with heretic idea:
> >
> >For gcc -D_FORTIFY_SOURCE=2 we expand all multiplication with size_t
> >type
On 30/10/13 10:00, Kai Tietz wrote:
> 2013/10/30 Andrew Haley :
>> On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
>>
>>> The reasons of adding builtins is performance. Without that one can
>>> write a simple template to generically check overflows like
>>>
>>> template class overflow {
>>> pub
On 10/30/2013 03:03 PM, David Brown wrote:
Technically speaking, casting your signed values to unsigned and using
that to detect overflow will not necessarily work - I think it would be
"implementation defined". But almost all architectures use two's
compliment arithmetic, and it will work ther
On Wed, Oct 30, 2013 at 1:02 AM, Sebastian Huber
wrote:
>
> In the file "libgcc/config/arm/t-elf", there is this block:
>
> # Currently there is a bug somewhere in GCC's alias analysis
> # or scheduling code that is breaking _fpmul_parts in fp-bit.c.
> # Disabling function inlining is a workaround
On Wed, Oct 30, 2013 at 10:00:07AM +0100, Kai Tietz wrote:
> 2013/10/30 Andrew Haley :
> > On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
> >
> >>>
> >> The reasons of adding builtins is performance. Without that one can
> >> write a simple template to generically check overflows like
> >>
> >> templa
On Wed, Oct 30, 2013 at 10:49:09AM -0400, Trevor Saunders wrote:
> On Wed, Oct 30, 2013 at 10:00:07AM +0100, Kai Tietz wrote:
> > 2013/10/30 Andrew Haley :
> > > On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
> > >
> > >>>
> > >> The reasons of adding builtins is performance. Without that one can
> >
On Wed, Oct 30, 2013 at 03:59:59PM +0100, Ondřej Bílka wrote:
> On Wed, Oct 30, 2013 at 10:49:09AM -0400, Trevor Saunders wrote:
> > On Wed, Oct 30, 2013 at 10:00:07AM +0100, Kai Tietz wrote:
> > > 2013/10/30 Andrew Haley :
> > > > On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
> > > >
> > > >>>
> > >
On 30/10/13 15:59, Ondřej Bílka wrote:
> On Wed, Oct 30, 2013 at 10:49:09AM -0400, Trevor Saunders wrote:
>> On Wed, Oct 30, 2013 at 10:00:07AM +0100, Kai Tietz wrote:
>>> 2013/10/30 Andrew Haley :
On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
>>
> The reasons of adding builtins is
On Wed, 30 Oct 2013, DJ Delorie wrote:
> My proposal is to allow the target to define its own type for
> pointers, sizeof_t, and ptrdiff_t to use, so that gcc can adapt to
> weird pointer sizes instead of the target having to use power-of-two
> pointer math.
>
> This means the target would someho
On 10/30/2013 03:23 PM, David Brown wrote:
> I believe that's only a minor reason for making signed overflows
> undefined behaviour. If it were a matter of implementation, I think it
> would have been made "implementation defined" rather than "undefined",
> so that two's complement machines could
On Tue, 2013-10-29 at 16:45 -0700, pins...@gmail.com wrote:
> I ran into similar issues building this way. The way I ended up working
> around is just copying the
> Already built libraries from a non Canadian cross build.
>
> Thanks,
> Andrew
Yes, but we should fix it so that we don't need a w
On 10/29/13 16:56, Gerald Pfeifer wrote:
Hi Balaji,
On Wed, 23 Oct 2013, Iyer, Balaji V wrote:
Is there anything you were thinking about that I missed?
the question was in a different context, but making the code a
bit more portable would be good.
Right now FreeBSD bootstrap is broken due to
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 30, 2013 1:04 PM
> To: Gerald Pfeifer; Iyer, Balaji V; gcc@gcc.gnu.org
> Subject: Re: libcilkrts portability
>
> On 10/29/13 16:56, Gerald Pfeifer wrote:
> > Hi Balaji,
> >
> > On Wed, 23 Oct 2013,
Consider this:
http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg02329.html
and
http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg02258.html
/scratch/toon/bd5894/./prev-gcc/xg++ -B/scratch/toon/bd5894/./prev-gcc/
-B/home/toon/compilers/install/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/scrat
> It is a deficiency that SIZE_TYPE is defined to be a string at all (and
> likewise for all the other target macros for standard typedefs including
> all those for ). Separately, it's a deficiency that these
> things are target macros rather than target hooks.
My thought was that there'd be
On Wed, 30 Oct 2013, DJ Delorie wrote:
>
> > It is a deficiency that SIZE_TYPE is defined to be a string at all (and
> > likewise for all the other target macros for standard typedefs including
> > all those for ). Separately, it's a deficiency that these
> > things are target macros rather t
So, given all that, is there any way to add the "target-specific
size_t" portion without waiting for-who-knows-how-long for the intN_t
and enum-size-type projects to finish? Some form of interim API that
we can put in, so that we can start working on finding all the
assumptions about size_t, whil
On Wed, 30 Oct 2013, DJ Delorie wrote:
> So, given all that, is there any way to add the "target-specific
> size_t" portion without waiting for-who-knows-how-long for the intN_t
> and enum-size-type projects to finish? Some form of interim API that
> we can put in, so that we can start working on
On Wed, 30 Oct 2013, Iyer, Balaji V wrote:
> This attached patch will check for usage of alloca.h before using it.
> The change is entirely in libcilkrts and I am committing this change as
> it is pretty obvious (the change was lifted from the autconf manual
> example).
Thanks, Balaji!
Now my
On 10/29/2013, 5:20 PM, Matthew Fortune wrote:
On 10/29/2013 09:43 AM, Matthew Fortune wrote:
It is hard for me to say what is going on. Elimination is done when we match
hard reg against constraints. May be elimination to hfp is rejected on some
sub-pass and LRA don't try all alternatives afte
I have tried Jakub patch listed in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543.
It works for my env.
Thanks.
2013/10/29 Jean Lee :
> Thanks. I will try Jakub patch listed in
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543.
>
> 2013/10/29 Yury Gribov :
>>> "copy_to_mode_reg (Pmode, XEXP
> -Original Message-
> From: Gerald Pfeifer [mailto:ger...@pfeifer.com]
> Sent: Wednesday, October 30, 2013 9:39 PM
> To: Iyer, Balaji V
> Cc: Jeff Law; gcc@gcc.gnu.org
> Subject: libcilkrts/runtime/config/generic/cilk-abi-vla.c failure (was:
> [PATCH,
> committed] libcilkrts - Add check
On 10/30/13 20:26, Andrew MacLeod wrote:
As a result, any gimple queries regarding types, decls, or expressions
are actually tree queries. They are sprinkled throughout gimple.[ch] and
gimplify.[ch], not to mention tree.[ch] as well as other parts of the
compiler where they happened to be needed
36 matches
Mail list logo
