Re: 3 quick questions about stack alignment for powerpc (32-bit) signal handlers [the change that caused misaligned]

2016-02-01 Thread Mark Millard 
The -16/16 code below produced correct alignment but too little space.

The -20/20 code below produces enough space but misalignment.

To maintain 16-byte alignment while increasing the space would have required 
going from -16/16 to -32/32. At least that is how I understand this code.


Index: sys/powerpc/powerpc/sigcode32.S
===
--- sys/powerpc/powerpc/sigcode32.S 
(.../head/sys/powerpc/powerpc/sigcode32.S)  (revision 209975)
+++ sys/powerpc/powerpc/sigcode32.S 
(.../projects/clang380-import/sys/powerpc/powerpc/sigcode32.S)  (working copy)
@@ -45,9 +45,9 @@
  */
.globl  CNAME(sigcode32),CNAME(szsigcode32)
 CNAME(sigcode32):
-   addi1,1,-16 /* reserved space for callee */
+   addi1,1,-20 /* reserved space for callee */
blrl
-   addi3,1,16+SF_UC/* restore sp, and get >sf_uc */
+   addi3,1,20+SF_UC/* restore sp, and get >sf_uc */
li  0,SYS_sigreturn
sc  /* sigreturn(scp) */
li  0,SYS_exit



The "working copy" is -r266778 from 2014-May-27.

-r209975 is from 2010-Jul-13.


===
Mark Millard
markmi at dsl-only.net

On 2016-Jan-31, at 10:58 PM, Mark Millard  wrote:

Just a correction to a sentence that I wrote. I had written:

> Frame at:0x...90 vs. 0x...1c
> call by frame:   0x...b0 vs. 0x...1c
> Arglist at:  0x...70 vs. 0x...dc
> Locals at:   0x...70 vs. 0x...dc
> Previous frame's sp: 0x...90 vs. 0x...1c
> 
> It looks like 4 additional pad bytes on the user/process stack are needed to 
> get back to alignment.

Of course the figures on the right need to get smaller, not larger: The stack 
grows towards smaller addresses. So to get to 0x...0 on the right I should have 
said:

It looks like 12 additional pad bytes on the user/process stack are needed to 
get back to alignment.

That would produce:

Frame at:0x...90 vs. 0x...10
call by frame:   0x...b0 vs. 0x...10
Arglist at:  0x...70 vs. 0x...d0
Locals at:   0x...70 vs. 0x...d0
Previous frame's sp: 0x...90 vs. 0x...10

===
Mark Millard
markmi at dsl-only.net

On 2016-Jan-31, at 10:47 PM, Mark Millard  wrote:

More evidence: By adding "break raise" and then using "info frame" to show the 
alignment at that point I can show that the later signal delivery changes the 
alignment on the user process stack compared to when raise was called. (Later I 
show the same for thr_kill.)

> Breakpoint 2, __raise (s=29) at /usr/src/lib/libc/gen/raise.c:50
> warning: Source file is more recent than executable.
> 50if (__sys_thr_self() == -1)
> (gdb) info frame
> Stack level 0, frame at 0xdc90:
> pc = 0x41904630 in __raise (/usr/src/lib/libc/gen/raise.c:50); saved pc = 
> 0x1800774
> called by frame at 0xdcb0
> source language c.
> Arglist at 0xdc70, args: s=29
> Locals at 0xdc70, Previous frame's sp is 0xdc90
> Saved registers:
> r29 at 0xdc84, r30 at 0xdc88, r31 at 0xdc8c, pc at 0xdc94, lr 
> at 0xdc94
> (gdb) cont
> Continuing.
> 
> Program received signal SIGINFO, Information request.
> 
> Breakpoint 1, 0x018006d0 in handler ()
> (gdb) info frame
> Stack level 0, frame at 0xd71c:
> pc = 0x18006d0 in handler; saved pc = 0xe008
> called by frame at 0xd71c
> Arglist at 0xd6dc, args: 
> Locals at 0xd6dc, Previous frame's sp is 0xd71c
> Saved registers:
> r31 at 0xd718, pc at 0xd720, lr at 0xd720

