Help with workflow
Hi Everyone This is my first post here. I need help mapping a enjoyable workflow from GnuCOBOL to GCC. I love COBOL and with GnuCOBOL, I can compile one of my programs to intermediate C and then take the GnuCOBOL source code for the runtime and the C outputted and hop around though it using ctags. It is great to write something in COBOL and then to see how it is actually implemented in the runtime in C. I want to do the same thing with Ada. This was my first attempt: gcc -c -gnatDGL but the output wasn't really that meaningful, it was basically just my program with no ctag links into the runtime. I tried to create a little shell script : gcc -c -fdump-tree-original-raw ada83_syntax.adb gcc -c -fdump-tree-gimple-raw ada83_syntax.adb gcc -c -fdump-tree-cfg-raw ada83_syntax.adb ctags ../*.[ch] ../ada/* *.original *.gimple *.cfg gvim ../*.[ch] ../ada/* *.original *.gimple *.cfg tags I was hoping that I would catch the top level C code and that it would help. It didn't seem to. Could anyone help with what I am trying to do? Thanks for reading-Pat
Re: Help with workflow
On 2020-12-20 7:24 a.m., Arnaud Charlet wrote:
Pat,
Not sure what you are trying to do . Are you trying to generate C code
from Ada? If so, can you clarify why? In other words, what is the high level
problem you are trying to solve and that you'd like to achieve? Is it the
ability to navigate in Ada code?
If you want to generate C from Ada, GCC isn't the right tool, since GCC
doesn't generate C code, it generates an intermediate representation which
is then translated into assembly code directly, without ever generating C code.
Arno
Hi Arnaud
Thanks for responding to my post. I am not trying to generate C but to
follow the intermediate representation into the Ada runtime.
So let's just say we had this:
*with* Ada.Text_IO;
*use* Ada.Text_IO;
*procedure* Do_Delays*is*
*begin*
Put_Line("Wait 5 seconds.");
*delay* 5.0;
Put_Line("Wait 2 seconds.");
*delay* 2.0;
Put_Line("Wait 7 seconds.");
*delay* 7.0;
Put_Line("That's all folks.");
*end* Do_Delays;
I want to follow "delay" through the intermediate representation into the Ada
runtime to see where the code actually causes a pause state to occur.
I can do this with GnuCOBOL because it compiles to C but that is not the case
here and I can't seem to figure out how to follow the code as it is being
translated through it's various stages and into the runtime.
Thanks again-Pat
Re: at web: /install/specific.html
On Wednesday 20 April 2005 06:12 am, Gerald Pfeifer wrote: > On Tue, 1 Mar 2005, Alec Voropay wrote: > > It seems, the local on the GCC web page > > http://gcc.gnu.org/install/specific.html > > does not work due to wrong HTML format. > > I'm afraid that, originally, I didn't understand what you meant by this, > but I believe that I do now and thus I committed a fix for this problem > two days ago. I think he meant it has the wrong doctype. That is clearly an xhtml document, but it has an html4 doctype. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgphonpeKFB6G.pgp Description: PGP signature
GCC 4.0.0 fsincos?
Hi,
I'm interested in gcc 4.0.0 because I believe it's supposed to generate
the fsincos instruction on x86 when appropriate.
I have the following code sample which I use to generate two random
Gaussian numbers, for which I think fsincos should probably be generated
by the compiler,
typedef double realv;
complex ComplexGaussRandom(realv s2, MTRand& Random)
{
realv B = 2.0 * pi * Random.rand();
realv R = sqrt( -s2 * log(1- Random.rand53()));
return R * complex(cos(B), sin(B));
}
If I compile with
$ ~/usr/bin/gcc-4.0.0 -S Com_Code.cc -ffast-math -O2
the relevant generated code section is
#APP
fldln2; fxch; fyl2x
#NO_APP
fmulp %st, %st(2)
fxch%st(1)
#APP
fsqrt
#NO_APP
fld %st(1)
#APP
fsin
#NO_APP
fxch%st(2)
#APP
fcos
#NO_APP
fxch%st(2)
movl8(%ebp), %eax
fmul%st(1), %st
fxch%st(1)
fmulp %st, %st(2)
fstpl 8(%eax)
fstpl (%eax)
addl$12, %esp
popl%ebx
popl%esi
popl%edi
popl%ebp
ret $4
So after generating R, a separate fsin and fcos seem to be generated. Am I
missing an option or something?
Thanks,
Patrick
$ ~/usr/bin/gcc-4.0.0 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --program-suffix=-4.0.0
--prefix=/home/mitran/usr
Thread model: posix
gcc version 4.0.0
Re: Reporting bugs: there is nothing to gain in frustrating reporters
On Thursday 16 June 2005 08:20 am, Daniel Berlin wrote: > You deny that Bug 21809 is the same bug as Bug 323, which was closed in > 1999? No, clearly, its some form of time travel by aliens wanting to subvert GCC to their own evil purposes. Vincent is their leader. I, for one, welcome our new Lefevrian overlords. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgphvSAXgbsGB.pgp Description: PGP signature
Re: Reporting bugs: there is nothing to gain in frustrating reporters
On Saturday 18 June 2005 02:52 am, Vincent Lefevre wrote: > Saying that the x86 processor is buggy is just completely silly. > Only some gcc developers think so. Yeah, the smart ones. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpMOhMZrQdEL.pgp Description: PGP signature
gcc developers, donate money to help fight cancer!
John Hall, the author of /Programming Linux Games/, and someone who I consider a friend, was diagnosed with Stage IV Melanoma, which is very life threatening. He's asking the public to help donate to the American Cancer Society ( http://www.acsevents.org/faf/r.asp?t=4&i=99915&u=99915-86454580 ), he's trying to raise $1,000 for melanoma research. All money donated goes straight to the American Cancer Society. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpNCmcXzSEta.pgp Description: PGP signature
Re: gcc installation on PowerPC
On Monday 15 August 2005 06:37 pm, Vijaya Kishore Idimadakala wrote: > Can anybody help?? Any tiny help is greatly > appreciated. This is a list for developers. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpNpaYI8Lm08.pgp Description: PGP signature
Re: Wiki Broken?
On Wednesday 24 August 2005 12:58 pm, Niko Matsakis wrote: > Indeed, I forgot that WikiName's must be MixedCase. Also known as BumpyCaps. Today's useless fact was brought to you by the letters A and K, and the number 47. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpjspGMxWLsx.pgp Description: PGP signature
[Fwd: GCC 4.0 bug]
I'm forwarding this message from a coworker.
He ran into this regression bug with GCC 4.0.1 (it works correctly in
3.4.1).
The conditional operator expression isn't handling static consts
correctly resulting in linker errors since it is trying to resolve to
statics that were never defined.
struct Foo
{
static const inta = 1;
static const intb = 2;
};
inline voidfoo(bool v)
{
std::cout << ((v) ? (Foo::a) : (Foo::b));
}
_Z3foob:
.LFB1425:
.file 1 "foo.cpp"
.loc 1 10 0
pushl %ebp
.LCFI0:
movl%esp, %ebp
.LCFI1:
subl$24, %esp
.LCFI2:
movl8(%ebp), %eax
movb%al, -4(%ebp)
.LBB2:
.loc 1 12 0
cmpb$0, -4(%ebp)
je .L2
movl_ZN3Foo1aE, %eax
movl%eax, -8(%ebp)
jmp .L4
.L2:
movl_ZN3Foo1bE, %eax
movl%eax, -8(%ebp)
.L4:
movl-8(%ebp), %eax
movl%eax, 4(%esp)
movl$_ZSt4cout, (%esp)
call_ZNSolsEi
.LBE2:
.loc 1 13 0
leave
ret
.LFE1425:
.size _Z3foob, .-_Z3foob
No declaration of _ZN3Foo1aE and _ZN3Foo1bE.
Changed Foo to:
struct Foo
{
static const inta;
static const intb;
};
const int Foo::a = 1;
const int Foo::b = 2;
Assembly of function the same, but in addition:
.globl _ZN3Foo1bE
.section.rodata
.align 4
.type _ZN3Foo1bE, @object
.size _ZN3Foo1bE, 4
_ZN3Foo1bE:
.long 2
.globl _ZN3Foo1aE
.align 4
.type _ZN3Foo1aE, @object
.size _ZN3Foo1aE, 4
_ZN3Foo1aE:
.long 1
Thanks,
Patrick Bennett
struct: link to next field
Hi everybody,
I am working on the intermediary tree representation of GCC right now
(writing a parser for it). I have a question regarding that.
If I declare a struct containing 2 fields like that in C:
struct foo {
int var_a;
char var_b;
} afoo;
afoo.var_a = 0;
afoo.var_b = 'a';
the abstract syntax tree I get (with -fdump-tree-original) does not
include information about the 2nd field (var_b) at the point of
declaration of the struct type. The declaration of 'var_b" is done only
at the point where I use it. That can be seen from the following struct
type declaration (in intermediary representation):
@147var_decl name: @149 type: @150 scpe: @1
srcp: InitAutoTestA.c:37 size: @6
algn: 32 used: 1
@149identifier_node strg: "afoo" lngt:4
@150record_type name: @153 size: @6 algn: 32
struct flds: @154 fncs: @155
binf: @156
@152expr_stmtline: 40 expr: @159 next: @160
@153type_declname: @161 type: @150 scpe: @1
srcp: InitAutoTestA.c:34 artificial
@154field_decl name: @162 type: @7 scpe: @150
srcp: InitAutoTestA.c:35 public
size: @10 algn: 32 bpos: @163
@155function_declname: @164 type: @165 scpe: @150
srcp: InitAutoTestA.c:34 artificial
operator assign member
public args: @166 undefined
static
@156binfotype: @150
@161identifier_node strg: "foo " lngt:3
@162identifier_node strg: "var_a " lngt:5
@163integer_cst type: @13 low : 0
the flds field of the record_type (@150) points to the field_decl of
var_a (@154), but there is not link to the field_decl of var_b at that
place.
However the GCC documentation (section 9.4.2 Classes) says: "Almost all
non-function members are available on the TYPE_FIELDS list. Given one
member, the next can be found by following the TREE_CHAIN." But I see no
chain or list in the present case.
I am using gcc version 3.3.5 (under Debian Linux).
Has anyone an idea why there is no link to the next field?
Cheers,
Pat
Extraneous newline emitted between error messages in GCC 6
GCC 6, compared to GCC 5, now emits an extra newline between error messages. Is this intended? $ cat error.c int x = a; int y = b; $ gcc-5 error.c error.c:1:9: error: ‘a’ undeclared here (not in a function) int x = a; ^ error.c:2:9: error: ‘b’ undeclared here (not in a function) int y = b; ^ $ gcc-6 error.c error.c:1:9: error: ‘a’ undeclared here (not in a function) int x = a; ^ error.c:2:9: error: ‘b’ undeclared here (not in a function) int y = b; ^ $
Re: Please, take '-Wmisleading-indentation' out of -Wall
I'm sad that this discussion died so soon without Antonio's points being adequately addressed.
Re: Please, take '-Wmisleading-indentation' out of -Wall
On Mon, May 30, 2016 at 1:06 PM, Jakub Jelinek wrote: > On Mon, May 30, 2016 at 01:01:09PM -0400, Patrick Palka wrote: >> I'm sad that this discussion died so soon without Antonio's points >> being adequately addressed. > > But how do you want to address that? His point is that it does not belong > into -Wall, while there seems to be a wide agreement that it should be part > of -Wall, it found lots of real bugs in wide range of code, and for projects > that just want to use weirdo formatting styles they always have option to > opt-out, using -Wno-misleading-indentation. > > Jakub Yeah, I guess you're right. There is nothing really left to address since the remaining points of contention are mostly subjective, like as to whether or not the warnings emitted by -Wmisleading-indentation are sufficiently easy to work around as required by the criteria of -Wall. (In some cases it may require re-indenting huge blocks of code, for example, but that's still mechanically easy I guess.) Though there are some inconsistencies regarding the inclusiveness of -Wall seeing as neither -Woverlength-strings nor -Wempty-body are enabled by -Wall even though they seemingly satisfy the criteria of -Wall more readily than -Wmisleading-indentation does.
Error building GCC 6.1.0 libstdc++
Hi, I'm running into a build problem when building GCC 6.1.0: /home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/./gcc/xgcc -shared-libgcc -B/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/./gcc -nostdinc++ -L/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/src -L/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/src/.libs -L/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/libsupc++/.libs -B/home/patrick/src/e7/toolchain/stage2/powerpc-eabispe/bin/ -B/home/patrick/src/e7/toolchain/stage2/powerpc-eabispe/lib/ -isystem /home/patrick/src/e7/toolchain/stage2/powerpc-eabispe/include -isystem /home/patrick/src/e7/toolchain/stage2/powerpc-eabispe/sys-include -L/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/./ld-x c++-header -nostdinc++ -g -O2 -I/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/include/powerpc-eabispe -I/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/include -I/home/patrick/src/e7/toolchain/src/gcc-combined/libstdc++-v3/libsupc++ -O2 -g /home/patrick/src/e7/toolchain/src/gcc-combined/libstdc++-v3/include/precompiled/extc++.h -o powerpc-eabispe/bits/extc++.h.gch/O2g.gch In file included from /home/patrick/src/e7/toolchain/src/gcc-combined/libstdc++-v3/include/precompiled/extc++.h:69:0: /home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/include/ext/throw_allocator.h:545:18: error: 'uniform_real_distribution' in namespace 'std' does not name a template type typedef std::uniform_real_distribution distribution_type; ^~~~~~~~~ /home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/include/ext/throw_allocator.h:546:18: error: 'mt19937' in namespace 'std' does not name a type typedef std::mt19937 engine_type; ^~~ I've done some analysis of this and it turns out to be an issue with the C library I'm using. The configure test "checking for ISO C99 support to TR1 in " is failing. This stops _GLIBCXX_USE_C99_STDINT_TR1 from being defined which subsequently causes the above build failure because doesn't include anymore. Is this a bug in the build system? If _GLIBCXX_USE_C99_STDINT_TR1 is required then should the configure abort? Alternatively, should libstdc++ still build without _GLIBCXX_USE_C99_STDINT_TR1? Patrick
Should the build system use ar rcs instead of ranlib + ar rc?
The build step that invokes "ranlib libbackend.a" (which immediately follows the invocation of "ar rc libbackend.a ...") takes over 7 seconds on my machine and causes the entire 450MB archive to be rewritten. By instead making the build system use ar rcs -- so that the archive and its index are built at once -- the time it takes for the compiler to get rebuilt gets reduced by 25%, from 27s to 20s (in a --disable-bootstrap tree after touching a random source file). This is a pretty significant reduction in compile time and disk io. Is this a good idea? Here's the patchlet I used: -- >8 -- diff --git a/Makefile.in b/Makefile.in index 117fbf5..5ebc3a3 100644 --- a/Makefile.in +++ b/Makefile.in @@ -393,7 +393,7 @@ MAKEINFOFLAGS = --split-size=500 AS = @AS@ AR = @AR@ -AR_FLAGS = rc +AR_FLAGS = rcs CC = @CC@ CXX = @CXX@ DLLTOOL = @DLLTOOL@ diff --git a/Makefile.tpl b/Makefile.tpl index 94a4f79..72ba24b 100644 --- a/Makefile.tpl +++ b/Makefile.tpl @@ -396,7 +396,7 @@ MAKEINFOFLAGS = --split-size=500 AS = @AS@ AR = @AR@ -AR_FLAGS = rc +AR_FLAGS = rcs CC = @CC@ CXX = @CXX@ DLLTOOL = @DLLTOOL@ diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 0786fa3..1c3a637 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -236,7 +236,7 @@ BISONFLAGS = FLEX = @FLEX@ FLEXFLAGS = AR = @AR@ -AR_FLAGS = rc +AR_FLAGS = rcs NM = @NM@ RANLIB = @RANLIB@ RANLIB_FLAGS = @ranlib_flags@ @@ -1883,17 +1883,14 @@ compilations: $(BACKEND) libbackend.a: $(OBJS) -rm -rf libbackend.a $(AR) $(AR_FLAGS) libbackend.a $(OBJS) - -$(RANLIB) $(RANLIB_FLAGS) libbackend.a libcommon-target.a: $(OBJS-libcommon-target) -rm -rf libcommon-target.a $(AR) $(AR_FLAGS) libcommon-target.a $(OBJS-libcommon-target) - -$(RANLIB) $(RANLIB_FLAGS) libcommon-target.a libcommon.a: $(OBJS-libcommon) -rm -rf libcommon.a $(AR) $(AR_FLAGS) libcommon.a $(OBJS-libcommon) - -$(RANLIB) $(RANLIB_FLAGS) libcommon.a # We call this executable `xgcc' rather than `gcc' # to avoid confusion if the current directory is in the path
Re: Should the build system use ar rcs instead of ranlib + ar rc?
On Sat, Jul 16, 2016 at 4:27 AM, Andreas Schwab wrote: > Andrew Pinski writes: > >> On Fri, Jul 15, 2016 at 6:46 PM, Patrick Palka wrote: >>> The build step that invokes "ranlib libbackend.a" (which immediately >>> follows the invocation of "ar rc libbackend.a ...") takes over 7 seconds >>> on my machine and causes the entire 450MB archive to be rewritten. By >>> instead making the build system use ar rcs -- so that the archive and >>> its index are built at once -- the time it takes for the compiler to get >>> rebuilt gets reduced by 25%, from 27s to 20s (in a --disable-bootstrap >>> tree after touching a random source file). This is a pretty significant >>> reduction in compile time and disk io. >>> >>> Is this a good idea? >> >> Yes and no. Do we know if all ar support rcs now? > > It is easy to find out: run a configure check. I see, I was not aware that non-GNU ar is supported. I posted a patch on gcc-patches that uses a configure check at https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00991.html > > Andreas. > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different."
PowerPC rs6000 multilib combinations
Hi, I've recently been using a target (e200z6) where a "-mno-spe -mabi=no-spe" libgcc was required. The closest combination provided by 4.9.1 was "-mno-spe -mabi=no-spe -mno-isel". My builds disable spe, but leave isel enabled. Unfortunately, with this combination of options gcc uses an incompatible libgcc which includes spe instructions. I have attached a patch which enables the "-mno-spe -mabi=no-spe" multilib. It seems a bit broken that gcc would use an spe version of libgcc when I specify "no-spe". Hopefully someone finds the patch useful. Kind regards, Patrick --- gcc/config/rs6000/t-spe.orig 2014-09-16 13:55:57.649114878 +1000 +++ gcc/config/rs6000/t-spe 2014-09-16 13:56:37.393116284 +1000 @@ -23,6 +23,7 @@ # -mcpu=7400 -maltivec -mabi=altivec # -mcpu=7400 -msoft-float # -msoft-float +# -mno-spe -mabi=no-spe # -mno-spe -mabi=no-spe -mno-isel # so we'll need to create exceptions later below. @@ -56,7 +57,6 @@ *msoft-float/*mno-spe* \ *msoft-float/*mabi=no-spe* \ *msoft-float/*mno-isel* \ - mno-spe/mabi=no-spe \ mno-spe/mno-isel \ mabi=no-spe/mno-isel \ mno-isel/mlittle \ @@ -67,7 +67,6 @@ mcpu=7400/maltivec/mlittle \ mabi=no-spe/mlittle \ mno-spe/mno-isel/mlittle \ - mno-spe/mabi=no-spe/mlittle \ mabi=altivec/mlittle \ maltivec/mlittle \ maltivec/mabi=altivec/mlittle
GSoC Project Ideas
Hi everyone, I am very interested in working on GCC as part of GSoC this year. A few years ago I was a somewhat active code contributor[1] and unfortunately my contributing waned once I went back to school, but I'm excited to potentially have the opportunity to work on GCC again this summer. My contributions were mainly to the C++ frontend and to the middle end, and I've been thinking about potential projects in these areas of the compiler. Here are some project ideas related to parts of the compiler that I've worked on in the past: * Extend VRP to track unions of intervals (inspired by comment #2 of PR72443 [2]) Value ranges tracked by VRP currently are represented as an interval or its complement: [a,b] and ~[a,b]. A natural extension of this is to support unions of intervals, e.g. [a,b]U[c,d]. Such an extension would make VRP more powerful and at the same time would subsume anti-ranges, potentially making the code less complex overall. * Make TREE_NO_WARNING more fine-grained (inspired by comment #7 of PR74762 [3]) TREE_NO_WARNING is currently used as a catch-all marker that inhibits all warnings related to the marked expression. The problem with this is that if some warning routine sets the flag for its own purpose, then that later may inhibit another unrelated warning from firing, see for example PR74762. Implementing a more fine-grained mechanism for inhibiting particular warnings would eliminate such issues. * Make -Wmaybe-uninitialized more robust (Inspired by the recent thread to move -Wmaybe-uninitialized to -Wextra [4]) Right now the pass generates too many false-positives, and hopefully that can be fixed somewhat. I think a distinction could be made between the following two scenarios in which a false-positive warning is emitted: 1. the pass incorrectly proves that there exists an execution path that results in VAR being used uninitialized due to a deficiency in the implementation, or 2. the pass gives up on exhaustively verifying that all execution paths use VAR initialized (e.g. because there are too many paths to check). The MAX_NUM_CHAINS, MAX_CHAIN_LEN, etc constants currently control when this happens. I'd guess that a significant fraction of false-positives occur due to the second case, so maybe it would be worthwhile to allow the user to suppress warnings of this second type by specifying a warning level argument, e.g. -Wmaybe-uninitialized=1|2. Still, false-positives are generated in the first case too, see e.g. PR61112. These can be fixed by improving the pass to understand such control flow. * Bug fixing in the C++ frontend / general C++ frontend improvements There are 100s of open PRs about the C++ frontend, and the goal here would just be to resolve as many as one can over the summer. Would any of these ideas work as a GSoC project? Regards, Patrick Palka [1]: https://gcc.gnu.org/git/?p=gcc.git;a=search;s=ppalka;st=author [2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72443#c2 [3]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74762#c7 [4]: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00020.html
Re: GSoC Project Ideas
Hi Richard, Jakub and Martin,
First of all I'm sorry for the very late reply, and I will be more
punctual with my replies from now on.
On Fri, Mar 8, 2019 at 4:35 AM Richard Biener
wrote:
>
> On Thu, Mar 7, 2019 at 7:20 PM Martin Sebor wrote:
> >
> > On 3/4/19 6:17 AM, Richard Biener wrote:
> > > On Mon, Mar 4, 2019 at 1:23 PM Jakub Jelinek wrote:
> > >>
> > >> On Mon, Mar 04, 2019 at 01:13:29PM +0100, Richard Biener wrote:
> > >>>>>* Make TREE_NO_WARNING more fine-grained
> > >>>>> (inspired by comment #7 of PR74762 [3])
> > >>>>>TREE_NO_WARNING is currently used as a catch-all marker that
> > >>>>> inhibits all
> > >>>>>warnings related to the marked expression. The problem with
> > >>>>> this is that
> > >>>>>if some warning routine sets the flag for its own purpose,
> > >>>>>then that later may inhibit another unrelated warning from
> > >>>>> firing, see for
> > >>>>>example PR74762. Implementing a more fine-grained mechanism
> > >>>>> for
> > >>>>>inhibiting particular warnings would eliminate such issues.
> > >>>> Might be interesting. You'd probably need to discuss the details
> > >>>> further.
> > >>>
> > >>> I guess an implementation could use TREE_NO_WARNING (or
> > >>> gimple_no_warning_p)
> > >>> as indicator that there's out-of-bad detail information which could be
> > >>> stored as
> > >>> a map keyed off either a location or a tree or gimple *.
> > >>
> > >> I guess on tree or gimple * is better, there would need to be some hook
> > >> for
> > >> copy_node/gimple_copy that would add the info for the new copy as well if
> > >> the TREE_NO_WARNING or gimple_no_warning_p bit was set. Plus there
> > >> could be
> > >> some purging of this on the side information, e.g. once code is handed
> > >> over
> > >> from the FE to the middle-end (maybe do that only at free_lang_data
> > >> time),
> > >> for any warnings that are FE only there is no need to keep records in
> > >> the on
> > >> the side mapping that have info about those FE warnings only, as later on
> > >> the FE warnings will not be reported anymore.
> > >> The implementation could be e.g. a hash map from tree/gimple *
> > >> (pointers) to
> > >> bitmaps of warning numbers, with some hash table to ensure that the same
> > >> bitmap is used for all the spots that need to have the same set of
> > >> warnings
> > >> disabled.
This design makes a lot of sense, thank you for this!
> > >
> > > A possibly related project is to "defer" output of diagnostics until we
> > > know
> > > the stmt/expression we emit it for survived dead code elimination. Here
> > > there's
> > > the question what to key the diagnostic off and how to move it (that is,
> > > detect
> > > if the code causing it really fully went dead).
Interesting. Which diagnostics would you have in mind to defer in this way?
> >
> > Another (maybe only remotely related) aspect of this project might
> > be getting #pragma GCC diagnostic to work reliably with middle-end
> > warnings emitted for inlined code. That it doesn't work is one of
> > the frustrations for users who run into false positives with "late"
> > warnings like -Wstringop-overflow or -Wformat-overflow.
Thank you Martin for bringing this up!
>
> A similar issue is they are not carried along from compile-time to
> LTO link time. I'm not even sure how they are attached to anything
> right now ... certainly not in DECL_FUNCTION_SPECIFIC_OPTIMIZATION.
This is good to know too.
I know that there is only a week left to submit a proposal, but I am
thinking of a project proposal that can be summarized in one line as
"Improving the diagnostics infrastructure of GCC," which combines the
original proposal about a finer-grained
TREE_NO_WARNING/gimple_no_warning mechanism along with Richard's and
Martin's ideas of preserving diagnostic pragmas after inlining and for
LTO link time, and maybe Richard's idea of being able to defer
diagnostics until we know for sure that the code in question survives
DCE. Would such a proposal be well-defined and tractable enough for
GSoC? If so, would anyone volunteer to be a mentor for this project?
Regards,
Patrick
>
> > I'm sure there are bugs that track this but here's a test case
> > involving -Warray-bounds:
> >
> >int a[3];
> >
> >int f (int i)
> >{
> > return a[i];
> >}
> >
> >#pragma GCC diagnostic push
> >#pragma GCC diagnostic ignored "-Warray-bounds"
> >int g (void)
> >{
> > return f (7); // expect no -Warray-bounds
> >}
> >#pragma GCC diagnostic pop
> >
> >int h (void)
> >{
> > return f (7); // expect -Warray-bounds
> >}
> >
> > Martin
Re: GSoC Project Ideas
On Sun, Mar 3, 2019 at 5:16 PM Jeff Law wrote: > > On 3/3/19 4:06 PM, Patrick Palka wrote: > > Hi everyone, > > > > I am very interested in working on GCC as part of GSoC this year. A few > > years > > ago I was a somewhat active code contributor[1] and unfortunately my > > contributing waned once I went back to school, but I'm excited to > > potentially > > have the opportunity to work on GCC again this summer. My contributions > > were > > mainly to the C++ frontend and to the middle end, and I've been thinking > > about > > potential projects in these areas of the compiler. Here are some project > > ideas > > related to parts of the compiler that I've worked on in the past: > > > > * Extend VRP to track unions of intervals > > (inspired by comment #2 of PR72443 [2]) > > Value ranges tracked by VRP currently are represented as an interval > > or > > its complement: [a,b] and ~[a,b]. A natural extension of this is > > to support unions of intervals, e.g. [a,b]U[c,d]. Such an extension > > would make VRP more powerful and at the same time would subsume > > anti-ranges, potentially making the code less complex overall. > You should get in contact with Aldy and Andrew. I believe their work > already subsumes everything you've mentioned here. > > > > > > > * Make TREE_NO_WARNING more fine-grained > > (inspired by comment #7 of PR74762 [3]) > > TREE_NO_WARNING is currently used as a catch-all marker that inhibits > > all > > warnings related to the marked expression. The problem with this is > > that > > if some warning routine sets the flag for its own purpose, > > then that later may inhibit another unrelated warning from firing, > > see for > > example PR74762. Implementing a more fine-grained mechanism for > > inhibiting particular warnings would eliminate such issues. > Might be interesting. You'd probably need to discuss the details further. > > > > > > * Make -Wmaybe-uninitialized more robust > > (Inspired by the recent thread to move -Wmaybe-uninitialized to > > -Wextra [4]) > > Right now the pass generates too many false-positives, and hopefully > > that > > can be fixed somewhat. > > I think a distinction could be made between the following two > > scenarios in > > which a false-positive warning is emitted: > > 1. the pass incorrectly proves that there exists an execution path > > that > >results in VAR being used uninitialized due to a deficiency in > > the > >implementation, or > > 2. the pass gives up on exhaustively verifying that all execution > > paths > >use VAR initialized (e.g. because there are too many paths to > > check). > >The MAX_NUM_CHAINS, MAX_CHAIN_LEN, etc constants currently > > control > >when this happens. > > I'd guess that a significant fraction of false-positives occur due to > > the > > second case, so maybe it would be worthwhile to allow the user to > > suppress > > warnings of this second type by specifying a warning level argument, > > e.g. > > -Wmaybe-uninitialized=1|2. > > Still, false-positives are generated in the first case too, see e.g. > > PR61112. These can be fixed by improving the pass to understand such > > control flow. > I'd suggest you look at my proposal from 2005 if you want to improve > some of this stuff. > > You might also look at the proposal to distinguish between simple > scalars that are SSA_NAMEs and the addressable/aggregate cases. > > In general I'm not a fan of extending the predicate analysis as-is in > tree-ssa-uninit.c. I'd first like to see it broken into an independent > analysis module. The analysis it does has applications for other > warnings and optimizations. Uninit warnings would just be a client of > hte generic analysis pass. > > I'd love a way to annotate paths (or subpaths, or ssa-names) for cases > where the threaders identify a jump threading path, but don't actually > optimize it (often because it's a cold path or to avoid code bloat > problems). THese unexecutable paths that we leave in the CFG are often > a source of false positives when folks use -O1, -Os and profile directed > optimizations. Bodik has some thoughts in this space, but I haven't > really looked to see how feasible they are in the real world. Hi J
Re: Obsolete powerpc*-*-*spe*
On 15/02/17 01:49, Segher Boessenkool wrote:
It is also used in many PPC based microcontrollers, which are used in
the automotive industry and other places where you need highly reliable
and robust but powerful microcontrollers. However, gcc support for
these has traditionally been poor - there is little support for the
variety of cores and configurations available from Freescale/NXP. I
believe there is a chicken-and-egg situation here - few people use gcc
with these devices because there is poorer device support compared to
Freescale CodeWarrior or Green Hills, and there is little incentive for
gcc developers (such as the CodeSourcery or IBM PPC folks) to support
devices in gcc if no one uses that combination.
Yes, we use GCC also one these chips, however, due to the lack of VLE
support the situation is even worse. Looks like support for the non-IBM
PowerPC is dead in GCC. I can understand this pretty well.
It's not true though; we still support all those cores, just not the
VLE extension (we never have), and I propose GCC 7 will drop the SPE
extension as well -- not all other support we have for those cores.
They will have to use soft float, alas.
Will the SPFP APU still be supported?
Kind regards,
Patrick
Re: Obsolete powerpc*-*-*spe*
On 15/02/17 01:49, Segher Boessenkool wrote:
With the Qualcomm takeover of Freescale/NXP I guess the PowerPC has no
future in this area and they will move to ARM for the processor cores.
That is my understanding as well, yes.
Our reps have suggested that the opposite may well be the case: It's
Qualcomm buying into a large segment of the automotive MCU market.
I know of at least two issues they will face with an ARM takeover:
1. There's an enormous amount of legacy PowerPC code out there.
2. Currently only small (Cortex-M0/M3) cores are available in the 150C+
operating temperature ratings required for some automotive (engine bay
or on engine) installations.
Of course these things can be overcome, but it will take time and effort.
Patrick
[trans-mem] _ITM_abortTransaction not considered as noreturn function
Dear Richard,
When I was looking at this problem of tail call optimization, I have
found that _ITM_abortTransaction was not considered as a 'noreturn'
function. Do you have any reason not doing this? If not, I propose to
add ECF_NORETURN in calls.c:special_function_p().
Also I just want to point out that BUILT_IN_TM_START is missing in this
switch/case but I think I figure out why it is ok to not have it (except
in the case of nested transactions).
Thanks in advance for your time,
Patrick Marlier.
Index: calls.c
===
--- calls.c (revision 170149)
+++ calls.c (working copy)
@@ -473,9 +473,10 @@
{
switch (DECL_FUNCTION_CODE (fndecl))
{
+ case BUILT_IN_TM_ABORT:
+ flags |= ECF_NORETURN;
case BUILT_IN_TM_COMMIT:
case BUILT_IN_TM_COMMIT_EH:
- case BUILT_IN_TM_ABORT:
case BUILT_IN_TM_IRREVOCABLE:
case BUILT_IN_TM_GETTMCLONE_IRR:
case BUILT_IN_TM_MEMCPY:
Re: [trans-mem] _ITM_abortTransaction not considered as noreturn function
On 02/15/2011 05:33 PM, Richard Henderson wrote: On 02/15/2011 12:35 AM, Patrick Marlier wrote: When I was looking at this problem of tail call optimization, I have found that _ITM_abortTransaction was not considered as a 'noreturn' function. Do you have any reason not doing this? If not, I propose to add ECF_NORETURN in calls.c:special_function_p(). DEF_TM_BUILTIN (BUILT_IN_TM_ABORT, "_ITM_abortTransaction", BT_FN_INT, ATTR_TM_NORETURN_NOTHROW_LIST) It's already marked noreturn. The big switch in special_function_p is only there to add ECF_TM_OPS, for which we do not have an attribute. Thanks for the explanation. Now I get it. Patrick.
Re: Integration of transactional memory support into a data-flow extension of OpenMP
Hi Ismail! My study mainly focuses on integration of transactional memory support into data-flow extension of OpenMP that is aiming increased expressiveness and performance while preserving the paradigms' properties. I am really happy to see people working with transactional memory. I will try to follow your work. My project combines development and research components and can be decomposed into 5 phases. 1. Study the compatibility of the transactional memory and OpenMP constructs in the transmem development branch of GCC and propose solutions to the possible technical difficulties. In the Velox project, one application named QuakeTM was using TM and OpenMP without problem but I know that the OpenMP was not used extensively. So probably you will find some problems. 2. Study the desgin and implementation of both data-flow (streaming) and transmem branches of GCC, interacting with their maintainers. I am not a maintainer (not yet at least) of the trans-mem branch but I know quite well TM and some part of implementation details in gcc. So if you post questions, I will try to answer them. Note : Just an example code from LeeTM for compatibility research of OpenMP and trans-mem . #define MEMSET _ITM_memsetW #define MEMCPY _ITM_memcpyRtWt #define BEGIN_TRANSACTION \ _ITM_beginTransaction (pr_instrumentedCode | pr_hasNoIrrevocable\ | pr_hasNoAbort) #define END_TRANSACTION \ _ITM_commitTransaction () Why did you use explicit calls to _ITM_* functions? why not using the __transaction semantic? // transaction body lee->layNextTrack(track, targ->private_buffer); Did you transactify accesses in this function? or does it use only MEMSET and MEMCPY? (I have tried LeeTM only one time and I can't remember implementation details.) There is not a big performance difference between our approach (OpenMP + trans-mem) and (pthreads + tinySTM). Interesting. Actually I am one of the developers of TinySTM and I am quite interested to see exact results. Good luck and feel free to ask questions. Patrick Marlier.
Re: Integration of transactional memory support into a data-flow extension of OpenMP
Dear Ismail, On 05/03/2011 11:18 PM, ismail wrote: >> ++ First of all, MEMCPY and MEMSET functions do not include any >> transaction identifier (id) and transactions inside the LeeTM fails >> during transactional access to the memory. I think this case is also >> for tinySTM-0.9.9 and tinySTM-1.0. >> >> ++ tinySTM-0.9.9 has mem access functions with transaction handlers as >> the following >> ++stm_word_t stm_load(stm_tx_t *tx, volatile stm_word_t *addr); >> ++void stm_store(stm_tx_t *tx, volatile stm_word_t *addr, stm_word_t >> value); >> ++void stm_store2(stm_tx_t *tx, volatile stm_word_t *addr, stm_word_t >> value, stm_word_t mask); >> >> >> ++but tinySTM-1.0 does not . Your opinions on these different version >> of mem-access functions would be great. TinySTM 1.0 uses implicit transaction descriptor by default (same as 0.9.9) but you can compile it with EXPLICIT_TX_PARAMETER (Makefile) and then the transaction descriptor is explicit. But functions are the same from 0.9.9 to 1.0.0 so I don't really see the problem. >> ++My idea to convert from one version of mem-access function to >> another is as the following: >> >> >> ++ I think I have to make some explicit function calls as the >> following: >> ++ _ITM_transaction * td = _ITM_getTransaction(); >> ++int doWhat = >> _ITM_beginTransaction(td,pr_instrumentedCode,&txn_start_loc); >> ++ . >> ++_ITM_transactionId cur_id = _ITM_getTransactionId(); I do not understand that... >> ++ Of course , It would be great to share the study and results with >> you when I organize my study and all other things. I guess we will meet together at the EuroTM meeting in Paris. Patrick Marlier.
Re: Integration of transactional memory support into a data-flow extension of OpenMP
Dear Ismail, On Fri, 6 May 2011, ismail wrote: TinySTM 1.0 uses implicit transaction descriptor by default (same as 0.9.9) but you can compile it with EXPLICIT_TX_PARAMETER (Makefile) and then the transaction descriptor is explicit. But functions are the same from 0.9.9 to 1.0.0 so I don't really see the problem. --- Yes . thanks for update , I remembered . Also I wrote the version wrong it is "0.9.0b1 release". There should be a parameter like EXPLICIT_TX_PARAMETER in trans-mem. Did you need a kind of parameter --- while compiling the trans-mem branch ? For example to use trans-mem to transactify LeeTM (I am especially talking about the MEMSET and MEMCPY funcs. of trans-mem do not have transaction identifier while accessing to the mem.). --- I am currently using the explicit function calls when I need transaction identifier as the following. Humm... libitm is always using implicit transaction descriptor and there is no such flag as in TinySTM. Don't confuse transaction descriptor and transaction identifier. I think it is better to use always implicit transaction descriptor it avoids the burden to manage it. --- I tried to get transaction handler which does not ---have explicit ---descriptor where another function needs transaction ---descriptor as ---a parameter. Hummm... which one has explicit tx descriptor? All ITM functions are using implicit transaction descriptor as far as I remember, otherwise it is a bit odd. Patrick.
[4.7,trans-mem] Summary of unsolved known bugs
Hi Guys! Transactional Memory will be released in 4.7 so even if it is experimental, I hope it will come with only few bugs in it. Users could be enthusiastic to test it so it could be great to offer them a great experience. Here a list of known bugs for trans-mem. I have tried to sort it by priority (highest first). * Stack save/restore not working? -> XFAIL testcases Related to this: ICE: verify_gimple failed: invalid rhs for gimple memory store with -fgnu-tm --param tm-max-aggregate-size=32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51472 [trans-mem] save/restore of thread-local data in nested txns is missing http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49581 * Caller-save happens on _ITM_beginTransaction ([trans-mem] Segfault in libitm when compiling with -O2) -> Fix proposed but probably not optimal. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48625 * [trans-mem] problem with TM clone aliases Leads to add _ITM_getTMCloneOrIrrevocable in a __transaction_atomic. -> Fix proposed. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51516 * ICE: in function_and_variable_visibility, at ipa.c:835 with -O -fgnu-tm and overriding virtual transaction_safe function -> Fix proposed. http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01182.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51411 * ICE: verify_flow_info failed: BB 3 can not throw but has an EH edge with -fgnu-tm -fnon-call-exceptions and transaction_callable http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51212 * ICE when lto1 does not have -fgnu-tm and object file uses TM http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51280 * AIX unexpected error_mark node in new TM tests -> Probably already fixed? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51174 Probably should be closed: * libitm failures http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51124 * infinite loop when compiling http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48075 Fixed but still open: * ICE: vector VEC(inline_summary_t,base) index domain error, in inline_summary at ipa-inline.h:193 with -O -fgnu-tm, transaction_safe and overloaded contructor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51273 * ICE: SIGSEGV in ix86_init_builtins (i386.c:27691) with -fgnu-tm and any fortran code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51291 I hope this message could help. Do not hesitate to complete the list (I can try to have a look at it) or close bugs (I cannot do it). I take the opportunity of this message to thank Richard, Aldy and Torvald for the work done on trans-mem. Patrick Marlier.
Re: [4.7,trans-mem] Summary of unsolved known bugs
On 12/15/2011 03:07 PM, Jack Howarth wrote: on x86_64-apple-darwin11. While Linux/ia32 and Linux/x86-64 don't seem to be exhibiting those failures any more, I don't see any analysis of the cause of the previous failures or fixes proposed to address these. Did the problem just go latent on those targets perhaps? Thanks Jack! You are true. I just paid attention to those failures (I though it was fixed). Some may be due to Darwin or x86_64, I only get memcpy/memset failures. Patrick.
Re: [4.7,trans-mem] Summary of unsolved known bugs
Wonderful! Thanks Aldy. On 12/21/2011 09:11 AM, Aldy Hernandez wrote: * ICE when lto1 does not have -fgnu-tm and object file uses TM http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51280 I believe I wasn't able to reproduce this. Arg really! For the openmp testcase, I was wrong but the tm testcase should show the problem. Please, can you (and maybe someone else) confirm that I am not the only one to see that? (Note I have started a thread here about that: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01221.html) Patrick.
[trans-mem] RFC Fix missing REG_TM notes
In trans-mem.c:make_tm_edge, it gets the slot for insertion but it
doesn't set it. Fixing this makes cfgexpand.c:
mark_transaction_restart_calls fails because sometimes the instruction
is not found. In the attached patch, I just ignore if insn is NULL but
do you have an idea why this happens?
On my side, I was able to fix the problem with genome but the patch is
not clean at all and I need to find exactly where and why the problem
was fixed.
Thanks!
--
Patrick Marlier.
Index: trans-mem.c
===
--- trans-mem.c (revision 183019)
+++ trans-mem.c (working copy)
@@ -2517,6 +2517,7 @@ make_tm_edge (gimple stmt, basic_block bb, struct
{
n = ggc_alloc_tm_restart_node ();
*n = dummy;
+ *slot = n;
}
else
{
Index: cfgexpand.c
===
--- cfgexpand.c (revision 183019)
+++ cfgexpand.c (working copy)
@@ -1978,16 +1978,22 @@ mark_transaction_restart_calls (gimple stmt)
tree list = n->label_or_list;
rtx insn;
- for (insn = next_real_insn (get_last_insn ());
- !CALL_P (insn);
+ /* ??? mark only the first call, is it right? */
+ for (insn = get_last_insn ();
+ insn && !CALL_P (insn);
insn = next_real_insn (insn))
continue;
+ /* ??? insn can be NULL, why? -> some reg_note are missing. */
+ if (!insn || find_reg_note(insn, REG_TM, NULL_RTX))
+ return;
+
if (TREE_CODE (list) == LABEL_DECL)
add_reg_note (insn, REG_TM, label_rtx (list));
else
for (; list ; list = TREE_CHAIN (list))
add_reg_note (insn, REG_TM, label_rtx (TREE_VALUE (list)));
+
}
}
Re: [trans-mem] RFC Fix missing REG_TM notes
On 01/09/2012 04:04 PM, Torvald Riegel wrote: On Mon, 2012-01-09 at 15:55 -0500, Patrick Marlier wrote: On my side, I was able to fix the problem with genome but the patch is not clean at all and I need to find exactly where and why the problem was fixed. What do you mean? Do you still see issues with Genome, even with the returns-twice patch? If so, just on i686 or x86_64 too? With libitm? Sorry for confusion. Of course, I disabled your returns-twice patch. I patched at different places and I hope to figure out where is the problem and that it is not a side effect... I am currently testing on x86_64 with libitm. Patrick.
Re: [4.7,trans-mem] Summary of unsolved known bugs
On 01/09/2012 05:20 AM, Torvald Riegel wrote: * ICE when lto1 does not have -fgnu-tm and object file uses TM > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51280 Still open? Yes. I have started a thread here: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01221.html But as I said, probably out of my knowledge... Here some more PR: * Bug 51698 - [trans-mem] TM runtime and application with LTO * [libitm, build] Clear hardware capabilities on libitm.so with Sun ld http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02093.html Not sure to know the status of this (Rainer?). PR? * Bug 51773 - error building libitm/aatree.cc on ARM * Bug 51173 - XFAIL: libitm.c++/static_ctor.C error: unsafe function call ‘void __cxa_guard_release(long long int*)’ within ‘transaction_safe’ function error: unsafe function call ‘int __cxa_guard_acquire(long long int*)’ within ‘transaction_safe’ function The static initialization is using locks. One way to fix that is to transform the acq/rel to a transaction, right? * Bug 51124 - libitm failures FAIL: libitm.c++/eh-1.C execution test -> Darwin: Xcode 4+ problem http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00329.html -> Solaris: ?. -- Patrick Marlier
Re: [trans-mem] RFC Fix missing REG_TM notes
On 01/09/2012 04:19 PM, Patrick Marlier wrote: On 01/09/2012 04:04 PM, Torvald Riegel wrote: On Mon, 2012-01-09 at 15:55 -0500, Patrick Marlier wrote: On my side, I was able to fix the problem with genome but the patch is not clean at all and I need to find exactly where and why the problem was fixed. What do you mean? Do you still see issues with Genome, even with the returns-twice patch? If so, just on i686 or x86_64 too? With libitm? Sorry for confusion. Of course, I disabled your returns-twice patch. I patched at different places and I hope to figure out where is the problem and that it is not a side effect... I am currently testing on x86_64 with libitm. Patrick. Continuation... In genome, the problem is that in ira-lives.c the bb has lost its abnormal edge and thus this 'if' is never satisfied for TM back edge. /* Allocnos can't go in stack regs at the start of a basic block that is reached by an abnormal edge. Likewise for call clobbered regs, because caller-save, fixup_abnormal_edges and possibly the table driven EH machinery are not quite ready to handle such allocnos live across such edges. */ if (bb_has_abnormal_pred (bb)) The bb has lost its abnormal edge here in cfgbuild.c:gimple_expand_cfg /* At the moment not all abnormal edges match the RTL representation. It is safe to remove them here as find_many_sub_basic_blocks will rediscover them. In the future we should get this fixed properly. */ if ((e->flags & EDGE_ABNORMAL) && !(e->flags & EDGE_SIBCALL)) remove_edge (e); So if I apply the modification from the previous post and if I don't remove_edge here, genome seems to work correctly. Actually, I don't really know what to do with this remove_edge... I hope this may help you guys! and thanks in advance for any comment on this (I will be happy to learn!). -- Patrick Marlier.
Re: [trans-mem] RFC Fix missing REG_TM notes
On 01/09/2012 04:19 PM, Patrick Marlier wrote:
On 01/09/2012 04:04 PM, Torvald Riegel wrote:
On Mon, 2012-01-09 at 15:55 -0500, Patrick Marlier wrote:
On my side, I was able to fix the problem with genome but the patch is
not clean at all and I need to find exactly where and why the problem
was fixed.
What do you mean? Do you still see issues with Genome, even with the
returns-twice patch? If so, just on i686 or x86_64 too? With libitm?
Sorry for confusion. Of course, I disabled your returns-twice patch. I
patched at different places and I hope to figure out where is the
problem and that it is not a side effect...
I am currently testing on x86_64 with libitm.
Patrick.
Attached the patch which makes genome works on my side on x86_64.
Torvald: could you tell me if it fixes the problem for you?
I did a regression test and no new failure (I should bootstrap and
regtest again, I will do it once I have a feedback on this).
Thanks.
--
Patrick Marlier.
Index: trans-mem.c
===
--- trans-mem.c (revision 183073)
+++ trans-mem.c (working copy)
@@ -2517,6 +2517,7 @@ make_tm_edge (gimple stmt, basic_block bb, struct
{
n = ggc_alloc_tm_restart_node ();
*n = dummy;
+ *slot = n;
}
else
{
Index: cfgexpand.c
===
--- cfgexpand.c (revision 183073)
+++ cfgexpand.c (working copy)
@@ -1978,11 +1978,16 @@ mark_transaction_restart_calls (gimple stmt)
tree list = n->label_or_list;
rtx insn;
- for (insn = next_real_insn (get_last_insn ());
- !CALL_P (insn);
+ /* ??? mark only the first call, is it right? */
+ for (insn = get_last_insn ();
+ insn && !CALL_P (insn);
insn = next_real_insn (insn))
continue;
+ /* ??? insn can be NULL, why? -> some reg_note are missing. */
+ if (!insn || find_reg_note(insn, REG_TM, NULL_RTX))
+ return;
+
if (TREE_CODE (list) == LABEL_DECL)
add_reg_note (insn, REG_TM, label_rtx (list));
else
@@ -4598,6 +4603,7 @@ gimple_expand_cfg (void)
find_many_sub_basic_blocks will rediscover them.
In the future we should get this fixed properly. */
if ((e->flags & EDGE_ABNORMAL)
+ && !(e->flags & EDGE_ABNORMAL_CALL)
&& !(e->flags & EDGE_SIBCALL))
remove_edge (e);
else
Index: gtm-builtins.def
===
--- gtm-builtins.def (revision 183073)
+++ gtm-builtins.def (working copy)
@@ -1,5 +1,5 @@
DEF_TM_BUILTIN (BUILT_IN_TM_START, "_ITM_beginTransaction",
- BT_FN_UINT_UINT, ATTR_TM_NOTHROW_RT_LIST)
+ BT_FN_UINT_UINT, ATTR_TM_NOTHROW_LIST)
DEF_TM_BUILTIN (BUILT_IN_TM_COMMIT, "_ITM_commitTransaction",
BT_FN_VOID, ATTR_TM_NOTHROW_LIST)
Re: [trans-mem] RFC Fix missing REG_TM notes
On 01/10/2012 05:39 PM, Richard Henderson wrote: Also outstanding is that the return value setup for beginTransaction needs to be adjusted into the new block. I.e. we current generate (set (reg eax) (call _ITM_beginTransaction)) (set (reg psuedo) (reg eax)) .Lrestart: // rest of tm block This must be (set (reg eax) (call _ITM_beginTransaction)) .Lrestart: (set (reg psuedo) (reg eax)) // rest of tm block lest the register allocator do the wrong thing. Yep good point. It means moving the insn from one BB to the next BB but I have no idea how to do it and where it should be done. Thanks. -- Patrick.
[trans-mem,libitm] brief report on known bugs
Let's do an update of the known reported bugs and for trans-mem/libitm. Thanks to everybody who helped in reporting, fixing, improving and reviewing trans-mem things. *Known bugs and eventually fixed in 4.7 or 4.8* trans-mem: * Bug 52141 - [trans-mem] ICE due to asm statement in trans-mem.c:expand_block_tm * Bug 51173 - XFAIL: libitm.c++/static_ctor.C error: unsafe function call ‘void __cxa_guard_release(long long int*)’ within ‘transaction_safe’ function error: unsafe function call ‘int __cxa_guard_acquire(long long int*)’ within ‘transaction_safe’ function The static initialization here is using locks. One way to fix that is to transform the acq/rel always by a transaction. Making them transaction_pure is not enough because in the constructor, the transaction may abort and so the lock will not be released. * Bug 52142 - [trans-mem] inlined transaction_pure functions are instrumented * Bug 51752 - trans-mem: publication safety violated * Bug 51252 - FAIL: c-c++-common/tm/freq.c (internal compiler error) -> Not fixed for all arch. * Bug 52042 - libitm.c/clone-1.c (all darwin) and libitm.c/stackundo.c (darwin 11) execution tests fail with -fpie for clone-1.c, the problem is that getsectdata doesn't work with -fpie. Fix proposed but I guess it needs some work to deal with all situations. * (No PR) - eh-1.C execution failures seen at -m32/-m64 on x86_64 darwin10/11 when built with Xcode 4.2(.1). The problem is due to a bug in darwin/Xcode 4.0 to 4.3 with weak references. http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00329.html http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00285.html http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01676.html So it fails to detect GCC_CHECK_ELF_STYLE_WEAKREF. Probably needs a workaround? *Features for 4.8* trans-mem: * Bug 51771 - trans-mem: abnormal edges get lost or corrupted -> Solved with return_twice for 4.7 but needs work for 4.8. -> part of the fix is here: http://gcc.gnu.org/ml/gcc/2012-01/msg00099.html * Bug 46480 - [trans-mem] Uninstrumented code path is missing libitm: * Bug 51855 - improve calculation of stack bottom in libitm's undolog * Bug 51169 - XFAIL: libitm.c/dropref-2.c execution test Bug 51170 - XFAIL: libitm.c/dropref.c execution test Bug 51172 - XFAIL: libitm.c++/dropref.C execution test Same problem for all the 3 PR, ie missing ABI feature. ABI feature will be implemented eventually. Do tests shoud be removed and added later when the feature is implemented? * (No PR) [libitm] libitm.h is not installed The fix is simple but maybe a reason for not exposing this to TM user? By the way, should it be renamed to simply itm.h? Thanks! -- Patrick Marlier.
Re: GCC aliasing rules: more aggressive than C99?
Richard Guenther wrote: On Sun, Jan 3, 2010 at 6:46 AM, Joshua Haberman wrote: ... elision by patrick of part of a quote of 6.5 Expressions #7... * an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or Literally interpreting this sentence the way you do removes nearly all advantages of type-based aliasing that you have when dealing with disambiguating a pointer dereference vs. an object reference and thus cannot be the desired interpretation (and thus we do not allow this). Since it would be hard to read this any other way, it seems then you maintain that you found a bug in the standard, has it been brought up to the committee? The latest draft I see still has that wording. Doesn't seem to be on the radar for C1x. This same thing has bitten me, though I agree with your rationale about how it would be a bad idea, still strictly speaking, gcc is not standards compliant on this one point, and rather than change gcc, the defect in the standard could be changed. If you don't have anyone participating on the committee right now, you only have to convince some one who is, e.g. Nick Stoughton or P. J. Plauger or Herb Sutter, right? It basically would force us to treat *ptr vs. Obj as *ptr vs. *(Obj *)ptr2. ...more elision I have seen other articles that interpret the standard in this way. See section "Casting through a union (2)" from this article, which claims that casts of this sort are legal and that GCC's warnings against them are false positives: http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html Yes, this article contains many mistakes but the author failed to listen. This one thing is, you say, not a mistake of the author but a mistake in the standard, and it's unkind to characterize it like that ...elided a bunch--patrick... Correct. GCC follows its own documentation here, not some random websites and maybe not the strict reading of the standard. There are other corner-cases where it does so, namely with the union type rule (which I fail to come up with a std reference at the moment). I hope in all of these cases it's been brought up as an issue, defects in the standard won't get fixed if there are no squeaky wheels! Patrick
Re: GCC aliasing rules: more aggressive than C99?
Erik Trulsson wrote:
Moreover I think you are misinterpreting 6.5 clause 7 (which I concede is
fairly easy since it is not quite as unambiguous as one could wish).
I believe that paragraph should not be interpreted as automatically allowing
all accesses that correspond to one of the sorts listed. Rather it should
be interpreted as saying that if an access is not included in that list then
it is not allowed, but even if it is included in that list there could be
other reasons why it is not allowed. (I.e. just as the attached footnote
suggests it is a list of what types of aliasing are allowed, not of which
pointers may be dereferenced.)
Good point, they're saying that something other than this list is
undefined for sure.
While the C Standard says in this section:
7 An object shall have its stored value accessed only by an lvalue
expression that has one of the following types:78)
with footnote 78 saying:
78) The intent of this list is to specify those circumstances in which
an object may or may not be aliased.
The same section of the C++ standard says:
15 If a program attempts to access the stored value of an object through
an lvalue of other than one of the following types the behavior is
undefined:49)
with footnote 49 saying:
49) The intent of this list is to specify those circumstances in which
an object may or may not be aliased.
The content of the section is almost identical, and both say identically
word for word:
— an aggregate or union type that includes one of the aforementioned
types among its members (including, recursively, a member of a
subaggregate or contained union),
and I think that the intent of the C version is the same as the C++
clearly states. This is a list of all the ways to access a stored value
through an lvalue. Anything else is undefined behavior. So constructing
code to bypass the pointer issues, gcc does allow accessing an int value
through a lvalue that is a union that contains an int like this:
int i;
union u{ int x; };
printf("%d\n",(*((union u*)&i)).x);
although it's perverse, it doesn't seem to break any aliasing rules and
neither gcc (nor g++ with an equivalent std::cout line), complain about
it with maximum aliasing bitching turned on. And indeed, the problems
with aliasing are more like the cool part about the structs I elided
above. -fstrict-aliasing is a promise to the compiler that you aren't
going to do weird things like:
void foo(int, float);
union u{
int a;
float b;
}
foo(u.a, u.b);
so that it can do some types of optimizations it couldn't otherwise do.
-Wstrict-aliasing tries to warn you if you break the promise, although
if the definition and call are in different compilation units gcc won't
know.
A funnier example of something that seems not to break the above
aliasing rules, (really equivalent to the printf above), the following
when compiled with -fstrict-aliasing -Wstrict-aliasing=3 doesn't get
complained about by 4.4.1 or 4.5.0 at least.
#include
union u { int x; };
void
foo(union u theu)
{
printf("%d\n",theu.x);
}
int main()
{
int i=7;
foo(*((union u*)&i));
return 0;
}
Patrick
Re: GCC aliasing rules: more aggressive than C99?
Nick Stoughton wrote: Herb is C++ ... The C1x timetable has us finishing the draft for an initial ballot this summer (the April Florence meeting being the last chance to submit new material). The best expert I know on the type based aliasing stuff is Clark Nelson at Intel (clark.nel...@intel.com). We did spend a considerable amount of time at the recent Santa Cruz meeting discussing this subject ... see N1409 and N1422 (the minutes including a summary of the discussion on N1409). http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1409.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1422.pdf I've read these, and while they deal with the same section of the standard, the issues are quite different. Patrick
Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?
Andrew Haley wrote: On 01/10/2010 12:39 PM, Andreas Schwab wrote: Andrew Haley writes: Why do you say the effective type is different? The object type is uint8_t, but accessed as uint32_t. That is undefined. Unless uint8_t is a character type, as I understand it. That is clearly the assumption on which the code relies. But in the new compilers it's an integer type, not a character type--from the spec: 7.18.1.1 Exact-width integer types 1 The typedef name intN_t designates a signed integer type with width N , no padding bits, and a two’s complement representation. Thus, int8_t denotes a signed integer type with a width of exactly 8 bits. 2 The typedef name uintN_t designates an unsigned integer type with width N . Thus, uint24_t denotes an unsigned integer type with a width of exactly 24 bits. 3 These types are optional. However, if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a two’s complement representation, it shall define the corresponding typedef names. Patrick
Fwd: Pseudo-templates
Dear all, We are two students in a Compiler Design course who have been assigned to work on a gcc beginners project. We have chosen the project on making pseudo-templated containers, and we had some questions about the semantics you want from them. The gcc page specifically mentioned splay trees and hash tables, so we will ask about those. The goal of the project was stated to be the elimination of abstraction penalties. The hash table and splay tree both store entries by pointer (except that splay tree can cast ints to the pointer and back out). Would you prefer a generic container that held items by value? We could do this, but it would break code that expects aliases to be preserved. We are currently working under the assumption that it is acceptable for all of our function-like macros to take the type of the stored elements. Do you agree? Is it okay for lookup function macros to take the type they are looking up? If we can take the type, we can make the semantics of returning pointers much more elegant. Thanks for your help, Patrick Moran Walter Maguire
[trans-mem] optimization problem with ITM functions
Hello,
Attached the cpp example.
While I was trying to understand the problem (segfault), I found this:
In special_function_p function (calls.c), ECF_TM_OPS flag is returned for
all TM builtin call except BUILT_IN_TM_START.
Question: is it really intentional or missing?
Moreover since BUILT_IN_TM_START is doing a setjmp, I suppose it should
add also the flag ECS_RETURNS_TWICE. If I add this, the generated code is
a bit different (more things happen in the stack, which I suppose right).
BUILT_IN_TM_ABORT is kind of longjmp, it should then add ECF_NORETURN,
right?.
Otherwise I have a strange bug with the attached cpp file when
_ITM_commitTransaction is the last call of a function with optimization
level>=2. This call is optimized as a tail call thus the epilogue is
before the jmp. But in this specific case, if the _ITM_commitTransaction
aborts and roll backs, it seems it creates a problem (corrupted stack) but
I didn't figure out the real reason.
To avoid this problem I have added ECF_RETURNS_TWICE for the transaction
commit which avoid this tail call optimization but I am sure this is not
the way to fix this.
Attached the patch for these problems.
Thanks for any help.
Patrick Marlier.#include
namespace bench
{
class LLNode
{
LLNode* next;
int data;
public:
__attribute__((transaction_safe))
LLNode(int val, LLNode* m_next)
{
data = val;
next = m_next;
}
__attribute__((transaction_safe))
~LLNode(){}
__attribute__((transaction_safe))
int get_val() {return data;}
__attribute__((transaction_safe))
LLNode* get_next() {return next;}
__attribute__((transaction_safe))
void set_val(int val) {data = val;}
__attribute__((transaction_safe))
void set_next(LLNode* n) {next = n;}
__attribute__((transaction_safe))
void *operator new(size_t size);
};
class LinkedList
{
LLNode* head;
public:
LinkedList();
void insert(int val);
};
}
using bench::LinkedList;
using bench::LLNode;
__attribute__((transaction_safe))
void* LLNode::operator new(size_t size)
{
return malloc(size);
}
LinkedList::LinkedList() : head(new LLNode(-1, NULL)) { }
void LinkedList::insert(int val)
{
__transaction [[atomic]] {
LLNode* prev = head;
LLNode* curr = head->get_next();
while (curr != NULL) {
if (curr->get_val() >= val)
break;
prev = curr;
curr = prev->get_next();
}
if (!curr || (curr->get_val() > val)){
LLNode* tmp = new LLNode(val,curr);
prev->set_next(tmp);
}
}
// asm volatile("nop");
}
Index: calls.c
===
--- calls.c (revision 168989)
+++ calls.c (working copy)
@@ -473,9 +473,17 @@
{
switch (DECL_FUNCTION_CODE (fndecl))
{
+
+ case BUILT_IN_TM_START:
+ flags |= ECF_RETURNS_TWICE | ECF_TM_OPS;
+ break;
+ case BUILT_IN_TM_ABORT:
+ flags |= ECF_NORETURN | ECF_TM_OPS;
+ break;
case BUILT_IN_TM_COMMIT:
case BUILT_IN_TM_COMMIT_EH:
- case BUILT_IN_TM_ABORT:
+ flags |= ECF_RETURNS_TWICE | ECF_TM_OPS;
+ break;
case BUILT_IN_TM_IRREVOCABLE:
case BUILT_IN_TM_GETTMCLONE_IRR:
case BUILT_IN_TM_MEMCPY:
RE : [trans-mem] optimization problem with ITM functions
Hello, Here the asm of the previous example: .globl _ZN5bench10LinkedList6insertEi .type _ZN5bench10LinkedList6insertEi, @function _ZN5bench10LinkedList6insertEi: .LFB46: .loc 1 24 0 .cfi_startproc pushq %r12 .cfi_def_cfa_offset 16 pushq %rbp .cfi_def_cfa_offset 24 pushq %rbx .cfi_def_cfa_offset 32 subq$16, %rsp .cfi_def_cfa_offset 48 ... .cfi_offset 3, -32 .cfi_offset 6, -24 .cfi_offset 12, -16 call_ITM_beginTransaction .L8: ... call_ITM_WU8 .loc 1 46 0 discriminator 4 addq$16, %rsp .cfi_remember_state .cfi_def_cfa_offset 32 popq%rbx .cfi_def_cfa_offset 24 popq%rbp .cfi_def_cfa_offset 16 popq%r12 .cfi_def_cfa_offset 8 .loc 2 56 0 discriminator 4 jmp _ITM_commitTransaction Since _ITM_commitTransaction can jump back to the label L8, the tail call optimization must not be allowed. Is it right? Do some other optimizations can create problems with this longjmp behavior of _ITM_commitTransaction? Does the ECF_RETURNS_TWICE flag is the right way to solve that? Should I fill a bug-report? Thanks. Patrick Marlier. De : Patrick Marlier [patrick.marl...@unine.ch] Date d'envoi : jeudi 20 janvier 2011 20:42 À : gcc@gcc.gnu.org Cc : r...@redhat.com; al...@redhat.com; gokcen.kes...@bsc.es Objet : [trans-mem] optimization problem with ITM functions Hello, Attached the cpp example. While I was trying to understand the problem (segfault), I found this: In special_function_p function (calls.c), ECF_TM_OPS flag is returned for all TM builtin call except BUILT_IN_TM_START. Question: is it really intentional or missing? Moreover since BUILT_IN_TM_START is doing a setjmp, I suppose it should add also the flag ECS_RETURNS_TWICE. If I add this, the generated code is a bit different (more things happen in the stack, which I suppose right). BUILT_IN_TM_ABORT is kind of longjmp, it should then add ECF_NORETURN, right?. Otherwise I have a strange bug with the attached cpp file when _ITM_commitTransaction is the last call of a function with optimization level>=2. This call is optimized as a tail call thus the epilogue is before the jmp. But in this specific case, if the _ITM_commitTransaction aborts and roll backs, it seems it creates a problem (corrupted stack) but I didn't figure out the real reason. To avoid this problem I have added ECF_RETURNS_TWICE for the transaction commit which avoid this tail call optimization but I am sure this is not the way to fix this. Attached the patch for these problems. Thanks for any help. Patrick Marlier.
Re: strcpy and strcat seem to lead to a stack overflow
You may be thinking of string capabilities in some other language.
Selected from the Linux man pages for these glibc functions:
strcpy:
char *strcpy(char *dest, const char *src);
The strcpy() function copies the string pointed to by src,
including
the terminating null byte ('\0'), to the buffer pointed to by
dest.
The strings may not overlap, and the destination string dest
must be
large enough to receive the copy. Beware of buffer overruns!
strcat:
char *strcat(char *dest, const char *src);
The strcat() function appends the src string to the dest
string, over‐
writing the terminating null byte ('\0') at the end of dest,
and then
adds a terminating null byte. The strings may not overlap,
and the
dest string must have enough space for the result. If dest
is not
large enough, program behavior is unpredictable; buffer
overruns are a
favorite avenue for attacking secure programs.
Neither strcpy nor strcat allocate or release buffers.
The programmer is expected to have previously allocated the dest buffer
of sufficient size. It seems likely from the behavior you describe,
in your case, the const src string is allocated on the stack and your
use of strcat with an unallocated dest is overwriting the end of
the src string on each iteration. Ultimately you either run out
of stack space or wipe out some other stack data which causes
unpredictable behavior.
Strings in C are not particularly user friendly.
As to whether they are intuitive, it all depends on what language we
first learn. Many languages invented in the 70s and 80s did not have
strong string handling capabilities. If you learn string handling on
one of those languages first, you come to not expect much and are
pleasantly surprised when encountering a language that does the
support work for you.
Many recommend using strncpy and strncat which require explicit
string lengths in order to remind the programmer to be careful
about buffer sizes and to avoid the risks of unterminated strings.
- patrick
On 2/22/2022 3:01 PM, Emile Michel Hobo via Gcc wrote:
Dear developers:
I find it counterintuitive that if I repeatedly reset a variable by using strcpy with an
empty string "" to that variable and then us strcat to add characters to that
variable that that seems to lead to a stack overflow.
I would expect strcpy to first free the variable, then malloc, then copy the
string value into the variable. I think that would be a better interpretation,
because it can keep running for quite some time before it overflows and doesn’t
really call it.
Instead, I got "Illegal instruction: 4".
I ended up reimplementing the reset function, implementing it with free and
malloc myself, but the way strings have been implemented in C is highly
counter-intuitive. In general pointers tend to be bug-prone, but here you would
expect this not to happen.
I hope you can fix this. Personally, I’m looking into switching to Ada.
All the best,
Emile M. Hobo
- Au fin! Et encore en plus. -
Re: Benchmark recommendations needed
I studied Dhrystone about 30 years ago and found it had a number of flaws back then. For example, most of the loops in the code are only executed 1-3 times, which minimizes the value of hoisting values out of inner loops. Read the Dhrystone wikipedia article for more information. Going back to what benchmarks might be useful... you might consider the Livermore Loops http://www.netlib.org/benchmark/livermorec These are 24 kernels (tight loops) originally in Fortran but ported to C 30 years ago. They are reasonably representative of floating point computational kernels. They are available without a fee. Even if you have no interest in floating point computation for your target architecture, examining the assembly output of these kernels will be helpful in finding where your port of gcc is doing well and where the machine architecture input to the various optimizer phases need some tuning. You also might review that code and write some modest test loops of your own for integer code patterns. Developing good benchmarks is a skill which requires the developer to know the intended purpose of the benchmark. I.e. is our goal to compare optimizer implementations? or different architectures (i.e. arm vs x86)? or different implementations of an architecture (i.e. intel vs amd or early x86 vs current x86) or ... well, you get the idea. Good luck, - Patrick McGehearty On 2/22/2022 3:49 PM, Paul Koning via Gcc wrote: On Feb 22, 2022, at 4:26 PM, Gary Oblock via Gcc wrote: Andras, The whole point of benchmarks is to judge a processor's performance. That being said, just crippling GCC is not reasonable because processors must be judged in the appropriate context and that includes the current state of the art compiler technology. If you have a new processor I'd benchmark it using the applications you built it for. Exactly. Part of what you want to see is that GCC optimizes well for the new machine, i.e., that there aren't artifacts of the machine description that get in the way of optimization. So you'd want to use applications that are good exercises not just of the code generator but also the optimizer. Dhrystone isn't really that, because it has evolved into mostly an optimizer test, not a machine or code generator test. paul
Slightly OT: We should move #gcc off of FreeNode
Today lilo (the FreeNode network owner) has decided to make one step away in a direction opposite of freedom, and banned all Tor users from the FreeNode network. Tor ( http://tor.eff.org ) is an open source anonymous gateway system. Many users who are not in the position to be able to use IRC otherwise (such as those who live in countries who do not believe in free speech) now cannot use Freenode any longer. Do we want to use an IRC network that no longer supports freedom? Our only option is to move to another network, such as irc.noderebellion.net or irc.oftc.net -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpjTTPifgTTZ.pgp Description: PGP signature
Re: Slightly OT: We should move #gcc off of FreeNode
On Wednesday 23 February 2005 06:58 am, Andrew Haley wrote: > Patrick McFarland writes: > > Today lilo (the FreeNode network owner) has decided to make one step > > away in a direction opposite of freedom, and banned all Tor users from > > the FreeNode network. > > I can't find a statement from FreeNode. Ask lilo or any oper personally. They have been "temporarily banning" all Tor users whenever a botnet shows up. However, it seems the botnet has been showing up constantly, so as long as the botnet is cranking away lilo keeps Tor users banned. > This would be a more appropriate discussion for GNU, which uses > Freenode as its official IRC network. I can't see what would be > achieved by gcc, a GNU project, going off on its own. #gcc on oftc already exists, actually. They got tired of the bullshit lilo pulls. This was more of a request for the rest of #gcc (on freenode) to follow along. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpMQEbQ3M8kd.pgp Description: PGP signature
Re: Slightly OT: We should move #gcc off of FreeNode
On Wednesday 23 February 2005 11:03 am, Florian Weimer wrote: > * Andrew Haley: > > Patrick McFarland writes: > > > Today lilo (the FreeNode network owner) has decided to make one step > > > away in a direction opposite of freedom, and banned all Tor users from > > > the FreeNode network. > > > > I can't find a statement from FreeNode. > > There is one, but it's fairly reasonable (Tor users are clearly > marked, not banned). Actually, lilo and company _have_ been k-lining and otherwise banning Tor users off the net, due to the actions of one or two users harassing some of the larger channels. They are stepping into the territory of a chanop's responsibility to police their own channel. This is no different than if the military arrested you for jay walking. > Patrick McFarland spammed countless mailing lists with his message. > Apparently, he's not interested in a real discussion, otherwise he'd > stick to the facts. No, I have warned multiple projects of lilo's wrongdoing, and suggested they move to another network. You can disagree with my assessment of the situation, but don't call it spamming. This is a real issue, and each project needs to decide if they want to deal with it or not. > > This would be a more appropriate discussion for GNU, which uses > > Freenode as its official IRC network. I can't see what would be > > achieved by gcc, a GNU project, going off on its own. > > I though that #gcc on oftc.net was more active, anyway, or has this > changed? This was more of a request for the #gcc on freenode to catch up with the rest of the #gcc and finally move to oftc. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpFHmnPDZ3SO.pgp Description: PGP signature
Re: Libitm issues porting to POWER8 HTM
Hi Peter, On Sat, Jun 15, 2013 at 2:44 AM, Peter Bergner wrote: > I'm currently implementing support for hardware transactional memory in > the rs6000 backend for POWER8. Things seem to be mostly working, but I > have run into a few issues I'm wondering whether other people are seeing. It sounds great! Is it already publicly available? > Finially, when compiling (static or non-static) static-ctor.C, I'm seeing: > > /home/bergner/gcc/gcc-fsf-mainline-htm/libitm/testsuite/libitm.c++/static_ctor.C:12:18: > error: unsafe function call 'void __cxa_guard_release(long long int*)' > within 'transaction_safe' function >static int y = x; > ^ > /home/bergner/gcc/gcc-fsf-mainline-htm/libitm/testsuite/libitm.c++/static_ctor.C:12:18: > error: unsafe function call 'int __cxa_guard_acquire(long long int*)' within > 'transaction_safe' function > > Does x86 not get calls to __cxa_guard_acquire and __cxa_guard_release for > this access, so it doesn't see this error? To be honest, I'm not sure > what we're supposed to do with this error. Sorry I don't have answers to your previous questions (I may have in the future when I will get a CPU with HTM). About the last one, this fails for a long long time now (even on x86): http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51173 Indeed, static constructors are not transaction safe yet and we should have a workaround for this... -- Patrick
[doc] Fixing reference inside Extended-Asm.html
I have noticed that the link Extended-asm-with-goto.html#Extended-asm-with-goto is wrong in http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html. Locally when I generate the html doc, the link is good, ie . Also the online page for Extended-asm-with-goto.html is wrong, '%20' instead of '-'. $ curl http://gcc.gnu.org/onlinedocs/gcc/Extended-asm-with-goto.html\#Extended-asm-with-goto Locally I have: Is the version of texinfo buggy to generate online documentation? Thanks, -- Patrick Marlier
Building GCC with -Wmissing-declarations and addressing its warnings
Hi everyone, I noticed that the GCC build process currently only uses the -Wmissing-prototypes flag, and not the -Wmissing-declarations flag. It seems that the former flag only works on C source files, which means that GCC's source files no longer benefit from this flag as they are now C++ files. The right flag to use, in this case, is -Wmissing-declarations, which works on both C and C++ source files. I decided to build GCC with this flag to see what kinds of warnings popped up, and to use these warnings to clean up the GCC source. I sifted through all the new warnings generated by -Wmissing-declarations during the build process and fixed the ones whose fixes were obvious. Most of my fixes are on global (non-debug) functions that are only referenced in the compilation unit in which they are defined. To fix these functions and to silence their warnings I have simply gave them static linkage. The rest of the fixes are on global function definitions whose declaration exists in a header file that was not included by the source file. To fix up these functions I simply included the relevant header file. The -Wmissing-declarations warnings that I did _not_ address are those emitted from the autogenerated gengtype header files, because their fixes are not trivial to me. They look like: In file included from ../../gcc/gcc/c/c-parser.c:14162:0: ./gt-c-c-parser.h: In function 'void gt_ggc_mx(c_token&)': ./gt-c-c-parser.h:50:1: warning: no previous declaration for 'void gt_ggc_mx(c_token&)' [-Wmissing-declarations] gt_ggc_mx (struct c_token& x_r ATTRIBUTE_UNUSED) I have also not addressed some of such warnings in predict.c and config/i386/i386.c because their fixes are not trivial to me either. Furthermore, I was not able to mark "static" any function that was used as a template argument to hash_table::traverse() because it seems that C++98 requires template argument pointers to have external linkage. (The C++11 standard relaxes this restriction, it seems.) The file var-tracking.c has many of such functions. Since I do not yet have a copyright assignment filed for GCC, I have omitted an actual code patch and instead provide you with a changelog that could be used to reconstruct the patch 100% if anyone is so inclined. Once my copyright assignment is filed, I will properly submit this patch if it is not yet done so by somebody else. On a related note, would a patch to officially enable -Wmissing-declarations in the build process be well regarded? Since -Wmissing-prototypes is currently enabled, I assume it is the intention of the GCC devs to address these warnings, and that during the transition from a C to C++ bootstrap compiler a small oversight was made (that -Wmissing-prototypes is a no-op against C++ source files). If the answer to the previous question is "yes" then how would one go about addressing the above gengtype-related warnings, if at all? Thanks for your time, Patrick * asan.c (asan_mem_ref_get_end): Make static. * calls.c: Include calls.h. * cfgexpand.c: Include cfgexpand.h. * cfgloop.c: Include tree-ssa-loop-niter.h. * cfgraphunit.c (decide_is_symbol_needed): Make static. * config/i386/i386.c (make_pass_insert_vzeroupper): Likewise. (ix86_avx_emit_vzeroupper): Likewise. * dwarf2out.c (init_addr_table_entry): Likewise. * gimple-builder.c: Include gimple-builder.h. * gimple-ssa-isolate-paths.c (isolate_path): Make static. * graphite.c (graphite_transform_loops): Likewise. * internal-fn.c (ubsan_expand_si_overflow_addsub_check): Make static. (ubsan_expand_si_overflow_neg_check): Likewise. (ubsan_expand_si_overflow_mul_check): Likewise. * ipa-devirt.c (hash_type_name): Likewise. (likely_target_p): Likewise. * ipa-inline-analysis.c (simple_edge_hints): Likewise. * ipa-profile.c (cmp_counts): Likewise. (contains_hot_call_p): Likewise. * ipa-prop.c (ipa_alloc_node_params): Likewise. (write_agg_replacement_chain): Likewise. * ipa.c (can_replace_by_local_alias): Likewise. * lto-streamer-out.c (output_symbol_p): Likewise. * omp-low.c (simd_clone_vector_of_formal_parm_types): Likewise. * print-tree.c: Include print-tree.h. * stmt.c: Include stmt.h. * stringpool.c: Include stringpool.h. * tree-cfg-cleanup.c: Include tree-cfg-cleanup.h. * tree-inline.c (redirect_all_calls): Make static. (freqs_to_count): Likewise. * tree-nested.c: Include tree-nested.h. * tree-predcom.c (tree_predictive_commoning): Make static. * tree-sra.c (ipa_sra_modify_function_body): Likewise. * tree-ssa-loop-im.c (movement_possibility): Likewise. (tree_ssa_lim): Likewise. * tree-ssa-loop-ivcanon.c (canonicalize_induction_variables): Likewise. (tree_un
Re: Building GCC with -Wmissing-declarations and addressing its warnings
On Thu, Feb 20, 2014 at 2:16 AM, Jonathan Wakely wrote: > On 13 February 2014 20:47, Patrick Palka wrote: >> On a related note, would a patch to officially enable >> -Wmissing-declarations in the build process be well regarded? > > What would be the advantage? A missing declaration for an extern function definition likely means that the function should be marked static instead, so enabling the flag would help detect whether a function should otherwise be given static linkage. Isn't this especially important in libstdc++, where accidentally exposing an internal symbol in the library's ABI means having to keep the symbol around until the next ABI bump? > >> Since >> -Wmissing-prototypes is currently enabled, I assume it is the >> intention of the GCC devs to address these warnings, and that during >> the transition from a C to C++ bootstrap compiler a small oversight >> was made (that -Wmissing-prototypes is a no-op against C++ source >> files). > > The additional safety provided by -Wmissing-prototypes is already > guaranteed for C++. > > In C a missing prototype causes the compiler to guess, probably > incorrectly, how to call the function. > > In C++ a function cannot be called without a previous declaration and > the linker will notice if you declare a function with one signature > and define it differently. Good point.. -Wmissing-declarations does not provide additional safety to C++. Really the only benefit to the flag is the static thing mentioned above.
Re: Building GCC with -Wmissing-declarations and addressing its warnings
On Thu, Feb 20, 2014 at 7:42 AM, Jonathan Wakely wrote:
> On 20 February 2014 10:02, Patrick Palka wrote:
>> On Thu, Feb 20, 2014 at 2:16 AM, Jonathan Wakely
>> wrote:
>>> On 13 February 2014 20:47, Patrick Palka wrote:
>>>> On a related note, would a patch to officially enable
>>>> -Wmissing-declarations in the build process be well regarded?
>>>
>>> What would be the advantage?
>>
>> A missing declaration for an extern function definition likely means
>> that the function should be marked static instead, so enabling the
>> flag would help detect whether a function should otherwise be given
>> static linkage. Isn't this especially important in libstdc++, where
>> accidentally exposing an internal symbol in the library's ABI means
>> having to keep the symbol around until the next ABI bump?
>
> It's not really an issue for libstdc++. All symbols are internal by
> default and we only export specifically chosen symbols. If a new
> symbol accidentally matches an existing pattern in the linker script
> then it will be noticed by the testsuite ('make check-abi' in the
> $objdir/$target/libstdc++-v3 dir) and we will make the pattern more
> specific.
Ah, ok, that makes sense.
>
> Making some functions static might be worthwhile, but for the other
> ones referred to in this quote from your first email:
>
>> The rest of the
>> fixes are on global function definitions whose declaration exists in a
>> header file that was not included by the source file. To fix up these
>> functions I simply included the relevant header file.
>
> The only advantage of this change is that if the definition is changed
> without also changing the header then you might get a failure during
> compilation rather than linking, but even that isn't guaranteed as the
> new definition could be interpreted as an overload rather than an
> incompatible declaration.
Wouldn't the overload require a separate declaration, which would be
missing, and thus the compiler would still emit the warning?
>
> Otherwise, including the header isn't *wrong* but it doesn't really
> gain much, except silencing a warning, and that warning is only
> emitted because you turned it on :-) And as you also said, some files
> can't easily be fixed to avoid the warning. IMHO the simplest way to
> solve the problem is not turn the warnings on!
For what it's worth, I have fixed the files that I originally regarded
as not easily fixable. They were pretty easy to fix after a little
bit of thought.
>
> Maybe others will disagree and will think enabling
> -Wmissing-declarations would be a useful change, but I don't see the
> point.
In my novice opinion, I think the flag helps keep source files tidy
and modular, and their interfaces well-defined. Its biggest benefit
is having the compiler inform you when a function should have been
marked static: marking a function static facilitates better
optimization and static analysis, and it helps convey the intent of
the function to the reader. (I counted nearly 100 (non-debug)
functions that could be made static in gcc, and 4 in libstdc++, by the
way.)
Re: Building GCC with -Wmissing-declarations and addressing its warnings
On Thu, Feb 20, 2014 at 1:14 PM, Jonathan Wakely wrote: > On 20 February 2014 15:31, Patrick Palka wrote: >> (I counted nearly 100 (non-debug) >> functions that could be made static in gcc, and 4 in libstdc++, by the >> way.) > > Which were the four in libstdc++? > > I only see __gslice_on_index and __concat_size_t. Those two along with _Rb_tree_rotate_left and _Rb_tree_rotate_right.
Re: PATCH: PR boehm-gc/48299: FAIL: boehm-gc.c/thread_leak_test.c
Hello, As I see in my x86_64/linux gcc build and for example recently in: http://gcc.gnu.org/ml/gcc-testresults/2012-02/msg02269.html === boehm-gc tests === Running target unix/-m32 FAIL: boehm-gc.c/thread_leak_test.c -O2 (test for excess errors) === boehm-gc Summary for unix/-m32 === Running target unix FAIL: boehm-gc.c/thread_leak_test.c -O2 (test for excess errors) due to redefinition of GC_LINUX_THREADS. Any reason why this patch was not applied? http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01903.html Thanks! -- Patrick
Re: PATCH: PR boehm-gc/48299: FAIL: boehm-gc.c/thread_leak_test.c
On 02/23/2012 02:04 PM, Patrick Marlier wrote: Hello, As I see in my x86_64/linux gcc build and for example recently in: http://gcc.gnu.org/ml/gcc-testresults/2012-02/msg02269.html === boehm-gc tests === Running target unix/-m32 FAIL: boehm-gc.c/thread_leak_test.c -O2 (test for excess errors) === boehm-gc Summary for unix/-m32 === Running target unix FAIL: boehm-gc.c/thread_leak_test.c -O2 (test for excess errors) due to redefinition of GC_LINUX_THREADS. Any reason why this patch was not applied? http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01903.html Thanks! -- Patrick Also note that the trunk boehm-gc seems to be fixed like this: Index: testsuite/boehm-gc.c/thread_leak_test.c === --- testsuite/boehm-gc.c/thread_leak_test.c (revision 184398) +++ testsuite/boehm-gc.c/thread_leak_test.c (working copy) @@ -1,4 +1,7 @@ -#define GC_LINUX_THREADS +#ifndef GC_THREADS +# define GC_THREADS +#endif + #include "leak_detector.h" #include #include
Re: PATCH: PR boehm-gc/48299: FAIL: boehm-gc.c/thread_leak_test.c
On 02/23/2012 09:34 PM, Jack Howarth wrote: On Thu, Feb 23, 2012 at 02:14:17PM -0500, Patrick Marlier wrote: On 02/23/2012 02:04 PM, Patrick Marlier wrote: Hello, As I see in my x86_64/linux gcc build and for example recently in: http://gcc.gnu.org/ml/gcc-testresults/2012-02/msg02269.html === boehm-gc tests === Running target unix/-m32 FAIL: boehm-gc.c/thread_leak_test.c -O2 (test for excess errors) === boehm-gc Summary for unix/-m32 === Running target unix FAIL: boehm-gc.c/thread_leak_test.c -O2 (test for excess errors) due to redefinition of GC_LINUX_THREADS. Any reason why this patch was not applied? http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01903.html Thanks! -- Patrick Also note that the trunk boehm-gc seems to be fixed like this: Index: testsuite/boehm-gc.c/thread_leak_test.c === --- testsuite/boehm-gc.c/thread_leak_test.c (revision 184398) +++ testsuite/boehm-gc.c/thread_leak_test.c (working copy) @@ -1,4 +1,7 @@ -#define GC_LINUX_THREADS +#ifndef GC_THREADS +# define GC_THREADS +#endif + #include "leak_detector.h" #include #include Patrick, This form still randomly fails on x86_64-apple-darwin11 with the logged output of... Setting LD_LIBRARY_PATH to .:/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc:/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/./boehm-gc/.libs:.libs:.:/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc:/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/./boehm-gc/.libs:.libs Leaked composite object at 0x10192bfe0 (/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120223/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:15, sz=4, NORMAL) Leaked composite object at 0x10192bf80 (/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120223/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:15, sz=4, NORMAL) Leaked composite object at 0x10192bfb0 (/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120223/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:15, sz=4, NORMAL) Leaked composite object at start: 0x10192bf90, appr. length: 48 when the test hangs. Jack This is another problem (related to darwin) as discussed in PR48299. You should try the bdwgc trunk (https://github.com/ivmai/bdwgc/) and see if the test passes. It could give a indication if it is still an unsolved issue or not. Patrick.
Re: Copyright assignment forms
Hi, Here the links about that: http://gcc.gnu.org/wiki/CopyrightAssignment -- Patrick On 08/02/2012 09:14 AM, Paulo J. Matos wrote: Hello, Could someone please send me the copyright assignment forms for single contributions and for all future contributions? Cheers,
libffi & powerpc
Hi there,
I'm running an embedded platform based on a powerpc 405EP CPU and a
gcc 4.1.0 cross-toolchain. My initial problem was that gcj compiled
binaries crash at runtime when interpreting java bytecode ("Illegal
instruction" message).
After many investigations, it looks like the problem comes from the
libffi library : I've run the libffi testsuite on my embedded paltform
and many of the tests show the same "Illegal instruction" message. For
instance, the "cls_uint" test crashes at the following line (from the
cls_uint.c file) :
res = (*((cls_ret_uint)pcl))(2147483647);
My knowledge about the powerpc architectures is very limited, but I've
seen mailing lists threads talking about "EABI" that I don't quite
understand but my intuition is that it could be related. For instance,
could it be that my cross toolchain is not compiled with the right
EABI (does this question make sense??) ?
Any ideas or thoughts about this problem ?
Thanks in advance for your replies.
Regards,
Patrick Olinet
Re: libffi & powerpc
Running with gdb, it looks like the problem comes from the
ppc_closure.S file of the libffi/src/powerpc directory, at line 32 :
stfd %f1, 48(%r1)
I don't understand anything to powerpc assembly, but after a google
search, "stfd" means "store floating-point double". But the PPC405
doesn't have any FPU, so I guess that's why it throws an "illegal
instruction".
I've compiled again my cross toolchain with the "--with-float=soft"
option, hoping that it would emulate FPU instruction, but this
unfortunately doesn't help... I'm nevertheless not sure that this
option is the right one...
Any thoughts ? Is there a bug in libffi in that it doesn't support
powerpc CPU without FPU ?
Regards,
Patrick
On 5/8/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
Patrick Olinet writes:
> Hi there,
>
> I'm running an embedded platform based on a powerpc 405EP CPU and a
> gcc 4.1.0 cross-toolchain. My initial problem was that gcj compiled
> binaries crash at runtime when interpreting java bytecode ("Illegal
> instruction" message).
>
> After many investigations, it looks like the problem comes from the
> libffi library : I've run the libffi testsuite on my embedded paltform
> and many of the tests show the same "Illegal instruction" message. For
> instance, the "cls_uint" test crashes at the following line (from the
> cls_uint.c file) :
>
> res = (*((cls_ret_uint)pcl))(2147483647);
>
> My knowledge about the powerpc architectures is very limited, but I've
> seen mailing lists threads talking about "EABI" that I don't quite
> understand but my intuition is that it could be related. For instance,
> could it be that my cross toolchain is not compiled with the right
> EABI (does this question make sense??) ?
>
> Any ideas or thoughts about this problem ?
Run it in gdb. When gdb stops with SIGILL, do
x/i $pc
Andrew.
Re: libffi & powerpc
> I've compiled again my cross toolchain with the "--with-float=soft" > option, hoping that it would emulate FPU instruction, but this > unfortunately doesn't help... I'm nevertheless not sure that this > option is the right one... If your entire toolchain is compiled with --with-float=soft, then you should use the same options when compiling your code. > I thought that fpu emulation worked by trapping cpu exceptions when a fpu instruction is being executed and then emulating this instruction on software level. Isn't the mechanism implemented by the "--with-float=soft" option ? Patrick
Re: libffi & powerpc
> I thought that fpu emulation worked by trapping cpu exceptions when a > fpu instruction is being executed and then emulating this instruction > on software level. Yes. > Isn't the mechanism implemented by the "--with-float=soft" option ? No. FPU emulation requires no special compile-time options. The whole idea is that it runs the same code as native FP. In contrast, soft-float generates inline subroutine calls for all floating-point operations. ok, I get it. So, is there a way to add fpu emulation emulation to my platform without having to change anything to my native binary code ? Patrick
Re: libffi & powerpc
Finally, I've tried it the dirty way, ie by commenting out all the
"stfd" instructions at the beginning of the ppc_closure.S file and
things seem to work !!!
"stfd" are used to save fpu registers and were always executed, even
if no float/double arguments were involved in the call and if no fpu
is present.
Of course, I'm still unable to use float/double with the libffi but I
don't need it so I don't think I'm going to dig into this. As far as I
understand, calls to the soft float ABI would be required to fix this.
What worries me a bit is that "stfd" instructions are used to save fpu
registers states before the call (it's my guess) and I would expect
them to be restored afterwards, probably with "lfd" assembly
instructions (that I would need to comment out as well). But I can't
see such instructions...
Any thoughts about that ?
And should I report a new bug for this libffi/powerpc problem ?
And thanks again to all of you for your help.
Patrick
On 5/14/07, Mike Stump <[EMAIL PROTECTED]> wrote:
On May 14, 2007, at 8:46 AM, Patrick Olinet wrote:
> Running with gdb, it looks like the problem comes from the
> ppc_closure.S file of the libffi/src/powerpc directory, at line 32 :
Maybe something like:
#ifndef _SOFT_FLOAT
> stfd %f1, 48(%r1)
#endif
but then, you might have to have something like:
#define CPP_SPEC \
"%{msoft-float: -D_SOFT_FLOAT} \
(picked at random from lynx.h) in the .h file for your port.
:-) But I'm sure there would be more work to do.
Re: libffi & powerpc
ok, I've created PR31937 related to the libffi bug and I've also submitted a quick patch to the gcc-patches mailing list Patrick On 5/16/07, Mike Stump <[EMAIL PROTECTED]> wrote: On May 15, 2007, at 2:20 AM, Patrick Olinet wrote: > Finally, I've tried it the dirty way, ie by commenting out all the > "stfd" instructions at the beginning of the ppc_closure.S file and > things seem to work !!! Wonderful. If you could, would you submit the patch to gcc- patches... I suspect it is better than nothing, and it might be trivial enough to go in without paperwork. Additionally, it might provide a basis for another contributor to build upon, as they then only have to do half the work. Thanks. > What worries me a bit is that "stfd" instructions are used to save > fpu registers states before the call (it's my guess) and I would > expect them to be restored afterwards, probably with "lfd" assembly > instructions (that I would need to comment out as well). But I > can't see such instructions... > Any thoughts about that ? Sure, don't worry about it, there is no matching instruction. You just can't do functions that return float/double/long double from my quick reading. > And should I report a new bug for this libffi/powerpc problem ? We prefer to have a bug report for each bug... :-)
Refactoring tool
gcc, Recently I have been interested in creating an open source refactoring tool. I did not have much luck finding an application that does what I need and thought that I could get some feedback from the gcc community. In particular I would like to add a flag which would cause gcc to emit symbol definition and use information. The -fdump-* flags provide much of this information in various formats. I would like to combine the salient information into a denser binary format that could be consumed by a subsequent application which would then modify the original source text. I would like this second application to be a command line tool which uses a syntax similar to gdb. For example "show unused headers in test.cpp" would print the header files which were included but not required in test.cpp. I have been able to come up with a small set of functions that I would like to be available, these include: rename [function|class|variable]+ [in scope] old_name new_name //rename a function or variable or class move [function|class|variable]+ to file //move a function class or variable definition to a different source code location remove using [namespace name] from file //fully qualify each symbol use with the appropriate namespace create function from file.begin_line file.end_line //create a function out of a block of code Having spent some time looking at the code for gcc it seems reasonably easy(with some suggestions) to traverse the tree generated and write the relevant information to a file. Any suggestions or pointers to related work would be much appreciated. Patrick Get the Yahoo! toolbar and be alerted to new email wherever you're surfing. http://new.toolbar.yahoo.com/toolbar/features/mail/index.php
Re: removing toxic emailers
To provide a face-to-face example of how banning can work without a formal written policy, I been in the leadership of a social gaming organization with chapters in various places. Our local group typically has 30-40 people show up at events and over the 30+ years of our existence, we've had multiple hundreds of different people participate. Those numbers somewhat match the number of active participants on this mailing list (to an order of magnitude at least). Like participants of this mailing list, we discourage disagreeable behavior because we lose participants if a few people make it unpleasant for the rest of us. When someone goes over the line, we (one or more people in the leadership) takes them aside (privately if possible) and politely point out their behavior is not doing them or the group any favors. If they seem to understand and agree to do better, that can be the end of it. Some people may need guidance more than once, but good intentions count. There have been a very small number of attendees to our group who's behavior is unacceptable and will not be tolerated. I can think of only three specific cases in the last 15 years. In each case, there was a broad consensus that the group would be better off without them. There have been many more cases where someone started going over the line but pulled back when corrected. With positive intervention, their behavior was modified and they continued in the group. I believe the same approach could work here. When someone goes over the line, a respected leader with a talent for calming things down could suggest to them privately that perhaps they might tone it down to a more appropriate level of discourse. There is a skill to calming done tempers and not everyone has the right talents for that, but the right intervention can help. While I have been irritated at some of the emails, I have not seen behavior that is severe enough to build a broad consensus for banning. To be very clear, I am not complaining about what position anyone has taken, only about when they present their point of view in a hostile or offensive way or presume the opposing point of view represents the face of evil. Hostility does not tend to change anyone's mind. I don't believe a formal policy is necessary. It should be clear when someone is way over the line and cannot accept counseling and guidance. At that point, the steering committee can give warning and finally take the necessary action. - Patrick McGehearty On 4/14/2021 4:24 PM, Jeff Law via Gcc wrote: On 4/14/2021 2:39 PM, Ian Lance Taylor wrote: On Wed, Apr 14, 2021 at 9:08 AM Jeff Law via Gcc wrote: once or twice when physical violence with threatened, but that's about it (aside from spammers). I don't think we want to get too deep into moderation and the like -- IMHO it should be an extremely rare event. As much as I disagree with some of the comments that have been made I don't think they've risen to the level of wanting/needing to ban those individuals from posting. I think it's useful to observe that there are a reasonable number of people who will refuse to participate in a project in which the mailing list has regular personal attacks and other kinds of abusive behavior. I know this because I've spoken with such people myself. They simply say "that project is not for me" and move on. So we don't get the choice between "everyone is welcome" and "some people are kicked off the list." We get the choice between "some people decline to participate because it is unpleasant" and "some people are kicked off the list." Given the choice of which group of people are going to participate and which group are not, which group do we want? (I'm raising this as a kind of first principle. If there is a system for banning people from the list, there are various things to discuss as to how that might work. And I've seen it work effectively in other communities. But if we don't agree on that first principle, there is no point to continuing.) It's been a long time, but I think when we've banned someone it's been through the steering committee. But yes, I understand your point and it's a good one and I think we can probably find some common ground there -- but even so I think banning should be a rare event and some official outreach to the offender should happen first. jeff
Re: Rescue of prehistoric GCC versions
On 1/9/20 5:28 AM, Eric S. Raymond wrote: > I have been able to rescue or reconstruct from patches the following > prehisoric GCC releases Great job. This is important > > gcc-0.9 > gcc-1.21 > gcc-1.22 > gcc-1.25 > gcc-1.26 > gcc-1.27 > gcc-1.28 > gcc-1.35 > > gcc-1.36 > gcc-1.37.1 > gcc-1.38 > gcc-1.39 > gcc-1.40 > gcc-1.41 > gcc-1.42 > gcc-2.1 > gcc-2.2.2 > gcc-2.3.3 > gcc-2.4.5 > gcc-2.5.8 > gcc-2.6.3 > gcc-2.7.2 > gcc-2.8.0 > > The gap in the sequence represents the beginning of the repository > history; r3 = gcc-1.36. > > The 0.9 to 0.35 tarballs can be glued to the front of the > history, one commit each, with a firewall commit containing a deleteall > to keep the content from leaking forward. This is an issue because > the early parts of the repo don't have complete trees. > > I'm now testing a conversion on the Great Beast that puts these in > place. If all goes well I will push this capability to the public > conversion repository later today. > > You can audit the reconstruction process by reading the script I wrote > to automate it: > > https://gitlab.com/esr/gcc-conversion/blob/master/ancients > > Unfortunately, I was only able to find valid patch chains to three > releases that don't have complete tarballs. > > If anyone else can scrounge up materials that could help complete > the fossil sequence, now would be a really good time for that. We > have only three days at most left to integrate them.
Re: FYI/RFC: strub: machine-independent stack scrubbing
I don't have any special expertise in this matter, but the possibility occurs to me that if the caller is an improperly vetted runtime linked-in agent such as a device driver, then the stack scrubbing might accidently or intentionally be omitted, reopening the security hole that stack scrubbing is intended to close. Having the scrubbing occur in the calle means the callee controls what information is returned, making it responsible for its own security. Someone with a deeper understanding of the security reasons for stack scrubbing may know whether my concern has any basis. - Patrick McGehearty On 7/14/2021 12:28 AM, Alexandre Oliva wrote: I've been working on an implementation of stack scrubbing, strub for short. It's quite different from the one that Embecosm folks presented at the Cauldron, in that this one aims to be machine-independent. Instead of machine-specific tweaking of epilogue logic to zero out a function's own stack frame, this design performs scrubbing at callers, passing to strubbed functions a watermark pointer, that they update as they move the stack pointer. The caller performs the stack cleaning up as a "finally" block after the call. - functions explicitly marked for strubbing, or internal-to-a-unit functions that use variables marked as requiring strubbing, just have their signature modified to add the watermark pointer, and they update the watermark at the end of the prologue and after alloca calls. - for functions that require strubbing (say, for using variables that require strubbing) but whose interface cannot be modified, the body is split into a clone, and the function is turned into a wrapper that calls the clone with its modified calling conventions, and then performs the strubbing. Variable argument lists and of builtin apply args are passed as extra arguments to the wrapped function, so that these features are not obstacles to strubbing. Large (> 4 words) arguments that are not gimple registers are passed by reference from the wrapper to the wrapped clone, to avoid duplicate copying. This is currently prototyped with an implementation that enables strubbing for nearly every function. Some exceptions are always_inline functions, and externally-visible functions with attributes that prevent cloning/splitting. Inlining strubbed functions into non-strubbed ones is not allowed (this would reverse the wrapping); I'm yet to figure out how to enable inlining of a wrapped body when the wrapper gets inlined into a strubbed function. Furthermore, I'm yet to implement logic to prevent strubbed functions from calling non-strubbed functions. The prototype bootstraps on x86_64-linux-gnu, and builds some working cross toolchains. I expect to contribute it not long after it's completed. For now, I look forward to feedback on any potentially objectionable implementation details that I've described, and I welcome advice on some issues described below. I've added a builtin that returns the stack address, and 3 new entry points in libgcc, each one also associated with a builtin: one to be called before a strubbed function, to initialize the watermark to be passed to it, one to update the watermark, and one to clean the stack up to the watermark. I'm considering making them independently inlineable, inlining none of them at -O0, the first one at -O[1gs], the second one at -O2, and all of them at -O3. Functions and variables with strubbing functionality are to be marked with an attribute, and I'm leaning towards naming it "strub". For functions, I intend the attribute to take a parameter, to select between the two strubbing modes, or to disable strubbing, whether enabling or preventing calls from strubbing functions. Internally, I'm using a numeric encoding for this attribute parameter, but I'm considering using such mnemonic terms as "at_calls", "internal", "callable", and "disabled". WDYT? I'm also considering the possibility of adding yet another scrubbing mode, that would select optional machine-dependent epilogue logic, as implemented by Embecosm. That will depend on schedule and on whether this possibility is found to be useful. Extending it to catch exceptions and perform strubbing of the propagating frame seems more challenging than the caller-based strubbing I've implemented, with exception support. I could use feedback on the usefulness of this strubbing mode (and on any issues with the others :-) The prototype uses modified copies of create_wrapper and expand_thunk for the wrapping. I find the body copying and dropping wasteful, constraining, and, in some cases, bug-inducing (taking address of labels comes to mind). I wonder if it would be acceptable to introduce wrapping logic to short-circuit the process, moving the body instead of copying it, and introducing hooks to grant callers better control over argument
Re: [GSoC][C++: Compiler Built-in Traits]: Example Impls & Small Patches
Hi Ken, On Mon, Feb 27, 2023 at 5:02 PM Ken Matsui via Gcc wrote: > > Hi, > > My name is Ken Matsui. I am highly interested in contributing to the > project idea, "C++: Implement compiler built-in traits for the > standard library traits." To understand how to implement those traits, > could you please give me some example implementations of the compiler > built-in traits, as well as some recommended traits to get started > with making small patches? Awesome, thanks for your interest in this project, and welcome! Most of the existing built-in traits are tabulated in gcc/cp/cp-trait.def, and their logic is defined in finish_trait_type or finish_trait_expr in gcc/cp/semantics.cc[2], and then the traits are conditionally used in the standard type trait definitions in libstdc++, e.g. std::remove_cv[3]. Take a look at the following commits that define (and add tests for) the built-in traits __remove_cv, __remove_reference and __remove_cvref and subsequently use them in libstdc++. Note that this first commit predates the new gcc/cp/cp-trait.def file which streamlined much of the boilerplate of adding a new built-in trait. In the new approach (that you would be using), only the semantics.cc change (which defines their logic) would be needed, alongside additions to cp-trait.def to declare each trait. https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9ca147154074a0de548138b4e73477e94903a855 https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=6ddbbbffbb5759a6c1d56c191364a6bd021f733e To get started, I'd recommend implementing bulit-in traits for std::remove_pointer, std::add_pointer and std::is_reference[4]. Let me know if you have any questions :) [1]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cp/cp-trait.def [2]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cp/semantics.cc;h=79b7cc72f212cef780a3eea65af2b883bb4ec3c8;hb=HEAD#l12102 [3]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/type_traits;h=2bd607a8b8ff52aba6fd205ab1af2bc4b92f78d0;hb=HEAD#l1539 [4]: As specified in https://en.cppreference.com/w/cpp/header/type_traits > > Also, I would appreciate receiving the contact information for the > project mentor, Patrick Palka. > > Sincerely, > Ken Matsui
Re: GSOC 2023 Contribution Request
Hi Kritika, On Wed, Feb 22, 2023 at 6:49 AM Kritika Rag via Gcc wrote: > > Hello Everyone! > > I’m Kritika Rag, a Computer Science pre-final year undergraduate > student from India. I’m quite passionate about web development and > competitive programming and now I’m looking forward to contributing to > open-source projects. I believe that GSOC 2023 would provide me with > the best way to start my open-source contribution journey. Since I’m a > competitive programmer, I have excellent command over Data Structures > & Algorithms and my primary language is C++, so C++ and GCC are > something that I use daily, therefore I would love to make my > contributions to GCC projects. I sincerely hope that this community > will provide me with the opportunity to do so and to work alongside > them. Great, thanks for your interest in contributing to GCC, and welcome! > > > I’m proficient in various coding languages like C/C++, HTML, CSS, > JavaScript, React, and Python, and have experimented with Git, Linux, > APIs, etc. I have also been fortunate enough to secure 3 internships, > 2 as a DSA problem setter and 1 as a research intern. I have also > participated in a few open-source programs like Hack October Fest 2022 > and GWoC 2022 and contributed to web development and data science > projects. > > I had been checking up on recent project proposals listed in GCC wiki > for the past 3 weeks and was interested in working either on the > project which aims to improve the utility routine library used by GCC > or related to Bug Patrol especially analyzing failing test cases (this > was present over the site a while ago but now I can't see it anywhere) > so I just wanted to ask can I choose it as my GSoC 2023 project? If > yes can anyone guide me to whom to connect to discuss it? > > And if I can't work on the above ideas then I have also gone through > the selected project ideas and want to work on the project "Implement > comp built-in traits for the standard library traits" so would be > grateful if anyone could guide me here also. I can't speak about the other projects, but I'm listed as the mentor for the built-in C++ trait project idea. On the frontend side most of the existing built-in traits are tabulated in gcc/cp/cp-trait.def, and their logic is defined in finish_trait_type or finish_trait_expr in gcc/cp/semantics.cc[2], and on library side the traits are conditionally used in the standard type trait definitions in libstdc++, e.g. std::remove_cv[3]. Take a look at the following commits that define (and add tests for) the built-in traits __remove_cv, __remove_reference and __remove_cvref and subsequently use them in libstdc++. Note that this first commit predates the new gcc/cp/cp-trait.def file which streamlined much of the boilerplate of adding a new built-in trait. In the new approach (that you would be using), only the semantics.cc change (which defines their logic) would be needed, alongside additions to cp-trait.def to declare each trait. https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9ca147154074a0de548138b4e73477e94903a855 https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=6ddbbbffbb5759a6c1d56c191364a6bd021f733e If you haven't already I'd recommend going through the GCC for new contributors guide https://gcc-newbies-guide.readthedocs.io/en/latest/index.html which goes through checking out, building and debugging GCC. Let me know if you have any questions :) [1]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cp/cp-trait.def [2]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cp/semantics.cc;h=79b7cc72f212cef780a3eea65af2b883bb4ec3c8;hb=HEAD#l12102 [3]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/type_traits;h=2bd607a8b8ff52aba6fd205ab1af2bc4b92f78d0;hb=HEAD#l1539 > > Thank you so much and I hope to hear from you soon. >
Cannot stat gcc/include-fixed/limits.h when installing GCC 4.7.2
Hi,
I originally sent this to the gcc-help list [1]. I'm not sure if it's a
bug in GCC or just an issue of some kind with my environment.
[1]: http://gcc.gnu.org/ml/gcc-help/2013-04/msg00090.html
I'm trying to build and install GCC 4.7.2, and I'm getting the following
error from the "install-mkheaders" target of gcc/Makefile:
[...]
/usr/bin/install -c -m 644
/home/pj/distro/pkg/gcc-4.7/tmp/src/gcc/gsyslimits.h \
/home/pj/distro/pkg/gcc-4.7/tmp/dest/usr/lib/amd64-linux-eglibc/gcc/x86_64-unknown-linux-gnu/4.7.2/install-tools/gsyslimits.h
/usr/bin/install -c -m 644 macro_list
/home/pj/distro/pkg/gcc-4.7/tmp/dest/usr/lib/amd64-linux-eglibc/gcc/x86_64-unknown-linux-gnu/4.7.2/install-tools/macro_list
/usr/bin/install -c -m 644 fixinc_list
/home/pj/distro/pkg/gcc-4.7/tmp/dest/usr/lib/amd64-linux-eglibc/gcc/x86_64-unknown-linux-gnu/4.7.2/install-tools/fixinc_list
set -e; for ml in `cat fixinc_list`; do \
multi_dir=`echo ${ml} | sed -e 's/^[^;]*;//'`; \
/bin/bash
/home/pj/distro/pkg/gcc-4.7/tmp/src/gcc/../mkinstalldirs
/home/pj/distro/pkg/gcc-4.7/tmp/dest/usr/lib/amd64-linux-eglibc/gcc/x86_64-unknown-linux-gnu/4.7.2/install-tools/include${multi_dir};
\
/usr/bin/install -c -m 644 include-fixed${multidir}/limits.h
/home/pj/distro/pkg/gcc-4.7/tmp/dest/usr/lib/amd64-linux-eglibc/gcc/x86_64-unknown-linux-gnu/4.7.2/install-tools/include${multi_dir}/limits.h;
\
done
/usr/bin/install: cannot stat `include-fixed/limits.h': No such file or
directory
make[3]: *** [install-mkheaders] Error 1
make[3]: Leaving directory `/home/pj/distro/pkg/gcc-4.7/tmp/gcc-build/gcc'
make[2]: *** [install-gcc] Error 2
make[2]: Leaving directory `/home/pj/distro/pkg/gcc-4.7/tmp/gcc-build'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/home/pj/distro/pkg/gcc-4.7/tmp/gcc-build'
make: *** [install] Error 2
I've confirmed that gcc/include-fixed/limits.h is generated when I
build GCC.
I watched for changes to gcc/include-fixed/limits.h while I updated the
"install" target of the top-level makefile:
$ inotifywait --monitor --format '[%T] %f: %e' --timefmt '%T'
gcc/include-fixed/ | grep -F -C 2 limits.h
Setting up watches.
Watches established.
[08:08:21] python2.6_d: DELETE,ISDIR
[08:08:21] gnu: DELETE
[08:08:21] syslimits.h: DELETE
[08:08:21] limits.h: MOVED_FROM
[08:08:21] syslimits.h: MOVED_TO
[08:08:21] syslimits.h: ATTRIB
[08:08:45] : OPEN,ISDIR
[08:08:45] xorg: OPEN,ISDIR
[08:08:45] xorg: CLOSE_NOWRITE,CLOSE,ISDIR
[08:08:45] syslimits.h: OPEN
[08:08:45] syslimits.h: ACCESS
[08:08:45] syslimits.h: CLOSE_NOWRITE,CLOSE
[08:08:45] irrlicht: OPEN,ISDIR
[08:08:45] irrlicht: CLOSE_NOWRITE,CLOSE,ISDIR
The deletion of syslimits.h, movement of limits.h to syslimits.h, and
change to the metadata of syslimits.h all look like the behavior of the
"stmp-fixinc" target. But as far as I can tell that target isn't being
updated with the top-level "install" target. (Nor should it be, as far
as I know.)
Does anyone have any idea what's happening here? Why is
gcc/include-fixed/limits.h being moved when updating the "install"
target?
Let me know if I can provide any other information that may help.
My build system:
* Linux 3.2.0
* EGLIBC 2.13
* GCC 4.7.2
* Binutils 2.22
Thanks,
--
Patrick "P. J." McDermott
http://www.pehjota.net/
http://www.pehjota.net/contact.html
GNU Make's -n option and $(MAKE) in makefiles (was: Cannot stat gcc/include-fixed/limits.h when installing GCC 4.7.2)
On 2013-04-16 15:00, Patrick 'P. J.' McDermott wrote:
[...]
>
> I'm trying to build and install GCC 4.7.2, and I'm getting the following
> error from the "install-mkheaders" target of gcc/Makefile:
[...]
>
> The deletion of syslimits.h, movement of limits.h to syslimits.h, and
> change to the metadata of syslimits.h all look like the behavior of the
> "stmp-fixinc" target. But as far as I can tell that target isn't being
> updated with the top-level "install" target. (Nor should it be, as far
> as I know.)
>
> Does anyone have any idea what's happening here? Why is
> gcc/include-fixed/limits.h being moved when updating the "install"
> target?
I've found the issue.
I'm using build helper utilities (similar to Debian's debhelper) to
build a distribution package of GCC. The utility that runs `make
install` first checks for an "install" target by running `make -n
install` [1], which is supposed to perform a dry run and print commands
without executing them. (debhelper's dh_auto_install does this check as
well [2].)
Running `make -n install` (or `MAKEFLAGS=n make install`) in GCC (4.7 at
least – I haven't tested 4.8 yet) instead actually executes commands.
Additionally, it updates the "stmp-fixinc" target of gcc/Makefile, which
as far as I can tell should not be updated with the top-level "install"
target. As a result, gcc/include-fixed/limits.h is moved to
gcc/include-fixed/syslimits.h, which causes the installation of a fixed
limits.h in the "install-mkheaders" target of gcc/Makefile to fail.
Example:
$ ../src/configure [...]
[...]
$ make bootstrap-lean
[...]
$ cp -Rp . ../gcc-build.build # Backup the build dir for comparison
$ make -n install
[...]
rm -rf include-fixed; mkdir include-fixed
chmod a+rx include-fixed
if [ -d ../prev-gcc ]; then \
cd ../prev-gcc && \
make real-install-headers-tar DESTDIR=`pwd`/../gcc/ \
libsubdir=. ; \
else \
set -e; for ml in `cat fixinc_list`; do \
sysroot_headers_suffix=`echo ${ml} | sed -e 's/;.*$//'`; \
multi_dir=`echo ${ml} | sed -e 's/^[^;]*;//'`; \
fix_dir=include-fixed${multi_dir}; \
[...]
rm -f ${fix_dir}/syslimits.h; \
if [ -f ${fix_dir}/limits.h ]; then \
mv ${fix_dir}/limits.h ${fix_dir}/syslimits.h; \
else \
cp ../../src/gcc/gsyslimits.h ${fix_dir}/syslimits.h; \
fi; \
chmod a+r ${fix_dir}/syslimits.h; \
done; \
fi
[...]
$ diff -Nur ../gcc-build.build . | diffstat -b
diff:
../gcc-build.build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stamp-bits:
Too many levels of symbolic links
diff: ./x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stamp-bits: Too
many levels of symbolic links
include-fixed/limits.h| 172
---
include-fixed/syslimits.h | 180
+++---
2 files changed, 172 insertions(+), 180 deletions(-)
The execution of commands appears to be caused by the use of the "MAKE"
macro [3], e.g. this line in the long command in the "stmp-fixinc"
target:
$(MAKE) real-$(INSTALL_HEADERS_DIR) DESTDIR=`pwd`/../gcc/ \
So this is partly an issue in the way GCC's makefiles use "$(MAKE)" in
long commands and mostly an issue in the (arguably non-standard and
surprising) way GNU Make (and System V make) treats commands that
contain "$(MAKE)". (Relevant: threads [4][5][6] on GNU Make mailing
lists and the discussion of proposals for -n and $(MAKE) behavior in
POSIX.1 [7].)
It could be avoided by defining a new macro, e.g. `_MAKE = $(MAKE)` and
replacing all expansions of MAKE in commands with expansions of the new
macro, e.g.:
$(_MAKE) real-$(INSTALL_HEADERS_DIR) DESTDIR=`pwd`/../gcc/ \
Thoughts?
[1]:
http://git.proteanos.com/opkhelper/opkhelper.git/tree/lib/buildsystem/make.sh?id=bf055e8#n99
[2]:
http://anonscm.debian.org/gitweb/?p=debhelper/debhelper.git;a=blob;f=Debian/Debhelper/Buildsystem/makefile.pm;h=c63b58e#l13
[3]: https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html
[4]: https://lists.gnu.org/archive/html/bug-make/2010-01/msg00014.html
[5]: https://lists.gnu.org/archive/html/help-make/2003-06/msg00048.html
[6]: https://lists.gnu.org/archive/html/help-make/2008-07/msg00017.html
[7]:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html#tag_20_76_18
--
Patrick "P. J." McDermott
http://www.pehjota.net/
http://www.pehjota.net/contact.html
