ems on Solaris in the past, I went
exactly that route. The GCC D maintainer, Iain Buclaw, has been
extremly helpful in the process of getting things to work, but
ultimately someone with an interest in the affected target, the
necessary knowledge about it and access to the platform to d
Richard Biener via Gcc writes:
>> It is possible that the build would perhaps work, but the configure
>> check for the presence of a D compiler requires not just the compiler,
>> but also a runtime and thus fails on Cygwin.
>
> The alternative then ist to build D with a cro
Iain Sandoe writes:
> also you can add —with-libphobos-druntime-only to the GCC-11 build, that
> makes a compiler sufficient for bootstrapping 12+ and is much less demanding
> on completeness of OS support.
I think I tried that as well and failed, but thsi was likely on an
earlier gcc-11 or even g
Rainer Orth writes:
> Just try to configure gcc with --enable-libphobos, which overrides the
> default of LIBPHOBOS_SUPPORTED. In quite a number of cases, this just
> works, but hasn't yet been verified. You won't know until you try,
> though.
I did that and it indeed doesn't build.
Regards,
A
ccount on that bugtracker.
>>
>> It is possible that the build would perhaps work, but the configure
>> check for the presence of a D compiler requires not just the compiler,
>> but also a runtime and thus fails on Cygwin.
>
> Just try to configure gcc with --enable-
that the build would perhaps work, but the configure
> check for the presence of a D compiler requires not just the compiler,
> but also a runtime and thus fails on Cygwin.
The alternative then ist to build D with a cross compiler.
>
> Regards,
> Achim.
> --
> +<[
ut the configure
> check for the presence of a D compiler requires not just the compiler,
> but also a runtime and thus fails on Cygwin.
Just try to configure gcc with --enable-libphobos, which overrides the
default of LIBPHOBOS_SUPPORTED. In quite a number of cases, this just
works, but has
Richard Biener via Gcc writes:
> I think we should fix this build problems. Is there a bugzilla with
> more details about the problem?
No, I don't have an account on that bugtracker.
It is possible that the build would perhaps work, but the configure
check for the presence of a
On Sun, Sep 3, 2023 at 1:45 PM ASSI wrote:
>
>
> Starting with gcc-12, gcd needs a D compiler to bootstrap, but gcc-11
> does not allow to build the necessary runtime on all platforms (Cygwin
> for instance). How is the prospective bootstrap sequence on such
> platforms?
I t
Starting with gcc-12, gcd needs a D compiler to bootstrap, but gcc-11
does not allow to build the necessary runtime on all platforms (Cygwin
for instance). How is the prospective bootstrap sequence on such
platforms?
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Androm
On 24.05.2023 11:01, Hongtao Liu wrote:
> On Wed, May 24, 2023 at 3:58 PM Jan Beulich via Gcc wrote:
>>
>> Hello,
>>
>> for a couple of years I was meaning to extend the use of these AVX512F
>> insns beyond the pretty minimalistic ones there are so far. Now that I've
>> got around to at least draf
EG_P (operands[1]) || REG_P (operands[2]). Here I think you
want register_operand instead of REG_P.
157(set (reg:V16SI 91)
158(and:V16SI (not:V16SI (subreg:V16SI (reg:V8DI 98) 0))
159(vec_duplicate:V16SI (mem:SI (reg:DI 99) [1 *f_3(D)+0 S4 A32]
>
> Just to mention it, avx512f-a
Hello,
for a couple of years I was meaning to extend the use of these AVX512F
insns beyond the pretty minimalistic ones there are so far. Now that I've
got around to at least draft something, I ran into a couple of issues I
cannot explain. I'd like to start with understanding the unexpected
effect
Sent from my iPhone
On 25.07.2022 17:45, ibuc...@gdcproject.org wrote:
>> On 25/07/2022 14:13 CEST Jan Beulich wrote:
>>
>>
>> On 25.07.2022 14:05, ibuc...@gdcproject.org wrote:
>>>> On 25/07/2022 08:45 CEST Jan Beulich wrote:
>>>> while commit 3f30a274913b ("
> On 25/07/2022 14:13 CEST Jan Beulich wrote:
>
>
> On 25.07.2022 14:05, ibuc...@gdcproject.org wrote:
> >> On 25/07/2022 08:45 CEST Jan Beulich wrote:
> >> while commit 3f30a274913b ("libiberty: Update D symbol demangling
> >> for latest ABI s
On 25.07.2022 14:05, ibuc...@gdcproject.org wrote:
>> On 25/07/2022 08:45 CEST Jan Beulich wrote:
>> while commit 3f30a274913b ("libiberty: Update D symbol demangling
>> for latest ABI spec") mentions in its description that tuple encoding
>> has chan
> On 25/07/2022 08:45 CEST Jan Beulich wrote:
>
>
> Hello,
>
> while commit 3f30a274913b ("libiberty: Update D symbol demangling
> for latest ABI spec") mentions in its description that tuple encoding
> has changed, there's no real adjustment to dlang_p
Hello,
while commit 3f30a274913b ("libiberty: Update D symbol demangling
for latest ABI spec") mentions in its description that tuple encoding
has changed, there's no real adjustment to dlang_parse_tuple() there,
nor are there any new (or replaced) test cases for that. Was this
si
On 4/20/21 4:20 PM, Jakub Jelinek wrote:
On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote:
On 4/20/21 10:24 AM, Jakub Jelinek via Gcc wrote:
The first release candidate for GCC 11.1 is available from
https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
ftp://
Peter Bergner via Gcc wrote:
On 4/20/21 4:20 PM, Jakub Jelinek via Gcc wrote:
On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote:
/tmp/cc8zG8DV.s: Assembler messages:
/tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13
/tmp/cc8zG8DV.s:2570: Error: unsupported r
> On 21/04/2021 00:02 Peter Bergner wrote:
>
>
> On 4/20/21 4:20 PM, Jakub Jelinek via Gcc wrote:
> > On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote:
> >> /tmp/cc8zG8DV.s: Assembler messages:
> >> /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13
> >> /tmp/
On 4/20/21 4:20 PM, Jakub Jelinek via Gcc wrote:
> On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote:
>> /tmp/cc8zG8DV.s: Assembler messages:
>> /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13
>> /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14
[s
On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote:
>
> On 4/20/21 10:24 AM, Jakub Jelinek via Gcc wrote:
> > The first release candidate for GCC 11.1 is available from
> >
> > https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
> > ftp://gcc.gnu.org/pub/gcc/snapshot
On Thu, Aug 20, 2020 at 11:51 AM Erick Ochoa
wrote:
>
> Hello,
>
> I am looking at the dump for the build_alias pass. I see a lot of
> variables with the naming convention D.[0-9]* in the points-to sets
> being printed.
>
> When I compile with
>
> -fdump-tree-all-all
Hello,
I am looking at the dump for the build_alias pass. I see a lot of
variables with the naming convention D.[0-9]* in the points-to sets
being printed.
When I compile with
-fdump-tree-all-all
I can see that the suffix D.[0-9]* is appended to some gimple variables.
I initially imagined
Am 29.04.2019 um 09:59 schrieb Johannes Pfau:
> Am 25.04.19 um 20:05 schrieb Rainer Emrich:
>> Does anybody knows what's the plans for D on mingw.
>>
>> AFAIS the frontend builds and is enabled for mingw. But the D runtime is
>> disabled for mingw and doesn'
Am 25.04.19 um 20:05 schrieb Rainer Emrich:
Does anybody knows what's the plans for D on mingw.
AFAIS the frontend builds and is enabled for mingw. But the D runtime is
disabled for mingw and doesn't build.
A quick dive into the source showed that there is code for mingw target.
Bu
Does anybody knows what's the plans for D on mingw.
AFAIS the frontend builds and is enabled for mingw. But the D runtime is
disabled for mingw and doesn't build.
A quick dive into the source showed that there is code for mingw target.
But it looks like the wrong configuration is sele
On 21 June 2017 at 15:44, David Edelsohn wrote:
> I am pleased to announce that the GCC Steering Committee has
> accepted the D Language front-end and runtime for inclusion in GCC
> and appointed Iain Buclaw as maintainer.
>
> The patches still require appro
I am pleased to announce that the GCC Steering Committee has
accepted the D Language front-end and runtime for inclusion in GCC
and appointed Iain Buclaw as maintainer.
The patches still require approval by a Global Reviewer.
Please join me in congratulating Iain on his
On 8 April 2016 at 11:09, Ulrich Windl wrote:
> Hello!
>
> Probably I'm doing something wrong, but I have some problems comparing a
> double with NAN: The value is NAN, but the test fails. Probably I should use
> isnana().
This mailing list is for discussing development of GCC, not help using
GC
On 08/04/16 11:09, Ulrich Windl wrote:
> Probably I'm doing something wrong, but I have some problems comparing a
> double with NAN: The value is NAN, but the test fails. Probably I should use
> isnana().
yes, that's how ieee works, nan != nan is true.
Hello!
Probably I'm doing something wrong, but I have some problems comparing a double
with NAN: The value is NAN, but the test fails. Probably I should use isnana().
Here's my test case:
---
#include
#include
int main()
{
double d = NAN;
assert(d == NAN);
Hi,
other bits. Tested x86_64-linux.
Thanks,
Paolo.
//
2015-07-28 Paolo Carlini
* call.c (build_op_delete_call, convert_like_real, build_over_call):
Use Use DECL_SOURCE_LOCATION and "%qD" in inform and pedwarn instead
aw
>>>> wrote:
>>>>> On 10 July 2014 08:26, Richard Biener wrote:
>>>>>> On July 10, 2014 8:31:54 AM CEST, Iain Buclaw
>>>>>> wrote:
>>>>>>>Hi,
>>>>>>>
>>>>
aw
>>>> wrote:
>>>>> On 10 July 2014 08:26, Richard Biener wrote:
>>>>>> On July 10, 2014 8:31:54 AM CEST, Iain Buclaw
>>>>>> wrote:
>>>>>>>Hi,
>>>>>>>
>>>>
d Biener wrote:
>>>>> On July 10, 2014 8:31:54 AM CEST, Iain Buclaw
>>>>> wrote:
>>>>>>Hi,
>>>>>>
>>>>>>I'm trying to get to the bottom of a bug when using the D front-end
>>>>>>with -flto.
gt;>> wrote:
>>>>>Hi,
>>>>>
>>>>>I'm trying to get to the bottom of a bug when using the D front-end
>>>>>with -flto.
>>>>>
>>>>>When compiling anything, it always ICEs at in
>>>>>str
On 10 July 2014 10:01, Richard Biener wrote:
> On Thu, Jul 10, 2014 at 10:51 AM, Iain Buclaw wrote:
>> On 10 July 2014 08:26, Richard Biener wrote:
>>> On July 10, 2014 8:31:54 AM CEST, Iain Buclaw
>>> wrote:
>>>>Hi,
>>>>
>>>>I&#x
On Thu, Jul 10, 2014 at 10:51 AM, Iain Buclaw wrote:
> On 10 July 2014 08:26, Richard Biener wrote:
>> On July 10, 2014 8:31:54 AM CEST, Iain Buclaw wrote:
>>>Hi,
>>>
>>>I'm trying to get to the bottom of a bug when using the D front-end
>>>wit
On 10 July 2014 08:26, Richard Biener wrote:
> On July 10, 2014 8:31:54 AM CEST, Iain Buclaw wrote:
>>Hi,
>>
>>I'm trying to get to the bottom of a bug when using the D front-end
>>with -flto.
>>
>>When compiling anything, it always ICEs at in
>&g
On July 10, 2014 8:31:54 AM CEST, Iain Buclaw wrote:
>Hi,
>
>I'm trying to get to the bottom of a bug when using the D front-end
>with -flto.
>
>When compiling anything, it always ICEs at in
>streamer_get_pickled_tree, at tree-streamer-in.c.
>
>The of it appears t
On 10 July 2014 07:31, Iain Buclaw wrote:
> Hi,
>
> I'm trying to get to the bottom of a bug when using the D front-end with
> -flto.
>
> When compiling anything, it always ICEs at in
> streamer_get_pickled_tree, at tree-streamer-in.c.
>
> The of it appears to b
Hi,
I'm trying to get to the bottom of a bug when using the D front-end with -flto.
When compiling anything, it always ICEs at in
streamer_get_pickled_tree, at tree-streamer-in.c.
The of it appears to be that the LTO frontend seems to never retrieve
what it is expected to find. But I
, Jonathan Wakely wrote:
> On Jan 25, 2014 1:32 AM, "Perry Smith" wrote:
>>
>> I think, a %D in a spec creates a list of -L/a/b/c -L/d/e/f. gcc -dumpspecs
>> shows me that link_libgcc goes to %D but it does not show me what %D
>> produces. Is there a way to get
On Jan 25, 2014 1:32 AM, "Perry Smith" wrote:
>
> I think, a %D in a spec creates a list of -L/a/b/c -L/d/e/f. gcc -dumpspecs
> shows me that link_libgcc goes to %D but it does not show me what %D
> produces. Is there a way to get gcc to dump that out?
>
> Basica
I think, a %D in a spec creates a list of -L/a/b/c -L/d/e/f. gcc -dumpspecs
shows me that link_libgcc goes to %D but it does not show me what %D produces.
Is there a way to get gcc to dump that out?
Basically what I'm trying to do is find the list of library paths that GCC
tells ld t
Hello All,
After many tentative releases, I am proud to announce the MELT plugin 0.9.6-d
release for GCC 4.6 and 4.7
MELT is a high-level domain specific language to extend GCC (with features like
pattern matching to make
that less difficult than thru GCC plugins hand-coded in C).
You can
On 21 July 2012 21:00, Florian Weimer wrote:
> * Iain Buclaw:
>
>> I've have received news from Walter Bright that the license of the D
>> frontend has been assigned to the FSF. As the current maintainer of
>> GDC, I would like to get this moved forward, starting wit
* Iain Buclaw:
> I've have received news from Walter Bright that the license of the D
> frontend has been assigned to the FSF. As the current maintainer of
> GDC, I would like to get this moved forward, starting with getting the
> ball rolling. What would need to be done?
On 10 May 2012 11:52, Iain Buclaw wrote:
>
> Thanks, would it be best to split the frontend, library, and patches
> to gcc proper into three parts?
>From observing how other big projects got merged, I think it is better:
1) If you have anything that can be committed independently of gdc
(like b
On 10 May 2012 10:48, Richard Guenther wrote:
> On Thu, May 10, 2012 at 11:37 AM, Iain Buclaw wrote:
>> On 11 April 2012 15:12, Iain Buclaw wrote:
>>> On 4 October 2011 08:08, Iain Buclaw wrote:
>>>> Hi,
>>>>
>>>> I've have
On Thu, May 10, 2012 at 11:37 AM, Iain Buclaw wrote:
> On 11 April 2012 15:12, Iain Buclaw wrote:
>> On 4 October 2011 08:08, Iain Buclaw wrote:
>>> Hi,
>>>
>>> I've have received news from Walter Bright that the license of the D
>>> fro
On 11 April 2012 15:12, Iain Buclaw wrote:
> On 4 October 2011 08:08, Iain Buclaw wrote:
>> Hi,
>>
>> I've have received news from Walter Bright that the license of the D
>> frontend has been assigned to the FSF. As the current maintainer of
>> GDC,
On 11/04/2012 15:12, Iain Buclaw wrote:
> This has been rather long wait from my side of the pond (moving has
> taken away quite some time from my side). But I'll be in a position
> to begin discussion on arrangements this weekend for patches to be
> submitted for GCC 4.8.
>
> I would be gratefu
On 4 October 2011 08:08, Iain Buclaw wrote:
> Hi,
>
> I've have received news from Walter Bright that the license of the D
> frontend has been assigned to the FSF. As the current maintainer of
> GDC, I would like to get this moved forward, starting with getting the
> ball r
On 05/10/2011 04:56, Iain Buclaw wrote:
> On 5 October 2011 00:10, Ian Lance Taylor wrote:
>> Iain Buclaw writes:
>>
>>> First question that pops up after having a quick look is, are there
>>> any tips around for writing the scripts for the testsuite? I'm not too
>>> familiar with Dejagnu, and t
On 4 October 2011 09:41, Andrew Haley wrote:
> On 10/04/2011 08:08 AM, Iain Buclaw wrote:
>
>> I've have received news from Walter Bright that the license of the D
>> frontend has been assigned to the FSF. As the current maintainer of
>> GDC, I would like to get this
On 10/4/2011 12:08 AM, Iain Buclaw wrote:
I've have received news from Walter Bright that the license of the D
frontend has been assigned to the FSF. As the current maintainer of
GDC, I would like to get this moved forward, starting with getting the
ball rolling. What would need to be
On 05/10/2011 12:00, Andi Kleen wrote:
David Brown writes:
Some toolchains are configured to have a series of "init" sections at
startup (technically, that's a matter of the default linker scripts
and libraries rather than the compiler). You can get code to run at
specific times during startu
David Brown writes:
>
> Some toolchains are configured to have a series of "init" sections at
> startup (technically, that's a matter of the default linker scripts
> and libraries rather than the compiler). You can get code to run at
> specific times during startup by placing the instructions dir
On 04/10/2011 23:47, Andrew Pinski wrote:
On Tue, Oct 4, 2011 at 2:40 PM, David Brown wrote:
"naked" functions are often useful in embedded systems, and are therefore
useful (and implemented) on many gcc targets. It would make sense to have
the attribute available universally in gcc, if that d
On 5 October 2011 00:10, Ian Lance Taylor wrote:
> Iain Buclaw writes:
>
>> The active development of the D frontend would continue to be mirrored
>> in an external repository, but will occasionally be merged into GDC
>> project.
>
> Well, Go does set a precedent
Iain Buclaw writes:
> The active development of the D frontend would continue to be mirrored
> in an external repository, but will occasionally be merged into GDC
> project.
Well, Go does set a precedent for this. The main issue here is that
this means that there is (another)
Iain Buclaw writes:
> On 4 October 2011 20:36, Andrew Pinski wrote:
>> On Tue, Oct 4, 2011 at 12:30 PM, Iain Buclaw wrote:
>>> These patches address two areas of the D language:
>>> 1) D calling convention.
>>> 2) Naked functions on i386 and x86_64
>&g
On Tue, Oct 4, 2011 at 2:40 PM, David Brown wrote:
> "naked" functions are often useful in embedded systems, and are therefore
> useful (and implemented) on many gcc targets. It would make sense to have
> the attribute available universally in gcc, if that doesn't involve a lot of
> extra work, e
On 04/10/11 21:36, Andrew Pinski wrote:
On Tue, Oct 4, 2011 at 12:30 PM, Iain Buclaw wrote:
These patches address two areas of the D language:
1) D calling convention.
2) Naked functions on i386 and x86_64
Some work would need to be done on naked functions at least first so
that changes
>>>>> "Iain" == Iain Buclaw writes:
Ian> There is a directory gcc/d/zlib, but gcc already has a top-level zlib
Ian> directory.
Iain> Zlib there is the version released with the D Phobos library, it is
Iain> slightly newer. But is harmless to remove.
You c
On 4 October 2011 20:36, Andrew Pinski wrote:
> On Tue, Oct 4, 2011 at 12:30 PM, Iain Buclaw wrote:
>> These patches address two areas of the D language:
>> 1) D calling convention.
>> 2) Naked functions on i386 and x86_64
>>
>> Some work would need to be done
On Tue, 4 Oct 2011, Iain Buclaw wrote:
> The original copyrights for the GDC D front-end for GCC are in the
> name of David Friedman, who has been MIA since 2007. Since the
> project has been revived, all changes and additions have been
> copyrighted in my name, Michael's, and V
On 4 October 2011 17:50, Joseph S. Myers wrote:
> On Tue, 4 Oct 2011, Iain Buclaw wrote:
>
>> Hi,
>>
>> I've have received news from Walter Bright that the license of the D
>> frontend has been assigned to the FSF. As the current maintainer of
>> GD
On Tue, Oct 4, 2011 at 12:30 PM, Iain Buclaw wrote:
> These patches address two areas of the D language:
> 1) D calling convention.
> 2) Naked functions on i386 and x86_64
>
> Some work would need to be done on naked functions at least first so
> that changes required are onl
On 4 October 2011 15:02, Ian Lance Taylor wrote:
> Iain Buclaw writes:
>
>> I've have received news from Walter Bright that the license of the D
>> frontend has been assigned to the FSF. As the current maintainer of
>> GDC, I would like to get this moved forwa
On 4 October 2011 09:41, Andrew Haley wrote:
> On 10/04/2011 08:08 AM, Iain Buclaw wrote:
>
>> I've have received news from Walter Bright that the license of the D
>> frontend has been assigned to the FSF. As the current maintainer of
>> GDC, I would like to get this
On Tue, 4 Oct 2011, Iain Buclaw wrote:
> Hi,
>
> I've have received news from Walter Bright that the license of the D
> frontend has been assigned to the FSF. As the current maintainer of
> GDC, I would like to get this moved forward, starting with getting the
> ball roll
Iain Buclaw writes:
> I've have received news from Walter Bright that the license of the D
> frontend has been assigned to the FSF. As the current maintainer of
> GDC, I would like to get this moved forward, starting with getting the
> ball rolling. What would need to be done?
On 10/04/2011 08:08 AM, Iain Buclaw wrote:
> I've have received news from Walter Bright that the license of the D
> frontend has been assigned to the FSF. As the current maintainer of
> GDC, I would like to get this moved forward, starting with getting the
> ball rolling. What
Hi,
I've have received news from Walter Bright that the license of the D
frontend has been assigned to the FSF. As the current maintainer of
GDC, I would like to get this moved forward, starting with getting the
ball rolling. What would need to be done? And what are the processes
required
On Tue, Nov 09, 2010 at 05:08:44AM -0800, Jakub Jelinek wrote:
> On Tue, Nov 09, 2010 at 09:36:08AM +, Andrew Haley wrote:
> > > The D specific part of gdc is already GPL, it's just copyrighted by
> > > Digital Mars. I understand the copyright must be reassign
On Tue, Nov 09, 2010 at 09:36:08AM +, Andrew Haley wrote:
> > The D specific part of gdc is already GPL, it's just copyrighted by
> > Digital Mars. I understand the copyright must be reassigned to the FSF.
> > Is it possible to fork the code, and assign copyright of one
et achieve the level of separation
>> achieved by Ada, for example; there are plenty of uses of GCC's tree
>> interfaces in the gofrontend/ directory that mean portability to other
>> back ends is more theory than reality.)
>
> The D specific part of gdc is already GPL, it
han reality.)
The D specific part of gdc is already GPL, it's just copyrighted by
Digital Mars. I understand the copyright must be reassigned to the FSF.
Is it possible to fork the code, and assign copyright of one fork to the
FSF and leave the other copyrighted by Digital Mars?
In gen
neral I'd like to encourage maintainers of separate front ends - not
limited to D - to work towards merging them into FSF GCC and maintaining
them there; additional front ends help improve the quality of the core
language-independent code, and no doubt GNU/Linux distributors would be
glad to avo
Who do I need to talk to in order to resolve the various licensing
issues so this becomes possible?
Walter Bright
Digital Mars
http://www.digitalmars.com
free C, C++, D programming language compilers
On Sun, Sep 26, 2010 at 06:09:34PM -0700, ir_idjit wrote:
> i can seem to get this to work:
>
> #define PREFIX "p_"
> #define HIGHER_INTERFACE(id) LOWER_INTERFACE(PREFIX, id)
>
> #define LOWER_INTERFACE(prefix, id) struct prefix##id \
> { \
> int i; \
> }
>
> int main(void)
> {
> HIG
drives me crazy that i can't get his to work
--
View this message in context:
http://old.nabble.com/passing--define-d-values-to--define-d-macros-tp29815182p29815215.html
Sent from the gcc - Dev mailing list archive at Nabble.com.
.
but if you're writing libraries that can be easily ported to many system
with VERY LITTLE modification, shouldn't this tiny functionality been
adressed?? an escape character would've been nice
--
View this message in context:
http://old.nabble.com/passing--define-d-values-to--defi
On Tue, Aug 04, 2009 at 05:58:05PM -0700, Vincent Lefevre wrote:
> On 2009-08-04 15:44:05 -0700, Joe Buck wrote:
> > But AFAIK neither Posix nor the C89 standard nor the C99 standard
> > say anything about -D and -U flags. It's the Single UNIX specification
> > that is t
On Wed, 5 Aug 2009, Dave Korn wrote:
> to integrate this behaviour into the driver. Perhaps we could even do the old
> behave-differently-according-to-argv[0] trick, although I'm not sure if that
> isn't slightly discouraged these days.
The proper thing is to build a separate driver binary (opti
on the GCC version. Or do GCC developers
> guaranty that no options that can take an argument will be added in the
> future?
I'm trying hard to think of a case where an option argument might begin with
-U or -D and not succeeding, but I guess it's possible in theory that some
future
On 2009-08-05 10:07:49 +0100, Dave Korn wrote:
> GCC does not install an executable called "c99". Or one called
> "c89". So what any standard requires of them is irrelevant to us,
> except that we would want to make it possible to support that mode
> of operation. And we do; with our predictable
Vincent Lefevre wrote:
> On 2009-08-04 15:44:05 -0700, Joe Buck wrote:
>> But AFAIK neither Posix nor the C89 standard nor the C99 standard
>> say anything about -D and -U flags. It's the Single UNIX specification
>> that is the issue, and it refers to a command that i
On 2009-08-04 15:44:05 -0700, Joe Buck wrote:
> But AFAIK neither Posix nor the C89 standard nor the C99 standard
> say anything about -D and -U flags. It's the Single UNIX specification
> that is the issue, and it refers to a command that is spelled "c89",
> or (in
ct in other GNU software. This would
> presumably also affect other options, such as making the default -
> std=c99
> instead of gnu89.
But AFAIK neither Posix nor the C89 standard nor the C99 standard
say anything about -D and -U flags. It's the Single UNIX specification
that is the issue, an
On 2009-08-05, at 04:03, Joe Buck wrote:
Another alternative would be an extra flag that would turn on
conformance
to the spec.
Traditionally spelled -posixly-correct in other GNU software. This would
presumably also affect other options, such as making the default -
std=c99
instead of g
On Tue, Aug 04, 2009 at 08:03:56AM -0700, Tom Tromey wrote:
> >>>>> "Erwin" == Unruh, Erwin writes:
>
> Erwin> In current gcc the order of options -D and -U is significant. The
> Erwin> Single Unix(r) Specification explicitly specifies that the o
>>>>> "Erwin" == Unruh, Erwin writes:
Erwin> In current gcc the order of options -D and -U is significant. The
Erwin> Single Unix(r) Specification explicitly specifies that the order
Erwin> should not matter for the c89 command. It reads (cited from
Erwin&
On 2009-08-04 08:23:52 +0200, Paolo Bonzini wrote:
> User-specified CFLAGS are always passed last in the Makefiles (at
> least for Automake, but it is a good practice in general) so that
> the user can override options like -D, -U, -O, -g, -f, -m.
>
> The specified behavior
On 2009-08-03 15:52:37 +0200, Unruh, Erwin wrote:
> In current gcc the order of options -D and -U is significant. The
> Single Unix(r) Specification explicitly specifies that the order
> should not matter for the c89 command. It reads (cited from
> version 2, which is ten years old)
1 - 100 of 117 matches
Mail list logo
