Re: [Tinycc-devel] Ready for Release 0.9.27

[Michael Matz]

Hi,

On Sat, 11 Feb 2017, Christian Jullien wrote:


Great, no more issues on RPi.

Now, testing on "8x2.4 GHz aarch64 / 32 GB RAM / APM X-Gene Mustang
board / Ubuntu 14.04.3 LTS"

jullien@gcc113:~/tinycc/tests/tests2$ ./42_function_pointer.exe
yo 24
Segmentation fault (core dumped)

This the only error I have on aarch64. Note, error appears also directly
when running ./42_function_pointer.exe from shell.


Indeed.  Same problem as 77d7ea04a, don't remember why I haven't checked 
arm64 at the time.  Fixed in mob now as well.



Ciao,
Michael.




-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Michael Matz
Sent: samedi 11 février 2017 14:34
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Ready for Release 0.9.27

Hi,

On Sat, 11 Feb 2017, Michael Matz wrote:


Your commit:
http://repo.or.cz/tinycc.git/blobdiff/cd9514abc4f4d7d90acce108b98ea2a
f58a1b8
0a..77d7ea04acb56f839031993c102366e30cad5c25:/tests/tests2/Makefile

Is the source of this error


Well, that means it uncovered a pre-existing bug in the arm32 linker.
I haven't tested arm32 myself in a long time.  I can take a look
later; I probably have some old arm32 debian chroot lying around

somewhere.

Oh, actually it wasn't a codegen bug at all.  I botched the testcase
invocation for NORUN tests, but that mattered only on arm where FILTER is
set to grep.  I've commited a fix for this to mob.


Ciao,
Michael.

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[Michael Matz]

Hi,

On Fri, 10 Feb 2017, grischka wrote:


FYI, GCC 6 behaves in the same way with -std=c89, -std=c99 and -std=c11.
Ditto for Clang 3.9.


I wouldn't really mind if we change the behavior.


I think we should.  If still for 0.9.27 I don't know.  It's a subtle 
change breaking stuff in strange corners.



Ciao,
Michael.


Basically tccgen.c contains 8 lines (in gen_op/expr_cond) similar to

