Re: Trouble installing gfortran
This mailing list is for development of gcc, not help using it. Please direct questions about using or building gcc to the gcc-help list, thanks. On 10 January 2012 00:54, John Harper wrote: > My little test program then compiled but wouldn't run even though the > library said to be missing does exist. It was peresumably put somewhere > that gfortran couldn't find it. What should I do now? Evidence: [...] > rimu[~]$ ./a.out > ./a.out: error while loading shared libraries: libquadmath.so.0: cannot open > shared object file: No such file or directory The dynamic linker needs to know how to find the library at run time. http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths
Re: contributing to gcc
On Mon, Jan 09, 2012 at 07:33:54PM -0500, Aayush Upadhyay wrote:
> I'm a sophomore in college, and I'm a solid C programmer. I'd like to work
> on an open source project, and the gcc compiler seems like a great one.
In addition to the other replies, you could also contribute to branches or
to GCC plugin (or to the GCC infrastructure). For example, you could (if you
wanted to) contribute to the MELT branch and plugin: http://gcc-melt.org/
Be however aware of one important point, specific to GCC and several other
GNU software: the copyright owner is the FSF, and you need some legal paper
to be done. Read carefully http://gcc.gnu.org/contribute.html#legal
This implies practically that you get some legal paper signed by you and by
your university (and by the FSF). Getting that paper signed takes
burocractic time and effort: you'll need to convince people in suits (e.g.
your University Dean) to sign a legal paper. You can understand this process
as also being a screening procedure for your personal motivation :-) [I'm
half joking here]
Be sure that you won't be able to contribute to GCC (even to some
experimental branches) without having settled the legal questions, which
requires such documents to be processed.
So if you are serious about contributing to GCC (or any branches of it),
start working on these legal aspects today. They take a lot of time
(months) to be achieved. I'm serious, if you want to contribute to GCC,
worry about the legal aspects right now (this means getting a legal paper
signed to transfer copyright to FSF and to share responsability in case you
violated some copyright).
And welcome to the GCC community, if you want to be part of it.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
struggling with make inside GCC MELT
Hello All
I am fighting against makefile issues on the GCC MELT branch.
Much more details are given in
http://stackoverflow.com/q/8727896/841108
and in
http://lists.gnu.org/archive/html/help-make/2012-01/msg00017.html
So (unless you ask) I won't repeat them here.
(and the bugs affect mostly me, not the usual MELT user)
The symptoms are:
1. make -j don't work
2. "make ; make" is running a lot of useless commands for the
second make and it should not
I probably am not understanding when stampfiles in Makefiles should be
used. The main point is that MELT cares much more about file contents
than file timestamps.
Should I also post on this list to get some help?
(In other words, is anyone interested in helping)
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: struggling with make inside GCC MELT
Basile Starynkevitch writes: > I am fighting against makefile issues on the GCC MELT branch. > > Much more details are given in >http://stackoverflow.com/q/8727896/841108 > and in >http://lists.gnu.org/archive/html/help-make/2012-01/msg00017.html > > So (unless you ask) I won't repeat them here. > > (and the bugs affect mostly me, not the usual MELT user) > > The symptoms are: > >1. make -j don't work > >2. "make ; make" is running a lot of useless commands for the > second make and it should not > > > I probably am not understanding when stampfiles in Makefiles should be > used. The main point is that MELT cares much more about file contents > than file timestamps. Your stackoverflow question has way too much detail for me to understand. I think you need to debug this like any other issue: reduce to the minimal test case. Stamp files in make work like this: FILE: STAMP-FILE; @true STAMP-FILE: DEPENDENCIES commands to create FILE.tmp move-if-change FILE.tmp FILE touch $@ What this says is: if any of DEPENDENCIES change, then run the commands to create FILE.tmp. The move-if-change shell script then compares FILE.tmp and FILE; if they are different, it moves FILE.tmp to FILE, updating the timestamp. If they are not different, FILE is left unchanged, with the same timestamp. The effect is that anything which depends on FILE is only rebuilt if the contents of FILE changes. Note that everything I show above is required. A naive approach would omit the "; @true" but it is necessary. Ian
Re: struggling with make inside GCC MELT
On Tue, Jan 10, 2012 at 07:12:50AM -0800, Ian Lance Taylor wrote:
> Basile Starynkevitch writes:
>
> > I am fighting against makefile issues on the GCC MELT branch.
> >
> > Much more details are given in
> >http://stackoverflow.com/q/8727896/841108
> > and in
> >http://lists.gnu.org/archive/html/help-make/2012-01/msg00017.html
> >
> > So (unless you ask) I won't repeat them here.
> >
> > (and the bugs affect mostly me, not the usual MELT user)
> >
> > The symptoms are:
> >
> >1. make -j don't work
> >
> >2. "make ; make" is running a lot of useless commands for the
> > second make and it should not
> >
> >
> > I probably am not understanding when stampfiles in Makefiles should be
> > used. The main point is that MELT cares much more about file contents
> > than file timestamps.
>
> Your stackoverflow question has way too much detail for me to
> understand. I think you need to debug this like any other issue: reduce
> to the minimal test case.
>
> Stamp files in make work like this:
>
> FILE: STAMP-FILE; @true
> STAMP-FILE: DEPENDENCIES
> commands to create FILE.tmp
> move-if-change FILE.tmp FILE
> touch $@
>
> What this says is: if any of DEPENDENCIES change, then run the commands
> to create FILE.tmp. The move-if-change shell script then compares
> FILE.tmp and FILE; if they are different, it moves FILE.tmp to FILE,
> updating the timestamp. If they are not different, FILE is left
> unchanged, with the same timestamp.
A big thanks for the reply. Then I can ask the next question: when should I use
time stamps files?
Only for dependencies upon content, or something else?
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: struggling with make inside GCC MELT
Basile Starynkevitch writes: > On Tue, Jan 10, 2012 at 07:12:50AM -0800, Ian Lance Taylor wrote: >> Basile Starynkevitch writes: >> >> > I am fighting against makefile issues on the GCC MELT branch. >> > >> > Much more details are given in >> >http://stackoverflow.com/q/8727896/841108 >> > and in >> >http://lists.gnu.org/archive/html/help-make/2012-01/msg00017.html >> > >> > So (unless you ask) I won't repeat them here. >> > >> > (and the bugs affect mostly me, not the usual MELT user) >> > >> > The symptoms are: >> > >> >1. make -j don't work >> > >> >2. "make ; make" is running a lot of useless commands for the >> > second make and it should not >> > >> > >> > I probably am not understanding when stampfiles in Makefiles should be >> > used. The main point is that MELT cares much more about file contents >> > than file timestamps. >> >> Your stackoverflow question has way too much detail for me to >> understand. I think you need to debug this like any other issue: reduce >> to the minimal test case. >> >> Stamp files in make work like this: >> >> FILE: STAMP-FILE; @true >> STAMP-FILE: DEPENDENCIES >> commands to create FILE.tmp >> move-if-change FILE.tmp FILE >> touch $@ >> >> What this says is: if any of DEPENDENCIES change, then run the commands >> to create FILE.tmp. The move-if-change shell script then compares >> FILE.tmp and FILE; if they are different, it moves FILE.tmp to FILE, >> updating the timestamp. If they are not different, FILE is left >> unchanged, with the same timestamp. > > > A big thanks for the reply. Then I can ask the next question: when should I > use time stamps files? > Only for dependencies upon content, or something else? Only for dependencies on content. That is, only when you want Make targets that depend on FILE to be rebuilt if the contents of FILE changes, and to not be rebuilt if any of DEPENDENCIES change without changing FILE. Ian
Re: IRA issue with shuffle copies...
On 01/07/2012 12:24 AM, Peter Bergner wrote:
Hi Vlad,
While debugging a slightly modified version of the test case in PR16458:
int
foo (unsigned int a, unsigned int b)
{
if (a == b) return 1;
if (a> b) return 2;
if (a< b) return 3;
if (a != b) return 4;
return 0;
}
I noticed a couple of ugly code gen warts which I tracked back to IRA.
Namely, compiling the above with -O2 -m32 on powerpc64-linux, I'm seeing:
li 9,3
mr 3,9
blr
and:
li 9,1
mr 3,9
blr
If we look at the rtl just before IRA, we have the following:
BB2:
(set (reg/v:SI 122 [ a ]) (reg:SI 3 3 [ a ]))
REG_DEAD (reg:SI 3 3 [ a ])
(set (reg/v:SI 123 [ b ]) (reg:SI 4 4 [ b ]))
REG_DEAD (reg:SI 4 4 [ b ])
(set (reg:CC 124) (compare:CC (reg/v:SI 122 [ a ]) (reg/v:SI 123 [ b ])))
(if_then_else (eq (reg:CC 124) (const_int 0 [0]))
goto BB6;
BB3:
(set (reg:CCUNS 125) (compare:CCUNS (reg/v:SI 122 [ a ]) (reg/v:SI 123 [ b
]))) REG_DEAD (reg/v:SI 123 [ b ])
REG_DEAD (reg/v:SI 122 [ a ])
(set (reg:SI 120 [ D.1379 ]) (const_int 2 [0x2]))
(if_then_else (gtu (reg:CC 124) (const_int 0 [0]))
goto BB8;
BB4:
(if_then_else (geu (reg:CC 124) (const_int 0 [0]))
goto BB7;
BB5:
(set (reg:SI 120 [ D.1379 ]) (const_int 3 [0x3]))
goto BB8;
BB6:
(set (reg:SI 120 [ D.1379 ]) (const_int 1 [0x1]))
goto BB8;
BB7:
(set (reg:SI 120 [ D.1379 ]) (const_int 4 [0x4]))
BB8:
(set (reg/i:SI 3 3) (reg:SI 120 [ D.1379 ])) REG_DEAD (reg:SI 120 [ D.1379 ])
(use (reg/i:SI 3 3))
return
When we start coloring the allocnos, we get the following:
Pass 1 for finding pseudo/allocno costs
r125: preferred CR_REGS, ...
r124: preferred CR_REGS, ...
r123: preferred GENERAL_REGS, ...
r122: preferred GENERAL_REGS, ...
r120: preferred GENERAL_REGS, ...
...
Popping a3(r122,l0) -- assign reg 3
Popping a2(r123,l0) -- assign reg 4
Popping a0(r120,l0) -- assign reg 9
Popping a4(r124,l0) -- assign reg 75
Popping a1(r125,l0) -- assign reg 3
Assigning 75 to a1r125
This looks a little startling, since we're initially assigning r125 to r3,
even though it's preferred class is CR_REGS before improve_allocation()
saves us and reassigns r125 to r75 (a real CR reg). The reason r125
ends up initially in r3 is that we detect a "shuffle" copy during the
set of r125, because r122 (and r123) dies in the insn r125 is defined in.
This ends up preferencing the costs for r125, such that it wants r3.
This in turn via ALLOCNO_UPDATED_HARD_REG_COSTS() increases the cost
of assigning r120 to r3, such that r120 ends up with r9 instead, when
we really really want it to get r3.
Thanks for the analysis, Peter.
Your comments about the "shuffle" copies seem to infer that they're being
used to try and help insns with two operand contraints, but in the case
above, they're over preferencing things. As an experiment, I disabled all
shuffle copies and the code gen for the test case above is much improved.
Do we really need or want to create shuffle copies for insns that do not
have a two operand constraint?
Yes, I think so. As I remember I did some benchmarking and it gave some
"order" in hard register assignments and improved code slightly (at
least for SPEC2000) even for 3-ops insn architectures.
If not, do you know how we can test for that?
If you think we do need that for non two operand contraint insns, can we
at least disable creating shuffle copies for allocnos that have different
preferred classes, since they're probably not going to be assigned the
same hard reg?
I guess we could try this and it might work.
Ala:
Index: ira-conflicts.c
===
--- ira-conflicts.c (revision 182936)
+++ ira-conflicts.c (working copy)
@@ -397,6 +397,11 @@ process_regs_for_copy (rtx reg1, rtx reg
enum machine_mode mode;
ira_copy_t cp;
+ if (!constraint_p
+&& reg_preferred_class (REGNO (reg1))
+!= reg_preferred_class (REGNO (reg2)))
+return false;
+
gcc_assert (REG_SUBREG_P (reg1)&& REG_SUBREG_P (reg2));
only_regs_p = REG_P (reg1)&& REG_P (reg2);
reg1 = go_through_subreg (reg1,&offset1);
Your thoughts?
Your patch might work. But we need to test it for major 2-ops
architecture x86/x86-64 and 3-ops ppc (I believe SPEC2000 would be ok
for this).
Re: [4.7,trans-mem] Summary of unsolved known bugs
On 01/09/12 04:20, Torvald Riegel wrote: Looking at Patrick's old list, the following bugs are still open [trans-mem] save/restore of thread-local data in nested txns is missing http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49581 Aldy, you wanted to take a look. Were you able to reproduce? I haven't looked at it in a long time... I haven't yet. * [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 Aldy, has this been fixed? You said you were waiting for review. Just committed a fix for this and closed the PR. * 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? Last I looked I couldn't reproduce. Torvald, perhaps you could see if you can reproduce on your end? Probably should be closed: * libitm failures http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51124 Can be closed? the static ctor part is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51173 I just closed this as it was an assortment of distinct failures reported by a variety of people on different architectures (some of which were already fixed). I have suggested in the notes that individual PRs be filed if problems are still present. A generic "libitm failures" PR doesn't help. Aldy
Re: IRA issue with shuffle copies...
On Tue, 2012-01-10 at 12:20 -0500, Vladimir Makarov wrote: > > Do we really need or want to create shuffle copies for insns that do not > > have a two operand constraint? > Yes, I think so. As I remember I did some benchmarking and it gave some > "order" in hard register assignments and improved code slightly (at > least for SPEC2000) even for 3-ops insn architectures. I'm a little skeptical about 3-op insn architectures, but will take your word for it since you tested it. I may have someone on the team disable completely for ppc just as a test just so we can analyze why it helps. Sometimes just knowing why is a good thing. :) > Your patch might work. But we need to test it for major 2-ops > architecture x86/x86-64 and 3-ops ppc (I believe SPEC2000 would be ok > for this). Ok, I'll have someone on my team kick off this patch on ppc, but it would be nice if someone else could do the runs on x86/x86_64 or other cpus that might be affected that we don't have access to. Peter
ANN: gcc-python-plugin 0.8
gcc-python-plugin is a plugin for GCC 4.6 onwards which embeds the CPython interpreter within GCC, allowing you to write new compiler warnings in Python, generate code visualizations, etc. It ships with "gcc-with-cpychecker", which implements static analysis passes for GCC aimed at finding bugs in CPython extensions. In particular, it can automatically detect reference-counting errors: http://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html Detailed release notes can be seen at: http://gcc-python-plugin.readthedocs.org/en/latest/0.8.html Some highlights of the 0.8 release: * it's much easier than before to emit compilation warnings * initial support for analyzing C++ code from a Python script * gcc-with-cpychecker has gained additional tests. It now has knowledge of which CPython API calls will crash when passed NULL, and will warn you (with details) about code paths that can trigger such a call. It can also now detect certain subtle errors in PyMethodDef tables. * numerous bug fixes and other improvements Tarball releases are available at: https://fedorahosted.org/releases/g/c/gcc-python-plugin/ Prebuilt-documentation can be seen at: http://gcc-python-plugin.readthedocs.org/en/latest/index.html The project's homepage is: https://fedorahosted.org/gcc-python-plugin/ The plugin and checker are Free Software, licensed under the GPLv3 or later. Thanks to Red Hat for funding their development, and to David Narvaez and Tom Tromey for their contributions to this release. Enjoy! Dave Malcolm
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/11/2012 09:29 AM, Patrick Marlier wrote: > + /* ??? mark only the first call, is it right? */ > + for (insn = get_last_insn (); > +insn && !CALL_P (insn); > insn = next_real_insn (insn)) > continue; FYI, there shall only be one call, surely. Hmm. I suppose there could be calls to memcpy in the case of very large structures passed by value (depending on the ABI). Or indeed, with -ftree-ter rebuilding more complex expressions we could have any arbitrary libcall. 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. r~
gcc-4.4-20120110 is now available
Snapshot gcc-4.4-20120110 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20120110/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 183077 You'll find: gcc-4.4-20120110.tar.bz2 Complete GCC MD5=e750bb6cabd416938a103067ac8fd52a SHA1=1b34d01fa3c95c89692264baa0cde1f6cad202ef Diffs from 4.4-20120103 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
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.
Go in gcc 4.7
The Go language is closing in what we are calling Go version 1. This will be a long-term stable release of Go, with no language or library API changes. Go 1 is described here: https://docs.google.com/a/google.com/document/pub?id=1ny8uI-_BHrDCZv_zNBSthNKAMX_fR_0dc6epA6lztRE The expected completion date is late February. My goal with gccgo is to include a complete Go 1 implementation with the gcc 4.7 release. Therefore, I plan to continue to patch the code in gcc/go and libgo. There shouldn't be any major changes, but there will be various minor ones. Since this code is only built optionally, it should not affect the rest of the release process. Please let me know about any objections or concerns. Ian
