Where is gstdint.h

[Aaron Gray]

Where is gstdint.h ? Does it acctually exist ?

libdecnumber seems to use it.

decimal32|64|128.h's include decNumber.h which includes deccontext.h which 
includes gstdint.h


If some one who knows, could sort this issue out please.

Many thanks in advance,

Aaron

Re: Where is gstdint.h

[Aaron Gray]

[EMAIL PROTECTED] wrote:

Where is gstdint.h ? Does it acctually exist ?

libdecnumber seems to use it.

decimal32|64|128.h's include decNumber.h which includes deccontext.h 
which includes gstdint.h


When you configure libdecnumber (e.g. by running top-level gcc configure), 
gstdint.h should be created, by modifying .  Since you said 
nothing about the conditions where you had a problem, you can't expect 
anyone to fix it for you.  If you do want it fixed, you should at least 
file a complete PR.  As it is more likely to happen with a poorly 
supported target, you may have to look into it in more detail than that.
When this happened to me, I simply made a copy of stdint.h to get over the 
hump.


Thanks for prompt reply.

I am doing 386 build. I could not find it in my build directory, but it is 
there after all. Sorry, not used to finding files in Linux.


Aaron

Re: Where is gstdint.h

[Aaron Gray]

[EMAIL PROTECTED] wrote:

Tim Prince wrote:

[EMAIL PROTECTED] wrote:

Where is gstdint.h ? Does it acctually exist ?

libdecnumber seems to use it.

decimal32|64|128.h's include decNumber.h which includes deccontext.h 
which includes gstdint.h


When you configure libdecnumber (e.g. by running top-level gcc 
configure), gstdint.h should be created, by modifying .  Since 
you said nothing about the conditions where you had a problem, you can't 
expect anyone to fix it for you.  If you do want it fixed, you should at 
least file a complete PR.  As it is more likely to happen with a poorly 
supported target, you may have to look into it in more detail than that.
When this happened to me, I simply made a copy of stdint.h to get over 
the hump.


This might happen when you run the top level gcc configure in its own 
directory.  You may want to try to make a new directory elsewhere and run 
configure there.


pwd
.../my-gcc-source-tree
mkdir ../build
cd ../build
../my-gcc-source-tree/configure
make


If you're suggesting trying to build in the top level directory to see if 
the same problem occurs, I would expect other problems to arise.  If it 
would help diagnose the problem, and the problem persists for a few weeks, 
I'd be willing to try it.


Tim you cleared this one up earlier, the gstdint.h was in the build tree 
after all.


Aaron

Re: Successfull Build of gcc on Cygwin WinXp SP2

[Aaron Gray]

Hi James,


Successfully built latest gcc on Win XP SP2 with cvs built cygwin.


I was wondering whether you could help to get me to the same point please.


$ cygcheck -V
cygcheck version 1.94
System Checker for Cygwin
Copyright 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006 Red Hat, 
Inc.

Compiled on Apr 17 2007

(It was actually compiled  on 23/04/2007)


First up I am getting cygcheck giving me :-

Cygcheck version 1.90
Compiled on Jan 31 2007

How do I get a later version of Cygwin ?


$ ./g++ -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../configure --prefix=/cygdrive/c/beta
--enable-languages=c,c++
Thread model: single
gcc version 4.3.0 20070424 (experimental)


Hope you do not mind helping me reproduce these results.

I am working on the LLVM project and am hoping to get Cygwin back as a 
platform for LLVM development.


Aaron

Re: Successfull Build of gcc on Cygwin WinXp SP2

[Aaron Gray]

James,


On 5/1/07, Aaron Gray <[EMAIL PROTECTED]> wrote:

Hi James,

> Successfully built latest gcc on Win XP SP2 with cvs built cygwin.

I was wondering whether you could help to get me to the same point 
please.



You will need to use Dave Korns patch for newlib.

http://sourceware.org/ml/newlib/2007/msg00292.html


I am getting the following :-

$ patch newlib/libc/include/stdio.h fix-gcc-bootstrap-on-cygwin-patch.diff
patching file newlib/libc/include/stdio.h
Hunk #1 succeeded at 475 (offset 78 lines).
Hunk #2 FAILED at 501.
Hunk #3 FAILED at 521.
2 out of 3 hunks FAILED -- saving rejects to file 
newlib/libc/include/stdio.h.rej


Has a variation of the patch already been applied ? Shall I revert stdio.h 
back to the CVS version ?


Aaron

Re: Successfull Build of gcc on Cygwin WinXp SP2

[Aaron Gray]

[EMAIL PROTECTED] wrote:

James,


On 5/1/07, Aaron Gray <[EMAIL PROTECTED]> wrote:

Hi James,

> Successfully built latest gcc on Win XP SP2 with cvs built cygwin.

I was wondering whether you could help to get me to the same point 
please.



You will need to use Dave Korns patch for newlib.

http://sourceware.org/ml/newlib/2007/msg00292.html


I am getting the following :-

$ patch newlib/libc/include/stdio.h 
fix-gcc-bootstrap-on-cygwin-patch.diff

patching file newlib/libc/include/stdio.h
Hunk #1 succeeded at 475 (offset 78 lines).
Hunk #2 FAILED at 501.
Hunk #3 FAILED at 521.
2 out of 3 hunks FAILED -- saving rejects to file 
newlib/libc/include/stdio.h.rej


I had to apply the relevant changes manually to the cygwin . It 
doesn't appear to match the version for which Dave made the patch.


Thanks Tim, could you post a .diff file for stdio.h please.

Aarom

Re: Successfull Build of gcc on Cygwin WinXp SP2

[Aaron Gray]

On 02 May 2007 02:47, Aaron Gray wrote:


James,


On 5/1/07, Aaron Gray wrote:

Hi James,


Successfully built latest gcc on Win XP SP2 with cvs built cygwin.


I was wondering whether you could help to get me to the same point
please.



You will need to use Dave Korns patch for newlib.

http://sourceware.org/ml/newlib/2007/msg00292.html


I am getting the following :-

$ patch newlib/libc/include/stdio.h 
fix-gcc-bootstrap-on-cygwin-patch.diff

patching file newlib/libc/include/stdio.h
Hunk #1 succeeded at 475 (offset 78 lines).
Hunk #2 FAILED at 501.
Hunk #3 FAILED at 521.
2 out of 3 hunks FAILED -- saving rejects to file
newlib/libc/include/stdio.h.rej

Has a variation of the patch already been applied ? Shall I revert 
stdio.h

back to the CVS version ?


 It is patched in newlib cvs, and then a second patch was applied on top 
to
fix a minor oversight, so if you're using cvs newlib, yes revert ("cvs 
up -C")

it.


As far as I know I am just using the newlib within winsup. So I presume I do 
not need to do this ?

Or do I need to patch manually ?

 However the actual problem is probably that you need to manually patch 
your
*previously-installed* stdio.h in /usr/include.  The change won't filter 
down

to /usr/include until the next cygwin release.


So I just patch the /usr/inclue/stdio.h.

Aaron

Cygwin build documentation error.

[Aaron Gray]

I am getting errors on building Cygwin. It appears to be something to do 
with the documentation.


