DejaGnu diagnostics checking confused, possibly related to 'dg-line'?
Hi!
Help. Save the attached file as 'gcc/testsuite/c-c++-common/goacc/l_.c',
and then run:
$ make check-gcc-c++ RUNTESTFLAGS=--all\ goacc.exp=l_.c
As expected for '-std=c++98' testing, which comes first:
PASS: c-c++-common/goacc/l_.c -std=c++98 (test for errors, line 14)
PASS: c-c++-common/goacc/l_.c -std=c++98 (test for warnings, line 11)
PASS: c-c++-common/goacc/l_.c -std=c++98 (test for excess errors)
WARNING: dg-line var l1 defined, but not used
WARNING: dg-line var l2 defined, but not used
WARNING: dg-line var l3 defined, but not used
But then it goes on with '-std=c++14', etc. testing:
UNRESOLVED: c-c++-common/goacc/l_.c -std=c++14 (test for errors, line 14)
PASS: c-c++-common/goacc/l_.c -std=c++14 (test for warnings, line 11)
PASS: c-c++-common/goacc/l_.c -std=c++14 (test for excess errors)
WARNING: dg-line var l1 defined, but not used
WARNING: dg-line var l2 defined, but not used
WARNING: dg-line var l3 defined, but not used
UNRESOLVED: c-c++-common/goacc/l_.c -std=c++17 (test for errors, line 14)
PASS: c-c++-common/goacc/l_.c -std=c++17 (test for warnings, line 11)
PASS: c-c++-common/goacc/l_.c -std=c++17 (test for excess errors)
WARNING: dg-line var l1 defined, but not used
WARNING: dg-line var l2 defined, but not used
WARNING: dg-line var l3 defined, but not used
UNRESOLVED: c-c++-common/goacc/l_.c -std=c++2a (test for errors, line 14)
PASS: c-c++-common/goacc/l_.c -std=c++2a (test for warnings, line 11)
PASS: c-c++-common/goacc/l_.c -std=c++2a (test for excess errors)
WARNING: dg-line var l1 defined, but not used
WARNING: dg-line var l2 defined, but not used
WARNING: dg-line var l3 defined, but not used
=== g++ Summary ===
# of expected passes9
# of unresolved testcases 3
Why is suddenly the "test for errors, line 14" an UNRESOLVED? (The
compiler diagnostics are as expected. This testcase doesn't depend on
'-std=[...]' at all.)
And now the "funny" thing: if I disable any of the 'dg-line' directives,
it works as expected, all-PASS. But note that "test for errors, line 14"
doesn't even use a 'dg-line'-captured line number. (It uses absoute line
numbers. Same issue visible when using relative ones, or when actually
using 'dg-line' for these.)
I reduced this from a much bigger testcase, and had originally found this
not with 'check-gcc-c++' but with 'check-gcc-c': things worked fine as
long as testing just a single testcase, but broke when testing several.
(Again the symptom was that the first testcase worked fine, but the
following ones had an unexpecte UNRESOLVED for the first 'dg-error' (only
for the first!).) Supposedly, 'check-gcc-c++' with a single testcase but
testing several variants is exhibiting the same problem.
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
static void test(void)
{
int i, j;
#pragma acc parallel
{
/* { dg-line l1 } */
/* { dg-line l2 } */
/* { dg-line l3 } */
#pragma acc loop gang
for (i = 0; i < 10; i++)
{
#pragma acc loop gang
/* { dg-error "inner loop uses same OpenACC parallelism as containing loop" "" { target *-*-* } 14 } */
/* { dg-message "containing loop" "" { target *-*-* } 11 } */
for (j = 0; j < 10; j++)
;
}
}
}
armv7+neon bus error
Hello, I built gcc for armv7+neon target with 128-bit stack alignment to enable ASan with custom shadow memory scale. I got bus error in runtime for some of utils built with the toolchain. I checked disassembler output and found that sometimes gcc vectorizes assignments at the ASan epilogue of functions. But it generates VSTR instruction for unaligned memory accesses which leads to bus error condition. I have the following gimple assignment in gcc: tree magic = build_int_cst (TREE_TYPE (shadow_ptr_type), val); tree dest = build2 (MEM_REF, TREE_TYPE (shadow_ptr_type), shadow, build_int_cst (shadow_ptr_type, base_addr_offset)); gimple *g = gimple_build_assign (dest, magic); It generates the following instructions: 9b16:f109 5300 add.wr3, r9, #536870912; 0x2000 9b1a:efc0 0010 vmov.i32d16, #0; 0x 9b1e:edc3 0b00 vstrd16, [r3] 9b22:edc3 0b01 vstrd16, [r3, #4] At the expand stage I have the following tree dump related to the case: (insn 56 55 57 311 (set (reg/f:SI 867) (plus:SI (reg:SI 856) (const_int 536870912 [0x2000]))) "ls.c":1394:1 -1 (nil)) (insn 57 56 58 311 (set (reg:SI 868) (reg/f:SI 867)) "ls.c":1394:1 -1 (nil)) (insn 58 57 59 311 (set (reg:V8QI 869) (const_vector:V8QI [ (const_int 0 [0]) repeated x8 ])) "ls.c":1394:1 -1 (nil)) (insn 59 58 60 311 (set (mem:V8QI (reg:SI 868) [33 S8 A32]) (reg:V8QI 869)) "ls.c":1394:1 -1 (nil)) (insn 60 59 61 311 (set (mem:V8QI (plus:SI (reg:SI 868) (const_int 4 [0x4])) [33 S8 A32]) (reg:V8QI 869)) "ls.c":1394:1 -1\ (nil)) I doesn't have enough experience with gcc internals to figure out why gcc generates the code above. And what conditions are met, which leads to the usage of vector instructions with unaligned addresses Any tips will be appreciate. Thanks, Andrei Kazmin
Re: Incremental updating of SSA_NAMEs that are passed to b_c_p
On Fri, 2020-10-30 at 09:22 +0100, Richard Biener wrote:
> On Thu, Oct 29, 2020 at 6:20 PM Ilya Leoshkevich
> wrote:
> > On Wed, 2020-10-28 at 12:18 +0100, Richard Biener wrote:
> > > On Tue, Oct 27, 2020 at 7:36 PM Ilya Leoshkevich via Gcc
> > > wrote:
> > > > Hi,
> > > >
> > > > I'd like to revive the old discussion regarding the interaction
> > > > of
> > > > jump threading and b_c_p causing the latter to incorrectly
> > > > return 1
> > > > in
> > > > certain cases:
> > > >
> > > > https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547236.html
> > > > https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549288.html
> > > >
> > > > The conclusion was that this happening during threading is just
> > > > a
> > > > symptom of a deeper problem: SSA_NAMEs that are passed to b_c_p
> > > > should
> > > > not be registered for incremental updating.
> > > >
> > > > I performed a little experiment and added an assertion to
> > > > create_new_def_for:
> > > >
> > > > --- a/gcc/tree-into-ssa.c
> > > > +++ b/gcc/tree-into-ssa.c
> > > > @@ -2996,6 +3014,8 @@ create_new_def_for (tree old_name, gimple
> > > > *stmt,
> > > > def_operand_p def)
> > > > {
> > > >tree new_name;
> > > >
> > > > + gcc_checking_assert (!used_by_bcp_p (old_name));
> > > > +
> > > >timevar_push (TV_TREE_SSA_INCREMENTAL);
> > > >
> > > >if (!update_ssa_initialized_fn)
> > > >
> > > > This has of course fired when performing basic block
> > > > duplication
> > > > during
> > > > threading, which can be fixed by avoiding duplication of basic
> > > > blocks
> > > > wi
> > > > th b_c_p calls:
> > > >
> > > > --- a/gcc/tree-cfg.c
> > > > +++ b/gcc/tree-cfg.c
> > > > @@ -6224,7 +6224,8 @@ gimple_can_duplicate_bb_p
> > > > (const_basic_block
> > > > bb)
> > > > || gimple_call_internal_p (g, IFN_GOMP_SIMT_EXIT)
> > > > || gimple_call_internal_p (g,
> > > > IFN_GOMP_SIMT_VOTE_ANY)
> > > > || gimple_call_internal_p (g,
> > > > IFN_GOMP_SIMT_XCHG_BFLY)
> > > > - || gimple_call_internal_p (g,
> > > > IFN_GOMP_SIMT_XCHG_IDX)))
> > > > + || gimple_call_internal_p (g,
> > > > IFN_GOMP_SIMT_XCHG_IDX)
> > > > + || gimple_call_builtin_p (g,
> > > > BUILT_IN_CONSTANT_P)))
> > > > return false;
> > > > }
> > > >
> > > > The second occurrence is a bit more interesting:
> > > >
> > > > gimple *
> > > > vrp_insert::build_assert_expr_for (tree cond, tree v)
> > > > {
> > > > ...
> > > > a = build2 (ASSERT_EXPR, TREE_TYPE (v), v, cond);
> > > > assertion = gimple_build_assign (NULL_TREE, a);
> > > > ...
> > > > tree new_def = create_new_def_for (v, assertion, NULL);
> > > >
> > > > The fix is also simple though:
> > > >
> > > > --- a/gcc/tree-vrp.c
> > > > +++ b/gcc/tree-vrp.c
> > > > @@ -3101,6 +3101,9 @@ vrp_insert::process_assert_insertions_for
> > > > (tree
> > > > name, assert_locus *loc)
> > > >if (loc->expr == loc->val)
> > > > return false;
> > > >
> > > > + if (used_by_bcp_p (name))
> > > > +return false;
> > > > +
> > > >cond = build2 (loc->comp_code, boolean_type_node, loc->expr,
> > > > loc-
> > > > > val);
> > > >assert_stmt = build_assert_expr_for (cond, name);
> > > >if (loc->e)
> > > >
> > > > My original testcase did not trigger anything else. I'm
> > > > planning
> > > > to
> > > > check how this affects the testsuite, but before going further
> > > > I
> > > > would
> > > > like to ask: is this the right direction now? To me it looks a
> > > > little-bit more heavy-handed than the original approach, but
> > > > maybe
> > > > it's
> > > > worth it.
> > >
> > > Disabling threading looks reasonable but I'd rather not disallow
> > > BB
> > > duplication
> > > or renaming. For VRP I guess we want to instead change
> > > register_edge_assert_for* to not register assertions for the
> > > result
> > > of
> > > __builtin_constant_p rather than just not allowing VRP to process
> > > it
> > > (there are other consumers still).
> >
> > If I understood Jeff correctly, we should disable incremental
> > updates
> > for absolutely all b_c_p arguments, so affecting as many consumers
> > as
> > possible must actually be a good thing when this approach is
> > considered?
> >
> > That said, regtest has revealed one more place where this is
> > happening:
> > rewrite_into_loop_closed_ssa_1 -> ... -> add_exit_phi ->
> > create_new_def_for. The reduced code is:
> >
> > int a;
> >
> > void
> > b (void)
> > {
> > while (a)
> > __builtin_constant_p (a) ?: 0;
> > if (a == 8)
> > while (1)
> > ;
> > }
> >
> > I guess we are not allowed to cancel this transformation, becase we
> > really need LCSSA for later passes? This now contradicts the
> > "prohibit
> > all updates" idea..
>
> Yes. I believe this looks at the issue from a wrong angle. SSA
> rewrite
> is just renaming and that's OK.
>
> > If you think that disabling threading is reasonable, could you
> > please
> > have another look at th
Re: DejaGnu diagnostics checking confused, possibly related to 'dg-line'?
Hi!
I've investigated some more.
On 2020-11-03T13:31:53+0100, I wrote:
> Help. Save the attached file as 'gcc/testsuite/c-c++-common/goacc/l_.c',
> and then run:
>
> $ make check-gcc-c++ RUNTESTFLAGS=--all\ goacc.exp=l_.c
>
> As expected for '-std=c++98' testing, which comes first:
>
> PASS: c-c++-common/goacc/l_.c -std=c++98 (test for errors, line 14)
> PASS: c-c++-common/goacc/l_.c -std=c++98 (test for warnings, line 11)
> PASS: c-c++-common/goacc/l_.c -std=c++98 (test for excess errors)
> WARNING: dg-line var l1 defined, but not used
> WARNING: dg-line var l2 defined, but not used
> WARNING: dg-line var l3 defined, but not used
>
> But then it goes on with '-std=c++14', etc. testing:
>
> UNRESOLVED: c-c++-common/goacc/l_.c -std=c++14 (test for errors, line
> 14)
> PASS: c-c++-common/goacc/l_.c -std=c++14 (test for warnings, line 11)
> PASS: c-c++-common/goacc/l_.c -std=c++14 (test for excess errors)
> WARNING: dg-line var l1 defined, but not used
> WARNING: dg-line var l2 defined, but not used
> WARNING: dg-line var l3 defined, but not used
> UNRESOLVED: c-c++-common/goacc/l_.c -std=c++17 (test for errors, line
> 14)
> PASS: c-c++-common/goacc/l_.c -std=c++17 (test for warnings, line 11)
> PASS: c-c++-common/goacc/l_.c -std=c++17 (test for excess errors)
> WARNING: dg-line var l1 defined, but not used
> WARNING: dg-line var l2 defined, but not used
> WARNING: dg-line var l3 defined, but not used
> UNRESOLVED: c-c++-common/goacc/l_.c -std=c++2a (test for errors, line
> 14)
> PASS: c-c++-common/goacc/l_.c -std=c++2a (test for warnings, line 11)
> PASS: c-c++-common/goacc/l_.c -std=c++2a (test for excess errors)
> WARNING: dg-line var l1 defined, but not used
> WARNING: dg-line var l2 defined, but not used
> WARNING: dg-line var l3 defined, but not used
>
> === g++ Summary ===
>
> # of expected passes9
> # of unresolved testcases 3
>
> Why is suddenly the "test for errors, line 14" an UNRESOLVED? (The
> compiler diagnostics are as expected. This testcase doesn't depend on
> '-std=[...]' at all.)
>
> And now the "funny" thing: if I disable any of the 'dg-line' directives,
> it works as expected, all-PASS. But note that "test for errors, line 14"
> doesn't even use a 'dg-line'-captured line number. (It uses absoute line
> numbers. Same issue visible when using relative ones, or when actually
> using 'dg-line' for these.)
>
>
> I reduced this from a much bigger testcase, and had originally found this
> not with 'check-gcc-c++' but with 'check-gcc-c': things worked fine as
> long as testing just a single testcase, but broke when testing several.
> (Again the symptom was that the first testcase worked fine, but the
> following ones had an unexpecte UNRESOLVED for the first 'dg-error' (only
> for the first!).) Supposedly, 'check-gcc-c++' with a single testcase but
> testing several variants is exhibiting the same problem.
The problem is indeed related to the "WARNING: dg-line var [...] defined,
but not used" diagnostics. These are produced via DejaGnu 'warning'
calls, which increments 'warncnt', and once that reaches
'warning_threshold' (default per '/usr/share/dejagnu/framework.exp' is:
'set warning_threshold 3'), this triggers UNRESOLVED via
'/usr/share/dejagnu/framework.exp:record_test'. That this UNRESOLVED
appears for the *next* testcase, must be considered some kind of bug
(improper use of 'warning'?), I suppose.
The following works around that:
--- gcc/testsuite/lib/gcc-dg.exp
+++ gcc/testsuite/lib/gcc-dg.exp
@@ -1008,6 +1008,8 @@ if { [info procs saved-dg-test] == [list] } {
} else {
regsub {^saved_linenr_} $varname "" org_varname
warning "dg-line var $org_varname defined, but not used"
+ global warncnt
+ incr warncnt -1
}
}
unset save_linenr_varnames
..., or:
--- gcc/testsuite/lib/gcc-dg.exp
+++ gcc/testsuite/lib/gcc-dg.exp
@@ -1007,7 +1007,7 @@ if { [info procs saved-dg-test] == [list] } {
eval unset $varname_used
} else {
regsub {^saved_linenr_} $varname "" org_varname
- warning "dg-line var $org_varname defined, but not used"
+ verbose "WARNING: dg-line var $org_varname defined, but not
used" 0
}
}
unset save_linenr_varnames
..., or hopefully something less hacky.
The question is, what quality/severity should the "dg-line var [...]
defined, but not used" diagnostic have?
For example, "FAIL":
--- gcc/testsuite/lib/gcc-dg.exp
+++ gcc/testsuite/lib/gcc-dg.exp
@@ -1007,7 +1007,7 @@ if { [info procs saved-dg-test] == [list] } {
eval unset $varname_used
} else {
regsub
Re: Dead Field Elimination and Field Reordering
On Fri, Oct 30, 2020 at 6:44 PM Erick Ochoa
wrote:
>
> Hello again,
>
> I've been working on several implementations of data layout
> optimizations for GCC, and I am again kindly requesting for a review of
> the type escape based dead field elimination and field reorg.
>
> Thanks to everyone that has helped me. The main differences between the
> previous commits have been fixing the style, adding comments explaining
> classes and families of functions, exit gracefully if we handle unknown
> gimple syntax, and added a heuristic to handle void* casts.
>
> This patchset is organized in the following way:
>
> * Adds a link-time warning if dead fields are detected
> * Allows for the dead-field elimination transformation to be applied
> * Reorganizes fields in structures.
> * Adds some documentation
> * Gracefully does not apply transformation if unknown syntax is detected.
> * Adds a heuristic to handle void* casts
>
> I have tested this transformations as extensively as I can. The way to
> trigger these transformations are:
>
> -fipa-field-reorder and -fipa-type-escape-analysis
>
> Having said that, I welcome all criticisms and will try to address those
> criticisms which I can. Please let me know if you have any questions or
> comments, I will try to answer in a timely manner.
>
> The code is in:
>
>refs/vendors/ARM/heads/arm-struct-reorg-wip
>
> Future work includes extending the current heuristic with ipa-modref
> extending the analysis to use IPA-PTA as discussed previously.
>
> Few notes:
>
> * Currently it is not safe to use -fipa-sra.
> * I added some tests which are now failing by default. This is because
> there is no way to safely determine within the test case that a layout
> has been transformed. I used to determine that a field was eliminated
> doing pointer arithmetic on the fields. And since that is not safe, the
> analysis decides not to apply the transformation. There is a way to deal
> with this (add a flag to allow the address of a field to be taken) but I
> wanted to hear other possibilities to see if there is a better option.
> * At this point we’d like to thank the again GCC community for their
> patient help so far on the mailing list and in other channels. And we
> ask for your support in terms of feedback, comments and testing.
I've only had a brief look at the branch - if you want to even have a
remote chance of making this stage1 you should break the branch
up into a proper patch series and post it with appropriate ChangeLogs
and descriptions.
First, standard includes may _not_ be included after including system.h,
in fact, they _need_ to be included from system.h - that includes
things like or . There are "convenient" defines you
can use like
#define INCLUDE_SET
#include "system.h"
and system.h will do what you want. Not to say that you should
use GCCs containers and not the standard library ones.
You expose way too many user-visible command-line options.
All the stmt / tree walking "meta" code should be avoided - it
would need to be touched each time we change GIMPLE or
GENERIC. Instead use available walkers if you really need
it in such DFS-ish way.
That "IPA SRA is not safe" is of course not an option but hints
at a shortcoming in your safety analysis.
In DFE in handle_pointer_arithmetic_constants you
look at the type of an operand - that's not safe since
this type doesn't carry any semantics.
The DFE code is really hard to follow since it diverges
from GCC style which would do sth like the following
to iterate over all stmt [operands]:
FOR_EACH_BB_FN (fun, bb)
{
for (auto gsi = gsi_start_phis (bb); !gsi_end_p (gsi); gsi_next (&gsi))
walk PHIs
for (auto gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
walk stmts, for example via walk_gimple_stmt ()
}
and I'd expect a single visitor with a switch () over the gimple/operation
kind rather than gazillion overloads I have no idea what they exactly
visit and how.
In a later change on the branch I see sth like ABORT_IF_NOT_C
where I'm not sure what this is after - you certainly can handle
IL constructs you do not handle conservatively (REFERENCE_TYPE
is the same as POINTER_TYPE - they are exchangable for the
middle-end, METHOD_TYPE is the same as FUNCTION_TYPE,
a QUAL_UNION_TYPE is not semantically different from
a UNION_TYPE for the middle-end it only differs in layout handing.
I see you only want to replace the void * "coloring" with modref
so you'll keep using "IPA type escape analysis". I don't think
that's good to go.
Richard.
Re: Dead Field Elimination and Field Reordering
Thanks for the review Richard I'll address what I can. I also provide maybe some hindsight into some of the design decisions here. I'm not trying to be defensive just hoping to illuminate why some decisions were made and how some criticisms may fail to really address the reason why these designs were made. On 03/11/2020 15:58, Richard Biener wrote: On Fri, Oct 30, 2020 at 6:44 PM Erick Ochoa wrote: Hello again, I've been working on several implementations of data layout optimizations for GCC, and I am again kindly requesting for a review of the type escape based dead field elimination and field reorg. Thanks to everyone that has helped me. The main differences between the previous commits have been fixing the style, adding comments explaining classes and families of functions, exit gracefully if we handle unknown gimple syntax, and added a heuristic to handle void* casts. This patchset is organized in the following way: * Adds a link-time warning if dead fields are detected * Allows for the dead-field elimination transformation to be applied * Reorganizes fields in structures. * Adds some documentation * Gracefully does not apply transformation if unknown syntax is detected. * Adds a heuristic to handle void* casts I have tested this transformations as extensively as I can. The way to trigger these transformations are: -fipa-field-reorder and -fipa-type-escape-analysis Having said that, I welcome all criticisms and will try to address those criticisms which I can. Please let me know if you have any questions or comments, I will try to answer in a timely manner. The code is in: refs/vendors/ARM/heads/arm-struct-reorg-wip Future work includes extending the current heuristic with ipa-modref extending the analysis to use IPA-PTA as discussed previously. Few notes: * Currently it is not safe to use -fipa-sra. * I added some tests which are now failing by default. This is because there is no way to safely determine within the test case that a layout has been transformed. I used to determine that a field was eliminated doing pointer arithmetic on the fields. And since that is not safe, the analysis decides not to apply the transformation. There is a way to deal with this (add a flag to allow the address of a field to be taken) but I wanted to hear other possibilities to see if there is a better option. * At this point we’d like to thank the again GCC community for their patient help so far on the mailing list and in other channels. And we ask for your support in terms of feedback, comments and testing. I've only had a brief look at the branch - if you want to even have a remote chance of making this stage1 you should break the branch up into a proper patch series and post it with appropriate ChangeLogs and descriptions. First, standard includes may _not_ be included after including system.h, in fact, they _need_ to be included from system.h - that includes things like or . There are "convenient" defines you can use like #define INCLUDE_SET #include "system.h" and system.h will do what you want. Not to say that you should use GCCs containers and not the standard library ones. Thanks I didn't know this! You expose way too many user-visible command-line options. Yes, I can certainly remove some debugging flags. All the stmt / tree walking "meta" code should be avoided - it would need to be touched each time we change GIMPLE or GENERIC. Instead use available walkers if you really need it in such DFS-ish way. There are two points being made here: 1. Use the available walkers 2. Changing gimple would imply changes to your code First: I did tried using the available walkers in the past, and the walk_tree function does not contain a post-order callback. We really need to propagate information from the gimple leaf nodes back to the root, and as a way to achieve this (and probably other things like maintaining a stack of the nodes visited to reach the current node) we really need a post-order callback. We did have a conversation about this where you pointed out this pattern: *walk_subtrees = 0; walk_tree (.. interesting subexpressions ... ); do post-order work In the preorder hook, but this only works with simple expressions and we need more complicated machinery. Furthermore, I did look into extending the current walk_tree function with post-order callbacks but due to implementation details in the function (tail-recursion), we both agreed that having both tail-recursion AND a post-order hook was impossible. Second: I would expect any transformation that performs an analysis in an IR be needing to at least be re-reviewed somehow when the IR is re-written. I also don't think extending the base visitor classes would be too difficult. That "IPA SRA is not safe" is of course not an option but hints at a shortcoming in your safety analysis. I looked into how to make this transformation safe with IPA-SRA in the past. I don't think it is really that bi
git tag creation for misc/first-auto-changelog
Hello. I would like to create a git tag for a point when we started using automatically-generated ChangeLog files. It's: cfdff3eeb902958d3eefe60d5712d64e2367843f and I would name it something like: misc/first-auto-changelog ? Thanks, Martin
Re: gcc/DATESTAMP not updated any longer
On Mon, 2 Nov 2020, Jakub Jelinek via Gcc wrote: > It isn't that easy (because update_version_git checks the gcc trunk and > so I had to insert a sh invocation in which I've tweaked it), but it worked, > thanks. But something is really wrong with the hooks, as the gcc-cvs mail > for the trunk daily bump wasn't sent again (r10, r9 and r8 changes did). I think any issue with an email not sent to gcc-cvs should be raised with overseers or postmaster; they'll need to check logs at the exact time to see if the email was ever submitted by the hooks to the MTA (and at least part of the mail sending from the hooks is I think asynchronous so any issues might not be reported back to the git commit command). If it was submitted to the MTA, the problem is with the MTA or mailman. If it was not submitted to the MTA, Joel might be able to advise on how to instrument the process of email sending from the hooks to see where it went wrong. -- Joseph S. Myers jos...@codesourcery.com
Re: git tag creation for misc/first-auto-changelog
On Tue, 3 Nov 2020 at 17:40, Martin Liška wrote: > > Hello. > > I would like to create a git tag for a point when we started > using automatically-generated ChangeLog files. It's: > > cfdff3eeb902958d3eefe60d5712d64e2367843f > > and I would name it something like: > misc/first-auto-changelog > > ? Seems like a good idea. Are you asking how to do that? git tag misc/first-auto-changelog cfdff3eeb902958d3eefe60d5712d64e2367843f git push origin tag misc/first-auto-changelog
