Re: Problem with extremely large procedures and 64-bit code

[Richard Biener]

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 when building the
> compiler. This particular code is serial. I made measurements with 32- and
> 64- bit both debug -g and optimize -O3 for two different examples (this is a
> circuit simulator and each example is a different circuit that uses
> different transistors).
>
> Example A is the one the effect is more acute. I listed at the bottom of
> the e-mail the 3 procedures that consume 90% of the execution time:
>
> a) As a counter-example, the factor code listed is heavily optimized
> hand-written 300-lines of C++ code that behaves as expected: 64-bit optimize
> is way faster than any other, up to 15x faster than 32-bit debug (btw great
> job in the compiler, it is really shining here).
>
> b) evalTran has 18000 lines of auto-generated code and behaves very
> counter-intuitively 64-bit optimize code is 3x slower than 32-bit optimize
> code.
>
> c) evalTranRhs has 5000 lines even worse: 64-bit is 4x slower than 32-bit.
> Notice that all the data structures in 32-bit code and 64-bit code are
> identical and most variables are identical - in fact all integers used are
> 64-bit, and most operations are floating-point ops. Initially I thought the
> 64-bit code was a lot bigger than 32-bit code and the cache was overwhelmed.
> In fact the difference in code sizes is not even 10% (at least debug -
> notice I calculated the size of each procedure in bytes)  so my trash-the
> I-cache conjecture seems to be wrong. The overall execution time is causing
> us a lot of problems - 64-bit optimize takes 16seconds, even more than
> 32-bit debug 10seconds and 32-bit optimize 4.8 seconds. Considering we only
> care about 64-bit optimize we got a big problem here.
>
> Example B is not so bad, and in fact 64-bit code is slightly faster than
> 32-bit code, would be nice if went even faster, but if I got A to behave
> like that I'd be pretty happy already.
>
> I tried to look at the wide array of optimizing options for the code, it
> is is a dizzying task and I could not get any kind of intuition besides the
> -O3 ... Would you have any suggestions for the proper flags for those
> ridiculously large auto-generated codes that might be able to alleviate this
> 32-bit vs 64-bit problem? Would you think that the fact this code is in a
> dynamic linked library (-fPIC) plays a role?

It's hard to tell without a testcase but GCC has various limits on
code sizes passes deal with so you might trip one of these which
effectively would disable optimizations.  For example loop dependence
analysis has a limit on the number of memory references it considers
(--param loop-max-datarefs-for-datadeps, default 1000).  Note that not
all such limits are controlled by --params.  We have
-Wdisabled-optimization that should warn if you run into any such
case (but the warning is unfortunately not correctly implemented by
all passes having such limits).

Thanks,
Richard.

> Thanks very much for your help,
> Ricardo
>
>
> All times are wall clock in micro-seconds - the main was checked against the
> reported UNIX time and is exact.
>
> example  A
> ==
> evalTran has 18000 lines of C code   (two for loops around 99% of the code)
> evalTranRhs has 5000 lines of C code (two for loops around 99% of the code)
>
> 32 bit debug -g -m32 -fPIC -Wall -Winvalid-pch -msse2
> %time  elapsed(us)   #calls  per call(us)timer name @DN@
> -  ---   --   --
> 2.503 254536833530 numerical TRAN factor
> 56.01  5695065   8335683 evalTranbytes=231791
> 35.41  3600646   13924   258 evalTranRhs bytes=57501
> 10010168242  1   10168242main @DT@
>
> 32 bit optimize -O3 -m32 -fPIC -Wall -Winvalid-pch -msse2
> %time  elapsed(us)   #calls  per call(us) timer name @DN@
> -  ---   --   --
> 0.710  34442 83354 numerical TRAN factor
> 43.06  2087757   8335250 evalTran
> 43.49  2108786   13925   151 evalTranRhs
> 1004848520   1   4848520 main @DT@
>
>
> 64 bit debug -g -fPIC -Wall -Winvalid-pch -msse2
> %time  elapsed(us)   #calls  per call(us) timer name @DN@
> -  ---   --   --
> 0.973  205144833524 numerical TRAN factor
> 46.43  9785920   83351174 evalTran bytes=252741
> 49.72  1047  13924   752 evalTranRhs bytes=58442
> 10021077659  1   21077659main @DT@
>
>
> 64 bit optimize -O3 -fPIC -Wall -Winvalid-pch -msse2
> %time  elapsed(us) 

GCC 5 Status Report (2015-01-19), Trunk in Stage 4 - an exception for OpenACC 2.0, nvptx and KNL offloading support?