Note the difference (raise before delivery vs. handler via delivery):

Frame at:0x...90 vs. 0x...1c
call by frame:   0x...b0 vs. 0x...1c
Arglist at:  0x...70 vs. 0x...dc
Locals at:   0x...70 vs. 0x...dc
Previous frame's sp: 0x...90 vs. 0x...1c

It looks like 4 additional pad bytes on the user/process stack are needed to 
get back to alignment.

[The span of addresses seems to be about: 0xdc90-0xd6dc==0x5B4==1460 
(raise's "frame at" minus handler's "Locals at").]


If I look at the frame for "break thr_kill" it also still shows an aligned 
user/process stack before the delivery:

> Breakpoint 3, 0x419046a0 in thr_kill () from /lib/libc.so.7
> (gdb) info frame
> Stack level 0, frame at 0xdc70:
> pc = 0x419046a0 in thr_kill; saved pc = 0x41904650
> called by frame at 0xdc90
> Arglist at 0xdc70, args: 
> Locals at 0xdc70, Previous frame's sp is 0xdc70

(The relevant addresses are the same as raise showed.)


Reminder of the source program structure that uses the potentially frame/stack 
alignment sensitive libc/stdio library code:

> # more sig_snprintf_use_test.c 
> #include  // for signal, SIGINFO, SIG_ERR, raise.
> #include   // for snprintf
> 
> void handler(int sig)
> {
>   char buf[32];
>   snprintf(buf, sizeof buf, "%d", sig); // FreeBSD's world does such
> // things in some of its handlers.
> }
> 
>

Re: GCC5: pkg vs. ports

2016-02-01 Thread Kubilay Kocak 
Hi William,

You may be seeing a previously saved config, try make rmconfig then check
again, or look at OPTIONS_DEFAULT inside Makefile

You're correct, if graphite *is* a default option, the package should have
it . Only other thing I can think of is a silent graphite build failure
that isn't fatal, resulting in a built but incomplete package. Unlikely all
else being equal though

Let us know what you find

./koobs
On 2 Feb 2016 3:06 AM, "William A. Mahaffey III"  wrote:

>
>
> I just did a full 'pkg upgrade' on my FBSD 9.3R box, which installed the
> newest GCC5. I also updated ports. When I used the pkg-provided GCC5, it
> doesn't have graphite support enabled, so no auto-parallelization. When I
> checked the port w/ make showconfig. it shows graphite enabled. I am
> recompiling it as I write this, but I thought the pkg was/is configured
> from the port & would have graphite enabled by default, w/ no recompile
> needed on my part, no ? I have the various other pkg's req'd for graphite
> support pkg-installed (& just updated this A.M.), so I thought I was ready
> to go. Not a huge issue, but recompiling the compiler shoots about an hour
> on my box, would be sweet to avoid that. TIA for any clues & have a good
> one.
>
>
> --
>
> William A. Mahaffey III
>
>  --
>
> "The M1 Garand is without doubt the finest implement of war
>  ever devised by man."
>-- Gen. George S. Patton Jr.
>
> ___
> freebsd-toolchain@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "
> freebsd-toolchain-unsubscr...@freebsd.org"
>
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: GCC5: pkg vs. ports

2016-02-01 Thread William A. Mahaffey III 

On 02/01/16 10:53, William A. Mahaffey III wrote:

On 02/01/16 10:48, Kubilay Kocak wrote:

If you need further help, freebsd-ports is the most appropriate list,
feel free to reply there:)

./koobs



Very well, I'll move this over there, sorry for the noise & thanks :-) 





Eek, when I try to subscribe to the ports list, I get some sort of 
error:




 freebsd-ports Subscription results

You must GET the form before submitting it.

freebsd-ports  
list run by moderators at freebsd.org 

freebsd-ports administrative interface 
 (requires 
authorization)
Overview of all freebsd.org mailing lists 





No clue here, anyone ? All I filled in was e-mail address & name, no 
passwords, but that's what I have done for other lists & it worked 


