On Sat, 30 Apr 2011 18:33:56 +0200
Aéris <ae...@imirhil.fr> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Le 30/04/2011 18:20, Jean-Yves F. Barbier a écrit :
> > ben d'après ce que j'ai compris, si (enfin si je veux garder les traces de
> > toutes les modifs d'un fichier jusqu'au commit final)
Je confirme. Et d'ailleurs, c'est une règle de base dans les gros
projets collaboratifs (comme GCC). On commit des *petites*
modifications, souvent de quelques lignes ou douzaines de lignes.
Par exemple, sur GCC (versionné avec SVN), il y a 173221 commits depuis
son origine (dans les années 1985?). Et les 5 derniers (obtenus par
svn log --limit 5) sont!
0
------------------------------------------------------------------------
r173221 | burnus | 2011-04-30 18:33:47 +0200 (Sat, 30 Apr 2011) | 8 lines
2011-04-30 Tobias Burnus <bur...@net-b.de>
PR fortran/48821
* gfortran.dg/import9.f90: New, proper test.
* gfortran.dg/interface_37.f90: Remove bogus
test (bogus copy of interface_36.f90).
------------------------------------------------------------------------
r173220 | dougkwan | 2011-04-30 18:26:23 +0200 (Sat, 30 Apr 2011) | 6 lines
2011-04-30 Doug Kwan <dougk...@google.com>
* include/Makefile.am (install-freestanding-headers): Also install
cxxabi_tweaks.h.
* include/Makefile.in: Regenerate.
------------------------------------------------------------------------
r173219 | burnus | 2011-04-30 17:54:49 +0200 (Sat, 30 Apr 2011) | 12 lines
2011-04-30 Tobias Burnus <bur...@net-b.de>
PR fortran/48800
* decl.c (gfc_match_import): Don't try to find the
symbol if already found.
2011-04-30 Tobias Burnus <bur...@net-b.de>
PR fortran/48800
* gfortran.dg/interface_37.f90: New.
------------------------------------------------------------------------
r173217 | dnovillo | 2011-04-30 17:20:58 +0200 (Sat, 30 Apr 2011) | 31 lines
cp/ChangeLog
2011-04-29 Le-Chun Wu <l...@google.com>
* cp-tree.h (LOOKUP_EXPLICIT_TMPL_ARGS): Define.
* call.c (build_new_function_call): Set it for TEMPLATE_ID_EXPRs.
(build_over_call): Use it to determine whether to emit a NULL
warning for template function instantiations.
(build_new_method_call): Set LOOKUP_EXPLICIT_TMPL_ARGS if
EXPLICIT_TARGS is set.
2011-04-29 Diego Novillo <dnovi...@google.com>
Le-Chun Wu <l...@google.com>
* call.c (conversion_null_warnings): Also handle assignments
when warning about NULL conversions.
testsuite/ChangeLog
2011-04-29 Le-Chun Wu <l...@google.com>
* g++.dg/warn/Wnull-conversion-1.C: New.
* g++.dg/warn/Wnull-conversion-2.C: New.
2011-04-29 Le-Chun Wu <l...@google.com>
* g++.dg/warn/Wconversion-null-2.C: Do not expect a NULL
warning in implicitly instantiated templates.
2011-04-29 Diego Novillo <dnovi...@google.com>
* g++.old-deja/g++.other/null3.C: Expect warning about converting
boolean to a pointer.
------------------------------------------------------------------------
r173216 | hubicka | 2011-04-30 16:08:03 +0200 (Sat, 30 Apr 2011) | 5 lines
* ipa-inline.c (can_inline_edge_p): Disregard limits when
inlining into function with flatten attribute.
(want_inline_small_function_p): Be more realistic about inlining
cold calls where callee size grows.
Le dernier commit de cette liste (r173216) est le patch ci-dessous
(je ne donne pas le patch du ChangeLog, il est ci dessu).
Index: gcc/ipa-inline.c
===================================================================
--- gcc/ipa-inline.c (revision 173215)
+++ gcc/ipa-inline.c (revision 173216)
@@ -272,9 +272,11 @@
FIXME: this is obviously wrong for LTO where STRUCT_FUNCTION is missing.
Move the flag into cgraph node or mirror it in the inline summary. */
else if (DECL_STRUCT_FUNCTION (e->callee->decl)
- && DECL_STRUCT_FUNCTION
(e->callee->decl)->can_throw_non_call_exceptions
+ && DECL_STRUCT_FUNCTION
+ (e->callee->decl)->can_throw_non_call_exceptions
&& !(DECL_STRUCT_FUNCTION (e->caller->decl)
- && DECL_STRUCT_FUNCTION
(e->caller->decl)->can_throw_non_call_exceptions))
+ && DECL_STRUCT_FUNCTION
+ (e->caller->decl)->can_throw_non_call_exceptions))
{
e->inline_failed = CIF_NON_CALL_EXCEPTIONS;
inlinable = false;
@@ -288,6 +290,11 @@
}
/* Check if caller growth allows the inlining. */
else if (!DECL_DISREGARD_INLINE_LIMITS (e->callee->decl)
+ && !lookup_attribute ("flatten",
+ DECL_ATTRIBUTES
+ (e->caller->global.inlined_to
+ ? e->caller->global.inlined_to->decl
+ : e->caller->decl))
&& !caller_growth_limits (e))
inlinable = false;
/* Don't inline a function with a higher optimization level than the
@@ -468,8 +475,39 @@
e->inline_failed = CIF_MAX_INLINE_INSNS_AUTO_LIMIT;
want_inline = false;
}
+ /* If call is cold, do not inline when function body would grow.
+ Still inline when the overall unit size will shrink because the offline
+ copy of function being eliminated.
+
+ This is slightly wrong on aggressive side: it is entirely possible
+ that function is called many times with a context where inlining
+ reduces code size and few times with a context where inlining increase
+ code size. Resoluting growth estimate will be negative even if it
+ would make more sense to keep offline copy and do not inline into the
+ call sites that makes the code size grow.
+
+ When badness orders the calls in a way that code reducing calls come
+ first, this situation is not a problem at all: after inlining all
+ "good" calls, we will realize that keeping the function around is
+ better. */
else if (!cgraph_maybe_hot_edge_p (e)
- && estimate_growth (e->callee) > 0)
+ && (DECL_EXTERNAL (e->callee->decl)
+
+ /* Unlike for functions called once, we play unsafe with
+ COMDATs. We can allow that since we know functions
+ in consideration are small (and thus risk is small) and
+ moreover grow estimates already accounts that COMDAT
+ functions may or may not disappear when eliminated from
+ current unit. With good probability making aggressive
+ choice in all units is going to make overall program
+ smaller.
+
+ Consequently we ask cgraph_can_remove_if_no_direct_calls_p
+ instead of
+ cgraph_will_be_removed_from_program_if_no_direct_calls */
+
+ || !cgraph_can_remove_if_no_direct_calls_p (e->callee)
+ || estimate_growth (e->callee) > 0))
{
e->inline_failed = CIF_UNLIKELY_CALL;
want_inline = false;
Comme tu peux le voir, les développeurs de gcc commettent des petits
patchs le plus souvent (quelques dizaines de lignes modifiées par commit).
Il peut arriver que la description du commit (c'est à dire l'entrée dans
un ChangeLog) soit presque aussi grosse que le changement commis.
C'est aussi dû à la règle sociale de GCC: on ne peut y commettre que du
code qui a été revu et approuvé par autrui.
Et même sur un développement où je suis tout seul, je commite plusieurs
fois par jour. Le temps entre deux commit, c'est le temps élémentaire
qu'on accepte de perdre. On a donc intérêt à ce qu'il ne soit pas trop
long.
C'est aussi un avantage de GIT sur SVN: il sait faire des branches
facilement et il sait commiter rapidement.
En gros, je commite souvent après correction d'un seul bogue ou ajout
d'une seule fonction ou méthode (notamment quand elle est publique), ou
ajout de quelques douzaines de lignes au maximum. Je commite toujours
avant de partir (manger, ou chez moi). Si je travaille toute la
journée, je vais svn commettre deux fois par jour au moins (sauf
peut-être quand je chasse un bogue insidieux qui me prend plusieurs
jours).
Bien sûr, faire cent commit-s dans une journée serait quand même
excessif. Un truc très important, c'est d'avoir un message clair
associé à son commit (ce n'est pas facile). Dans un développmeent
communautaire, c'est indispensable et fortement codifié (chaque entrée
d'un ChangeLog de GCC correspond à un commit). Quand je bosse tout
seul, j'ai à tort la faiblesse de mettre des messages de commit trop
courts, et je le regrette plus tard.
Il faut aussi savoir que Emacs a des modes pour faciliter le travail
dans un versionneur.
Cordialement
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive:
http://lists.debian.org/20110430192550.2be91344.bas...@starynkevitch.net