[Mark Farnell]

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 easier, as it relieves users from doing
assembly-like low level stuff as in CUDA and OpenCL.

Currently, OpenACC 2.0, nvptx and KNL (xeon phi) support live in the
gomp-4_0-branch  From previous discussions in this list, these
features are mature enough to be merged into the trunk, and the owner
of the trunk is just waiting for the codesourcery to do the job.

So in order to include these features into GCC 5.0, is it possible to
make an exception so that if these features merges into the trunk
within two weeks, they will be allowed to be merged and included into
GCC 5.0?

Otherwise it would be a big blow to both GCC, and OpenACC, as users
would otherwise be forced to use proprietary compilers.

Re: GCC 5 Status Report (2015-01-19), Trunk in Stage 4 - an exception for OpenACC 2.0, nvptx and KNL offloading support?

[Mark Farnell]

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 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 easier, as it relieves users from doing
> assembly-like low level stuff as in CUDA and OpenCL.
>
> Currently, OpenACC 2.0, nvptx and KNL (xeon phi) support live in the
> gomp-4_0-branch  From previous discussions in this list, these
> features are mature enough to be merged into the trunk, and the owner
> of the trunk is just waiting for the codesourcery to do the job.
>
> So in order to include these features into GCC 5.0, is it possible to
> make an exception so that if these features merges into the trunk
> within two weeks, they will be allowed to be merged and included into
> GCC 5.0?
>
> Otherwise it would be a big blow to both GCC, and OpenACC, as users
> would otherwise be forced to use proprietary compilers.

Re: organization of optimization options in manual

[Richard Biener]

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
>>> before you start moving everything in the .texi file.
>>
>>
>> Something to consider, if the optimization options are re-worked:
>> Arrange the -O options such that -O1 can be described by a
>> distinct set of specific optimizations enabled (or disabled)
>> in addition to -O0, and -O2 would be described as a composite
>> of specific optimizations applied to -O1 and so on. (This
>> might require the addition of new optimization options.)
>
> For -O1 to -O2 and -O2 to -O3, that makes sense.  However, -O0 to -O1 isn't
> something we can do this for right now as there are still many things that
> -O1 turns on that are not flag controlled.
>
> Whether or not to make all those bits individually controllable is a subject
> of debate.  Personally, I think we have too many options, so my inclination
> would not be to make all those bits individually controllable.  Others may
> have different opinions.

Also note that I'd like to go away from sharing the same pipeline with
-O1 and -O2 at least.  -Og started this already (you can't turn on extra
passes in the -Og GIMPLE pipeline) and the -O1 "pipeline" doesn't
make much sense currently - I'd rather base -O1 on -Og or split it
away completely.

The issue here is that a single flag controls multiple instances of a pass,
and -O1 would still have things like -ftree-copy-prop but not run as many
times as -O2 (and -O1 currently).

For us developers I'd always envisioned to make our pass manager
scriptable and the pass pipeline being basically a script (so you
can even do things like iterating ... heh).

So I really really don't believe in the usefulness of 95% of the
optimization options we have (to a compiler user).  And I'd rather
flag most of them as debugging ...

Richard.

> jeff
>

Re: [ping] Re: proper name of i386/x86-64/etc targets

[H.J. Lu]

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 Options", but in other places the manual
>>> uses x86, X86, i?86, i[34567]86, x86_64 (underscore instead of a dash),
>>> etc.
>>>
>>> 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-bit variants), "IA-32" for the 32-bit architecture (I
>>> believe that is Intel's official name), and "x86-64" (with a dash
>>> instead of underscore) for the 64-bit architecture.  But of course the
>>> target maintainers should have the final say on what names to use.

I like this suggestion.  Thanks.

>>
>> Ping?  Any thoughts?
>
> Let's ask Intel people ...
>



-- 
H.J.

extending gccmakedep to output file inclusions

[Thomas P]

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 makedepend's "-v" option [1][2].

The output would be similar to

fileA: fileB
fileA: fileC
...

if fileA includes (#include "...") fileB and fileC.

Currently closest is the behaviour of "gcc -M" (resp. "gcc -MM"), i.e. the 
gccmakedep result; however, make file dependencies are not semantically equal 
to file inclusion.

The feature is helpful for documentation.

Thomas

[1] http://xorg.freedesktop.org/archive/individual/util/makedepend-1.0.5.tar.bz2
[2] http://www.xfree86.org/4.0/makedepend.1.html

Re: [ping] Re: proper name of i386/x86-64/etc targets

[Michael Matz]

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-bit variants), "IA-32" for the 32-bit 
> > architecture (I believe that is Intel's official name), and "x86-64" 
> > (with a dash instead of underscore) for the 64-bit architecture.  But 
> > of course the target maintainers should have the final say on what 
> > names to use.
> 
> Ping?  Any thoughts?

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 better abbreviation in the wild that's vendor neutral 
and specifically means the 32bit incarnation of the x86 architecture).