--

William A. Mahaffey III

 --

"The M1 Garand is without doubt the finest implement of war
 ever devised by man."
   -- Gen. George S. Patton Jr.

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: GCC5: pkg vs. ports

2016-02-01 Thread William A. Mahaffey III 

On 02/01/16 10:18, Kubilay Kocak wrote:


Hi William,

You may be seeing a previously saved config, try make rmconfig then 
check again, or look at OPTIONS_DEFAULT inside Makefile


You're correct, if graphite *is* a default option, the package should 
have it . Only other thing I can think of is a silent graphite build 
failure that isn't fatal, resulting in a built but incomplete package. 
Unlikely all else being equal though


Let us know what you find

./koobs

On 2 Feb 2016 3:06 AM, "William A. Mahaffey III" > wrote:




I just did a full 'pkg upgrade' on my FBSD 9.3R box, which
installed the newest GCC5. I also updated ports. When I used the
pkg-provided GCC5, it doesn't have graphite support enabled, so no
auto-parallelization. When I checked the port w/ make showconfig.
it shows graphite enabled. I am recompiling it as I write this,
but I thought the pkg was/is configured from the port & would have
graphite enabled by default, w/ no recompile needed on my part, no
? I have the various other pkg's req'd for graphite support
pkg-installed (& just updated this A.M.), so I thought I was ready
to go. Not a huge issue, but recompiling the compiler shoots about
an hour on my box, would be sweet to avoid that. TIA for any clues
& have a good one.


-- 


William A. Mahaffey III

 --

"The M1 Garand is without doubt the finest implement of war
 ever devised by man."
   -- Gen. George S. Patton Jr.

___
freebsd-toolchain@freebsd.org
 mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to
"freebsd-toolchain-unsubscr...@freebsd.org
"




My build failed right at the end:

# Add target libraries and include files to packaging list.
/bin/rm -f -f /usr/ports/lang/gcc5-devel/work/PLIST.lib
cd /usr/ports/lang/gcc5-devel/work/stage/usr/local ; if [ -d lib/gcc5 ]; 
then  /usr/bin/find lib/gcc5 -type f -o -type l 
>>/usr/ports/lang/gcc5-devel/work/PLIST.lib ; fi
cd /usr/ports/lang/gcc5-devel/work/stage/usr/local ; if [ -d 
libexec/gcc5 ]; then  /usr/bin/find libexec/gcc5 -type f -o -type l 
>>/usr/ports/lang/gcc5-devel/work/PLIST.lib ; fi
cd /usr/ports/lang/gcc5-devel/work/stage/usr/local ; if [ -d include/gcj 
]; then  /usr/bin/find include/gcj -type f -o -type l 
>>/usr/ports/lang/gcc5-devel/work/PLIST.lib ; fi
cd /usr/ports/lang/gcc5-devel/work/stage/usr/local ; if [ -d include/gnu 
]; then  /usr/bin/find include/gnu -type f -o -type l 
>>/usr/ports/lang/gcc5-devel/work/PLIST.lib ; fi
cd /usr/ports/lang/gcc5-devel/work/stage/usr/local ; if [ -d 
include/java ]; then  /usr/bin/find include/java -type f -o -type l 
>>/usr/ports/lang/gcc5-devel/work/PLIST.lib ; fi
cd /usr/ports/lang/gcc5-devel/work/stage/usr/local ; if [ -d 
include/javax ]; then  /usr/bin/find include/javax -type f -o -type l 
>>/usr/ports/lang/gcc5-devel/work/PLIST.lib ; fi
cd /usr/ports/lang/gcc5-devel/work ; /usr/bin/sed -i -e "/PLIST.lib/ r 
PLIST.lib" /usr/ports/lang/gcc5-devel/work/.PLIST.mktmp