if ((t1 & (VT_BTYPE | VT_UNSIGNED)) == (VT_LLONG | VT_UNSIGNED) ...
if ((t1 & (VT_BTYPE | VT_UNSIGNED)) == (VT_INT | VT_UNSIGNED) ...

Maybe we just need to change these like this
if ((t1 & (VT_BTYPE | VT_UNSIGNED | VT_BITFIELD)) == 

Note that VT_BITFIELD set implies bit-field width < original type width.

--- grischka


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[Christian Jullien]

Great, no more issues on RPi.

Now, testing on "8x2.4 GHz aarch64 / 32 GB RAM / APM X-Gene Mustang
board / Ubuntu 14.04.3 LTS"

jullien@gcc113:~/tinycc/tests/tests2$ ./42_function_pointer.exe
yo 24
Segmentation fault (core dumped)

This the only error I have on aarch64. Note, error appears also directly
when running ./42_function_pointer.exe from shell.


-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Michael Matz
Sent: samedi 11 février 2017 14:34
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Ready for Release 0.9.27

Hi,

On Sat, 11 Feb 2017, Michael Matz wrote:

>> Your commit: 
>> http://repo.or.cz/tinycc.git/blobdiff/cd9514abc4f4d7d90acce108b98ea2a
>> f58a1b8 
>> 0a..77d7ea04acb56f839031993c102366e30cad5c25:/tests/tests2/Makefile
>> 
>> Is the source of this error
>
> Well, that means it uncovered a pre-existing bug in the arm32 linker.
> I haven't tested arm32 myself in a long time.  I can take a look 
> later; I probably have some old arm32 debian chroot lying around
somewhere.

Oh, actually it wasn't a codegen bug at all.  I botched the testcase
invocation for NORUN tests, but that mattered only on arm where FILTER is
set to grep.  I've commited a fix for this to mob.


Ciao,
Michael.

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[Michael Matz]

Hi,

On Sat, 11 Feb 2017, Michael Matz wrote:

Your commit: 
http://repo.or.cz/tinycc.git/blobdiff/cd9514abc4f4d7d90acce108b98ea2af58a1b8 
0a..77d7ea04acb56f839031993c102366e30cad5c25:/tests/tests2/Makefile


Is the source of this error


Well, that means it uncovered a pre-existing bug in the arm32 linker.
I haven't tested arm32 myself in a long time.  I can take a look later; I 
probably have some old arm32 debian chroot lying around somewhere.


Oh, actually it wasn't a codegen bug at all.  I botched the testcase
invocation for NORUN tests, but that mattered only on arm where FILTER is 
set to grep.  I've commited a fix for this to mob.



Ciao,
Michael.

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[Michael Matz]

Hi

On Sat, 11 Feb 2017, Christian Jullien wrote:


Michael,

Your commit: 
http://repo.or.cz/tinycc.git/blobdiff/cd9514abc4f4d7d90acce108b98ea2af58a1b8 
0a..77d7ea04acb56f839031993c102366e30cad5c25:/tests/tests2/Makefile


Is the source of this error


Well, that means it uncovered a pre-existing bug in the arm32 linker.
I haven't tested arm32 myself in a long time.  I can take a look later; I 
probably have some old arm32 debian chroot lying around somewhere.



Ciao,
Michael.

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[grischka]

Christian Jullien wrote:

About test 42

Comparing by hand the 42_function_pointer output and 42_function_pointer
expect files I see no different


Are you sure? That could mean that there is a comatibility problem
with the bash shell or the make program on your ARM installs.


Investigating further, I see in tests2/Makefile

# And some tests don't test the right thing with -run
NORUN =
42_function_pointer.test : NORUN = true

If I comment this line, it makes happy the whole test suite on RPi.

I've to idea why someone added this trick which is used there:


This test was present previously, but modified by Michael to test a
feature of the tcc linker specifically in executable file output mode.

That is the point of the "-NORUN trick".

However obviously the test works as it should on i386 and x86_64
(on windows too).


%.test: %.c %.expect
@echo Test: $*...
# test -run
@if test -z "$(NORUN)"; then \
$(TCC) -run $< $(ARGS) $(FILTER) >$*.output 2>&1 || true; \
  else \
$(TCC) $< -o ./$*.exe $(FILTER) 2>&1 && \
./$*.exe $(ARGS) >$*.output 2>&1 || true; \
  fi
@diff -Nbu $(SRC)/$*.expect $*.output && rm -f $*.output $*.exe

Any clue?


I've no clue either.

I would try to remove any @, 2>&1, $(FILTER), and rm ... and then run

$ make -C tests/tests2 42_function_pointer.test

and see what happens...

--- grischka



-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Christian Jullien
Sent: samedi 11 février 2017 10:56
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Ready for Release 0.9.27

Thanks for your fix, now the only remaining issue on RPi is:

Test: 42_function_pointer...
--- ../../tests/tests2/42_function_pointer.expect   2017-02-11
10:52:22.626094358 +0100
+++ 42_function_pointer.output  1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-yo 24
-42
Makefile:54: recipe for target '42_function_pointer.test' failed

I'll try to investigate this one too...

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of grischka
Sent: samedi 11 février 2017 09:48
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Ready for Release 0.9.27

Christian Jullien wrote:

Hi Grischka,

The culprit commit is "2016-12-20 grischka tests: OOT build fixes etc."
Sorry Grischka :o)

This is the first commit after which " Segmentation fault' appears.

More specifically, the issue is with lib/Makefile, if I revert only 
this file, seg. Fault is gone.

Don't ask me why, but adding again:

PICFLAGS = -fPIC


Great, thanks.  I think it was just the former comment why -fPIC was needed
("for linking into shared libraries")  which was confusing.
After all neither is tcc generating PIC code for shared libraries nor do we
support building shared libraries on ARM at all.

Anyway, I fixed it.

Now, I suppose that all tests are OK.

Except maybe "42_function_pointer" on ARM64 and possibly ARM?

The question for still failing tests then would be:

Did they work originally and were broken later (and if so by which commit)
or did they never work on that platform.

Thanks,

--- grischka



...

XFLAGS = $(TGT) $(PICFLAGS)
ifeq "$(XCC)" "$(CC)"
 XFLAGS += $(CFLAGS)
endif

Is enough.

I'm not sure if PICFLAGS should be globally set or inside the ifeq

section.

I let you deicde.

Christian


-Original Message-
From: Tinycc-devel
[mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of grischka
Sent: vendredi 10 février 2017 09:11
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Ready for Release 0.9.27

Christian Jullien wrote:

Here is the complete log I get this morning with current mob and

especially ...

make[1]: *** [abitest] Segmentation fault
 test3 
../tcc -B.. -I../include -I.. -I..

-DCONFIG_TRIPLET="\"arm-linux-gnueabihf\"" ...

Segmentation fault

I think we first need to find the cause of these crashes on ARM with -run.
Can you investigate that, eventually ?

Thanks,

-- grischka


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists

Re: [Tinycc-devel] Ready for Release 0.9.27

[Christian Jullien]

Michael,

Your commit:
http://repo.or.cz/tinycc.git/blobdiff/cd9514abc4f4d7d90acce108b98ea2af58a1b8
0a..77d7ea04acb56f839031993c102366e30cad5c25:/tests/tests2/Makefile

Is the source of this error

Test: 42_function_pointer...
--- ../../tests/tests2/42_function_pointer.expect   2017-02-11
11:51:38.535657127 +0100
+++ 42_function_pointer.output  1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-yo 24
-42
Makefile:54: recipe for target '42_function_pointer.test' failed
make[2]: *** [42_function_pointer.test] Error 1

at least on RPi

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Christian Jullien
Sent: samedi 11 février 2017 11:40
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Ready for Release 0.9.27

About test 42

Comparing by hand the 42_function_pointer output and 42_function_pointer
expect files I see no different

Investigating further, I see in tests2/Makefile

# And some tests don't test the right thing with -run NORUN =
42_function_pointer.test : NORUN = true

If I comment this line, it makes happy the whole test suite on RPi.

I've to idea why someone added this trick which is used there:

%.test: %.c %.expect
@echo Test: $*...
# test -run
@if test -z "$(NORUN)"; then \
$(TCC) -run $< $(ARGS) $(FILTER) >$*.output 2>&1 || true; \
  else \
$(TCC) $< -o ./$*.exe $(FILTER) 2>&1 && \
./$*.exe $(ARGS) >$*.output 2>&1 || true; \
  fi
@diff -Nbu $(SRC)/$*.expect $*.output && rm -f $*.output $*.exe

Any clue?

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Christian Jullien
Sent: samedi 11 février 2017 10:56
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Ready for Release 0.9.27

Thanks for your fix, now the only remaining issue on RPi is:

Test: 42_function_pointer...
--- ../../tests/tests2/42_function_pointer.expect   2017-02-11
10:52:22.626094358 +0100
+++ 42_function_pointer.output  1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-yo 24
-42
Makefile:54: recipe for target '42_function_pointer.test' failed

I'll try to investigate this one too...

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of grischka
Sent: samedi 11 février 2017 09:48
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Ready for Release 0.9.27

Christian Jullien wrote:
> Hi Grischka,
> 
> The culprit commit is "2016-12-20 grischka tests: OOT build fixes etc."
> Sorry Grischka :o)
> 
> This is the first commit after which " Segmentation fault' appears.
> 
> More specifically, the issue is with lib/Makefile, if I revert only 
> this file, seg. Fault is gone.
> Don't ask me why, but adding again:
> 
> PICFLAGS = -fPIC

Great, thanks.  I think it was just the former comment why -fPIC was needed
("for linking into shared libraries")  which was confusing.
After all neither is tcc generating PIC code for shared libraries nor do we
support building shared libraries on ARM at all.

Anyway, I fixed it.

Now, I suppose that all tests are OK.

Except maybe "42_function_pointer" on ARM64 and possibly ARM?

The question for still failing tests then would be:

Did they work originally and were broken later (and if so by which commit)
or did they never work on that platform.

Thanks,

--- grischka


> 
> ...
> 
> XFLAGS = $(TGT) $(PICFLAGS)
> ifeq "$(XCC)" "$(CC)"
>  XFLAGS += $(CFLAGS)
> endif
> 
> Is enough.
> 
> I'm not sure if PICFLAGS should be globally set or inside the ifeq
section.
> I let you deicde.
> 
> Christian
> 
> 
> -Original Message-----
> From: Tinycc-devel
> [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
> On Behalf Of grischka
> Sent: vendredi 10 février 2017 09:11
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] Ready for Release 0.9.27
> 
> Christian Jullien wrote:
>> Here is the complete log I get this morning with current mob and
> especially ...
>> make[1]: *** [abitest] Segmentation fault
> 
>>  test3 
>> ../tcc -B.. -I../include -I.. -I..
> -DCONFIG_TRIPLET="\"arm-linux-gnueabihf\"" ...
>> Segmentation fault
> 
> I think we first need to find the cause of these crashes on ARM with -run.
> Can you investigate that, eventually ?
> 
> Thanks,
> 
> -- grischka
> 
> 
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> 
> 
> ___
> Tinycc-devel mailing list
> Tinycc

Re: [Tinycc-devel] Ready for Release 0.9.27

[Christian Jullien]

About test 42

Comparing by hand the 42_function_pointer output and 42_function_pointer
expect files I see no different

Investigating further, I see in tests2/Makefile

# And some tests don't test the right thing with -run
NORUN =
42_function_pointer.test : NORUN = true

If I comment this line, it makes happy the whole test suite on RPi.

I've to idea why someone added this trick which is used there:

%.test: %.c %.expect
@echo Test: $*...
# test -run
@if test -z "$(NORUN)"; then \
$(TCC) -run $< $(ARGS) $(FILTER) >$*.output 2>&1 || true; \
  else \
$(TCC) $< -o ./$*.exe $(FILTER) 2>&1 && \
./$*.exe $(ARGS) >$*.output 2>&1 || true; \
  fi
@diff -Nbu $(SRC)/$*.expect $*.output && rm -f $*.output $*.exe

Any clue?

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Christian Jullien
Sent: samedi 11 février 2017 10:56
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Ready for Release 0.9.27

Thanks for your fix, now the only remaining issue on RPi is:

Test: 42_function_pointer...
--- ../../tests/tests2/42_function_pointer.expect   2017-02-11
10:52:22.626094358 +0100
+++ 42_function_pointer.output  1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-yo 24
-42
Makefile:54: recipe for target '42_function_pointer.test' failed

I'll try to investigate this one too...

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of grischka
Sent: samedi 11 février 2017 09:48
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Ready for Release 0.9.27

Christian Jullien wrote:
> Hi Grischka,
> 
> The culprit commit is "2016-12-20 grischka tests: OOT build fixes etc."
> Sorry Grischka :o)
> 
> This is the first commit after which " Segmentation fault' appears.
> 
> More specifically, the issue is with lib/Makefile, if I revert only 
> this file, seg. Fault is gone.
> Don't ask me why, but adding again:
> 
> PICFLAGS = -fPIC

Great, thanks.  I think it was just the former comment why -fPIC was needed
("for linking into shared libraries")  which was confusing.
After all neither is tcc generating PIC code for shared libraries nor do we
support building shared libraries on ARM at all.

Anyway, I fixed it.

Now, I suppose that all tests are OK.

Except maybe "42_function_pointer" on ARM64 and possibly ARM?

The question for still failing tests then would be:

Did they work originally and were broken later (and if so by which commit)
or did they never work on that platform.

Thanks,

--- grischka


> 
> ...
> 
> XFLAGS = $(TGT) $(PICFLAGS)
> ifeq "$(XCC)" "$(CC)"
>  XFLAGS += $(CFLAGS)
> endif
> 
> Is enough.
> 
> I'm not sure if PICFLAGS should be globally set or inside the ifeq
section.
> I let you deicde.
> 
> Christian
> 
> 
> -Original Message-----
> From: Tinycc-devel
> [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
> On Behalf Of grischka
> Sent: vendredi 10 février 2017 09:11
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] Ready for Release 0.9.27
> 
> Christian Jullien wrote:
>> Here is the complete log I get this morning with current mob and
> especially ...
>> make[1]: *** [abitest] Segmentation fault
> 
>>  test3 
>> ../tcc -B.. -I../include -I.. -I..
> -DCONFIG_TRIPLET="\"arm-linux-gnueabihf\"" ...
>> Segmentation fault
> 
> I think we first need to find the cause of these crashes on ARM with -run.
> Can you investigate that, eventually ?
> 
> Thanks,
> 
> -- grischka
> 
> 
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> 
> 
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> 


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[Christian Jullien]

Thanks for your fix, now the only remaining issue on RPi is:

Test: 42_function_pointer...
--- ../../tests/tests2/42_function_pointer.expect   2017-02-11
10:52:22.626094358 +0100
+++ 42_function_pointer.output  1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-yo 24
-42
Makefile:54: recipe for target '42_function_pointer.test' failed

I'll try to investigate this one too...

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of grischka
Sent: samedi 11 février 2017 09:48
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Ready for Release 0.9.27

Christian Jullien wrote:
> Hi Grischka,
> 
> The culprit commit is "2016-12-20 grischka tests: OOT build fixes etc."
> Sorry Grischka :o)
> 
> This is the first commit after which " Segmentation fault' appears.
> 
> More specifically, the issue is with lib/Makefile, if I revert only 
> this file, seg. Fault is gone.
> Don't ask me why, but adding again:
> 
> PICFLAGS = -fPIC