Ciao,
Michael.

Re: [ping] Re: proper name of i386/x86-64/etc targets

[H.J. Lu]

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 entire family of architectures
>> > (including the original 16-bit variants), "IA-32" for the 32-bit
>> > architecture (I believe that is Intel's official name), and "x86-64"
>> > (with a dash instead of underscore) for the 64-bit architecture.  But
>> > of course the target maintainers should have the final say on what
>> > names to use.
>>
>> Ping?  Any thoughts?
>
> 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 better abbreviation in the wild that's vendor neutral
> and specifically means the 32bit incarnation of the x86 architecture).
>

The problem with i386 is it is a real processor.  When someone says i386,
it isn't clear if it means the processor or 32-bit x86.


-- 
H.J.

Re: [ping] Re: proper name of i386/x86-64/etc targets

[Michael Matz]

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 better abbreviation in the wild that's vendor 
> > neutral and specifically means the 32bit incarnation of the x86 
> > architecture).
> >
> 
> The problem with i386 is it is a real processor.  When someone says 
> i386, it isn't clear if it means the processor or 32-bit x86.

That's what I meant with its own problems :)  But ia32 seems worse to me 
than this IMO.


Ciao,
Michael.

Re: [ping] Re: proper name of i386/x86-64/etc targets

[H.J. Lu]

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 it has its own problems,
>> > but I'm not aware of any better abbreviation in the wild that's vendor
>> > neutral and specifically means the 32bit incarnation of the x86
>> > architecture).
>> >
>>
>> The problem with i386 is it is a real processor.  When someone says
>> i386, it isn't clear if it means the processor or 32-bit x86.
>
> That's what I meant with its own problems :)  But ia32 seems worse to me
> than this IMO.
>

At least, IA-32 is clear, although IA-64 may be confusing :-).  FWIW,
i386 is also vendor specific.


-- 
H.J.

Re: [ping] Re: proper name of i386/x86-64/etc targets

[Uros Bizjak]

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 of any better abbreviation in the wild that's vendor
>>> > neutral and specifically means the 32bit incarnation of the x86
>>> > architecture).
>>> >
>>>
>>> The problem with i386 is it is a real processor.  When someone says
>>> i386, it isn't clear if it means the processor or 32-bit x86.
>>
>> That's what I meant with its own problems :)  But ia32 seems worse to me
>> than this IMO.
>>
>
> At least, IA-32 is clear, although IA-64 may be confusing :-).  FWIW,
> i386 is also vendor specific.

Wikipedia agrees [1]:

--q--
IA-32 (short for "Intel Architecture, 32-bit", sometimes also called
i386[1][2] through metonymy)[3] is the third generation of the x86
architecture, first implemented in the Intel 80386 microprocessors in
1985. It was the first incarnation of x86 to support 32-bit
computing.[4] As such, "IA-32" may be used as a metonym to refer to
all x86 versions that support 32-bit computing.[5][6]
--/q--

IMO, comparing IA-32 and i386, IA-32 looks better.

[1] http://en.wikipedia.org/wiki/IA-32

Uros.

Re: [ping] Re: proper name of i386/x86-64/etc targets

[Michael Matz]

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 after-the-fact invention of "ia32") 
for an architecture that exists since 1985 as sensible source for 
supporting either point of view ;-)  It totally lacks references to 
config.guess which IMHO is a much better source of "how to call an 
architecture" :)

Anyway, I've said the things I had to say, crouching back under my stone 
:)


Ciao,
Michael.

Re: [ping] Re: proper name of i386/x86-64/etc targets

[Sandra Loosemore]

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 most of them actually after the after-the-fact invention of "ia32")
for an architecture that exists since 1985 as sensible source for
supporting either point of view ;-)  It totally lacks references to
config.guess which IMHO is a much better source of "how to call an
architecture" :)


I brought up the Wikipedia names in my initial query because I presume 
the Wikipedians have already fought the battle over what color to paint 
this particular bikeshed.  :-)


FWIW, I was employed at Intel back in the 2001-2003 timeframe and my 
vague recollection was that it was during that time that they started 
promoting "IA-32" as the official name for the 32-bit x86 architecture, 
as a branding thing to better promote their own "IA-64" architecture as 
its 64-bit successor rather than AMD's "x86-64".  So certainly a lot of 
the confusion arises because the 32-bit x86 architecture was around 
under other names long before Intel re-named it.


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 we could also 
ignore the 16-bit x86 variants for the purposes of GCC and just use 
"x86" instead of "i386 and x86-64".