> Compressing man pages (compress-man)
===>   Installing ldconfig configuration file
===>  Installing for gcc5-devel-5.3.1.s20160126
===>  Checking if gcc5-devel already installed
===>   An older version of gcc5-devel is already installed 
(gcc5-devel-5.3.1.s20160119)

  You may wish to ``make deinstall'' and install this port again
  by ``make reinstall'' to upgrade it properly.
  If you really wish to overwrite the old port of gcc5-devel
  without deleting it first, set the variable "FORCE_PKG_REGISTER"
  in your environment or the "make install" command line.
*** [check-already-installed] Error code 1

Stop in /usr/ports/lang/gcc5-devel.
*** [install] Error code 1

Stop in /usr/ports/lang/gcc5-devel.
 2983.69 real  9852.39 user   807.15 sys

Completed at 10:33:36 AM MCST on Monday, February  1, 2016


i.e. it wouldn't overwrite the pkg-installed version (I think). I (think 
I) recall having to do a 'make FORCE_PKG_REGISTER=1 install' or some 
such before, or just use the version down in the stage directory 



--

William A. Mahaffey III

 --

"The M1 Garand is without doubt the finest implement of war
 ever devised by man."
   -- Gen. George S. Patton Jr.

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: GCC5: pkg vs. ports

2016-02-01 Thread Kubilay Kocak 
On 2/02/2016 3:24 AM, William A. Mahaffey III wrote:
> On 02/01/16 10:18, Kubilay Kocak wrote:
>>
>> Hi William,
>>
>> You may be seeing a previously saved config, try make rmconfig then
>> check again, or look at OPTIONS_DEFAULT inside Makefile
>>
>> You're correct, if graphite *is* a default option, the package should
>> have it . Only other thing I can think of is a silent graphite build
>> failure that isn't fatal, resulting in a built but incomplete package.
>> Unlikely all else being equal though
>>
>> Let us know what you find
>>
>> ./koobs
>>
>> On 2 Feb 2016 3:06 AM, "William A. Mahaffey III" > > wrote:
>>
>>
>>
>> I just did a full 'pkg upgrade' on my FBSD 9.3R box, which
>> installed the newest GCC5. I also updated ports. When I used the
>> pkg-provided GCC5, it doesn't have graphite support enabled, so no
>> auto-parallelization. When I checked the port w/ make showconfig.
>> it shows graphite enabled. I am recompiling it as I write this,
>> but I thought the pkg was/is configured from the port & would have
>> graphite enabled by default, w/ no recompile needed on my part, no
>> ? I have the various other pkg's req'd for graphite support
>> pkg-installed (& just updated this A.M.), so I thought I was ready
>> to go. Not a huge issue, but recompiling the compiler shoots about
>> an hour on my box, would be sweet to avoid that. TIA for any clues
>> & have a good one.
>>
>>
>> --
>> William A. Mahaffey III
>>
> 
> The *ports* version looks AOK, Makefile dated Jan 31, & 'make
> showconfig' says graphite is ready to go. When it gets done, I'll try to
> compile some code w/ it & verify it is AOK. I just didn't know why the
> *pkg* version was different.
> 
> 

William,

I've just had a quick look, and if you're using the lang/gcc5 port, it
appears the GRAPHITE option defaults to OFF:

https://svnweb.freebsd.org/ports/head/lang/gcc5/Makefile?revision=403073=markup#l48

This explains why that (gcc5) package doesn't have it enabled.

Also see the last revision commit log:

https://svnweb.freebsd.org/ports?view=revision=403073

./koobs
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: GCC5: pkg vs. ports

