On 2015.11.16 at 14:18 -0800, Steven Noonan wrote:
> Hi folks,
>
> (I'm not subscribed to the list, so please CC me on all responses.)
>
> This is using GCC 5.2 on Linux x86_64. On a project at work I've found
> that one of our shared libraries refuses to link because of some
> symbol references
On 17/11/15 05:55, David Wohlferd wrote:
> How much pessimism are we talking here? Wouldn't clobbering everything
> effectively force the reloading of (some? most? all?) registers? And
> more memory will be needed to store things that used to just require
> registers?
No, really not. It only
On Sat, 14 Nov 2015, Maciej W. Rozycki wrote:
> Any or all of these options may have effects beyond propagating the IEEE
> Std 754 compliance mode down to the assembler and the linker. In
> particular `-mieee=strict' is expected to guarantee code generated to
> fully comply to IEEE Std 754 rathe
On 11/16/2015 10:55 PM, David Wohlferd wrote:
- There is no standard that says it must do this.
True. But these after all are extensions and extensions have been
notoriously under-documented through the years.
- I'm only aware of 1 person who has ever asked for this change. And the
request
On Wed, Nov 18, 2015 at 5:31 AM, Jeff Law wrote:
> On 11/16/2015 10:55 PM, David Wohlferd wrote:
>>
>>
>> - There is no standard that says it must do this.
>
> True. But these after all are extensions and extensions have been
> notoriously under-documented through the years.
>
>> - I'm only aware
Snapshot gcc-5-20151117 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/5-20151117/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5
On Tue, Nov 17, 2015 at 02:31:29PM -0700, Jeff Law wrote:
> >- There is a plausible work-around with extended asm, which (mostly) has
> >clear semantics regarding clobbers.
> Converting an old-style asm to extended asm can be painful. ANd in the
> case of legacy code the conversion process itself
Is there a reason why libmpx and libgccjit aren't build for x32? This
is in the case when building IA-32, x86-64, and x32 all together.
Haven't tested any other way to build. I suspect it's just an
oversight in the way configuration works since I cannot see a
technical reason.
