On Tue, Jan 20, 2015 at 4:57 AM, Ricardo Telichevesky wrote:
> Hi,
>
> I have a strange problem with extremely large procedures when generating
> 64-bit code
> I am using gcc 4.9.2 on RHEL6.3 on a 64-thread 4-socket Xeon E7 4820 with
> 256GB of memory. No avx extensions, using sse option whe
I know that we are already in stage 4, but features such as OpenACC
2.0, nvptx and KNL (xeon phi) offloading support are so important
for GCC, and if they have to be deferred to GCC 6.0, then it would be
a great loss to GCC, as OpenACC 2.0 makes heterogeneous manycore
programming so much easie
Oh sorry. I just checked out the svn again, and see it already
merged. Well done!
On Tue, Jan 20, 2015 at 11:59 PM, Mark Farnell wrote:
> I know that we are already in stage 4, but features such as OpenACC
> 2.0, nvptx and KNL (xeon phi) offloading support are so important
> for GCC, and
On Mon, Jan 19, 2015 at 6:03 PM, Jeff Law wrote:
> On 01/17/15 07:34, Gary Funck wrote:
>>
>> On 01/14/15 23:15:59, Jeff Law wrote:
>>>
>>> Sounds good. I think just starting with the list & creating the buckets
>>> with the list. Then post here and we'll iterate and try to nail that
>>> down
>>
On Mon, Jan 19, 2015 at 11:31 PM, Uros Bizjak wrote:
> On Tue, Jan 20, 2015 at 3:26 AM, Sandra Loosemore
> wrote:
>
>>> I've noticed that the GCC user documentation is quite inconsistent about
>>> the name(s) it uses for i386/x86-64/etc targets. invoke.texi has a
>>> section for "i386 and x86-64
Hello,
[previously sent mail with same content possibly rejected because of text-only
email requirement not met]
I would like to suggest/recommend a feature whereby the gccmakedep component of
the gcc suite can be made to emit "file inclusion" notices similar to the ones
resulting from makedep
Hi,
On Mon, 19 Jan 2015, Sandra Loosemore wrote:
> > I'd be happy to work on a patch to bring the manual to using a common
> > naming convention, but what should it be? Wikipedia seems to use
> > "x86" (lowercase) to refer to the entire family of architectures
> > (including the original 16-b
On Tue, Jan 20, 2015 at 6:07 AM, Michael Matz wrote:
> Hi,
>
> On Mon, 19 Jan 2015, Sandra Loosemore wrote:
>
>> > I'd be happy to work on a patch to bring the manual to using a common
>> > naming convention, but what should it be? Wikipedia seems to use
>> > "x86" (lowercase) to refer to the ent
Hi,
On Tue, 20 Jan 2015, H.J. Lu wrote:
> > ia32 is confusing because ia64 (a well known term) sounds related but
> > can't be farther away from it, and it's also vendor specific. Our
> > traditional i386 seems better to me (although it has its own problems,
> > but I'm not aware of any bette
On Tue, Jan 20, 2015 at 6:14 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 20 Jan 2015, H.J. Lu wrote:
>
>> > ia32 is confusing because ia64 (a well known term) sounds related but
>> > can't be farther away from it, and it's also vendor specific. Our
>> > traditional i386 seems better to me (although
On Tue, Jan 20, 2015 at 3:23 PM, H.J. Lu wrote:
>>> > ia32 is confusing because ia64 (a well known term) sounds related but
>>> > can't be farther away from it, and it's also vendor specific. Our
>>> > traditional i386 seems better to me (although it has its own problems,
>>> > but I'm not aware
Hi,
On Tue, 20 Jan 2015, Uros Bizjak wrote:
> > At least, IA-32 is clear, although IA-64 may be confusing :-). FWIW,
> > i386 is also vendor specific.
>
> Wikipedia agrees [1]:
I wouldn't use a wikipedia article that only cites sources from after 2008
(and most of them actually after the aft
On 01/20/2015 08:11 AM, Michael Matz wrote:
Hi,
On Tue, 20 Jan 2015, Uros Bizjak wrote:
At least, IA-32 is clear, although IA-64 may be confusing :-). FWIW,
i386 is also vendor specific.
Wikipedia agrees [1]:
I wouldn't use a wikipedia article that only cites sources from after 2008
(and
On Tue, Jan 20, 2015 at 10:27 AM, Sandra Loosemore
wrote:
> On 01/20/2015 08:11 AM, Michael Matz wrote:
>>
>> Hi,
>>
>> On Tue, 20 Jan 2015, Uros Bizjak wrote:
>>
At least, IA-32 is clear, although IA-64 may be confusing :-). FWIW,
i386 is also vendor specific.
>>>
>>>
>>> Wikipedia agr
> Ping? Any thoughts?
x86 for the family and x86-32/x86-64 for the 2 architectures?
--
Eric Botcazou
On 01/16/2015 06:47 PM, Vladimir Makarov wrote:
>
> On 2015-01-16 12:30 PM, Andreas Krebbel wrote:
>> Hi,
>>
>> on S/390 I see invalid subregs being generated by LRA although
>> CANNOT_CHANGE_MODE_CLASS is supposed
>> to prevent these. The reason appears to be the code you've added with:
>>
>> c
On Tue, Jan 20, 2015 at 10:51 AM, Eric Botcazou wrote:
>> Ping? Any thoughts?
>
> x86 for the family and x86-32/x86-64 for the 2 architectures?
>
Works for me.
--
H.J.
On 1/20/2015 1:02 PM, H.J. Lu wrote:
> On Tue, Jan 20, 2015 at 10:51 AM, Eric Botcazou wrote:
>>> Ping? Any thoughts?
>> x86 for the family and x86-32/x86-64 for the 2 architectures?
>>
> Works for me.
>
>
Sounds good to me. You can always explain the terms and their relationship
to others in a
On 01/20/2015 11:40 AM, H.J. Lu wrote:
On Tue, Jan 20, 2015 at 10:27 AM, Sandra Loosemore
wrote:
Since there seems to be arguments against using both "IA-32" and "i386" for
the 32-bit x86 architecture, how about, uh, "32-bit x86"? With the other
names in parentheses where appropriate? I think
On Tue, Jan 20, 2015 at 11:16 AM, Sandra Loosemore
wrote:
> On 01/20/2015 11:40 AM, H.J. Lu wrote:
>>
>> On Tue, Jan 20, 2015 at 10:27 AM, Sandra Loosemore
>> wrote:
>>>
>>> Since there seems to be arguments against using both "IA-32" and "i386"
>>> for
>>> the 32-bit x86 architecture, how about,
On 01/20/2015 12:21 PM, H.J. Lu wrote:
On Tue, Jan 20, 2015 at 11:16 AM, Sandra Loosemore
wrote:
Ummm, this seems like an inconsistent position. "32-bit x86" isn't even a
new name; it's a restricting adjective "32-bit" on the existing name "x86".
But "x86-32" isn't an existing real name for a
On Tue, Jan 20, 2015 at 11:38 AM, Sandra Loosemore
wrote:
> On 01/20/2015 12:21 PM, H.J. Lu wrote:
>>
>> On Tue, Jan 20, 2015 at 11:16 AM, Sandra Loosemore
>> wrote:
>>>
>>>
>>> Ummm, this seems like an inconsistent position. "32-bit x86" isn't even
>>> a
>>> new name; it's a restricting adjecti
I have a question about libcc1.so and where it is put in the install
directory. My understanding is that GCC install files are put in a
directory containing the target name or contain the target
name as part of the filename (aka mips-linux-gnu-gcc) so that two GCC's
with different targets could be
On Tue, 20 Jan 2015, Steve Ellcey wrote:
> I tried this, building cross compilers for mips-mti-linux-gnu and
> mips-img-linux-gnu and checked to see if any files overlapped between
> the two. The only overlap I found was with libcc1. Both cross compilers
> had a lib directory directly under the
24 matches
Mail list logo