Am I missing something simple such as a package like cygwin-doc and if so 
where do I get it ?


Error text below...

Many thanks in advance,

Aaron


make[3]: Entering directory `/usr/build/cygwin/i686-pc-cygwin/winsup/doc'
gcc -g /usr/src/src/winsup/doc/doctool.c -o doctool
./doctool -m -d /usr/src/src/winsup/doc -d /usr/src/src/winsup/utils -d 
/usr/src/src/winsup/cygwin -s /usr/src/src/winsup/doc -o cygwin-ug-net.sgml 
/usr/src/src/winsup/doc/cygwin-ug-net.in.sgml
xmlto html -o cygwin-ug-net/ -m /usr/src/src/winsup/doc/cygwin.dsl 
cygwin-ug-net.sgml

usage: xmlto [OPTION]... FORMAT XML
OPTIONs are:
 -v  verbose output (-vv for very verbose)
 -x stylesheet   use the specified stylesheet instead of choosing one
 -m fragment use the XSL fragment to customize the stylesheet
 -o directoryput output in the specified directory instead of
 the current working directory
 -p postprocopts pass option to postprocessor
 --extensionsturn on stylesheet extensions for this tool chain
 --searchpathcolon-separated list of fallback directories
 --skip-validation
 do not attempt to validate the input before processing

Available FORMATs depend on the type of the XML file (which is
determined automatically).

For documents of type "docbook":
fo
html
html-nochunks
htmlhelp
javahelp
man
txt
xhtml
xhtml-nochunks
xmlto html-nochunks -m /usr/src/src/winsup/doc/cygwin.dsl cygwin-ug-net.sgml
usage: xmlto [OPTION]... FORMAT XML
OPTIONs are:
 -v  verbose output (-vv for very verbose)
 -x stylesheet   use the specified stylesheet instead of choosing one
 -m fragment use the XSL fragment to customize the stylesheet
 -o directoryput output in the specified directory instead of
 the current working directory
 -p postprocopts pass option to postprocessor
 --extensionsturn on stylesheet extensions for this tool chain
 --searchpathcolon-separated list of fallback directories
 --skip-validation
 do not attempt to validate the input before processing

Available FORMATs depend on the type of the XML file (which is
determined automatically).

For documents of type "docbook":
fo
html
html-nochunks
htmlhelp
javahelp
man
txt
xhtml
xhtml-nochunks
cp cygwin-ug-net.html cygwin-ug-net/cygwin-ug-net-nochunks.html
rm -f cygwin-ug-net/cygwin-ug-net-nochunks.html.gz
gzip cygwin-ug-net/cygwin-ug-net-nochunks.html
./doctool -m -d /usr/src/src/winsup/doc -d /usr/src/src/winsup/utils -d 
/usr/src/src/winsup/cygwin -s /usr/src/src/winsup/doc -o cygwin-api.sgml 
/usr/src/src/winsup/doc/cygwin-api.in.sgml
xmlto html -o cygwin-api/ -m /usr/src/src/winsup/doc/cygwin.dsl 
cygwin-api.sgml

usage: xmlto [OPTION]... FORMAT XML
OPTIONs are:
 -v  verbose output (-vv for very verbose)
 -x stylesheet   use the specified stylesheet instead of choosing one
 -m fragment use the XSL fragment to customize the stylesheet
 -o directoryput output in the specified directory instead of
 the current working directory
 -p postprocopts pass option to postprocessor
 --extensionsturn on stylesheet extensions for this tool chain
 --searchpathcolon-separated list of fallback directories
 --skip-validation
 do not attempt to validate the input before processing

Available FORMATs depend on the type of the XML file (which is
determined automatically).

For documents of type "docbook":
fo
html
html-nochunks
htmlhelp
javahelp
man
txt
xhtml
xhtml-nochunks
xmlto html -o faq -m /usr/src/src/winsup/doc/cygwin.dsl 
/usr/src/src/winsup/doc/faq-sections.xml

usage: xmlto [OPTION]... FORMAT XML
OPTIONs are:
 -v  verbose output (-vv for very verbose)
 -x stylesheet   use the specified stylesheet instead of choosing one
 -m fragment use the XSL fragment to customize the stylesheet
 -o directoryput output in the specified directory instead of
 the current working directory
 -p postprocopts pass option to postprocessor
 --extensionsturn on stylesheet extensions for this tool chain
 --searchpathcolon-separated list of fallback directories
 --skip-validation
 do not attempt to validate the input before processing

Available FORMATs depend on the type of the XML file (which is
determined automatically).

For documents of type "docbook":
fo
html
html-nochunks
htmlhelp
javahelp
man
txt
xhtml
xhtml-nochunks
sed -i 's;;;g' faq/faq.*.html
xmlto html -o faq -m /usr/src/src/winsup/doc/cygwin.dsl 
/usr/src/src/winsup/doc/faq.xml

usage: xmlto [OPTION]... FORMAT XML
OPTIONs are:
 -v  verbose output (-vv for very verbose)
 -x stylesheet   use the specified stylesheet instead of choosing one
 -m fragment use the XSL fragment to customize the stylesheet
 -o directoryput output in the specified directory instead of
 the current working directory

Re: Cygwin build documentation error.

[Aaron Gray]

Aaron Gray wrote:


I am getting errors on building Cygwin. It appears to be something to do
with the documentation.

Am I missing something simple such as a package like cygwin-doc and if so
where do I get it ?

Error text below...

Many thanks in advance,
[...]

`/usr/build/cygwin/i686-pc-cygwin/winsup/doc'

gcc -g /usr/src/src/winsup/doc/doctool.c -o doctool
./doctool -m -d /usr/src/src/winsup/doc -d /usr/src/src/winsup/utils -d
/usr/src/src/winsup/cygwin -s /usr/src/src/winsup/doc -o 
cygwin-ug-net.sgml

/usr/src/src/winsup/doc/cygwin-ug-net.in.sgml
xmlto html -o cygwin-ug-net/ -m /usr/src/src/winsup/doc/cygwin.dsl
cygwin-ug-net.sgml
usage: xmlto [OPTION]... FORMAT XML



This should go to the Cygwin list.  You're building in winsup, which is
not part of gcc, so this is totally off topic.

The answer is that you probably have a missing package, or maybe a
non-Cygwin/native version of xmlto in your PATH, but we don't know.
Send your cygcheck output as directed in cygwin.com/problems.html.

Brian


I have appended the cygcheck output as an attachment. And append the build 
error output ...


Many thanks in advance,

Aaron

