subject:"\[Factor\-talk\] gcc versions"

Re: [Factor-talk] gcc versions

2015-08-14 Thread Doug Coleman

Cool. Here's an issue for it:
https://github.com/slavapestov/factor/issues/1440

On Fri, Aug 14, 2015 at 1:31 PM, Jon Harper  wrote:

> I started this discussion because I thought that not everybody was aware
> of the impact of the recent c++11 changes. We now have stronger
> requirements than most projects, but this also means we have cleaner c++
> code :) I think that's worth it.
>
> I'll test with different gcc and clang versions so we can add a check in
> factor.sh.
>
> Note: Wheezy is now oldstable, so has been "obsolete" for 4 months (it
> still gets security fixes until february 2016, and after that debian's LTS
> until 2018).
>
> Jon
>
> On Fri, Aug 14, 2015 at 7:54 PM, John Benediktsson 
> wrote:
>
>> Are we using too-bleeding-edge C++ features?
>>
>> Is the suggestion maybe we scale down to some subset compilers have had
>> working for 3-4 years?
>>
>>
>> On Aug 14, 2015, at 10:51 AM, Jon Harper  wrote:
>>
>> Well that's GCC 4.7.2  September 20, 2012
>> Gcc did fix this in GCC 4.7.3  April 11,
>> 2013
>>
>> Also, clang does not error on the implicit this, but crashes hard earlier
>> than gcc :)
>>
>> $ clang --version
>> Debian clang version 3.0-6.2 (tags/RELEASE_30/final) (based on LLVM 3.0)
>> Target: i386-pc-linux-gnu
>> Thread model: posix
>>
>> $ CC=clang CXX=clang++ make
>> make `./build-support/factor.sh make-target`
>> [...snip...]
>> 1.  vm/free_list_allocator.hpp:124:57: current parser token ';'
>> 2.  vm/free_list_allocator.hpp:1:1: parsing namespace 'factor'
>> 3.  vm/free_list_allocator.hpp:123:68: parsing function body 'sweep'
>> 4.  vm/free_list_allocator.hpp:123:68: in compound statement ('{}')
>> clang: error: unable to execute command: Segmentation fault
>> 
>>
>>
>> --
>>
>> ___
>> Factor-talk mailing list
>> Factor-talk@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>
>>
>>
>> --
>>
>> ___
>> Factor-talk mailing list
>> Factor-talk@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>
>>
>
>
> --
>
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] gcc versions

2015-08-14 Thread Jon Harper

I started this discussion because I thought that not everybody was aware of
the impact of the recent c++11 changes. We now have stronger requirements
than most projects, but this also means we have cleaner c++ code :) I think
that's worth it.

I'll test with different gcc and clang versions so we can add a check in
factor.sh.

Note: Wheezy is now oldstable, so has been "obsolete" for 4 months (it
still gets security fixes until february 2016, and after that debian's LTS
until 2018).

Jon

On Fri, Aug 14, 2015 at 7:54 PM, John Benediktsson  wrote:

> Are we using too-bleeding-edge C++ features?
>
> Is the suggestion maybe we scale down to some subset compilers have had
> working for 3-4 years?
>
>
> On Aug 14, 2015, at 10:51 AM, Jon Harper  wrote:
>
> Well that's GCC 4.7.2  September 20, 2012
> Gcc did fix this in GCC 4.7.3  April 11,
> 2013
>
> Also, clang does not error on the implicit this, but crashes hard earlier
> than gcc :)
>
> $ clang --version
> Debian clang version 3.0-6.2 (tags/RELEASE_30/final) (based on LLVM 3.0)
> Target: i386-pc-linux-gnu
> Thread model: posix
>
> $ CC=clang CXX=clang++ make
> make `./build-support/factor.sh make-target`
> [...snip...]
> 1.  vm/free_list_allocator.hpp:124:57: current parser token ';'
> 2.  vm/free_list_allocator.hpp:1:1: parsing namespace 'factor'
> 3.  vm/free_list_allocator.hpp:123:68: parsing function body 'sweep'
> 4.  vm/free_list_allocator.hpp:123:68: in compound statement ('{}')
> clang: error: unable to execute command: Segmentation fault
> 
>
>
> --
>
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
>
> --
>
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] gcc versions

2015-08-14 Thread John Benediktsson

Are we using too-bleeding-edge C++ features?

Is the suggestion maybe we scale down to some subset compilers have had working 
for 3-4 years?