Great, thanks.  I think it was just the former comment why -fPIC was needed
("for linking into shared libraries")  which was confusing.
After all neither is tcc generating PIC code for shared libraries nor do we
support building shared libraries on ARM at all.

Anyway, I fixed it.

Now, I suppose that all tests are OK.

Except maybe "42_function_pointer" on ARM64 and possibly ARM?

The question for still failing tests then would be:

Did they work originally and were broken later (and if so by which commit)
or did they never work on that platform.

Thanks,

--- grischka


> 
> ...
> 
> XFLAGS = $(TGT) $(PICFLAGS)
> ifeq "$(XCC)" "$(CC)"
>  XFLAGS += $(CFLAGS)
> endif
> 
> Is enough.
> 
> I'm not sure if PICFLAGS should be globally set or inside the ifeq
section.
> I let you deicde.
> 
> Christian
> 
> 
> -Original Message-
> From: Tinycc-devel 
> [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
> On Behalf Of grischka
> Sent: vendredi 10 février 2017 09:11
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] Ready for Release 0.9.27
> 
> Christian Jullien wrote:
>> Here is the complete log I get this morning with current mob and
> especially ...
>> make[1]: *** [abitest] Segmentation fault
> 
>>  test3 
>> ../tcc -B.. -I../include -I.. -I..
> -DCONFIG_TRIPLET="\"arm-linux-gnueabihf\"" ...
>> Segmentation fault
> 
> I think we first need to find the cause of these crashes on ARM with -run.
> Can you investigate that, eventually ?
> 
> Thanks,
> 
> -- grischka
> 
> 
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> 
> 
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> 


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[grischka]