2016-02-01 Thread Kubilay Kocak 
On 2/02/2016 3:37 AM, William A. Mahaffey III wrote:
> On 02/01/16 10:18, Kubilay Kocak wrote:
>>
>> Hi William,
>>
>> You may be seeing a previously saved config, try make rmconfig then
>> check again, or look at OPTIONS_DEFAULT inside Makefile
>>
>> You're correct, if graphite *is* a default option, the package should
>> have it . Only other thing I can think of is a silent graphite build
>> failure that isn't fatal, resulting in a built but incomplete package.
>> Unlikely all else being equal though
>>
>> Let us know what you find
>>
>> ./koobs
>>
>> On 2 Feb 2016 3:06 AM, "William A. Mahaffey III" > > wrote:
>>
>>
>>
>> I just did a full 'pkg upgrade' on my FBSD 9.3R box, which
>> installed the newest GCC5. I also updated ports. When I used the
>> pkg-provided GCC5, it doesn't have graphite support enabled, so no
>> auto-parallelization. When I checked the port w/ make showconfig.
>> it shows graphite enabled. I am recompiling it as I write this,
>> but I thought the pkg was/is configured from the port & would have
>> graphite enabled by default, w/ no recompile needed on my part, no
>> ? I have the various other pkg's req'd for graphite support
>> pkg-installed (& just updated this A.M.), so I thought I was ready
>> to go. Not a huge issue, but recompiling the compiler shoots about
>> an hour on my box, would be sweet to avoid that. TIA for any clues
>> & have a good one.
>>
>>
>> --
>> William A. Mahaffey III
>>
>> 
>> --
>>
>> "The M1 Garand is without doubt the finest implement of war
>>  ever devised by man."
>>-- Gen. George S. Patton Jr.
>>
>> ___
>> freebsd-toolchain@freebsd.org
>>  mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
>> To unsubscribe, send any mail to
>> "freebsd-toolchain-unsubscr...@freebsd.org
>> "
>>
> 
> 
> My build failed right at the end:
> 
> # Add target libraries and include files to packaging list.
> /bin/rm -f -f /usr/ports/lang/gcc5-devel/work/PLIST.lib
> cd /usr/ports/lang/gcc5-devel/work/stage/usr/local ; if [ -d lib/gcc5 ];
> then  /usr/bin/find lib/gcc5 -type f -o -type l
>>>/usr/ports/lang/gcc5-devel/work/PLIST.lib ; fi
> cd /usr/ports/lang/gcc5-devel/work/stage/usr/local ; if [ -d
> libexec/gcc5 ]; then  /usr/bin/find libexec/gcc5 -type f -o -type l
>>>/usr/ports/lang/gcc5-devel/work/PLIST.lib ; fi
> cd /usr/ports/lang/gcc5-devel/work/stage/usr/local ; if [ -d include/gcj
> ]; then  /usr/bin/find include/gcj -type f -o -type l
>>>/usr/ports/lang/gcc5-devel/work/PLIST.lib ; fi
> cd /usr/ports/lang/gcc5-devel/work/stage/usr/local ; if [ -d include/gnu
> ]; then  /usr/bin/find include/gnu -type f -o -type l
>>>/usr/ports/lang/gcc5-devel/work/PLIST.lib ; fi
> cd /usr/ports/lang/gcc5-devel/work/stage/usr/local ; if [ -d
> include/java ]; then  /usr/bin/find include/java -type f -o -type l
>>>/usr/ports/lang/gcc5-devel/work/PLIST.lib ; fi
> cd /usr/ports/lang/gcc5-devel/work/stage/usr/local ; if [ -d
> include/javax ]; then  /usr/bin/find include/javax -type f -o -type l
>>>/usr/ports/lang/gcc5-devel/work/PLIST.lib ; fi
> cd /usr/ports/lang/gcc5-devel/work ; /usr/bin/sed -i -e "/PLIST.lib/ r
> PLIST.lib" /usr/ports/lang/gcc5-devel/work/.PLIST.mktmp
> > Compressing man pages (compress-man)
> ===>   Installing ldconfig configuration file
> ===>  Installing for gcc5-devel-5.3.1.s20160126
> ===>  Checking if gcc5-devel already installed
> ===>   An older version of gcc5-devel is already installed
> (gcc5-devel-5.3.1.s20160119)
>   You may wish to ``make deinstall'' and install this port again
>   by ``make reinstall'' to upgrade it properly.
>   If you really wish to overwrite the old port of gcc5-devel
>   without deleting it first, set the variable "FORCE_PKG_REGISTER"
>   in your environment or the "make install" command line.
> *** [check-already-installed] Error code 1
> 
> Stop in /usr/ports/lang/gcc5-devel.
> *** [install] Error code 1
> 
> Stop in /usr/ports/lang/gcc5-devel.
>  2983.69 real  9852.39 user   807.15 sys
> 
> Completed at 10:33:36 AM MCST on Monday, February  1, 2016
> 
> 
> i.e. it wouldn't overwrite the pkg-installed version (I think). I (think
> I) recall having to do a 'make FORCE_PKG_REGISTER=1 install' or some
> such before, or just use the version down in the stage directory 
> 
> 