> On Aug 14, 2015, at 10:51 AM, Jon Harper  wrote:
> 
> Well that's GCC 4.7.2 September 20, 2012
> Gcc did fix this in GCC 4.7.3 April 11, 2013
> 
> Also, clang does not error on the implicit this, but crashes hard earlier 
> than gcc :)
> 
> $ clang --version
> Debian clang version 3.0-6.2 (tags/RELEASE_30/final) (based on LLVM 3.0)
> Target: i386-pc-linux-gnu
> Thread model: posix
> 
> $ CC=clang CXX=clang++ make
> make `./build-support/factor.sh make-target`
> [...snip...]
> 1.  vm/free_list_allocator.hpp:124:57: current parser token ';'
> 2.  vm/free_list_allocator.hpp:1:1: parsing namespace 'factor'
> 3.  vm/free_list_allocator.hpp:123:68: parsing function body 'sweep'
> 4.  vm/free_list_allocator.hpp:123:68: in compound statement ('{}')
> clang: error: unable to execute command: Segmentation fault
> 
> --
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] gcc versions

2015-08-14 Thread Doug Coleman

I missed your point.

We decided to use C++11 features a few months ago, so we need whatever it
takes to compile that correctly.

Maybe we need to switch to cmake or modify factor.sh to check that the
compiler version is high enough.

It sucks that Debian is shipping a buggy compiler with a stable release.



On Fri, Aug 14, 2015 at 11:10 AM, Jon Harper  wrote:

> "So if the fix is correct, then we are all good."
> The implicit this fix doesn't change anything:
> With Wheezy's clang, it has no effect: it always segfaults during the
> precompilation of master.hpp
> With Wheezy's gcc, it goes from a false negative error during the
> precompilation of master.hpp to a segfault during the compilation of
> compaction.cpp
>
> Also, there are tons of other implicit this uses. This one just happens to
> be in a lambda and calling a non const method of this.
>
> I'm not sure we want to support 2012's compilers ?
>
> Jon
>
> On Fri, Aug 14, 2015 at 7:54 PM, Doug Coleman 
> wrote:
>
>> Interesting. Both versions work with my clang.
>>
>> ergmac:factor erg$ [master*] clang --version
>> Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
>> Target: x86_64-apple-darwin14.4.0
>> Thread model: posix
>>
>> So if the fix is correct, then we are all good.
>>
>> Doug
>>
>> On Fri, Aug 14, 2015 at 10:51 AM, Jon Harper 
>> wrote:
>>
>>> Well that's GCC 4.7.2  September 20, 2012
>>> Gcc did fix this in GCC 4.7.3  April 11,
>>> 2013
>>>
>>> Also, clang does not error on the implicit this, but crashes hard
>>> earlier than gcc :)
>>>
>>> $ clang --version
>>> Debian clang version 3.0-6.2 (tags/RELEASE_30/final) (based on LLVM 3.0)
>>> Target: i386-pc-linux-gnu
>>> Thread model: posix
>>>
>>> $ CC=clang CXX=clang++ make
>>> make `./build-support/factor.sh make-target`
>>> [...snip...]
>>> 1.  vm/free_list_allocator.hpp:124:57: current parser token ';'
>>> 2.  vm/free_list_allocator.hpp:1:1: parsing namespace 'factor'
>>> 3.  vm/free_list_allocator.hpp:123:68: parsing function body 'sweep'
>>> 4.  vm/free_list_allocator.hpp:123:68: in compound statement ('{}')
>>> clang: error: unable to execute command: Segmentation fault
>>> 
>>>
>>>
>>> --
>>>
>>> ___
>>> Factor-talk mailing list
>>> Factor-talk@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>>
>>>
>>
>>
>> --
>>
>> ___
>> Factor-talk mailing list
>> Factor-talk@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>
>>
>
>
> --
>
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] gcc versions

2015-08-14 Thread Jon Harper

"So if the fix is correct, then we are all good."
The implicit this fix doesn't change anything:
With Wheezy's clang, it has no effect: it always segfaults during the
precompilation of master.hpp
With Wheezy's gcc, it goes from a false negative error during the
precompilation of master.hpp to a segfault during the compilation of
compaction.cpp

Also, there are tons of other implicit this uses. This one just happens to
be in a lambda and calling a non const method of this.

I'm not sure we want to support 2012's compilers ?

Jon

On Fri, Aug 14, 2015 at 7:54 PM, Doug Coleman 
wrote:

> Interesting. Both versions work with my clang.
>
> ergmac:factor erg$ [master*] clang --version
> Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
> Target: x86_64-apple-darwin14.4.0
> Thread model: posix
>
> So if the fix is correct, then we are all good.
>
> Doug
>
> On Fri, Aug 14, 2015 at 10:51 AM, Jon Harper 
> wrote:
>
>> Well that's GCC 4.7.2  September 20, 2012
>> Gcc did fix this in GCC 4.7.3  April 11,
>> 2013
>>
>> Also, clang does not error on the implicit this, but crashes hard earlier
>> than gcc :)
>>
>> $ clang --version
>> Debian clang version 3.0-6.2 (tags/RELEASE_30/final) (based on LLVM 3.0)
>> Target: i386-pc-linux-gnu
>> Thread model: posix
>>
>> $ CC=clang CXX=clang++ make
>> make `./build-support/factor.sh make-target`
>> [...snip...]
>> 1.  vm/free_list_allocator.hpp:124:57: current parser token ';'
>> 2.  vm/free_list_allocator.hpp:1:1: parsing namespace 'factor'
>> 3.  vm/free_list_allocator.hpp:123:68: parsing function body 'sweep'
>> 4.  vm/free_list_allocator.hpp:123:68: in compound statement ('{}')
>> clang: error: unable to execute command: Segmentation fault
>> 
>>
>>
>> --
>>
>> ___
>> Factor-talk mailing list
>> Factor-talk@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>
>>
>
>
> --
>
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] gcc versions

2015-08-14 Thread Doug Coleman

Interesting. Both versions work with my clang.

ergmac:factor erg$ [master*] clang --version
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.4.0
Thread model: posix

So if the fix is correct, then we are all good.

Doug

On Fri, Aug 14, 2015 at 10:51 AM, Jon Harper  wrote:

> Well that's GCC 4.7.2  September 20, 2012
> Gcc did fix this in GCC 4.7.3  April 11,
> 2013
>
> Also, clang does not error on the implicit this, but crashes hard earlier
> than gcc :)
>
> $ clang --version
> Debian clang version 3.0-6.2 (tags/RELEASE_30/final) (based on LLVM 3.0)
> Target: i386-pc-linux-gnu
> Thread model: posix
>
> $ CC=clang CXX=clang++ make
> make `./build-support/factor.sh make-target`
> [...snip...]
> 1.  vm/free_list_allocator.hpp:124:57: current parser token ';'
> 2.  vm/free_list_allocator.hpp:1:1: parsing namespace 'factor'
> 3.  vm/free_list_allocator.hpp:123:68: parsing function body 'sweep'
> 4.  vm/free_list_allocator.hpp:123:68: in compound statement ('{}')
> clang: error: unable to execute command: Segmentation fault
> 
>
>
> --
>
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] gcc versions

2015-08-14 Thread Jon Harper

Well that's GCC 4.7.2  September 20, 2012
Gcc did fix this in GCC 4.7.3  April 11, 2013

Also, clang does not error on the implicit this, but crashes hard earlier
than gcc :)

$ clang --version
Debian clang version 3.0-6.2 (tags/RELEASE_30/final) (based on LLVM 3.0)
Target: i386-pc-linux-gnu
Thread model: posix

$ CC=clang CXX=clang++ make
make `./build-support/factor.sh make-target`
[...snip...]
1.  vm/free_list_allocator.hpp:124:57: current parser token ';'
2.  vm/free_list_allocator.hpp:1:1: parsing namespace 'factor'
3.  vm/free_list_allocator.hpp:123:68: parsing function body 'sweep'
4.  vm/free_list_allocator.hpp:123:68: in compound statement ('{}')
clang: error: unable to execute command: Segmentation fault

--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] gcc versions

2015-08-14 Thread Doug Coleman

Maybe gcc should spend more time implementing C++14 and fixing bugs and
less time worrying about someone stealing their AST.

You can use clang and it should work.
CC=clang CXX=clang++ make

I'll patch the implicit this but I don't know what else to say. :)

Doug

On Fri, Aug 14, 2015 at 10:00 AM, Jon Harper  wrote:

> Hi,
> for info, we can't compile the factor vm with the default compiler (gcc
> 4.7.2) of debian oldstable wheezy anymore.
>
> First, it has a false compilation error (
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54277):
> g++ -c -x c++-header -Wall -DFACTOR_VERSION="0.98"
> -DFACTOR_GIT_LABEL="heads/master-5ba44b37bc82bfdea706c16f33b3bbc13b9ca87c"
> -fomit-frame-pointer -Wl,--no-as-needed -m32 -O3 -g -std=c++11 -o
> vm/master.hpp.gch vm/master.hpp
> In file included from vm/master.hpp:112:0:
> vm/free_list_allocator.hpp: In lambda function:
> vm/free_list_allocator.hpp:137:35: error: no matching function for call to
> ‘factor::mark_bits::marked_p(factor::cell&) const’
> vm/free_list_allocator.hpp:137:35: note: candidate is:
> In file included from vm/master.hpp:109:0:
> vm/mark_bits.hpp:81:8: note: bool
> factor::mark_bits::marked_p(factor::cell) 
> vm/mark_bits.hpp:81:8: note:   no known conversion for implicit ‘this’
> parameter from ‘const factor::mark_bits*’ to ‘factor::mark_bits*’
>
> The following patch workarounds error:
> diff --git a/vm/free_list_allocator.hpp b/vm/free_list_allocator.hpp
> index 65e6851..461004c 100644
> --- a/vm/free_list_allocator.hpp
> +++ b/vm/free_list_allocator.hpp
> @@ -137 +137 @@ void free_list_allocator::compact(Iterator& iter,
> Fixup fixup,
> -if (!state.marked_p(block_addr))
> +if (!this->state.marked_p(block_addr))
>
>
> Even with the workaround, when then have
> g++ -c -Wall -DFACTOR_VERSION="0.98"
> -DFACTOR_GIT_LABEL="heads/master-5ba44b37bc82bfdea706c16f33b3bbc13b9ca87c"
> -fomit-frame-pointer -Wl,--no-as-needed -m32 -O3 -g -std=c++11 -o
> vm/compaction.o vm/compaction.cpp
> vm/compaction.cpp: In lambda function:
> vm/compaction.cpp:165:1: internal compiler error: in get_expr_operands, at
> tree-ssa-operands.c:1035
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
>
>
> Jon
>
>
> --
>
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

[Factor-talk] gcc versions

2015-08-14 Thread Jon Harper

Hi,
for info, we can't compile the factor vm with the default compiler (gcc
4.7.2) of debian oldstable wheezy anymore.

First, it has a false compilation error (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54277):
g++ -c -x c++-header -Wall -DFACTOR_VERSION="0.98"
-DFACTOR_GIT_LABEL="heads/master-5ba44b37bc82bfdea706c16f33b3bbc13b9ca87c"
-fomit-frame-pointer -Wl,--no-as-needed -m32 -O3 -g -std=c++11 -o
vm/master.hpp.gch vm/master.hpp
In file included from vm/master.hpp:112:0:
vm/free_list_allocator.hpp: In lambda function:
vm/free_list_allocator.hpp:137:35: error: no matching function for call to
‘factor::mark_bits::marked_p(factor::cell&) const’
vm/free_list_allocator.hpp:137:35: note: candidate is:
In file included from vm/master.hpp:109:0:
vm/mark_bits.hpp:81:8: note: bool factor::mark_bits::marked_p(factor::cell)

vm/mark_bits.hpp:81:8: note:   no known conversion for implicit ‘this’
parameter from ‘const factor::mark_bits*’ to ‘factor::mark_bits*’

The following patch workarounds error:
diff --git a/vm/free_list_allocator.hpp b/vm/free_list_allocator.hpp
index 65e6851..461004c 100644
--- a/vm/free_list_allocator.hpp
+++ b/vm/free_list_allocator.hpp
@@ -137 +137 @@ void free_list_allocator::compact(Iterator& iter,
Fixup fixup,
-if (!state.marked_p(block_addr))
+if (!this->state.marked_p(block_addr))


Even with the workaround, when then have
g++ -c -Wall -DFACTOR_VERSION="0.98"
-DFACTOR_GIT_LABEL="heads/master-5ba44b37bc82bfdea706c16f33b3bbc13b9ca87c"
-fomit-frame-pointer -Wl,--no-as-needed -m32 -O3 -g -std=c++11 -o
vm/compaction.o vm/compaction.cpp
vm/compaction.cpp: In lambda function:
vm/compaction.cpp:165:1: internal compiler error: in get_expr_operands, at
tree-ssa-operands.c:1035
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Jon
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] gcc versions

Re: [Factor-talk] gcc versions

Re: [Factor-talk] gcc versions

Re: [Factor-talk] gcc versions

Re: [Factor-talk] gcc versions

Re: [Factor-talk] gcc versions

Re: [Factor-talk] gcc versions

Re: [Factor-talk] gcc versions

[Factor-talk] gcc versions

9 matches

Site Navigation

Mail list logo

Footer information