Steffen Nurpmeso wrote:

Well, i still have this patch that allows multiple -rpath
arguments, that would be really cool to have in by default --


Ok, you had luck ;)
http://repo.or.cz/tinycc.git/commitdiff/ee5425fe952fdf02fdcdf94f440ee482b6be61ad

Because as I said I don't in general push other peoples' patches,
this one looks a bit different but it does the same thing.

--- grischka


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[grischka]

Christian Jullien wrote:

Hi Grischka,

The culprit commit is "2016-12-20 grischka tests: OOT build fixes etc."
Sorry Grischka :o)

This is the first commit after which " Segmentation fault' appears.

More specifically, the issue is with lib/Makefile, if I revert only this
file, seg. Fault is gone.
Don't ask me why, but adding again:

PICFLAGS = -fPIC


Great, thanks.  I think it was just the former comment why -fPIC was
needed ("for linking into shared libraries")  which was confusing.
After all neither is tcc generating PIC code for shared libraries
nor do we support building shared libraries on ARM at all.

Anyway, I fixed it.

Now, I suppose that all tests are OK.

Except maybe "42_function_pointer" on ARM64 and possibly ARM?

The question for still failing tests then would be:

Did they work originally and were broken later (and if so by
which commit)  or did they never work on that platform.

Thanks,

--- grischka




...

XFLAGS = $(TGT) $(PICFLAGS)
ifeq "$(XCC)" "$(CC)"
 XFLAGS += $(CFLAGS)
endif

Is enough.

I'm not sure if PICFLAGS should be globally set or inside the ifeq section.
I let you deicde.

Christian


-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of grischka
Sent: vendredi 10 février 2017 09:11
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Ready for Release 0.9.27

Christian Jullien wrote:

Here is the complete log I get this morning with current mob and

especially ...

make[1]: *** [abitest] Segmentation fault



 test3 
../tcc -B.. -I../include -I.. -I..

-DCONFIG_TRIPLET="\"arm-linux-gnueabihf\"" ...

Segmentation fault


I think we first need to find the cause of these crashes on ARM with -run.
Can you investigate that, eventually ?

Thanks,

-- grischka


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[Christian Jullien]

Hi Grischka,

The culprit commit is "2016-12-20 grischka tests: OOT build fixes etc."
Sorry Grischka :o)

This is the first commit after which " Segmentation fault' appears.

More specifically, the issue is with lib/Makefile, if I revert only this
file, seg. Fault is gone.
Don't ask me why, but adding again:

PICFLAGS = -fPIC

...

XFLAGS = $(TGT) $(PICFLAGS)
ifeq "$(XCC)" "$(CC)"
 XFLAGS += $(CFLAGS)
endif

Is enough.

I'm not sure if PICFLAGS should be globally set or inside the ifeq section.
I let you deicde.

Christian


-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of grischka
Sent: vendredi 10 février 2017 09:11
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Ready for Release 0.9.27

Christian Jullien wrote:
> Here is the complete log I get this morning with current mob and
especially ...
> make[1]: *** [abitest] Segmentation fault

>  test3 
> ../tcc -B.. -I../include -I.. -I..
-DCONFIG_TRIPLET="\"arm-linux-gnueabihf\"" ...
> Segmentation fault

I think we first need to find the cause of these crashes on ARM with -run.
Can you investigate that, eventually ?

Thanks,

-- grischka


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[Christian JULLIEN]

Grischka,

It would be a real pleasure to investiate that if I only have time.
The best I can do is to test and find commit that breaks tcc on RPi.

Christian

P.S. I'll try to find few hours this week-end, but not sure I can.


 Le:10 février 2017 à 09:11 (GMT +01:00)
De:"grischka" gris...@gmx.de
À:"tinycc-devel@nongnu.org" tinycc-devel@nongnu.org
Objet:Re: [Tinycc-devel] Ready for Release 0.9.27


Christian Jullien wrote:
 Here is the complete log I get this morning with current mob and 
especially ...
 make[1]: *** [abitest] Segmentation fault

  test3 
 ../tcc -B.. -I../include -I.. -I.. 
-DCONFIG_TRIPLET="\"arm-linux-gnueabihf\"" ...
 Segmentation fault

I think we first need to find the cause of these crashes on
ARM with -run.  Can you investigate that, eventually ?

Thanks,

-- grischka


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[grischka]

Christian Jullien wrote:

Here is the complete log I get this morning with current mob and especially ...
make[1]: *** [abitest] Segmentation fault



 test3 
../tcc -B.. -I../include -I.. -I.. -DCONFIG_TRIPLET="\"arm-linux-gnueabihf\"" 
...
Segmentation fault


I think we first need to find the cause of these crashes on
ARM with -run.  Can you investigate that, eventually ?

Thanks,

-- grischka


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[grischka]

Vincent Lefevre wrote:

Note that according to C99, a bit-field is a type ("unsigned int" here
is just a type specifier). Just like an array is not the same type of
the type of its elements. See 6.7.2.1p9 in C99:

  A bit-field is interpreted as a signed or unsigned integer type
  consisting of the specified number of bits.107) [...]

  107) As specified in 6.7.2 above, if the actual type specifier
   used is int or a typedef-name defined as int, then it is
   implementation-defined whether the bit-field is signed or
   unsigned.

When interpreting the standard, it is important to consider the
*whole* standard, not just individual sentences, which may be
ambiguous.


If that were true then all your citations wouldn't prove anything ;)


FYI, GCC 6 behaves in the same way with -std=c89, -std=c99 and -std=c11.
Ditto for Clang 3.9.