Anyway, I've said the things I had to say, crouching back under my stone
:)


Likewise going back to hiding under my lilypad.  :-)

-Sandra

Re: [ping] Re: proper name of i386/x86-64/etc targets

[H.J. Lu]

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 agrees [1]:
>>
>>
>> I wouldn't use a wikipedia article that only cites sources from after 2008
>> (and most of them actually after the after-the-fact invention of "ia32")
>> for an architecture that exists since 1985 as sensible source for
>> supporting either point of view ;-)  It totally lacks references to
>> config.guess which IMHO is a much better source of "how to call an
>> architecture" :)
>
>
> I brought up the Wikipedia names in my initial query because I presume the
> Wikipedians have already fought the battle over what color to paint this
> particular bikeshed.  :-)
>
> FWIW, I was employed at Intel back in the 2001-2003 timeframe and my vague
> recollection was that it was during that time that they started promoting
> "IA-32" as the official name for the 32-bit x86 architecture, as a branding
> thing to better promote their own "IA-64" architecture as its 64-bit
> successor rather than AMD's "x86-64".  So certainly a lot of the confusion
> arises because the 32-bit x86 architecture was around under other names long
> before Intel re-named it.
>
> 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 we could also ignore the
> 16-bit x86 variants for the purposes of GCC and just use "x86" instead of
> "i386 and x86-64".
>

Please don't invent a new name.  It may confuse people.


-- 
H.J.

Re: [ping] Re: proper name of i386/x86-64/etc targets

[Eric Botcazou]

> Ping?  Any thoughts?

x86 for the family and x86-32/x86-64 for the 2 architectures?

-- 
Eric Botcazou

Re: LRA and CANNOT_CHANGE_MODE_CLASS

