(add gcc-patches)
On 12/01/2015 08:39 AM, Matthias Klose wrote:
On 01.12.2015 03:58, Ulrich Drepper wrote:
On Mon, Nov 30, 2015 at 9:14 PM, Jeff Law wrote:
Right, but isn't AC_COMPILE_IFELSE a compile test, not a run test?
The problem macro is _AC_COMPILER_EXEEXT_WORKS. The message is at
On Tue, Dec 1, 2015 at 2:39 AM, Matthias Klose wrote:
> that might be another instance of
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02064.html
> Does something like this help?
No, same problem as before. This macro doesn't actually generate any
code in configure.
Hi,
~/gnu/gcc/configure --prefix=/usr --enable-bootstrap --enable-shared
--enable-host-shared --enable-threads=posix --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-in
On Tue, Dec 1, 2015 at 10:16 AM, Bernd Edlinger
wrote:
> Your host_alias looks wrong: isn't it equal to your build_alias ?
Yes. The goal is to basically build a native compiler but prevent it
from trying to run any binaries. There is no fine-grained way to tell
the configuration mechanism to ru
On 28/11/15 04:05, David Wohlferd wrote:
> On 11/24/2015 6:50 PM, David Wohlferd wrote:
>> I have solved the problem with my previous patch. Here's the update
>> (feedback welcome): http://www.LimeGreenSocks.com/gcc/24414g.zip
>>
>> Based on my understanding from the previous thread, this patch now
On 11/30/2015 12:55:40, Richard Biener wrote:
> The first release candidate for GCC 5.3 is available from
> ftp://gcc.gnu.org/pub/gcc/snapshots/5.3.0-RC-20151130
I've built it and it has features from 5.3 branch, but when I run gcc
-v it says:
> gcc version 5.2.1 20151130 (GCC)
Also, __GNUC__ __
On 1 December 2015 at 16:51, Marqin Marqin wrote:
> On 11/30/2015 12:55:40, Richard Biener wrote:
>> The first release candidate for GCC 5.3 is available from
>> ftp://gcc.gnu.org/pub/gcc/snapshots/5.3.0-RC-20151130
>
> I've built it and it has features from 5.3 branch, but when I run gcc
There i
On 01/12/2015 17:08, Richard Earnshaw wrote:
> On 28/11/15 04:05, David Wohlferd wrote:
>> On 11/24/2015 6:50 PM, David Wohlferd wrote:
>>> I have solved the problem with my previous patch. Here's the update
>>> (feedback welcome): http://www.LimeGreenSocks.com/gcc/24414g.zip
>>>
>>> Based on my
I have a question involving ivopts and PR 48814, which was a fix for
the post increment operation. Prior to the fix for PR 48814, MIPS
would generate this loop for strcmp (C code from glibc):
$L4:
lbu $3,0($4)
lbu $2,0($5)
addiu $4,$4,1
beq $3,$0,$L7
2015-12-01 18:12 GMT+01:00 Jonathan Wakely :
> That's expected, because you're not using the final 5.3.0 release,
> because there is no final 5.3.0 release.
I thought I'm using 5.3.0-rc1 release, like it's with Linux kernel.
When I downloaded 4.0-rc1 it was named 4.0-rc1.
On 12/1/2015 8:08 AM, Richard Earnshaw wrote:
> Formatting nit: the '== NULL_TREE)' should line up with the start of
> 'lookup_attribute'.
> Same here.
Ok. Other than that, how do we proceed here?
When pursuing a course to "deprecate and later completely remove basic
asm within functions," I
On 12/1/2015 10:10 AM, Bernd Edlinger wrote:
> And a test case is missing too.
>
> I think this warning concentrates now only on basic asm.
> And people will be probably fix it in the most easy way,
> by just adding a colon.
Probably true. At least I hope it's that easy for most people.
> But I
On 11/30/2015 4:01 AM, Andrew Haley wrote:
>> There is a way for people to be clear about what they want to clobber,
>> and that's to use extended asm. The way to clear up the ambiguity
is to
>> start deprecating basic asm, not to add to the confusion by changing
its
>> behavior after all thes
On 1 December 2015 at 21:14, Marqin Marqin wrote:
> 2015-12-01 18:12 GMT+01:00 Jonathan Wakely :
>> That's expected, because you're not using the final 5.3.0 release,
>> because there is no final 5.3.0 release.
>
> I thought I'm using 5.3.0-rc1 release, like it's with Linux kernel.
GCC is not the
On 12/01/2015 02:11 PM, Steve Ellcey wrote:
With the current top-of-tree we now generate:
addiu $4,$4,1
$L8:
lbu $3,-1($4)
addiu $5,$5,1
beq $3,$0,$L7
lbu $2,-1($5) # This is a branch delay slot
beq $3,$2,$L8
addiu
On Tue, 1 Dec 2015, David Wohlferd wrote:
> Saying it's dead in the docs is the first step to making it dead in the code.
> This patch just implements an optional warning (unless #3,4 crank it up to a
> default warning), but the intent is that eventually (v7? v8?) this turns into
> a fatal error.
On 12/01/2015 04:25 PM, Joseph Myers wrote:
On Tue, 1 Dec 2015, David Wohlferd wrote:
Saying it's dead in the docs is the first step to making it dead in the code.
This patch just implements an optional warning (unless #3,4 crank it up to a
default warning), but the intent is that eventually (v
On 12/01/2015 03:29 PM, David Wohlferd wrote:
On 11/30/2015 4:01 AM, Andrew Haley wrote:
>> There is a way for people to be clear about what they want to clobber,
>> and that's to use extended asm. The way to clear up the ambiguity
is to
>> start deprecating basic asm, not to add to the confu
On 12/01/2015 07:17 AM, Ulrich Drepper wrote:
On Tue, Dec 1, 2015 at 2:39 AM, Matthias Klose wrote:
that might be another instance of
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02064.html
Does something like this help?
No, same problem as before. This macro doesn't actually generate any
c
On Tue, Dec 01, 2015 at 08:41:22PM -0700, Jeff Law wrote:
> Isn't "asm" conditionally supported for ISO C++? In which case it's not
> mandatory and semantics are implementation defined.
Yes.
> My strong preference is still to document the desired semantics for GCC
> and treat anything that doe
On 12/1/2015 7:56 PM, Segher Boessenkool wrote:
On Tue, Dec 01, 2015 at 08:41:22PM -0700, Jeff Law wrote:
Isn't "asm" conditionally supported for ISO C++? In which case it's not
mandatory and semantics are implementation defined.
Yes.
My strong preference is still to document the desired sem
On 1.12.2015, David Wohlferd wrote:
On 12/1/2015 10:10 AM, Bernd Edlinger wrote:
> > But IMHO asm("bla":) isn't any better than asm("bla").
> > I think _any_ asm with non-empty assembler string, that
> > claims to clobber _nothing_ is highly suspicious, and worth to be
> > warned about. I don't se
22 matches
Mail list logo