I wouldn't really mind if we change the behavior.

Basically tccgen.c contains 8 lines (in gen_op/expr_cond) similar to

 if ((t1 & (VT_BTYPE | VT_UNSIGNED)) == (VT_LLONG | VT_UNSIGNED) ...
 if ((t1 & (VT_BTYPE | VT_UNSIGNED)) == (VT_INT | VT_UNSIGNED) ...

Maybe we just need to change these like this
 if ((t1 & (VT_BTYPE | VT_UNSIGNED | VT_BITFIELD)) == 

Note that VT_BITFIELD set implies bit-field width < original type width.

--- grischka


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[Christian Jullien]

Segmentation fault
 tests2-dir 
make -k -C tests2
make[2]: Entering directory '/home/jullien/tinycc/tests/tests2'
Test: 00_assignment...
Test: 01_comment...
Test: 02_printf...
Test: 03_struct...
Test: 04_for...
Test: 05_array...
Test: 06_case...
Test: 07_function...
Test: 08_while...
Test: 09_do_while...
Test: 10_pointer...
Test: 11_precedence...
Test: 12_hashdefine...
Test: 13_integer_literals...
Test: 14_if...
Test: 15_recursion...
Test: 16_nesting...
Test: 17_enum...
Test: 18_include...
Test: 19_pointer_arithmetic...
Test: 20_pointer_comparison...
Test: 21_char_array...
Test: 22_floating_point...
Test: 23_type_coercion...
Test: 24_math_library...
Test: 25_quicksort...
Test: 26_character_constants...
Test: 27_sizeof...
Test: 28_strings...
Test: 29_array_address...
Test: 30_hanoi...
Test: 31_args...
Test: 32_led...
--- ../../tests/tests2/32_led.expect2017-02-10 06:54:31.118324525 +0100
+++ 32_led.output   2017-02-10 06:55:18.858179490 +0100
@@ -1,4 +1,4 @@
- _   _   _   _
-  |  _|  _| |_| |_  |_|
-  | |_   _|   |  _| |_|   |
+
+
+

Makefile:54: recipe for target '32_led.test' failed
make[2]: *** [32_led.test] Error 1
Test: 33_ternary_op...
Test: 35_sizeof...
Test: 36_array_initialisers...
Test: 37_sprintf...
Test: 38_multiple_array_index...
Test: 39_typedef...
Test: 40_stdio...
Test: 41_hashif...
Test: 42_function_pointer...
--- ../../tests/tests2/42_function_pointer.expect   2017-02-10 
06:54:31.118324525 +0100
+++ 42_function_pointer.output  1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-yo 24
-42
Makefile:54: recipe for target '42_function_pointer.test' failed
make[2]: *** [42_function_pointer.test] Error 1
Test: 43_void_param...
Test: 44_scoped_declarations...
Test: 45_empty_for...
Test: 46_grep...
Test: 47_switch_return...
Test: 48_nested_break...
Test: 49_bracket_evaluation...
Test: 50_logical_second_arg...
Test: 51_static...
Test: 52_unnamed_enum...
Test: 54_goto...
Test: 55_lshift_type...
Test: 56_btype_excess-1...
Test: 57_btype_excess-2...
Test: 58_function_redefinition...
Test: 59_function_array...
Test: 60_enum_redefinition...
Test: 61_undefined_enum...
Test: 62_enumerator_redefinition...
Test: 63_local_enumerator_redefinition...
Test: 64_macro_nesting...
Test: 67_macro_concat...
Test: 70_floating_point_literals...
Test: 71_macro_empty_arg...
Test: 72_long_long_constant...
Test: 73_arm64...
Test: 74_nocode_wanted...
Test: 75_array_in_struct_init...
Test: 76_dollars_in_identifiers...
Test: 77_push_pop_macro...
Test: 78_vla_label...
Test: 79_vla_continue...
Test: 80_flexarray...
Test: 81_types...
Test: 82_attribs_position...
Test: 82_nocode_wanted...
Test: 83_utf8_in_identifiers...
Test: 84-hex-float...
Test: 86-memory-model...
Test: 86-struct-init...
Test: 87_dead_code...
Test: 87_ptr_longlong_arith32...
Test: 88_codeopt...
make[2]: Target 'all' not remade because of errors.
make[2]: Leaving directory '/home/jullien/tinycc/tests/tests2'
Makefile:85: recipe for target 'tests2-dir' failed
make[1]: *** [tests2-dir] Error 2
 pp-dir 
make -k -C pp
make[2]: Entering directory '/home/jullien/tinycc/tests/pp'
PPTest 01 ...
PPTest 02 ...
PPTest 03 ...
PPTest 04 ...
PPTest 05 ...
PPTest 06 ...
PPTest 07 ...
PPTest 08 ...
PPTest 09 ...
PPTest 10 ...
PPTest 11 ...
PPTest 12 ...
PPTest 13 ...
PPTest 14 ...
PPTest 15 ...
PPTest 16 ...
PPTest 17 ...
make[2]: Leaving directory '/home/jullien/tinycc/tests/pp'
make[1]: Target 'all' not remade because of errors.
make[1]: Leaving directory '/home/jullien/tinycc/tests'
Makefile:307: recipe for target 'test' failed
make: *** [test] Error 2


From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Christian JULLIEN
Sent: jeudi 9 février 2017 09:11
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Ready for Release 0.9.27

Sure, I always do ./configure.

I've just made a new test from a brand new checkout and error is gone.
For ARM32/64 I always do a clean checkout, I have the impression that failing 
tests are new (and probably never tested before on RPi).
I'll try today or tomorrow to find the first commit that breaks tcc on RPi.

C.

Le : 09 février 2017 à 08:51 (GMT +01:00)
De : "grischka" <gris...@gmx.de>
À : "tinycc-devel@nongnu.org" <tinycc-devel@nongnu.org>
Objet : Re: [Tinycc-devel] Ready for Release 0.9.27


Christian Jullien wrote:
> *- Linux CentOS 6.x [KO]*
> ../tcc -B.. -I../include -I.. -I.. -DCONFIG_LDDIR="\"lib64\"" 
> -DTCC_TARGET_X86_64 ../tcc.c libtcc2 -lm -ldl -Wl,-rpath=. -o tcc2
> 
> libtcc2:0: error: unrecognized character \x7f

Strange, should be libtcc2.so Seems DLLEXT=.so was not set from
configure. Did you ./configure?

> *- Raspberry Pi 3 (ARM) [KO]*
> ret_int_test... Makefile:226: recipe for target 'abitest' failed
> make[1]: *** [abitest] Segmentation fault
> Makefile:54: recipe for target '32_led.test' failed
> Makefile:54: recipe for target 

Re: [Tinycc-devel] Ready for Release 0.9.27

[Vincent Lefevre]

On 2017-02-09 21:01:11 +, Thomas Preud'homme wrote:
> On jeudi 9 février 2017 18:40:13 GMT grischka wrote:
> > Vincent Lefevre wrote:
> > > The C standard says:
> > >   6.3.1.1 Boolean, characters, and integers
> > >   
> > >   [...]
> > >   
> > >   If an int can represent all values of the original type (as
> > >   restricted by the width, for a bit-field), the value is converted
> > >   to an int; otherwise, it is converted to an unsigned int. These are
> > >   called the integer promotions.58) All other types are unchanged by
> > >   the integer promotions.
> > > 
> > > In my example of my Debian bug report:
> > >   struct { unsigned int a:3; } s = { 1 };
> > >   
> > >   s.a - 2
> > > 
> > > The original type (a 3-bit unsigned bit-field) contains the values
> > > from 0 to 7. An int can represent all of them. Thus s.a is converted
> > > to an int, and s.a - 2 gives -1 (as an int).
> > > 
> > > But according to the test, tcc seems to regard s.a - 2 as
> > > (unsigned int) (-1), i.e. UINT_MAX. However, tcc behaves correctly
> > > on ((unsigned char) 1 - 2), giving -1.
> > > 
> > > Note that GCC 6.3.0, ICC 15.0.0 and Clang 3.9.1 are correct on this
> > > test.
> > 
> > But note that MSVC still behaves like tcc, and that such behavior

MSVC is a C++ compiler. The rules with old C++ standards might be
different (possibly not intentionally). It seems to be confirmed
by :

  For C++, other integral and enumeration types are allowed for
  bit-fields; it is explicit that bit-fields do not have special types
  ([class.bit], "The bit-field attribute is not part of the type of
  the class member.").

> > can be seen compliant to the standard too, at least before the rather
> > recent addition of the
> > 
> > ... (as restricted by the width, for a bit-field) ...
> > 
> > phrase, with the result that now basically every possible ':X' field-width
> > is supposed to define its own integral C type.
> 
> Indeed, this parenthesis is not prosent in C99. Without this it reads as if 
> the original type is the base type of the bitfield. Since tcc aims at C99 
> conformance I agree with grischka this is a "won't fix".

No, this is not really a change of the standard, but a clarification.
See: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_315.htm

  Last sentence of paragraph 2 of 6.3.1.1, add the words as restricted
  by the width, for a bit-field as follows:

If an int can represent all values of the original type (as
restricted by the width, for a bit-field), the type is converted
to an int;

This has been done for C11.

Note that according to C99, a bit-field is a type ("unsigned int" here
is just a type specifier). Just like an array is not the same type of
the type of its elements. See 6.7.2.1p9 in C99:

  A bit-field is interpreted as a signed or unsigned integer type
  consisting of the specified number of bits.107) [...]

  107) As specified in 6.7.2 above, if the actual type specifier
   used is int or a typedef-name defined as int, then it is
   implementation-defined whether the bit-field is signed or
   unsigned.

When interpreting the standard, it is important to consider the
*whole* standard, not just individual sentences, which may be
ambiguous.

FYI, GCC 6 behaves in the same way with -std=c89, -std=c99 and -std=c11.
Ditto for Clang 3.9.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[Daniel Glöckner]

On Thu, Feb 09, 2017 at 01:35:31PM +0100, Vincent Lefevre wrote:
>   If an int can represent all values of the original type (as
>   restricted by the width, for a bit-field), the value is converted
>   to an int; otherwise, it is converted to an unsigned int. These are
>   called the integer promotions.58) All other types are unchanged by
>   the integer promotions.