make[3]: Entering directory `/usr/build/cygwin/i686-pc-cygwin/winsup/doc'
gcc -g /usr/src/src/winsup/doc/doctool.c -o doctool
./doctool -m -d /usr/src/src/winsup/doc -d /usr/src/src/winsup/utils -d 
/usr/src/src/winsup/cygwin -s /usr/src/src/winsup/doc -o cygwin-ug-net.sgml 
/usr/src/src/winsup/doc/cygwin-ug-net.in.sgml
xmlto html -o cygwin-ug-net/ -m /usr/src/src/winsup/doc/cygwin.dsl 
cygwin-ug-net.sgml

usage: xmlto [OPTION]... FORMAT XML
OPTIONs are:
 -v  verbose output (-vv for very verbose)
 -x stylesheet   use the specified stylesheet instead of choosing one
 -m fragment use the XSL fragment to customize the stylesheet
 -o directoryput output in the specified directory instead of
 the current working directory
 -p postprocopts pass option to postprocessor
 --extensionsturn on stylesheet extensions for this tool chain
 --searchpathcolon-separated list of fallback directories
 --skip-validation
 do not attempt to validate the input before processing

Available FORMATs depend on the type of the XML file (which is
determined automatically).

For documents of type "docbook":
fo
html
html-nochunks
htmlhelp
javahelp
man
txt
xhtml
xhtml-nochunks
xmlto html-nochunks -m /usr/src/src/winsup/doc/cygwin.dsl cygwin-ug-net.sgml
usage: xmlto [OPTION]... FORMAT XML
OPTIONs are:
 -v  verbose output (-vv for very verbose)
 -x stylesheet   use the specified stylesheet instead of choosing one
 -m fragment use the XSL fragment to customize the stylesheet
 -o directoryput output in the specified directory instead of
 the current working directory
 -p postprocopts pass option to postprocessor
 --extensionsturn on stylesheet extensions for this tool chain
 --searchpathcolon-separated list of fallback directories
 --skip-validation
 do not attempt to validate the input before processing

Available FORMATs depend on the type of the XML file (which is
determined automatically).

For documents of type "docbook":
fo
html
html-nochunks
htmlhelp
javahelp
man
txt
xhtml
xhtml-nochunks
cp cygwin-ug-net.html cygwin-ug-net/cygwin-ug-net-nochunks.html
rm -f cygwin-ug-net/cygwin-ug-net-nochunks.html.gz
gzip cygwin-ug-net/cygwin-ug-net-nochunks.html
./doctool -m -d /usr/src/src/winsup/doc -d /usr/src/src/winsup/utils -d 
/usr/src/src/winsup/cygwin -s /usr/src/src/winsup/doc -o cygwin-api.sgml 
/usr/src/src/winsup/doc/cygwin-api.in.sgml
xmlto html -o cygwin-api/ -m /usr/src/src/winsup/doc/cygwin.dsl 
cygwin-api.sgml

usage: xmlto [OPTION]... FORMAT XML
OPTIONs are:
 -v  verbose output (-vv for very verbose)
 -x stylesheet   use the specified stylesheet instead of choosing one
 -m fragment use the XSL fragment to customize the stylesheet
 -o directoryput output in the specified directory instead of
 the current working directory
 -p postprocopts pass option to postprocessor
 --extensionsturn on stylesheet extensions for this tool chain
 --searchpathcolon-separated list of fallback directories
 --skip-validation
 do not attempt to validate the input before processing

Available FORMATs depend on the type of the XML file (which is
determined automatically).

For documents of type "docbook":
fo
html
html-nochunks
htmlhelp
javahelp
man
txt
xhtml
xhtml-nochunks
xmlto html -o faq -m /usr/src/src/winsup/doc/cygwin.dsl 
/usr/src/src/winsup/doc/faq-sections.xml

usage: xmlto [OPTION]... FORMAT XML
OPTIONs are:
 -v  verbose output (-vv for very verbose)
 -x stylesheet   use the specified stylesheet instead of choosing one
 -m fragment use the XSL fragment to customize the stylesheet
 -o directoryput output in the specified directory instead of
 the current

Re: Successfull Build of gcc on Cygwin WinXp SP2

[Aaron Gray]

 JFTR, the patch is only required for building gcc, not for building 
winsup.

As Brian says, we'll deal with any winsup problems on the cygwin list.


Sorry for adding to the confusion as I am actually trying to build GCC CVS 
on Cygwin :)


Can you give me any indication of when the next version of Cygwin will be, 
and if it will have latest GCC from CVS ?


Aaron

Re: Successfull Build of gcc on Cygwin WinXp SP2

[Aaron Gray]

Successfully built latest gcc on Win XP SP2 with cvs built cygwin.


CVS Cygwin contains CVS newlib, i.e. already the patched version of
sdtdio.h, so if you use cvs built cygwin you should not patch anything.

To build GCC 4.3, you should simply move the new stdio.h on /usr/include.

You can also use the current Cygwin snapshot which comes with the new
stdio.h.


Great, where do I get Cygwin snapshots ?

Aaron

Re: Successfull Build of gcc on Cygwin WinXp SP2

[Aaron Gray]

You can also use the current Cygwin snapshot which comes with the new
stdio.h.


Great, where do I get Cygwin snapshots ?


Sorry, silly question.

Aaron

Re: Successfull Build of gcc on Cygwin WinXp SP2

[Aaron Gray]

On Tue, 1 May 2007, Aaron Gray wrote:


>> You can also use the current Cygwin snapshot which comes with the new
>> stdio.h.
>
> Great, where do I get Cygwin snapshots ?



Here:

  http://cygwin.com/snapshots/

The snapshots should be installed following this:

  http://cygwin.com/faq/faq-nochunks.html#faq.setup.snapshots



Thank you. I am a bit unsure of where abouts (what directory) do you install 
the snapshot ?


The FAQ does not seem to say that. From the instructions it would seem it 
would go in the current users directory.


I am a bit confused what winsup is as well.

Aaron

Re: Successfull Build of gcc on Cygwin WinXp SP2

[Aaron Gray]

Aaron Gray wrote:

Thank you. I am a bit unsure of where abouts (what directory) do you 
install

the snapshot ?


Again, this has nothing to do with gcc, take it the Cygwin list.  If you
are using the full snapshots (cygwin-inst-$date.tar.bz2) they should be
unpacked in the root (/).  The other types are just the cygwin1.dll
which goes in /usr/bin of course.  And again, you do *not* need to mess
with any of this to make stdio.h usable for building gcc.  Just take
stdio.h from newlib HEAD and place it in /usr/include.


The FAQ does not seem to say that. From the instructions it would seem it
would go in the current users directory.


Read it again.  Both tar commands include -C which means "cd to this
directory before extacting."


I am a bit confused what winsup is as well.


That is just a directory in the "src" tree that contains the code for
Cygwin, MinGW, w32api, and other miscellaneous Windows things.  But note
that you can't build Cygwin from just winsup/cygwin, as Cygwin needs
other parts of the "src" tree, such as libiberty and newlib.  When you
do a "cvs co cygwin" that is actually a CVS module that gets you a
selected subset of the entire "src" tree, including the toplevel scripts
that are shared across gcc/binutils/gdb/sim/etc.  If you later do "cvs
up" from the toplevel you'll accidently get the entire "src" tree which
you don't need, so you have to do "cvs up" in each individual directory.


Thanks. I think I understand most of that and will try again fresh tommorow.

I'll try not to bother the GCC list if I can possibly avoid it.

Thanks again,

Aaron

Variadic Template Specialization vis a vi the INCITS/ISO/IEC 14882-2011 standard

[Aaron Gray]

Prompted by a Stack Overflow article :-


http://stackoverflow.com/questions/17332749/vs2013-fails-with-variadic-template-specialization/

There seems to be anomalies between GCC 4.8.1's 0x11 implementation
and the standard.

It shows the code :-

template  struct OpF;

template  struct
OpF { };

int foo(int x) { return 0; }

OpF f;


Given the C++ Standard outlaws this code, see 14.1 paragraphs 11 and 15.

Note that GCC accepts the following code with either -std=gnu++11 or
-std=c++11, the latter should be strict to the standard. Also given
these paragraphs were in the draft C++ standard too.

On the other hand GCC 4.8.1 will not accept a simple trailing 'int'
parameter after a variadic template list.

 template < typename TR, typename ... Ts, int i> TR tester(Ts...);
// error: parameter pack ‘Ts’ must be at the end of the template
parameter list

There seems to be quite an inconsistency even in an augmentation to
the standard.

On a personal note both these forms are syntactically correct but not
semantically by the standard, given that this is just a simple type
based pattern matching problem as far as I can see it would be nice to
have it within the language as it seems to fit naturally with
requirements.

Regards,

Aaron

Re: Plan for removing global state from GCC's internals

[Aaron Gray]

I started to do this starting with the C++ parser class'izing it but
no one was interested.

On 1 July 2013 20:43, Joseph S. Myers  wrote:
> On Mon, 1 Jul 2013, David Malcolm wrote:
>
>> > As for accessing globals directly versus via APIs: yes, I suppose you do
>> > still have an access to a global class instance in each place you formerly
>> > had a global variable (that's now a member of that class), so by itself
>> > such a conversion to a better API doesn't reduce the number of global
>> > variable accesses, just improves the interface in other ways - and it's
>> > the changes to pass a pointer to an instance around that reduce the global
>> > state usage.  In the case of dump files, pass-local state may be a better
>> > place than the universe to keep the instance - it is after all passes.c
>> > that calls dump_start / dump_finish.
>>
>> So a pass instance should have its own dump_flags, and various dump
>> methods?  Perhaps, but as before, I'd prefer to fix the state issue
>
> Yes (or rather, the pass instance should contain an instance of the dumper
> class, which in turn has dump_flags and dump_file members) - as far as I
> can tell, the lifetime of dump_file and dump_flags is already basically
> per-pass rather than global.
>
>> Would you be in favor killing off these macros:
>>   #define input_line LOCATION_LINE (input_location)
>>   #define input_filename LOCATION_FILE (input_location)
>>   #define in_system_header (in_system_header_at (input_location))
>> with patches that make the usage of "input_location" explicit?  (by
>> replacing all uses of these macros with their expansions, cleaning up
>> line-wraps as needed).
>
> Yes.
>
>> The only other macro that implicitly uses input_location is
>> EXPR_LOC_OR_HERE; that could be removed in favor of:
>>   EXPR_LOC_OR_LOC(expr, input_location)
>> again making input_location explicit.
>
> (I suspect then eliminating the input_location from this - ensuring all
> expressions have meaningful locations so EXPR_LOC_OR_LOC isn't needed at
> all - will depend on Andrew MacLeod's proposal.  It doesn't explicitly
> mention this, but one thing that would be desirable as part of making
> front ends generate internal representation closer to the source would be
> explicitly representing locations for constants, and for references to
> declarations within expressions, so that everywhere that wants a location
> for an expression can reliably extract one from it rather than finding
> there is no location because certain expressions are shared.)
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

[cxx-conversion] gcc-4.7.0 on Cygwin and MinGW32 with --enable-build-with-cxx successes

[Aaron Gray]

Hi,

Just to let people know I have succeeded in building gcc-4.7.0 with
--enable-build-with-cxx (All stages built as C++) on latest Cygwin
with GCC 4.5.3 and on MinGW32 with a rebuilt GCC 4.6.2 as the GCC
4.6.2 that came with MinGW was missing stdarg.h and stddef.h and
possibly other headers.

Many thanks,

Aaron

Contributing and GCC GPL

[Aaron Gray]

Hi,

I have developed several patches for GCC and am wondering as a purely
open source non commercial developer whether there are any issues
regarding getting patches into GCC. Do I need to sign an agreement at
all ?

Many thanks in advance,

Aaron

copyright assignment forms for GCC

[Aaron Gray]

Hi,

I  would like copyright assignment forms for GCC. I am an independent
open source developer with no commercial connections. I have not
contributed to GCC as of yet, but have a number of possible patches
waiting to be sent. Currently they are all mods of existing code.

Many thanks in advance,

Aaron Gray

Re: The C++ conversion branch has been merged into trunk

[Aaron Gray]

On 15 August 2012 03:05, Diego Novillo  wrote:
>
> I have committed rev 190402, which merges the cxx-conversion branch into
> trunk.  Thanks to everyone who provided review feedback and tested the
> branch.
>
> While we have tested the changes pretty thoroughly, we will monitor results
> from testers for any new failures introduced by these changes. Please CC
> myself and Lawrence on any issues that may be related to the C++ changes.
>
> As discussed in http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html,
> there are no functional changes to the compiler. We tried very hard to limit
> the amount of API changes we introduced to minimize merge conflicts.
>
> Now that the changes are in trunk we will start changing the APIs to take
> advantage of the re-written data structures.
>
> I have also committed the changes to the home page news section and 4.8
> changes to reflect the new implementation language.

I have made Gengtype changes to support methods in structs/classes,
and other minor changes, and have modified latest 4.7 parser.c to
class'ize cp_parser and cp_lexer. I got operators (new) parsing, but
bumped into problems with the gengtype handwritten parser with regard
to constructors. So am currently working on a new gengtype frontend to
support C++ 2003.

Currently I am just waiting on GCC copyright assignment to come
through. I will update my changes to SVN head, and give a patch once
the copyright assignment has gone through.

Regards,

Aaron

C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h

[Aaron Gray]

Hi,

I have put in three patches on the 29th of August, but have not heard
any real feedback on them :-


[PATCH] Remove dependency of cp/cp-lang.c on cp/parser.h

http://gcc.gnu.org/ml/gcc-patches/2012-08/msg02010.html

[PATCH] limited C++ parsing support for gengtype

http://gcc.gnu.org/ml/gcc-patches/2012-08/msg02016.html

[PATCH] C++'ization of cp/parser.c/h

http://gcc.gnu.org/ml/gcc-patches/2012-08/msg02018.html


This last patch possibly needs freshening, but all were tested and
tested with the GCC testsuite.

Thanks,

Aaron

Re: C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h

[Aaron Gray]

On 10 September 2012 15:53, Gabriel Dos Reis
 wrote:
> [ I am adding back GCC mailing list in the CC: as this would be useful
> for other contributors. ]
>
> On Mon, Sep 10, 2012 at 9:42 AM, Aaron Gray  
> wrote:
>> On 10 September 2012 15:25, Gabriel Dos Reis 
>> wrote:
>>>
>>> On Mon, Sep 10, 2012 at 8:59 AM, Aaron Gray 
>>> wrote:
>>> > On 10 September 2012 14:35, Gabriel Dos Reis
>>> > 
>>> > wrote:
>>> >>
>>> >> On Mon, Sep 10, 2012 at 8:23 AM, Aaron Gray
>>> >> 
>>> >> wrote:
>>> >> > Hi,
>>> >> >
>>> >> > I have put in three patches on the 29th of August, but have not heard
>>> >> > any real feedback on them :-
>>> >> [...]
>>> >> > [PATCH] C++'ization of cp/parser.c/h
>>> >> >
>>> >> > http://gcc.gnu.org/ml/gcc-patches/2012-08/msg02018.html
>>> >> >
>>> >> >
>>> >> > This last patch possibly needs freshening, but all were tested and
>>> >> > tested with the GCC testsuite.
>>> >>
>>> >> You did receive a real feedback on the last patch.
>>> >
>>> >
>>> > Gaby,
>>> >
>>> > In reply, I was trying to do the first phase of a set of incremental
>>> > changes
>>> > towards normalizing the C++ frontend.
>>> >
>>> > Having looked at the complexity of parsing C++ and the complexity and
>>> > pragmatics of the semantics and the complexity of the GCC C++
>>> > "middleend"
>>> > code and know it to a degree then to have something working keep it
>>> > working
>>> > seems the best bet to me.
>>> >
>>> > So the interfaces can be made distinct and normalized while keeping the
>>> > code
>>> > running and passing the testsuite. Once the interfaces are distinct more
>>> > radical changes can be made.
>>> >
>>> > Just my 2cents,
>>> >
>>> > Aaron
>>> >
>>>
>>> Aaron,
>>>
>>> I am not sure I understand what you are saying.
>>> The patch I commented on was *radical* change from the current state, and
>>> there
>>> is no answer to why you needed to make such a radical change,
>>
>>
>> As I understand things we are C++'izing the GCC C++ frontend ?
>>
>> And encapsulation and class'ization seems to be the first step in doing that
>> I would have thought ?
>
> It is not clear what the benefit is to move existing perfectly working
> internal non-member functions to being member functions a huge struct.
>
> Encapsulation does not necessarily mean that all functions have to
> be member functions or that all data type definitions have to reside
> in a .h file.  In fact, I would argue that the patch you posted reduced
> encapsulation and abstraction, as opposed to increasing it.  Datatypes
> and member functions that have no business of being exposed to the
> entire world are now made public.

Next stage is to make the struct's classes and make most member
function private. I was not worried at this stage about exposing the
header as it is not used by ant other .c files except cp/cp-lang.c
which is not actually dependant upon parser.h hence my very basic
first patch.

>> My changes are orthogonal to the original code.
>
> No, they are not -- hence the comments.

please see above.

>
>> All I have done is create
>> classes out of the cp_lexer_* and cp_parser_* functions and moved a few
>> statics into the classes where it was logical and where there were no weird
>> dependencies stopping that being done.
>
> You did not provide a rationale of why it was logical to move those functions
> as you did.  The comments I made looked at the heart of the changes you made.

Sorry I should have explained the whole approach.

What I am looking to obtain is isolating the C++ parser with no real
semantic changes, just isolating the interfaces in order that the
parser be reusable as a library component and allow migration to other
solutions.

Aaron

Re: C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h

[Aaron Gray]

On 10 September 2012 16:54, Gabriel Dos Reis
 wrote:
> On Mon, Sep 10, 2012 at 10:41 AM, Aaron Gray  
> wrote:
>
>> What I am looking to obtain is isolating the C++ parser with no real
>> semantic changes, just isolating the interfaces in order that the
>> parser be reusable as a library component and allow migration to other
>> solutions.
>
> Yes, for that, you need reduce the scope of your patch.
>
> Use Occam's razor.  Do not move a declaration out of cp/parser.c unless
> you have a compelling reason for it.

Okay.

> "Classization" is not sufficient argument.

Its an incremental step forward.

> A good interface is likely to be reduced to the essential.
>
> I would suggest that you do not create any file out of cp/parser.c for the
> moment.  Just focus on identifying the interface of the parser within
> cp/parser.c.

It is actually two "generic" cross frontend functions that are linked
to and not actually declared in parser.h - 'c_parse_file()', via
cp/cp-lang.c and 'pragma_lex()', used by cp/lex.c.

But yes I agree. This comes down to 'cp_parser::translation_unit()',
afaics this is the only method that needs exposing in cp_parser.

> Do no move data types out of cp/parser.c unless there is a good reason for it.

Okay agreed.

> If an existing function does not "poke" into what should morally be
> (private)  data members of the cp_parser struct, don't make it a
> member function yet.

I made most statics. And also the next stage of making it a class and
member functions private would mean you would have to declare these
function friend functions ?

>  If a function does, then look at whether it can
> be expressed in terms of more reduced set of  observer/mutator functions;
> if that is the case, then do that.  Adding the observer/mutator function does
> not change semantics.  Isolating the interface means isolating the 
> computational
> basis.

I think this is another stage of abstraction all together.

Aaron

Possible headsup on GCC testsuite PCH failures

[Aaron Gray]

Can someone double check this for me I am getting 99 PCH failures on
the testsuite from GIT HEAD.

Many thanks in advance,

Aaron

When did 4.8 fork and where was it forked from ?

[Aaron Gray]

Hi,

I am trying to find out when 4.8 forked and where it actually forked from ?

This information does not seem immediately available.

Many thanks in advance,

Aaron

Re: How to understand gcc source code?

[Aaron Gray]

  * what is the proportion of cross-compilation? I have no real clue. I 
would suppose that during all the GCC runs in the last month, only a 
minority was cross-compilation (for some embedded systems). Of these, what 
are the favorite target machines & systems. I really don't know this one 
(maybe ARM or PowerPC32?).


Don't forget all the Linux based routers like OpenWRT and Netgear devices 
that are cross compiled using GCC. GCC+Linux is very scalable !


My 0.02 pence,

Aaron

Re: How to understand gcc source code?

[Aaron Gray]

Aaron Gray wrote:
  * what is the proportion of cross-compilation? I have no real clue. 
I would suppose that during all the GCC runs in the last month, only a 
minority was cross-compilation (for some embedded systems). Of these, 
what are the favorite target machines & systems. I really don't know 
this one (maybe ARM or PowerPC32?).


Don't forget all the Linux based routers like OpenWRT and Netgear 
devices that are cross compiled using GCC. GCC+Linux is very scalable !


Aren't they often ARM boards running Linux? But usually, you cross 
compile (on Linux/x86 or AMD64, towards target Linux/ARM or whatever)...


AFAIK Mainly MIP's based CPU's.

I'm more interested in figures from the GCC user perspective. A device 
with some embedded Linux, even if sold in the millions, has its software 
probably compiled only a few times for the last release (and perhaps a 
thousand times for its entire development). Linux based routers could 
not run the GCC compiler (inside the router)!


Yes, I was not totally clear in my "GCC+Linux" comment :)

Aaron

Re: Official GCC git repository

[Aaron Gray]

Hi -

On Fri, Mar 14, 2008 at 10:41:42AM -0400, Frank Ch. Eigler wrote:


[...]
OK, /git/gcc.git appears ready for you to populate & maintain.  Access
as {http,git,ssh}://gcc.gnu.org/gcc.git should all work.


Just a reminder - an empty git repository has been ready for you for some 
time.


Is there GIT Web support ?

Aaron

Re: Official GCC git repository

[Aaron Gray]

Hi -


>>OK, /git/gcc.git appears ready for you to populate & maintain.  Access
>>as {http,git,ssh}://gcc.gnu.org/gcc.git should all work.

Is there GIT Web support ?


I believe a quoted line above already answers that question.  But yes. :-)


Ah, http://gcc.gnu.org/git/ works, great.

Aaron

Re: More on GCC Back Ends

[Aaron Gray]

http://gcc.gnu.org/onlinedocs/gccint/Back-End.html
This mentions a file "config.gcc" which I can't find in the GCC source. 
This page tells too little I guess.


Its under the 'gcc' directory.

Aaron

Re: gcc-in-cxx branch created

[Aaron Gray]

Hi,

Just in case you are interested in it I have a 4.2.1 compiling and built 
using C++.


I have not really worked on it for quite a while now.

   http://www.gccpp.org

Download at :-

   http://www.gccpp.org/download/

Aaron

Re: Successfull Build of gcc on Cygwin WinXp SP2

[Aaron Gray]

On 03 May 2007 03:41, Aaron Gray wrote:

 Various people run the testsuite on cygwin every now and again; check 
the

gcc-testresults@ mailinglist archive.


Yes, Tim has allready run it :-

http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01540.html



 I haven't done one for weeks now


Looks like there are some real problems with GCC-4.3-20070427.

It fails to compile LLVM on both Cygwin and Linux producing rogue error 
messages and some weird bugs.


Aaron


Aaron

Re: GCC 4.2.0 RC3 Available

[Aaron Gray]

GCC 4.2.0 RC3 is now available from:

 ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501


It does not build LLVM there seems to be a stdlib++ problem.

I cannot really file a BugZilla report as I have not distilled the code down 
to make an accurate report.


Aaron

Re: GCC 4.2.0 RC3 Available

[Aaron Gray]

GCC 4.2.0 RC3 is now available from:

 ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501


It does not build LLVM there seems to be a stdlib++ problem.

I cannot really file a BugZilla report as I have not distilled the code 
down to make an accurate report.


Luckily it was just a local library file selection problem.

LLVM and LLVM-GCC4 build on GCC 4.2.0 RC3.

Aaron

Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot 20070427

[Aaron Gray]

I have successfully built GCC-4.2.0-20070501 on latest Cygwin snapshot 
20070427.


GCC 4.2.0 RC3 is available from:

   ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501

I have not done run the testsuite ( make check) but have built LLVM and 
LLVM-GCC4. So indications are very good.


Aaron

Re: Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot 20070427

[Aaron Gray]

On 06 May 2007 07:15, Aaron Gray wrote:


I have successfully built GCC-4.2.0-20070501 on latest Cygwin snapshot
20070427.

GCC 4.2.0 RC3 is available from:

ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501

I have not done run the testsuite ( make check)


 I'm doing that.  Should be finished in another day or so...  :-O


[ Note to self: never run make check with CYGWIN=error_start=insight. 
D'oh! ]


On the LLVM build I am getting multiple :-

   warning: visibility attribute not supported in this configuration; 
ignored


with the same line number, eight or so in some cases but usually two.

Have not looked into this properly yet, I missed it earlier when first 
building but on rebuilding have captured it in a log file for thurther 
examination.


I can put together a test example if required.

Report back if I find anything thurther.

Aaron

Re: Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot 20070427

[Aaron Gray]

- Original Message - 
From: "Dave Korn" <[EMAIL PROTECTED]>

To: "'Dave Korn'" <[EMAIL PROTECTED]>; "'Aaron Gray'" <[EMAIL PROTECTED]>
Cc: "'GCC'" 
Sent: Sunday, May 06, 2007 4:10 PM
Subject: RE: Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot 
20070427




On 06 May 2007 15:54, Dave Korn wrote:

[ Cygwin list snipped from CC line: not relevant there. ]



  If you can produce once that shows excess warnings being emitted, yes,
that would be worth filing a PR.  Hmm, a quick test I couldn't get excess
ones, but the line numbers all look wrong..


Filed as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31844.


It was on struct's or classes, I have not checked it but I think it but 
inheritance maybe the culprit.


Aaron

Re: Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot 20070427

[Aaron Gray]

Hi Aaron,

One issue that might affect many some is that COM doesn't work. 
 has a patch that is 
pending review I guess, but probably won't go into 4.2.


Its not a very big patch, shame it cannot be reviewed in time.

Does this effect XPCOM meaning Mozilla and friends will not compile ?

Aaron

Re: Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot 20070427

[Aaron Gray]

Aaron Gray wrote:

One issue that might affect many some is that COM doesn't work. 
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067> has a patch that 
is pending review I guess, but probably won't go into 4.2.



Does this effect XPCOM meaning Mozilla and friends will not compile ?


It is triggered anywhere multiple inheritance is combined with stdcall. 
 Since I believe XPCOM uses stdcall on Windows (but "cdecl" on other 
targets), I believe the answer here is 'Yes, Mozilla will not compile.'


But its fine on Unix platforms, that is good.

I am not sure if MinGW will/is used to compile Mozilla on Windows anyway.

I think it's likely that mingw.org will include this fix in their own 
releases of 4.2, which is probably a bad thing, as it makes the need to 
get this fix into official GCC sources seem less urgent.  A lot of GCC 
patches for Windows-related issues tend to stall for a long time in this 
state; I'm not really sure why.


Yes, this is perplexing.

Aaron

Re: Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot 20070427

[Aaron Gray]

Aaron Gray wrote:

One issue that might affect many some is that COM doesn't work. 
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067> has a patch that is 
pending review I guess, but probably won't go into 4.2.



Does this effect XPCOM meaning Mozilla and friends will not compile ?


It is triggered anywhere multiple inheritance is combined with stdcall. 
Since I believe XPCOM uses stdcall on Windows (but "cdecl" on other 
targets), I believe the answer here is 'Yes, Mozilla will not compile.'


Mozilla is built using Microsoft cl on Windows. And if 'cdecl' is used on 
Unix then there is no problem with XPCOM and GCC 4.2.0 RC3.


Aaron

genautomata.c bug

[Aaron Gray]

I think I have found some bugs in genautomata.c

   regexp = create_node( sizeof( struct decl));

I believe this should be :-

   regexp = create_node( sizeof( struct regexp));

Lines :-

   1546
   1551

Compare with :-

   1576

Aaron

Re: genautomata.c bug

[Aaron Gray]

On 5/14/07, Dave Korn <[EMAIL PROTECTED]> wrote:

On 14 May 2007 12:40, Wei Chen wrote:

> help~~
> where is the statement?

  At the line numbers Aaron mentioned of the latest rev of genautomata.c

> in whichi function?

  gen_regexp_el

> i can't confirm them now!

  Please see http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00882.html


cheers,
  DaveK
--
Can't think of a witty .sigline today




It's the same case in my GCC 3.4.5


I would not worry about it. It does no really effect genautomata only a few 
extra kbytes allocated.


Aaron

Mainline build problems

[Aaron Gray]

There are problems with :-

   print-rtl.c:395
   c-common.c:4099
   c-pretty-print.c:822
   dwarf2asm.c:56
   dwarf2out.c:...

It seems to be a unsigned issue to do with HOST_WIDE_INT_PRINT_HEX, 
HOST_WIDE_INT_PRINT_DOUBLE_HEX and friends.


Aaron 

Re: Mainline build problems

[Aaron Gray]

On 14 May 2007 18:48, Aaron Gray wrote:


There are problems with :-

print-rtl.c:395
c-common.c:4099
c-pretty-print.c:822
dwarf2asm.c:56
dwarf2out.c:...

It seems to be a unsigned issue to do with HOST_WIDE_INT_PRINT_HEX,
HOST_WIDE_INT_PRINT_DOUBLE_HEX and friends.


 Could you possibly be any more vague please?  I was overwhelmed by the 
sheer

deluge of information in that post  

 Seriously, Aaron, what kind of use is that report supposed to be?  No 
clue
as to what the "problem" is or even why you think one exists, no mention 
of
any error messages or warnings you might have seen, no mention of any 
symptoms

or misbehaviour that are why you think there is or may be problems, no
description other than "unsigned issue" of which there are many and 
varied, no

clue as to why you make the inference that
whatever-it-is-that-you-haven't-told-us might be related to those two 
format

strings

 Would you mind trying again please?  Your last report was much better!


Getting the following error on building from SVN trunk.

gcc/print-rtl.c:397: error: format '%lx' expects type 'long unsigned int', 
but argument 3 has type 'long int'


gcc/c-common.c:4099: error: format '%lx' expects type 'long unsigned int', 
but argument 4 has type 'long int'
gcc/c-common.c:4099: error: format '%lx' expects type 'long unsigned int', 
but argument 4 has type 'long int'


gcc/c-pretty-print.c:822: error: format '%lx' expects type 'long unsigned 
int', but argument 3 has type 'long int'


gcc/dwarf2asm.c:56: error: format '%lx' expects type 'long unsigned int', 
but argument 3 has type 'long int'


gcc/dwarf2out.c:2074: error: format '%lx' expects type 'long unsigned int', 
but argument 4 has type 'long int'
gcc/dwarf2out.c:5772: error: format '%4lu' expects type 'long unsigned int', 
but argument 3 has type 'dw_offset'
gcc/dwarf2out.c:5775: error: format '%lu' expects type 'long unsigned int', 
but argument 3 has type 'dw_offset'
gcc/dwarf2out.c:5823: error: format '%lu' expects type 'long unsigned int', 
but argument 3 has type 'dw_offset'
gcc/dwarf2out.c:7094: error: format '%lx' expects type 'long unsigned int', 
but argument 3 has type 'dw_offset'
gcc/dwarf2out.c:7276: error: format '%lx' expects type 'long unsigned int', 
but argument 4 has type 'dw_offset'


There maybe more ...

Aaron 

Re: mainline fails to build?

[Aaron Gray]

On 5/14/07, Mike Stump <[EMAIL PROTECTED]> wrote:


it gets farther.  Anyone want to claim this is obvious?  I glanced at
the code and it seems reasonable.


Nothing has changed in dwarf2out.c since April 24.

Now on the other hand c-format.c changed, which might have been the
problem in the first place.


Looks like either a change in hwint.h or several changes in #def macros.

Aaron

Something weird with cp/decl.c switch statement

[Aaron Gray]

There is something weird with the switch statement in cp/decl.c:7105.

GITWeb :-

http://git.infradead.org/?p=gcc.git;a=blob;f=gcc/cp/decl.c;h=407e5db8d650f1d19c618c7b67566407c2d35fce;hb=master#l7105

Can someone verify this.

Take a close look in a text editor at the bracketting and indentation.

I dont think it will effect the decl.c's logic, but what does it say about 
the GCC's C parser, is this legal C ?


Aaron 

Re: Something weird with cp/decl.c switch statement

[Aaron Gray]

On 6/5/07, Aaron Gray <[EMAIL PROTECTED]> wrote:

There is something weird with the switch statement in cp/decl.c:7105.
I dont think it will effect the decl.c's logic, but what does it say 
about

the GCC's C parser, is this legal C ?


Yes this is legal C :).
Just for everyone else the code looks like:
switch( a)
{
 case b:
 {
   ...
   break
   case c:
.
 }
}

case are just special kind of labels.


MS Visual Studio does not parse it. Are you sure its legal C ?

Aaron

Re: Something weird with cp/decl.c switch statement

[Aaron Gray]

On 6/5/07, Aaron Gray <[EMAIL PROTECTED]> wrote:

MS Visual Studio does not parse it. Are you sure its legal C ?


Yes I am.  Try this:
int f(int a)
{
 switch (a)
 {
   case 1:
   {
 int b = 2;
 break;
 case 2:
 break;
   }
 }
}

This is valid C90 and C99, though invalid C++98.

If you are using visual studio, make sure it is being compiled as C
and not C++.  C++ is not a true superset of C; anyone who thinks needs
to tell their CS teacher (or book author) that they are wrong and they
should relearn about the two languages.


Your right :)

Aaron

Re: use of %n in genmodes.c causes trouble on Vista

[Aaron Gray]

Danny Smith wrote:


Unless I'missing soemthing, this is 'just' a build issue in genmode.c.
GCC builds fine for Vista target on WindowsXP. So the fix needs to be 
build dependent, not host dependent.


Well if a clean fix can be found that simply avoids the use of %n, then
that's target independent and clean. I think that makes sense. The idea
that %n is a security risk is not some Microsoft-only invention, and it
is not unlikely that other environments will implement a similar check.


In case you have not seen it, this is the bit of code we are talking about 
:-


   
http://git.infradead.org/?p=gcc.git;a=blob;f=gcc/genmodes.c;h=8e71a123edb46166a16971bbf1862c2a0cfcf1b9;hb=master#l788

I think a sprintf followed by a strlen and printf is _guarenteed_ to be much 
more portable than printf's return value. The overhead of the strlen is 
minimal.


A simple fix that works on all platforms is all that is required.

Aaron

Re: use of %n in genmodes.c causes trouble on Vista

[Aaron Gray]

I think a sprintf followed by a strlen and printf is _guarenteed_ to be 
much

more portable than printf's return value. The overhead of the strlen is
minimal.


Maybe portable, but how do you choose the length of the buffer to pass
to sprintf!  Ironic: we'd be trading a mostly-bogus security issue for
a buffer overflow problem.


snprintf (from libiberty) ?

we should maybe check the maximum length of identifiers anyway ?

This thing is really trivial security wise anyway.

Aaron

SOOL Hashes

[Aaron Gray via Gcc]

a712557bc4d071895a30d5691395661c15d40f738e7090ea8ffc923e20d746ac2177374146a5699512a3a9f1d6e576ad4b070a78233d01ec9493f88e8564a198
 SOOL Presentation - in depth.pdf
532f84ce40ed291d7c00b3714904300c2bd538f836cb3bdf5b28003eb0c19ebdcf1f9faf0fabf8a3be6ecc6f7c29cfedd67464e467f98742445e0b2d555145d0
 SOOL Presentation - in depth.pptx
74294b176de8f4826e5881459de03c3f0f97da2896a5ab0075622baf4db68add8d8d580e6426523de3648cc9acdb89255142d3d473e5945ca2091915d91e71c9
 SOOL Presentation.pdf
7269bb7092991501f63631f548d4838bd8845645366bfd52fba452f3dbf470c3d0cd5194829b93789f74080884261eb9a6808aac7a98f73b0e0243cc0f1bd652
 SOOL Presentation.pptx

-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language
Researcher, Information Theorist, and Computer Scientist.

Wanted: original ConceptGCC downloads / branch, concepts-lite branch

[Aaron Gray via Gcc]

Hi,

I am looking for the original ConceptGCC source code, the
https://www.generic-programming.org/software/ConceptGCC/download.html has
all broken links and the SVN is gone.

Is this available on GCC git or SVN ?

Also I am wondering if the original concepts-lite code is available too
anywhere please ?

Also any pointers to the documentation for the current implementation ?

Regards,

Aaron
-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher,
Information Theorist, and Computer Scientist.

Re: Wanted: original ConceptGCC downloads / branch, concepts-lite branch

[Aaron Gray via Gcc]

On Wed, 17 Aug 2022 at 13:16, Ben Boeckel  wrote:
>
> On Wed, Aug 17, 2022 at 12:42:42 +0100, Aaron Gray via Gcc wrote:
> > I am looking for the original ConceptGCC source code, the
> > https://www.generic-programming.org/software/ConceptGCC/download.html has
> > all broken links and the SVN is gone.
> >
> > Is this available on GCC git or SVN ?
>
> There is this repo that may be of interest:
>
> https://github.com/asutton/gcc
>
> No idea of the state of it though or how useful it is for C++20
> Concepts.

Thanks this from 2018

Aaron
-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language
Researcher, Information Theorist, and Computer Scientist.

Re: Wanted: original ConceptGCC downloads / branch, concepts-lite branch

[Aaron Gray via Gcc]

>>> Also I am wondering if the original concepts-lite code is available too
>>> anywhere please ?
>>
>>
>> Define "original".

a post ConceptGCC, GCC branch implementation ?

>> Andrew Sutton's Concepts Lite implementation was merged into GCC trunk, and 
>> evolved to also support C++20 concepts.

Great thought so !

> I think it was merged in August 2015 and first released in GCC 6.1

I am just trying to get an overview of the implementation history, and
code bases.

Many thanks,

Aaron
-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language
Researcher, Information Theorist, and amateur Computer Scientist.

C++ Concepts: Working Paper n number ?

[Aaron Gray via Gcc]

Hi, Another query please.

I seem to have found the Concepts Technical Specification :-

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3929.pdf

But am looking for the n number of the C++ Concepts Working Paper ?

Many thanks in advance,

Aaron
-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher,
Information Theorist, and Computer Scientist.

Re: Wanted: original ConceptGCC downloads / branch, concepts-lite branch

[Aaron Gray via Gcc]

Great, thanks alot !

On Wed, 17 Aug 2022 at 21:23, Jonathan Wakely  wrote:
>
>
>
> On Wed, 17 Aug 2022, 16:20 Richard Earnshaw via Gcc,  wrote:
>>
>>
>>
>> On 17/08/2022 12:42, Aaron Gray via Gcc wrote:
>> > Hi,
>> >
>> > I am looking for the original ConceptGCC source code, the
>> > https://www.generic-programming.org/software/ConceptGCC/download.html has
>> > all broken links and the SVN is gone.
>> >
>> > Is this available on GCC git or SVN ?
>> >
>> > Also I am wondering if the original concepts-lite code is available too
>> > anywhere please ?
>> >
>> > Also any pointers to the documentation for the current implementation ?
>> >
>> > Regards,
>> >
>> > Aaron
>>
>> Not withstanding what others have already said, the various concepts
>> branches are still in the git repository, but aren't in the standard
>> pull set.  You can use git fetch to explicitly pull them:
>>
>> d743a72b52bcfaa1effd7fabe542c05a30609614refs/dead/heads/c++-concepts
>>
>>
>
>
> This is "concepts lite".
>
>
>> 780065c813a72664bd46a354a2d26087464c74fc
>> refs/dead/heads/conceptgcc-branch
>>
>>
>
>
> I think this was Doug Gregor's work, but I don't know how much of ConceptGCC 
> is present on the branch.
>
>
>> ce85971fd96e12d0d6675ecbc46c9a1884df766c
>> refs/dead/heads/cxx0x-concepts-branch
>> 14d4dad929a01ff7179350f0251af752c3125d74
>
>
>
> This is described at https://gcc.gnu.org/git.html as:
>
> "This branch contains the beginnings of a re-implementation of Concepts, a 
> likely future feature of C++, using some of the code from the prototype 
> implementation on conceptgcc-branch. It is not currently maintained."
>
> I don't know who did this work, check the git history.



-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language
Researcher, Information Theorist, and amateur computer scientist.

Re: C++ Concepts: Working Paper n number ?

[Aaron Gray via Gcc]

Wonderful, thank you !

On Wed, 17 Aug 2022 at 22:04, Jonathan Wakely  wrote:
>
>
>
> On Wed, 17 Aug 2022, 16:52 Aaron Gray via Gcc,  wrote:
>>
>> Hi, Another query please.
>>
>> I seem to have found the Concepts Technical Specification :-
>>
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3929.pdf
>
>
>
> That's an old draft, see https://en.cppreference.com/w/cpp/experimental for 
> the ISO TS number and the draft numbers.
>
>>
>>
>> But am looking for the n number of the C++ Concepts Working Paper ?
>
>
> Do you mean C++0x Concepts? N2042, and see N2618.
>
>


-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language
Researcher, Information Theorist, and amateur computer scientist.

Issues with -Wno-format-truncation

[Aaron Gray via Gcc]

I think is an issue with GCC's buffer overflow analysis accuracy

Found an issue for it, on GCC v12.4, I am using v13.3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374

I have found quite a lot of issues relating to this on StackOverflow
and elsewhere but no reference to it on the GCC mailing list.

Hoping this might be fixed soon, it might reduce quite a lot of noise.

https://github.com/AaronNGray/pdfalto/actions/runs/13463238846/job/37623204502#step:9:450
```
/home/runner/work/pdfalto/pdfalto/src/AnnotsXrce.cc:444:59: warning:
‘%lg’ directive output may be truncated writing between 1 and 13 bytes
into a region of size 8 [-Wformat-truncation=]
450 444 | snprintf(temp, sizeof(temp), "%lg", x);
451 | ^~~
452/home/runner/work/pdfalto/pdfalto/src/AnnotsXrce.cc:444:58: note:
assuming directive output of 12 bytes
453 444 | snprintf(temp, sizeof(temp), "%lg", x);
454 | ^
```

```
snprintf(temp, sizeof(temp), "%lg", x);
```
https://github.com/AaronNGray/pdfalto/blob/buffer-overflows/src/AnnotsXrce.cc#L444

```
char *temp = (char *) malloc(16 * sizeof(char));
```
https://github.com/AaronNGray/pdfalto/blob/buffer-overflows/src/AnnotsXrce.cc#L419

-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language
Researcher, Information Theorist, and amateur computer scientist.