Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #94083 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2016-09-26 14:31 +0100 |
| Last post | 2016-10-15 13:46 -0700 |
| Articles | 20 on this page of 154 — 22 participants |
Back to article view | Back to comp.lang.c
Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 14:31 +0100
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-26 15:45 +0200
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 15:22 +0100
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-26 16:31 +0200
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-27 15:05 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-28 00:42 +0100
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 09:50 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-28 18:39 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 12:28 +0100
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-07 04:36 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 05:31 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 14:00 +0100
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 07:48 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 17:36 +0100
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 10:38 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 19:47 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 12:25 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 12:26 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 13:10 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 13:22 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 14:13 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 01:15 +0100
Re: Why I use gcc James Harris <james.harris.1@gmail.com> - 2016-10-08 10:42 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 11:36 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 14:25 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 15:05 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 16:29 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 17:21 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 16:39 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 16:58 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 21:15 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-10-08 11:27 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 20:09 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 21:16 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 21:28 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 01:19 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 01:36 +0100
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-08 09:32 -0700
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-09 03:44 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 12:07 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 12:12 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 12:37 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 13:57 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 14:32 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 20:00 +0100
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-09 13:14 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 22:54 +0100
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-15 14:40 -0700
Re: Why I use gcc James Kuyper <jameskuyper@verizon.net> - 2016-10-07 10:37 -0400
Re: Why I use gcc supercat@casperkitty.com - 2016-10-07 07:52 -0700
Re: Why I use gcc jameskuyper@verizon.net - 2016-10-07 09:10 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-10-07 10:48 -0700
Re: Why I use gcc jameskuyper@verizon.net - 2016-10-07 16:21 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-10-08 11:15 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 17:12 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 12:20 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 12:32 -0700
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 14:45 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 15:12 +0100
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 15:26 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-09-26 08:00 -0700
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 10:49 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 17:30 +0100
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-26 21:12 +0200
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-26 22:09 +0200
Re: Why I use gcc supercat@casperkitty.com - 2016-09-26 13:32 -0700
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-26 23:14 +0200
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 22:47 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 01:13 +0100
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-27 01:18 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-26 17:41 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 02:01 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-27 08:41 -0700
Re: Why I use gcc James Harris <james.harris.1@gmail.com> - 2016-09-27 01:41 +0100
Re: Why I use gcc jameskuyper@verizon.net - 2016-09-26 18:15 -0700
Re: Why I use gcc Gareth Owen <gwowen@gmail.com> - 2016-09-27 20:59 +0100
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-27 21:50 +0100
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 06:26 -0700
Re: Why I use gcc gazelle@shell.xmission.com (Kenny McCormack) - 2016-09-27 23:23 +0000
Re: Why I use gcc Noob <root@127.0.0.1> - 2016-10-08 00:12 +0200
Re: Why I use gcc James Kuyper <jameskuyper@verizon.net> - 2016-10-07 23:11 -0400
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 10:58 +0100
Re: Why I use gcc jameskuyper@verizon.net - 2016-10-08 07:07 -0700
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-07 21:44 -0700
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-27 09:48 +0200
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 11:22 +0100
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-27 13:52 +0200
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-27 14:47 +0200
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-27 15:18 +0200
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 14:38 +0100
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-27 17:21 +0200
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-27 17:17 +0200
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-27 08:52 -0700
Re: Why I use gcc Robert Wessel <robertwessel2@yahoo.com> - 2016-09-30 02:00 -0500
Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 07:18 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-27 08:46 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 09:11 -0700
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 13:33 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 14:13 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 15:30 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 08:29 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 07:11 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 21:43 +0100
Re: Why I use gcc raltbos@xs4all.nl (Richard Bos) - 2016-09-30 17:50 +0000
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 01:04 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-26 17:39 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 01:49 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 11:39 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 11:56 +0100
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-27 15:15 -0700
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-28 08:55 +0200
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-26 22:11 +0200
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 22:04 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-10 11:39 +0100
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-10 07:32 -0700
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-10-10 16:17 +0100
Re: Why I use gcc Robert Wessel <robertwessel2@yahoo.com> - 2016-10-10 21:09 -0500
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-10-11 04:18 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 10:56 +0100
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-11 04:08 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 13:36 +0100
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-11 06:20 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 14:29 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-11 09:31 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 19:38 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-10-11 12:23 -0700
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-10-11 23:19 +0200
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 23:26 +0100
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-10-12 09:01 +0200
Re: Why I use gcc supercat@casperkitty.com - 2016-10-12 08:55 -0700
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-12 10:52 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-10-12 12:34 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-12 13:18 -0700
Re: Why I use gcc luser droog <luser.droog@gmail.com> - 2016-10-12 13:24 -0700
Re: Why I use gcc crankypuss <undisclosedUserid@gmail.com> - 2016-10-13 13:31 -0600
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-16 03:00 -0700
Re: Why I use gcc crankypuss <undisclosedUserid@gmail.com> - 2016-10-16 04:46 -0600
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-16 04:05 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-11 12:28 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-11 13:24 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 21:28 +0100
Re: Why I use gcc gazelle@shell.xmission.com (Kenny McCormack) - 2016-10-11 20:43 +0000
Re: Why I use gcc Robert Wessel <robertwessel2@yahoo.com> - 2016-10-11 23:40 -0500
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-11 04:40 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-10 18:19 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-10 09:08 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-10 18:04 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-10-10 10:39 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-10 11:25 -0700
Re: Why I use gcc Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-10 17:05 -0400
Re: Why I use gcc supercat@casperkitty.com - 2016-10-10 14:46 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-15 13:39 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-15 13:40 -0700
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-15 13:46 -0700
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-27 08:29 -0700 |
| Message-ID | <20210839-710e-4647-81da-1f8241c7dfbf@googlegroups.com> |
| In reply to | #94143 |
On Tuesday, September 27, 2016 at 9:30:32 AM UTC-5, Ben Bacarisse wrote: > But if there are already different opinions about what kind of thing > these modifiers are and therefore where they should go (I am just taking > your word that that is the case) then there will be some objections to > standardising it. > > However, since extensions are always going to be permitted under the > blanket of UB, I wonder if any of the implementations would change where > something like this standardised. It's probably easier to ask the > offending implementations to change, or at least to accept the > alternative syntax. If the Standard were to specify that a certain syntax should be supported when practical, preferably one which will not have a *contrary* meaning on any implementation, and for which most existing implementations could add support via macro definitions, then implementations could continue to support code using their existing syntax while programmers migrated to using the new syntax. IMHO, rather than imposing a "no new features" rule, a much more useful stance for the next Committee would be that new features should be designed so that code can use them while remaining compatible with old compilers through the aid of compatibility headers. Waiting until features are implemented before standardizing them almost guarantees the existence of divergent implementations.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-27 07:11 -0700 |
| Message-ID | <35d4478c-fba3-4ef5-9a87-e0db86bfef23@googlegroups.com> |
| In reply to | #94124 |
On Tuesday, September 27, 2016 at 2:48:46 AM UTC-5, David Brown wrote: > On 26/09/16 22:32, supercat wrote: > > Should compiler writers not give programmers the opportunity to improve the > > efficiency of their code by letting them tell the compiler which calling > > conventions to use in different cases? > > > > No, that's fair enough (though it is better if the toolchain can figure > out the more efficient calling conventions itself). If a library will be used by dozens or hundreds of different programs, there's no way the compiler can know whether a calling convention which adds 6 bytes of code to a called function but saves two bytes at each call site will be more or less efficient than the alternative which is more expensive to call. Further, even if the compiler examined all of the client code and picked the optimal convention for the library, that would mean that changing one piece of client code (so that on balance the other calling convention would have been cheaper) would require recompiling every piece of client code that calls that function. Not very practical. Being able to have the header designate a calling convention seems much more practical. > The problem here is that you have a single OS on a single hardware > platform, with application level code - and you /still/ have a dozen > different calling conventions to deal with, with each compiler having > different details in how these are specified. There is no reason (besides perhaps politics) why the Standard could not provide useful advisory guidance about how such things should be handled. If one were to include within the language advisory guidance about every feature that would be relevant on 10% or more of implementations, the total size of the document would be *at most* 10x the size of one describing the features that would be relevant to average implementation. If the material were placed in various annexes, it would not impede use of the Standard by those who aren't interested in such details.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-26 21:43 +0100 |
| Message-ID | <nsc1a2$ot3$1@dont-email.me> |
| In reply to | #94099 |
On 26/09/2016 20:12, David Brown wrote: > On 26/09/16 18:30, BartC wrote: > I can think of several possible ways to handle the situation: > > 1. Complain to Microsoft, and insist that they define a single sensible, > consistent ABI to be used on Windows. Make sure that all compilers for > Windows use that ABI and calling convention, and that they use it by > default so that you don't need implementation-specific extensions to > call libraries. Make sure that everyone who makes libraries and DLL's > for Windows follows those rules. > > 2. Use macros to wrap the implementation-dependent parts as neatly as > possible, in a way that should cause no challenges to machine-generated > C code. > > 3. Moan about it in newsgroups to people who have nothing to do with the > problem, and are content to use macro workarounds if they were in the > same situation. > > 4. Throw your hands up in the air in despair, because you can only > support one compiler for your tools, and you always have trouble > installing that tool. > > 5. Re-invent autotools with a Windows version. > > > Personally, I'd go for solution number 2. It should take less time than > writing the posts in this thread. I normally generate x64 directly and don't have any such problems (and I've used x86-16 and x86-32 with similar approaches for over 30 years). The problems come when I use C (that standardised, ubiquitous language with compilers for every conceivable platform) as an intermediate language. You'd think it would make things much simpler! I've already done a huge amount of work in the past in getting six C compilers to compile my code, but that was done on OS-neutral projects just so I could get something working for comparison purposes. Real programs though do need this stdcall stuff, or some compilers do and some don't, but my C code generator prefers to target one version of C not half a dozen. Stipulating gcc only is very tempting. But so is the idea of not having to stipulate any particular compiler, even though most open source C probably does have a gcc dependency. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-09-30 17:50 +0000 |
| Message-ID | <57eea5e4.2629656@news.xs4all.nl> |
| In reply to | #94099 |
David Brown <david.brown@hesbynett.no> wrote: > The root of the problem is not the compilers or the C standards - it is > MS and Windows, which is a jumbled and inconsistent mess of interfaces > and calling conventions, and which never had a proper defined ABI that > everyone could stick to. It has one _massive_ advantage, though. It doesn't come with Linux Weenies. Richard
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-27 01:04 +0100 |
| Message-ID | <nscd2e$d3$1@dont-email.me> |
| In reply to | #94093 |
On 26/09/2016 17:30, BartC wrote: > Apparently the solution, according to David Brown, is not to fix the > various compilers but to introduce lots of conditional macros enumerated > by target compiler. If anyone wants to go this route for any purpose then these appear to be the macros defined by the half-dozen compilers I use: #if defined __LCC__ #error "THIS IS LCC" #elif defined __POCC__ #error "THIS IS PELLES C" #elif defined __DMC__ #error "THIS IS DMC" #elif defined __GNUC__ #error "THIS IS GCC" #elif defined __TINYC__ #error "THIS IS TCC" #elif defined __clang__ #error "THIS IS CLANG" #endif I think I will have to use one or two of these to force compiler-specific code where I can't find an alternative common code sequence that works across all compilers. (Meanwhile I may use the above anyway just to provide useful runtime information. Although not by aborting the compilation; that's just a test.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-26 17:39 -0700 |
| Message-ID | <lnintitbuw.fsf@kst-u.example.com> |
| In reply to | #94111 |
BartC <bc@freeuk.com> writes:
> On 26/09/2016 17:30, BartC wrote:
>> Apparently the solution, according to David Brown, is not to fix the
>> various compilers but to introduce lots of conditional macros enumerated
>> by target compiler.
>
> If anyone wants to go this route for any purpose then these appear to be
> the macros defined by the half-dozen compilers I use:
>
> #if defined __LCC__
> #error "THIS IS LCC"
>
> #elif defined __POCC__
> #error "THIS IS PELLES C"
>
> #elif defined __DMC__
> #error "THIS IS DMC"
>
> #elif defined __GNUC__
> #error "THIS IS GCC"
>
> #elif defined __TINYC__
> #error "THIS IS TCC"
>
> #elif defined __clang__
> #error "THIS IS CLANG"
>
> #endif
Clang defines both __clang__ and __GNUC__ (presumably because it
endeavors to be gcc-compatible), so you should test __clang__ first.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-27 01:49 +0100 |
| Message-ID | <nscfll$6pb$1@dont-email.me> |
| In reply to | #94115 |
On 27/09/2016 01:39, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 26/09/2016 17:30, BartC wrote: >>> Apparently the solution, according to David Brown, is not to fix the >>> various compilers but to introduce lots of conditional macros enumerated >>> by target compiler. >> >> If anyone wants to go this route for any purpose then these appear to be >> the macros defined by the half-dozen compilers I use: >> >> #if defined __LCC__ >> #error "THIS IS LCC" >> >> #elif defined __POCC__ >> #error "THIS IS PELLES C" >> >> #elif defined __DMC__ >> #error "THIS IS DMC" >> >> #elif defined __GNUC__ >> #error "THIS IS GCC" >> >> #elif defined __TINYC__ >> #error "THIS IS TCC" >> >> #elif defined __clang__ >> #error "THIS IS CLANG" >> >> #endif > > Clang defines both __clang__ and __GNUC__ (presumably because it > endeavors to be gcc-compatible), so you should test __clang__ first. When I compile the above with clang, I get the CLANG message not the gcc one. (But I do use __GNUC__ in connection with callback attributes that gcc needs; maybe they are needed for clang as well. I'll check that when I next get clang fully working.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-09-27 11:39 +0100 |
| Message-ID | <87eg45d3tu.fsf@bsb.me.uk> |
| In reply to | #94118 |
BartC <bc@freeuk.com> writes: > On 27/09/2016 01:39, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: >>> On 26/09/2016 17:30, BartC wrote: >>>> Apparently the solution, according to David Brown, is not to fix the >>>> various compilers but to introduce lots of conditional macros enumerated >>>> by target compiler. >>> >>> If anyone wants to go this route for any purpose then these appear to be >>> the macros defined by the half-dozen compilers I use: >>> >>> #if defined __LCC__ >>> #error "THIS IS LCC" >>> >>> #elif defined __POCC__ >>> #error "THIS IS PELLES C" >>> >>> #elif defined __DMC__ >>> #error "THIS IS DMC" >>> >>> #elif defined __GNUC__ >>> #error "THIS IS GCC" >>> >>> #elif defined __TINYC__ >>> #error "THIS IS TCC" >>> >>> #elif defined __clang__ >>> #error "THIS IS CLANG" >>> >>> #endif >> >> Clang defines both __clang__ and __GNUC__ (presumably because it >> endeavors to be gcc-compatible), so you should test __clang__ first. > > When I compile the above with clang, I get the CLANG message not the > gcc one. I get (as expected) the GCC message, but then I think there is something odd about your clang installation. I think you reported trouble installing it. Or maybe it's a clang under Windows thing. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-27 11:56 +0100 |
| Message-ID | <nsdj9f$soi$1@dont-email.me> |
| In reply to | #94127 |
On 27/09/2016 11:39, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> On 27/09/2016 01:39, Keith Thompson wrote: >>> BartC <bc@freeuk.com> writes: >>>> #elif defined __GNUC__ >>>> #error "THIS IS GCC" >>>> >>>> #elif defined __TINYC__ >>>> #error "THIS IS TCC" >>>> >>>> #elif defined __clang__ >>>> #error "THIS IS CLANG" >>>> >>>> #endif >>> >>> Clang defines both __clang__ and __GNUC__ (presumably because it >>> endeavors to be gcc-compatible), so you should test __clang__ first. >> >> When I compile the above with clang, I get the CLANG message not the >> gcc one. > > I get (as expected) the GCC message, but then I think there is something > odd about your clang installation. I think you reported trouble > installing it. Or maybe it's a clang under Windows thing. I get "GCC" when compiling the code on Linux with clang. I get "CLANG" on Windows with clang. But the new clang for Windows seems to be designed to work with MSVC, so it might be odd if it set __GNUC__! (I have told it to use gcc include files, but __GNUC__ must be set elsewhere.) So perhaps the clang test does need to be done before the gcc test, if I'm going to use an exclusive set of tests like the above. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-27 15:15 -0700 |
| Message-ID | <kfnbmz9c7lt.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #94128 |
BartC <bc@freeuk.com> writes:
> On 27/09/2016 11:39, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>> On 27/09/2016 01:39, Keith Thompson wrote:
>>>> BartC <bc@freeuk.com> writes:
>>>>
>>>>> #elif defined __GNUC__
>>>>> #error "THIS IS GCC"
>>>>>
>>>>> #elif defined __TINYC__
>>>>> #error "THIS IS TCC"
>>>>>
>>>>> #elif defined __clang__
>>>>> #error "THIS IS CLANG"
>>>>>
>>>>> #endif
>>>>
>>>> Clang defines both __clang__ and __GNUC__ (presumably because it
>>>> endeavors to be gcc-compatible), so you should test __clang__ first.
>>>
>>> When I compile the above with clang, I get the CLANG message not the
>>> gcc one.
>>
>> I get (as expected) the GCC message, but then I think there is something
>> odd about your clang installation. I think you reported trouble
>> installing it. Or maybe it's a clang under Windows thing.
>
> I get "GCC" when compiling the code on Linux with clang.
>
> I get "CLANG" on Windows with clang.
>
> But the new clang for Windows seems to be designed to work with MSVC,
> so it might be odd if it set __GNUC__! (I have told it to use gcc
> include files, but __GNUC__ must be set elsewhere.)
>
> So perhaps the clang test does need to be done before the gcc test, if
> I'm going to use an exclusive set of tests like the above.
It might be a good idea to start off cascades like this with a
sanity check, eg,
#if 0 \
+ defined __LCC__ \
+ defined __POCC__ \
+ defined __DMC__ \
+ defined __GNUC__ \
+ defined __TINYC__ \
+ defined __clang__ \
> 1
/* .. special case handling here .. */
#elif ...
to be sure the environment isn't pathological in some way
(especially one that was not anticipated).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-28 08:55 +0200 |
| Message-ID | <nsfph8$leb$2@dont-email.me> |
| In reply to | #94174 |
On 28/09/16 00:15, Tim Rentsch wrote: > BartC <bc@freeuk.com> writes: > >> On 27/09/2016 11:39, Ben Bacarisse wrote: >>> BartC <bc@freeuk.com> writes: >>>> On 27/09/2016 01:39, Keith Thompson wrote: >>>>> BartC <bc@freeuk.com> writes: >>>>> >>>>>> #elif defined __GNUC__ >>>>>> #error "THIS IS GCC" >>>>>> >>>>>> #elif defined __TINYC__ >>>>>> #error "THIS IS TCC" >>>>>> >>>>>> #elif defined __clang__ >>>>>> #error "THIS IS CLANG" >>>>>> >>>>>> #endif >>>>> >>>>> Clang defines both __clang__ and __GNUC__ (presumably because it >>>>> endeavors to be gcc-compatible), so you should test __clang__ first. >>>> >>>> When I compile the above with clang, I get the CLANG message not the >>>> gcc one. >>> >>> I get (as expected) the GCC message, but then I think there is something >>> odd about your clang installation. I think you reported trouble >>> installing it. Or maybe it's a clang under Windows thing. >> >> I get "GCC" when compiling the code on Linux with clang. >> >> I get "CLANG" on Windows with clang. >> >> But the new clang for Windows seems to be designed to work with MSVC, >> so it might be odd if it set __GNUC__! (I have told it to use gcc >> include files, but __GNUC__ must be set elsewhere.) >> >> So perhaps the clang test does need to be done before the gcc test, if >> I'm going to use an exclusive set of tests like the above. > > It might be a good idea to start off cascades like this with a > sanity check, eg, > > #if 0 \ > + defined __LCC__ \ > + defined __POCC__ \ > + defined __DMC__ \ > + defined __GNUC__ \ > + defined __TINYC__ \ > + defined __clang__ \ > > 1 > > /* .. special case handling here .. */ > > #elif ... > > to be sure the environment isn't pathological in some way > (especially one that was not anticipated). > Has that any advantages over: #if defined __LCC__ // Macros for LCC #elif defined __POCC__ // Macros for POCC ... #else // Default macros // or #error This compiler is not supported! #endif I can't see where the sanity check here helps - do some compilers have trouble implementing #elif properly?
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-09-26 22:11 +0200 |
| Message-ID | <nsbvdj$hiv$2@dont-email.me> |
| In reply to | #94085 |
Le 26/09/2016 à 15:45, Richard Heathfield a écrit : > > Well, just write in ISO C, and you're fine. > > <lots of non-ISO C stuff snipped> > Windows is fully ISO C compatible. Just do not use graphics, sound, sensors, and do not take photos or do anything useful.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-09-26 22:04 +0100 |
| Message-ID | <nsc2hi$r36$1@dont-email.me> |
| In reply to | #94104 |
On 26/09/16 21:11, jacobnavia wrote: > Le 26/09/2016 à 15:45, Richard Heathfield a écrit : >> >> Well, just write in ISO C, and you're fine. >> >> <lots of non-ISO C stuff snipped> >> > > Windows is fully ISO C compatible. Just do not use graphics, sound, > sensors, and do not take photos or do anything useful. comp.os.ms-windows.programmer.win32 -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-10 11:39 +0100 |
| Message-ID | <ntfr4l$5oj$1@dont-email.me> |
| In reply to | #94083 |
On 26/09/2016 14:31, BartC wrote:
I've been finding yet more reasons to use and recommend only gcc to
compile my projects. I've found two or three compiler bugs just in the
last couple of days; they're supposed to be incredibly rare!
Actually, out of the six C compilers I've used, I've found bugs in three
at some time or other, while a fourth crashes while linking (a kind of
bug too I suppose). And a fifth doesn't work.
I've tried compiling my new project, and I've removed OS-sensitive stuff
for now to make it easy for them (so no __stdcall or
_declspec(dllimport); there are associated issues to sort out first
anyway). These are the results so far:
32-bit 64-bit Notes
Pelles C OK OK [1]
Lccwin OK X [2]
Digital Mars X -- [3]
gcc/tdm OK OK
Tiny C OK OK/X [4]
clang X X [5]
[1] Pelles C: I've found one or two bugs in the past, that have involved
using workarounds. It still has problems with __declspec(dllimport)
which will stop me using it in 64-bit mode when I need to do a full version.
[2] lccwin: One bug I could work around, but another one would require
too many wide-reaching changes to get around, so I can't use the 64-bit
version for now.
[3] DMC: I think this compiles (output is not sent to redirected
stderror so loads of warnings scroll up my screen). But it crashes badly
when linking. It might however later manage to link the 'one-file'
version - all the C sources combined into a single file.
[4] Tiny C: Had a problem with passing and returning 8-byte structs. I
changed an isolated bit of code to use struct pointers instead. However,
the 64-bit version intermittently crashes when trying to link.
[5] Clang: Usually only 32- or 64-bit version would work at any one
time. But at the moment I can use neither (as it now piggy-backs onto
MSVC rather than gcc). So I can test it, although if someone has a
working version, I suspect it will work.
I also have a part-working version of MSVC 32-bit (a seventh compiler),
but this is fiddly to invoke so will only attempt trying it on the
'one-file' version of the project.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2016-10-10 07:32 -0700 |
| Message-ID | <a0fa529f-6bf8-46a9-af58-adc38be91112@googlegroups.com> |
| In reply to | #94680 |
On Monday, October 10, 2016 at 1:39:46 PM UTC+3, Bart wrote: > > I also have a part-working version of MSVC 32-bit (a seventh compiler), > but this is fiddly to invoke so will only attempt trying it on the > 'one-file' version of the project. > > -- > Bartc Fiddly ? What does it mean? Few months ago I wrote an utility (interface definition processor) that invokes MSVC, as well as gcc, for various targets, as a part of its processing routine. Invocation part was trivial, as expected, as long as my utility was invoked in proper environment. In specific case of MSVC compiler "proper environment" was VS2013 x64 Native Tools Command Prompt.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-10-10 16:17 +0100 |
| Message-ID | <ntgbdk$307$1@dont-email.me> |
| In reply to | #94681 |
On 10/10/16 15:32, already5chosen@yahoo.com wrote: > On Monday, October 10, 2016 at 1:39:46 PM UTC+3, Bart wrote: >> >> I also have a part-working version of MSVC 32-bit (a seventh compiler), >> but this is fiddly to invoke so will only attempt trying it on the >> 'one-file' version of the project. >> >> -- >> Bartc > > Fiddly ? What does it mean? I'm not sure what "fiddly" means in this context, but I can tell you what its opposite is: make -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-10-10 21:09 -0500 |
| Message-ID | <faiovb91tp2l1lsv64qo4v5790j4rr76ur@4ax.com> |
| In reply to | #94682 |
On Mon, 10 Oct 2016 16:17:24 +0100, Richard Heathfield <rjh@cpax.org.uk> wrote: >On 10/10/16 15:32, already5chosen@yahoo.com wrote: >> On Monday, October 10, 2016 at 1:39:46 PM UTC+3, Bart wrote: >>> >>> I also have a part-working version of MSVC 32-bit (a seventh compiler), >>> but this is fiddly to invoke so will only attempt trying it on the >>> 'one-file' version of the project. >>> >>> -- >>> Bartc >> >> Fiddly ? What does it mean? > >I'm not sure what "fiddly" means in this context, but I can tell you >what its opposite is: > > make BartC has managed to install a non-standard distribution of MSVC (one intended for the internal use of another product), rather than a complete/normal installation. For some odd reason it doesn't work all that well as a stand-alone product.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-10-11 04:18 +0100 |
| Message-ID | <nthllg$7i6$1@dont-email.me> |
| In reply to | #94699 |
On 11/10/16 03:09, Robert Wessel wrote: > On Mon, 10 Oct 2016 16:17:24 +0100, Richard Heathfield > <rjh@cpax.org.uk> wrote: > >> On 10/10/16 15:32, already5chosen@yahoo.com wrote: >>> On Monday, October 10, 2016 at 1:39:46 PM UTC+3, Bart wrote: >>>> >>>> I also have a part-working version of MSVC 32-bit (a seventh compiler), >>>> but this is fiddly to invoke so will only attempt trying it on the >>>> 'one-file' version of the project. >>>> >>>> -- >>>> Bartc >>> >>> Fiddly ? What does it mean? >> >> I'm not sure what "fiddly" means in this context, but I can tell you >> what its opposite is: >> >> make > > > BartC has managed to install a non-standard distribution of MSVC (one > intended for the internal use of another product), rather than a > complete/normal installation. For some odd reason it doesn't work all > that well as a stand-alone product. "Doctor, it 'urts when I do *this*." "Well, then; don't do it." -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-11 10:56 +0100 |
| Message-ID | <ntid0j$7je$1@dont-email.me> |
| In reply to | #94699 |
On 11/10/2016 03:09, Robert Wessel wrote: > On Mon, 10 Oct 2016 16:17:24 +0100, Richard Heathfield >> I'm not sure what "fiddly" means in this context, but I can tell you >> what its opposite is: >> >> make > BartC has managed to install a non-standard distribution of MSVC (one > intended for the internal use of another product), rather than a > complete/normal installation. For some odd reason it doesn't work all > that well as a stand-alone product. > If I could find a standalone cl.exe and associated set of support files that could be downloaded then I would have used it. But somehow I don't think it would have been any better: On 10/10/2016 15:32, already5chosen@yahoo.com wrote: > Invocation part [of MSVC] was trivial, as expected, as long as my > utility was invoked in proper environment. In specific case of MSVC > compiler "proper environment" was VS2013 x64 Native Tools Command > Prompt. We're talking about a program that translates one input file to an output file. It's the simplest possible kind of application. What 'proper environment' is necessary? Anyway it eventually worked - within its 'special environment'. But that's OK for a one-off test after also testing with 5 or 6 other compilers. It's incredible however that a version of MSVC-2008 intended for compiling CPython has managed to compile 28000 lines of C that is nothing to do with Python. (It just needed a tweak as it didn't recognise 'stdint.h') (Compiling with /O2 for speed, MSVC-2008 produces an executable that is little faster than my own native-code compiler. And I'm targeting x64 which has a 5% performance penalty compared with the 32-bit x86 which is this MSVC's target. Mine however doesn't need a special 'native environment', and can still fit on a floppy disk without compression. /This/ is why I can criticise C compilers if I want.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2016-10-11 04:08 -0700 |
| Message-ID | <79a418d5-5782-43a3-8dc2-2a16343f3398@googlegroups.com> |
| In reply to | #94703 |
On Tuesday, October 11, 2016 at 12:57:03 PM UTC+3, Bart wrote: > On 11/10/2016 03:09, Robert Wessel wrote: > > On Mon, 10 Oct 2016 16:17:24 +0100, Richard Heathfield > > >> I'm not sure what "fiddly" means in this context, but I can tell you > >> what its opposite is: > >> > >> make > > > BartC has managed to install a non-standard distribution of MSVC (one > > intended for the internal use of another product), rather than a > > complete/normal installation. For some odd reason it doesn't work all > > that well as a stand-alone product. > > > > If I could find a standalone cl.exe and associated set of support files > that could be downloaded then I would have used it. But somehow I don't > think it would have been any better: > > On 10/10/2016 15:32, already5chosen@yahoo.com wrote: > > > Invocation part [of MSVC] was trivial, as expected, as long as my > > utility was invoked in proper environment. In specific case of MSVC > > compiler "proper environment" was VS2013 x64 Native Tools Command > > Prompt. > > We're talking about a program that translates one input file to an > output file. It's the simplest possible kind of application. What > 'proper environment' is necessary? > > Anyway it eventually worked - within its 'special environment'. But > that's OK for a one-off test after also testing with 5 or 6 other compilers. > > It's incredible however that a version of MSVC-2008 intended for > compiling CPython has managed to compile 28000 lines of C that is > nothing to do with Python. (It just needed a tweak as it didn't > recognise 'stdint.h') > > (Compiling with /O2 for speed, MSVC-2008 produces an executable that is > little faster than my own native-code compiler. And I'm targeting x64 > which has a 5% performance penalty compared with the 32-bit x86 which is > this MSVC's target. > > Mine however doesn't need a special 'native environment', and can still > fit on a floppy disk without compression. /This/ is why I can criticise > C compilers if I want.) > > -- > Bartc Are you claiming that MS compiler installation is bloated? That's certainly true. Are you claiming that getting MS standalone compiler is tricky? That's certainly wrong. Just for sake of argument I installed Visual C++ Build Tools on my home desktop. http://landinghub.visualstudio.com/visual-cpp-build-tools The process was not quick due to huge download size and my not very fast Internet (several Mbits/s, I don't remember exactly how many), but certainly very straight forward. At the end of the process installer wanted to reboot, I refused and so far I don't see that compilation suffers because of it. Also download was not quick, but it was many times quicker than what would be expected according to disk space, occupied by the installation (~2.7 GB). Probably, their stuff compresses very well. Majority of the disk space (~1.5 GB) is occupied by directory "C:\Program Files (x86)\Windows Kits". Somehow, I think that I can delete it and it will not affect my ability to compile desktop applications targeting Windows 7 or older versions. But I didn't try it yet. Among the rest, it seems that most of space is taken by "universal" libraries, that I also don't need. Out of other irrelevant stuff, there are libraries for ARM (260 MB). So, yes, leaner installation package would be nice, but at least in my scenario, it's not a deal breaker.
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web