I've had a look at the code. We can easily change gv() to cast
unsigned bitfields < 32 bits to signed int, but there are lots of
places where the code just looks at the VT_UNSIGNED flag or the
VT_LLONG basic type and doesn't notice that VT_BITFIELD is set as
well (and the size is < 32 bits).

Best regards,

  Daniel

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[Thomas Preud'homme]

On jeudi 9 février 2017 18:40:13 GMT grischka wrote:
> Vincent Lefevre wrote:
> > The C standard says:
> >   6.3.1.1 Boolean, characters, and integers
> >   
> >   [...]
> >   
> >   If an int can represent all values of the original type (as
> >   restricted by the width, for a bit-field), the value is converted
> >   to an int; otherwise, it is converted to an unsigned int. These are
> >   called the integer promotions.58) All other types are unchanged by
> >   the integer promotions.
> > 
> > In my example of my Debian bug report:
> >   struct { unsigned int a:3; } s = { 1 };
> >   
> >   s.a - 2
> > 
> > The original type (a 3-bit unsigned bit-field) contains the values
> > from 0 to 7. An int can represent all of them. Thus s.a is converted
> > to an int, and s.a - 2 gives -1 (as an int).
> > 
> > But according to the test, tcc seems to regard s.a - 2 as
> > (unsigned int) (-1), i.e. UINT_MAX. However, tcc behaves correctly
> > on ((unsigned char) 1 - 2), giving -1.
> > 
> > Note that GCC 6.3.0, ICC 15.0.0 and Clang 3.9.1 are correct on this
> > test.
> 
> But note that MSVC still behaves like tcc, and that such behavior
> can be seen compliant to the standard too, at least before the rather
> recent addition of the
> 
> ... (as restricted by the width, for a bit-field) ...
> 
> phrase, with the result that now basically every possible ':X' field-width
> is supposed to define its own integral C type.

Indeed, this parenthesis is not prosent in C99. Without this it reads as if 
the original type is the base type of the bitfield. Since tcc aims at C99 
conformance I agree with grischka this is a "won't fix".

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[grischka]