[Andreas Krebbel]

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:
>>
>> commit c6a6cdaaea571860c94f9a9fe0f98c597fef7c81
>> Author: vmakarov 
>> Date: Tue Oct 23 15:51:41 2012 +
>>
>> ...
>> int
>> simplify_subreg_regno (unsigned int xregno, machine_mode xmode,
>> unsigned int offset, machine_mode ymode)
>> {
>> struct subreg_info info;
>> unsigned int yregno;
>>
>> #ifdef CANNOT_CHANGE_MODE_CLASS
>> /* Give the backend a chance to disallow the mode change. */
>> if (GET_MODE_CLASS (xmode) != MODE_COMPLEX_INT
>> && GET_MODE_CLASS (xmode) != MODE_COMPLEX_FLOAT
>> && REG_CANNOT_CHANGE_MODE_P (xregno, xmode, ymode)
>> /* We can use mode change in LRA for some transformations. */<---
>> && ! lra_in_progress)<---
>> return -1;
>>
>> ...
>>
>> In my testcase it is a subreg which is wrapped into a strict_low_part:
>>
>> ira:
>> (insn 295 294 296 39 (set (strict_low_part (subreg:SI (reg/v:TI 252 [ g ]) 
>> 4))
>> (reg:SI 108 [ D.99773 ])) /home3/andreas/patched/../gcc/gcc/ipa-icf.h:391 
>> 882 {movstrictsi}
>> (nil))
>>
>> reload:
>> (insn 295 930 931 39 (set (strict_low_part (reg:SI 16 %f0 [ g+4 ]))
>> (reg:SI 0 %r0 [orig:108 D.99773 ] [108])) 
>> /home3/andreas/patched/../gcc/gcc/ipa-icf.h:391 882
>> {movstrictsi}
>> (nil))
>>
>> Assigning an FPR here is wrong due to the differing endianess of GPRs vs 
>> FRPs.
>>
>>  From what I've seen there does not seem to be code after that in LRA which 
>> would repair this. Do you
>> have a hint how I can get this working again?
> Originally the condition ! lra_in_progress was added to deal with 
> situation of matching reloads of operands with different modes for x86.  
> LRA temporarily generates illegal subregs of pseudos to deal with such 
> situation.  Later such subregs started to be marked by LRA_SUBREG_P.
> 
> You could try to change condition !lra_in_progress to (!lra_in_progress 
> || ! LRA_SUBREG_P (original_pseudo)).  You need to pass original_pseudo 
> somehow too.  Let me know if it does not work.
> 
Looks like it was my own code which caused the problem. I've provided a 
movstrict pattern using a
subreg which I've otherwise suppressed by cannot_change_mode_class. LRA 
correctly assumed that the
subreg is allowed when accepted by the pattern. The failure is gone after 
removing the pattern.

Thanks for your help!

-Andreas-

Re: [ping] Re: proper name of i386/x86-64/etc targets

[H.J. Lu]

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.

Re: [ping] Re: proper name of i386/x86-64/etc targets

[Joel Sherrill]

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 sentence of two if needed for user clarification.

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [ping] Re: proper name of i386/x86-64/etc targets

[Sandra Loosemore]

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 we could also ignore the
16-bit x86 variants for the purposes of GCC and just use "x86" instead of
"i386 and x86-64".



Please don't invent a new name.  It may confuse people.


On 01/20/2015 12: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.


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 anything, as far as 
I can tell.


-Sandra

Re: [ping] Re: proper name of i386/x86-64/etc targets

[H.J. Lu]

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, uh, "32-bit x86"?  With the other
>>> names in parentheses where appropriate?  I think we could also ignore the
>>> 16-bit x86 variants for the purposes of GCC and just use "x86" instead of
>>> "i386 and x86-64".
>>>
>>
>> Please don't invent a new name.  It may confuse people.
>
>
> On 01/20/2015 12: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.
>
>
> 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 anything, as far as I can tell.
>
> -Sandra
>

"x86-32" is mentioned in

http://www.lyberty.com/tech/terms/x86_WHAT-IS_.html
http://superuser.com/questions/186503/is-x86-32-bit-or-64-bit
https://forums.digitalpoint.com/threads/what-does-x64-and-x86-mean.674631/

-- 
H.J.

Re: [ping] Re: proper name of i386/x86-64/etc targets

[Sandra Loosemore]

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 anything, as far as I can tell.


"x86-32" is mentioned in

http://www.lyberty.com/tech/terms/x86_WHAT-IS_.html
http://superuser.com/questions/186503/is-x86-32-bit-or-64-bit
https://forums.digitalpoint.com/threads/what-does-x64-and-x86-mean.674631/


I wouldn't consider random blog or forum postings to be reliable 
sources.  Can you cite manufacturer/vendor literature, technical 
reports, or news articles using that term?


FWIW, when I'm reviewing BSPs and associated documentation for
Mentor's own products, I always check the manufacturer's web site and 
verify that we use the name exactly as it appears in their own marketing 
literature and/or data sheets.  Wikipedia's standards for naming are a 
little different  they prefer to use the most common and familiar 
name for things.


-Sandra

Re: [ping] Re: proper name of i386/x86-64/etc targets

[H.J. Lu]

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 adjective "32-bit" on the existing name
>>> "x86".
>>> But "x86-32" isn't an existing real name for anything, as far as I can
>>> tell.
>>>
>> "x86-32" is mentioned in
>>
>> http://www.lyberty.com/tech/terms/x86_WHAT-IS_.html
>> http://superuser.com/questions/186503/is-x86-32-bit-or-64-bit
>> https://forums.digitalpoint.com/threads/what-does-x64-and-x86-mean.674631/
>
>
> I wouldn't consider random blog or forum postings to be reliable sources.
> Can you cite manufacturer/vendor literature, technical reports, or news
> articles using that term?
>
> FWIW, when I'm reviewing BSPs and associated documentation for
> Mentor's own products, I always check the manufacturer's web site and verify
> that we use the name exactly as it appears in their own marketing literature
> and/or data sheets.  Wikipedia's standards for naming are a little
> different  they prefer to use the most common and familiar name for
> things.

I checked with my colleagues at Intel.  x86-32 is somtimes used to refer
32-bit processors from Intel and AMD.


-- 
H.J.

libcc1.so bug/install location question

[Steve Ellcey]

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 installed into the same installation
directory and not stomp on each other.

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 install directory that contained
a libcc1.so, libcc1.so.0, libcc1.so.0.0.0, and libcc1.la file in them.
The files in each install directory were different which makes sense since
I was building for two different targets.

Is this overlap of names intended or is it a bug?

Steve Ellcey

Re: libcc1.so bug/install location question

[Joseph Myers]

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 install directory that contained
> a libcc1.so, libcc1.so.0, libcc1.so.0.0.0, and libcc1.la file in them.
> The files in each install directory were different which makes sense since
> I was building for two different targets.

It was stated in 
 that it doesn't 
depend on the target.

(Even for files that don't depend on the target, separate copies can be 
more helpful for building cross compilers.)

-- 
Joseph S. Myers
jos...@codesourcery.com