I note the GRAPHITE option defaults to OFF in gcc5-devel as well.

Regarding the install issue, try:

* make clean reinstall, OR
* remove the pkg then make clean install

If you need further help, freebsd-ports is the most appropriate list,
feel free to reply there :)

./koobs

Re: GCC5: pkg vs. ports

2016-02-01 Thread William A. Mahaffey III 

On 02/01/16 10:48, Kubilay Kocak wrote:

If you need further help, freebsd-ports is the most appropriate list,
feel free to reply there:)

./koobs



Very well, I'll move this over there, sorry for the noise & thanks :-) 

--

William A. Mahaffey III

 --

"The M1 Garand is without doubt the finest implement of war
 ever devised by man."
   -- Gen. George S. Patton Jr.

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

GCC5: pkg vs. ports

2016-02-01 Thread William A. Mahaffey III 



I just did a full 'pkg upgrade' on my FBSD 9.3R box, which installed the 
newest GCC5. I also updated ports. When I used the pkg-provided GCC5, it 
doesn't have graphite support enabled, so no auto-parallelization. When 
I checked the port w/ make showconfig. it shows graphite enabled. I am 
recompiling it as I write this, but I thought the pkg was/is configured 
from the port & would have graphite enabled by default, w/ no recompile 
needed on my part, no ? I have the various other pkg's req'd for 
graphite support pkg-installed (& just updated this A.M.), so I thought 
I was ready to go. Not a huge issue, but recompiling the compiler shoots 
about an hour on my box, would be sweet to avoid that. TIA for any clues 
& have a good one.



--

William A. Mahaffey III

 --

"The M1 Garand is without doubt the finest implement of war
 ever devised by man."
   -- Gen. George S. Patton Jr.

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: GCC5: pkg vs. ports

2016-02-01 Thread William A. Mahaffey III 

On 02/01/16 10:40, Kubilay Kocak wrote:

On 2/02/2016 3:24 AM, William A. Mahaffey III wrote:

On 02/01/16 10:18, Kubilay Kocak wrote:

Hi William,

You may be seeing a previously saved config, try make rmconfig then
check again, or look at OPTIONS_DEFAULT inside Makefile

You're correct, if graphite *is* a default option, the package should
have it . Only other thing I can think of is a silent graphite build
failure that isn't fatal, resulting in a built but incomplete package.
Unlikely all else being equal though

Let us know what you find

./koobs

On 2 Feb 2016 3:06 AM, "William A. Mahaffey III" > wrote:



 I just did a full 'pkg upgrade' on my FBSD 9.3R box, which
 installed the newest GCC5. I also updated ports. When I used the
 pkg-provided GCC5, it doesn't have graphite support enabled, so no
 auto-parallelization. When I checked the port w/ make showconfig.
 it shows graphite enabled. I am recompiling it as I write this,
 but I thought the pkg was/is configured from the port & would have
 graphite enabled by default, w/ no recompile needed on my part, no
 ? I have the various other pkg's req'd for graphite support
 pkg-installed (& just updated this A.M.), so I thought I was ready
 to go. Not a huge issue, but recompiling the compiler shoots about
 an hour on my box, would be sweet to avoid that. TIA for any clues
 & have a good one.


 --
 William A. Mahaffey III


The *ports* version looks AOK, Makefile dated Jan 31, & 'make
showconfig' says graphite is ready to go. When it gets done, I'll try to
compile some code w/ it & verify it is AOK. I just didn't know why the
*pkg* version was different.



William,

I've just had a quick look, and if you're using the lang/gcc5 port, it
appears the GRAPHITE option defaults to OFF:

https://svnweb.freebsd.org/ports/head/lang/gcc5/Makefile?revision=403073=markup#l48

This explains why that (gcc5) package doesn't have it enabled.

Also see the last revision commit log:

https://svnweb.freebsd.org/ports?view=revision=403073

./koobs



Actually, when I did a 'make install' from the 
'/usr/ports/lang/gcc5-devel' diredctory, the 1st thing it did was go 
download the files from kernel.org & proceed:



Beginning background make install
Initiated at 09:43:52 AM MCST on Monday, February  1, 2016

Making GCC 5.3.1.s20160126 for x86_64-portbld-freebsd9.3 
[c,c++,objc,fortran,java]

===>  License GPLv3 GPLv3RLE accepted by the user
===>  Found saved configuration for gcc5-devel-5.2.1.s20151124
===>   gcc5-devel-5.3.1.s20160126 depends on file: /usr/local/sbin/pkg - 
found

=> gcc-5-20160126.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch 
http://mirrors.kernel.org/sources.redhat.com/gcc/snapshots/5-20160126/gcc-5-20160126.tar.bz2

gcc-5-20160126.tar.bz2  87 MB0 Bps
===> Fetching all distfiles required by gcc5-devel-5.3.1.s20160126 for 
building

===>  Extracting for gcc5-devel-5.3.1.s20160126
=> SHA256 Checksum OK for gcc-5-20160126.tar.bz2.
===>  Patching for gcc5-devel-5.3.1.s20160126
===>  Applying extra patch /usr/ports/lang/gcc5-devel/files/java-patch-hier
===>  Applying FreeBSD patches for gcc5-devel-5.3.1.s20160126
===>   gcc5-devel-5.3.1.s20160126 depends on file: /usr/local/bin/as - found
===>   gcc5-devel-5.3.1.s20160126 depends on executable: gmake - found
===>   gcc5-devel-5.3.1.s20160126 depends on file: 
/usr/local/share/java/ecj-4.5.jar - found

===>   gcc5-devel-5.3.1.s20160126 depends on executable: zip - found
===>   gcc5-devel-5.3.1.s20160126 depends on file: /usr/local/bin/as - found
===>   gcc5-devel-5.3.1.s20160126 depends on package: perl5>=5.20<5.21 - 
found
===>   gcc5-devel-5.3.1.s20160126 depends on shared library: libgmp.so - 
found (/usr/local/lib/libgmp.so)
===>   gcc5-devel-5.3.1.s20160126 depends on shared library: libmpfr.so 
- found (/usr/local/lib/libmpfr.so)
===>   gcc5-devel-5.3.1.s20160126 depends on shared library: libmpc.so - 
found (/usr/local/lib/libmpc.so)
===>   gcc5-devel-5.3.1.s20160126 depends on shared library: libiconv.so 
- found (/usr/local/lib/libiconv.so)
===>   gcc5-devel-5.3.1.s20160126 depends on shared library: libisl.so - 
found (/usr/local/lib/libisl.so)

===>  Configuring for gcc5-devel-5.3.1.s20160126
cd /usr/ports/lang/gcc5-devel/work/gcc-5-20160126 ; contrib/gcc_update 
--touch

configure: loading site script /usr/ports/Templates/config.site


When I look in /usr/ports/distfiles, I see:


[root@devbox, gcc5-devel, 10:48:56am] 410 % lltr /usr/ports/distfiles/
total 617025
-rw-r--r--  1 root  wheel   1118845 Sep 23  2008 zip30.tar.gz
-rw-r--r--  1 root  wheel 10658 Jun 17  2013 dialog4ports-0.1.5.tar.gz
-rw-r--r--  1 root  wheel   1327342 Oct  5  2014 make-4.1.tar.bz2
-rw-r--r--  1 root  wheel  85807011 Oct 28 17:42 gcc-4.9-20151028.tar.bz2
-rw-r--r--  1 root  wheel  91322403 Nov 10 16:42 gcc-5-20151110.tar.bz2
-rw-r--r--  1 root