Vincent Lefevre wrote:


The C standard says:

  6.3.1.1 Boolean, characters, and integers

  [...]

  If an int can represent all values of the original type (as
  restricted by the width, for a bit-field), the value is converted
  to an int; otherwise, it is converted to an unsigned int. These are
  called the integer promotions.58) All other types are unchanged by
  the integer promotions.

In my example of my Debian bug report:

  struct { unsigned int a:3; } s = { 1 };

  s.a - 2

The original type (a 3-bit unsigned bit-field) contains the values
from 0 to 7. An int can represent all of them. Thus s.a is converted
to an int, and s.a - 2 gives -1 (as an int).

But according to the test, tcc seems to regard s.a - 2 as
(unsigned int) (-1), i.e. UINT_MAX. However, tcc behaves correctly
on ((unsigned char) 1 - 2), giving -1.

Note that GCC 6.3.0, ICC 15.0.0 and Clang 3.9.1 are correct on this
test.


But note that MSVC still behaves like tcc, and that such behavior
can be seen compliant to the standard too, at least before the rather
recent addition of the

   ... (as restricted by the width, for a bit-field) ...

phrase, with the result that now basically every possible ':X' field-width
is supposed to define its own integral C type.

--- grischka

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[Vincent Lefevre]

Hi,

On 2017-02-08 23:09:05 +, Thomas Preud'homme wrote:
> On mercredi 8 février 2017 20:15:10 GMT grischka wrote:
> > Anyone else any patches that that 0.9.27 should still have?
> 
> I'd like to fix
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832759 (if it is
> indeed a bug, I haven't checked carefully) but don't wait for me.

The C standard says:

  6.3.1.1 Boolean, characters, and integers

  [...]

  If an int can represent all values of the original type (as
  restricted by the width, for a bit-field), the value is converted
  to an int; otherwise, it is converted to an unsigned int. These are
  called the integer promotions.58) All other types are unchanged by
  the integer promotions.

In my example of my Debian bug report:

  struct { unsigned int a:3; } s = { 1 };

  s.a - 2

The original type (a 3-bit unsigned bit-field) contains the values
from 0 to 7. An int can represent all of them. Thus s.a is converted
to an int, and s.a - 2 gives -1 (as an int).

But according to the test, tcc seems to regard s.a - 2 as
(unsigned int) (-1), i.e. UINT_MAX. However, tcc behaves correctly
on ((unsigned char) 1 - 2), giving -1.

Note that GCC 6.3.0, ICC 15.0.0 and Clang 3.9.1 are correct on this
test.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[Christian JULLIEN]

Sure, I always do ./configure.

I've just made a new test from a brand new checkout and error is gone.
For ARM32/64 I always do a clean checkout, I have the impression that failing 
tests are new (and probably never tested before on RPi).
I'll try today or tomorrow to find the first commit that breaks tcc on RPi.

C.



 Le:09 février 2017 à 08:51 (GMT +01:00)
De:"grischka" gris...@gmx.de
À:"tinycc-devel@nongnu.org" tinycc-devel@nongnu.org
Objet:Re: [Tinycc-devel] Ready for Release 0.9.27


Christian Jullien wrote:
 *- Linux CentOS 6.x [KO]*
 ../tcc -B.. -I../include -I.. -I.. -DCONFIG_LDDIR="\"lib64\"" 
 -DTCC_TARGET_X86_64 ../tcc.c libtcc2 -lm -ldl -Wl,-rpath=. -o tcc2
 
 libtcc2:0: error: unrecognized character \x7f

Strange, should be libtcc2.so  Seems DLLEXT=.so was not set from
configure. Did you ./configure?

 *- Raspberry Pi 3 (ARM) [KO]*
 ret_int_test... Makefile:226: recipe for target 'abitest' failed
 make[1]: *** [abitest] Segmentation fault
 Makefile:54: recipe for target '32_led.test' failed
 Makefile:54: recipe for target '42_function_pointer.test' failed

