On Wed, Apr 29, 2015 at 08:15:35AM +0300, Sergey Korshunoff wrote:
> > both GCC and CLang (the two major, FLOSS C++ compilers) will be written in
> > C++ soon
> It's a time of the cfront 3.0 reanimation :-)
Too bad, one would have to rewrite it from scratch, I guess this would be
more doable than
> both GCC and CLang (the two major, FLOSS C++ compilers) will be written in
> C++ soon
It's a time of the cfront 3.0 reanimation :-)
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> handle alloca like VLA regarding SP save/restore
method 1: perform a call to the val_sp_save() analog from the alloca()
method 2: define a built function alloca, which replace a call to the
alloca with the VLAdeclaration. Is alloca*.S needed in such case?
___
About gcc, clang, VLA and alloca:
https://llvm.org/bugs/show_bug.cgi?id=16099
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> In particular, I don't know precisely what the rules are for combining
> alloca() and VLAs. I don't think you're allowed to do so in the same
> scope, but I'm not at all confident our code works if we do both in
> the same function
A Google responce when I trying to find a test suit for "VLA+all
Hi, Pilip!
> There's a patch to do that attached, feel free to
> test and commit it if you like. (It passes all the tests, at least
--- 78_vla_label.expect 2015-04-28 08:43:32.0 +0300
+++ 78_vla_label.output 2015-04-29 06:40:26.0 +0300
@@ -1,2 +1,3 @@
+78_vla_label.c:22: warning: i
On 04/10/2015 01:15 AM, Rob Landley wrote:
> On Thu, Apr 9, 2015 at 1:44 PM, Sergey Korshunoff wrote:
>> Hi!
>> Only now I found an interesting proposal by Rob Landley:
>> http://elinux.org/CELF_Project_Proposal/Combine_tcg_with_tcc
>>
>> Is there any work done in such direction?
>
> Yes, somebod
I think you misunderstood OP's point.
There is this issue: both GCC and CLang (the two major, FLOSS C++
compilers) will be written in C++ soon. CLang was already C++, and GCC
is in the process of being ported to C++11. So, effectively, newer
revisions of C++ will only be built by compilers writ
Hello,
> Some critical "user level" applications are written
>
in the latest c++ dialect, and this dialect will soon be compilable only
with
>
c++ written c++ compiler, hence shutting down for good any C compiler.
I think you've been hyped into thinking that only C++ can compile
C++. This
Hi,
Since version 4.8, gcc is now c++. clang is c++. Furthermore, the c++
standardization body is going bersek in complexity (c++11->c++14...).
I'm worried about compiling an "everyday use" c++ compiler from a C compiler on
on a medium term timeframe. Some critical "user level" applications are w
On Tue, Apr 28, 2015 at 8:53 AM, Sergey Korshunoff wrote:
> I removed all calls to vla_sp_save() keeping these only in
> decl_initializer(). All tests passed.
That's not saying very much—we don't have good test coverage for VLAs.
I think we can get away with simplifying the code a lot, but I'd
ra
Hi!
I removed all calls to vla_sp_save() keeping these only in
decl_initializer(). All tests passed.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Hello,
thanks for your answers.
turns out it was fully my fault ; for an unknown reason I cloned the repo
up to 1cbb4d3 and tried to compile that.
taking the lastest repo proved to be more helpfull, and compilation worked
like a charm. Now I need to work on install :)
Best regards, and thanks f
Hi!
> Here's the fixed patch and a test case.
Yes, this version is good enough and can be pushed (I think). Nice.
> it would be great if we wouldn't end
> up storing each VLA pointer twice
This can be done later.
> I think we should be able to get away with simply setting
> *vla_sp_loc to c in
Oh, I see. You're right, that's another bug in the old code, but easy
enough to fix. Here's the fixed patch and a test case.
If you want to optimize things, it would be great if we wouldn't end
up storing each VLA pointer twice—having it on the stack once should
be enough. I think we should be abl
15 matches
Mail list logo