Are these regressions?  If so we would probably need to know by
which commit it was introduced (I'm afraid)

 *- APM X-Gene Mustang board (Aarch64) [KO]*
 
 make[2]: *** [42_function_pointer.test] Error 1

Not sure about this 42_function_pointer.test.  It's some new nifty
test for the linker.

Michael, is it supposed to work on ARM and/or AARCH64?

Thanks,

-- gr



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[grischka]

Christian Jullien wrote:

*- Linux CentOS 6.x [KO]*
../tcc -B.. -I../include -I.. -I.. -DCONFIG_LDDIR="\"lib64\"" 
-DTCC_TARGET_X86_64 ../tcc.c libtcc2 -lm -ldl -Wl,-rpath=. -o tcc2


libtcc2:0: error: unrecognized character \x7f


Strange, should be libtcc2.so  Seems DLLEXT=.so was not set from
configure. Did you ./configure?


*- Raspberry Pi 3 (ARM) [KO]*
ret_int_test... Makefile:226: recipe for target 'abitest' failed
make[1]: *** [abitest] Segmentation fault
Makefile:54: recipe for target '32_led.test' failed
Makefile:54: recipe for target '42_function_pointer.test' failed


Are these regressions?  If so we would probably need to know by
which commit it was introduced (I'm afraid)


*- APM X-Gene Mustang board (Aarch64) [KO]*

make[2]: *** [42_function_pointer.test] Error 1


Not sure about this 42_function_pointer.test.  It's some new nifty
test for the linker.

Michael, is it supposed to work on ARM and/or AARCH64?

Thanks,

-- gr



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[grischka]

avih wrote:
(I might be sending this exact same message again. Not sure if my first 
attempt got sent correctly)


grischka, why does commit 5efa75d9 revert commit 9b3e4c58 ? (using gcc 
instead of $(CC) at the tests).


This breaks self-hosting when gcc is not available. If gcc is available 
and used already, then $(CC) is gcc, so why hard-code gcc?


Because these are "developer only" targets.

You may set CC=tcc, but then we still do not want to compare the
output of tcc with the output of tcc, obviously.

Actually we do not want any of the expect files to be rebuild by
users and testers at all.

On the downside as a developer you need to delete the .expect file
manually if you want it to be rebuilt.

-- gr

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[Christian Jullien]

Great news,

 

Here is a quick test with mod on 5 systems (fails on Linux ARM/ARM64/x64 for
different reasons)

- Windows 32bit {OK] - only tested with my OpenLisp huge non-regression test

- Windows 64bit [OK] - only tested with my OpenLisp huge non-regression test

- Linux CentOS 6.x [KO]

 dlltest 

../tcc -B.. -I../include -I.. -I.. -DONE_SOURCE -DCONFIG_LDDIR="\"lib64\""
-DTCC_TARGET_X86_64 -DLIBTCC_AS_DLL ../libtcc.c -lm -ldl -shared -o libtcc2

../tcc -B.. -I../include -I.. -I.. -DCONFIG_LDDIR="\"lib64\""
-DTCC_TARGET_X86_64 ../tcc.c libtcc2 -lm -ldl -Wl,-rpath=. -o tcc2

libtcc2:0: error: unrecognized character \x7f

make[1]: *** [dlltest] Error 1

 

- Raspberry Pi 3 (ARM) [KO]

...

./abitest-tcc -B.. -I../include -I.. -I..

ret_int_test... Makefile:226: recipe for target 'abitest' failed

make[1]: *** [abitest] Segmentation fault

 

--- ../../tests/tests2/32_led.expect2017-02-09 06:12:23.920041867 +0100

+++ 32_led.output   2017-02-09 06:13:11.539883594 +0100

@@ -1,4 +1,4 @@

- _   _   _   _

-  |  _|  _| |_| |_  |_|

-  | |_   _|   |  _| |_|   |

+

+

+

 

...

Makefile:54: recipe for target '32_led.test' failed

Test: 42_function_pointer...

--- ../../tests/tests2/42_function_pointer.expect   2017-02-09
06:12:23.9300
41833 +0100

+++ 42_function_pointer.output  1970-01-01 01:00:00.0 +0100

@@ -1,2 +0,0 @@

-yo 24

-42

Makefile:54: recipe for target '42_function_pointer.test' failed

 

...

Test: 88_codeopt...

make[2]: Target 'all' not remade because of errors.

make[2]: Leaving directory '/home/jullien/tinycc/tests/tests2'

Makefile:85: recipe for target 'tests2-dir' failed

make[1]: *** [tests2-dir] Error 2

 

- APM X-Gene Mustang board (Aarch64) [KO]

Test: 42_function_pointer...

--- ../../tests/tests2/42_function_pointer.expect   2016-10-13
21:48:59.8278

35999 -0700

+++ 42_function_pointer.output  1969-12-31 16:00:00.0 -0800

@@ -1,2 +0,0 @@

-yo 24

-42

make[2]: *** [42_function_pointer.test] Error 1

 

 

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of grischka
Sent: mercredi 8 février 2017 20:15
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Ready for Release 0.9.27

 

Hi all,

 

I pushed some last patches that I found and updated the version

number:  
http://repo.or.cz/w/tinycc.git?a=shortlog;h=refs/heads/mob

 

So, as far as I'm concerned it would be ready for release.

Anyone else any patches that that 0.9.27 should still have?

 

Everyone else, please test.

 

--- grischka

 

 

___

Tinycc-devel mailing list

  Tinycc-devel@nongnu.org

 
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[Thomas Preud'homme]

On mercredi 8 février 2017 20:15:10 GMT grischka wrote:
> Hi all,

Hi,

> 
> I pushed some last patches that I found and updated the version
> number: http://repo.or.cz/w/tinycc.git?a=shortlog;h=refs/heads/mob
> 
> So, as far as I'm concerned it would be ready for release.

Yay!

> Anyone else any patches that that 0.9.27 should still have?

I'd like to fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832759 (if it 
is indeed a bug, I haven't checked carefully) but don't wait for me.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[Steffen Nurpmeso]

Hello.

grischka  wrote:
 |Hi all,
 |
 |I pushed some last patches that I found and updated the version
 |number: http://repo.or.cz/w/tinycc.git?a=shortlog;h=refs/heads/mob
 |
 |So, as far as I'm concerned it would be ready for release.
 |Anyone else any patches that that 0.9.27 should still have?

Well, i still have this patch that allows multiple -rpath
arguments, that would be really cool to have in by default --
after massive and repeated hints hints from Michael Matz this is
clean, right?  I mean, i would commit it myself, but note i have
red eyes and at times start to drivel.  It is extremely unlikely
that i would be of any but (let me say) further testing use beside
that, especially since i have to deal with C++ in the not too
distant future...

And then the patch which avoids segmentation faults when compiling
a small unready C source still applies cleanly, i.e., that
"section_ptr_add(s, 8);" in relocate_section().  I've updated from
71c5ce5..5efa75d.   Hm.  But i cannot reproduce the crash no more,
even without that patch!  On x86_64.  Cool!!

 |Everyone else, please test.

Looks good for what i have.
Thank you!

--steffen

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

[grischka]

avih wrote:

It's not really clear to me why you keep removing windows headers. Now, and 
also the previous time few months ago when you removed a lot of network related 
headers.
I know for a fact that some things which use network and built cleanly with 
stock tcc stopped building few months ago due to this, and now probably more 
things would not build.
It was at the repo anyway, it worked, deleting them doesn't make the repo 
smaller since it's at the history anyway, so why make life harder for users who 
want to use tcc without external mingw headers which possibly require 
modifications, which I presume the ones you removed already have this effort 
put into them?


IMO it is not a reasonable goal for tinycc to "maintain" windows
headers in the sense of completeness or patching the files.  If
anything they should be replaced by newer versions taken directly
from mingw or mingw-w64, preferably unchanged.

If wanted a more complete or newer set could be put as a separate
pack on the savannah download folder provided that someone puts one
together.

Other than that we have the standard ansi headers, and in addition
from the windows headers what is necessary to compile the hello_win
example.  It's just that I like that criterion because it is well
defined.

Regards,

--- grischka


On Wednesday, February 8, 2017 9:15 PM, grischka  wrote:
 


 Hi all,

I pushed some last patches that I found and updated the version
number: http://repo.or.cz/w/tinycc.git?a=shortlog;h=refs/heads/mob

So, as far as I'm concerned it would be ready for release.
Anyone else any patches that that 0.9.27 should still have?

Everyone else, please test.

--- grischka


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel