[PATCH] Reset prologue_location before calling code_end [PR 100467]

[Bernd Edlinger]

Hi,

this fixes a fallout from my previous patch to improve
debug info of virtual thunks.

Tested on x86_64-pc-linux-gnu with --target_board=unix/-m32
Is it OK for trunk?


Thanks
Bernd.
From 7bea6a83f4daf97ac1cfeb6c2e10fb7ae742340f Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Sat, 8 May 2021 07:46:17 +0200
Subject: [PATCH] Reset prologue_location before calling code_end

Some targets emit thunks from the targetm.asm_out.code_end
function and set the DECL_IGNORED_P, but due to
e69ac020372 ("Add line debug info for virtual thunks")
the value in prologue_location is no longer ignored.

So reset that value before calling the backend.

2021-05-08  Bernd Edlinger  

	PR middle-end/100467
	* toplev.c (compile_file): Call insn_locations_init before
	targetm.asm_out.code_end.
---
 gcc/toplev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/toplev.c b/gcc/toplev.c
index d8cc254..7e23253 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -523,6 +523,7 @@ compile_file (void)
 
   /* This must be at the end before unwind and debug info.
 	 Some target ports emit PIC setup thunks here.  */
+  insn_locations_init ();
   targetm.asm_out.code_end ();
 
   /* Do dbx symbols.  */
-- 
1.9.1

Re: [GOVERNANCE] Where to file complaints re project-maintainers?

[Ian Lance Taylor via Gcc-patches]

On Sun, May 9, 2021 at 8:33 AM abebeos  wrote:
>
> To me this sounds quite like an "disorganized mess, where bullies, abusers 
> and even IT-fascists can thrive".
>
> It is clear to me that some gcc project maintainers, the steering committee 
> and bountysource are crossing ethical (if not legal) boundaries.

The GCC project maintainers and the steering committee are definitely
not crossing ethical or legal boundaries here.

I don't know anything about Bountysource.  Bountysource is completely
separate from GCC.  It appears from your link that John Paul Adrian
Glaubitz posted a bounty for some GCC work.  A number of people and
organizations supported the bounty, but the GCC project itself did
not.  Although the work is for GCC, the GCC project has nothing to do
with that bounty.  That is handled entirely by Bountysource.


> The Issue:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
>
> The Bounty (a bit higher than $7K)
>
> https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
>
> The Complaint re Voting Process:
>
> https://github.com/bountysource/core/issues/1532
>
> Bountysource may write whatever they want in their terms-of-service - the 
> relevant law is still above. And of course OSS-ethics, which are more that a 
> basic code-monkey-mentality of the kind "only code is work, only patch 
> authors are workers".
>
> * there is a bounty
> * I start work (working around a major gcc project deficit, which is a 
> missing CI, testing testing testing, concluding, "reviving" and existent 
> patch)
> * I claim 50%
> * a dispute starts, which is then aborted non-transparently by some anonymous 
> coward, without waiting for the major backers votes,  and all gcc 
> participants simply keep silence.
>
> I am aware that the effort to fight for 50% of a $7K bounty is not worth it - 
> even the distraction for opening a discussion here is essentially not worth 
> the effort.
>
> I cared more or less only on what Microchip ($5K contibution to the bounty) 
> had to say, and the other two top backers. And I'm still curious about this.
>
> If they too say "research, analysis and integration work is no work" and 
> "effort to validate abandoned patches and reuse of them is no work" - well, 
> then I guess I'll rest my case.
>
> But at least it gets "on file", so other people which struggle with gcc 
> (especially in combination with bountysource) have a point-of-reference.
>
> Very disappointing all this.
>
> I mean really? An OSS project which brute-force aborts a voting-procedure 
> (=IT-fascism)? Just to award a monetary value to an gcc-project insider?
>
> And everyone keeps silence?

If I'm reading the Bountysource page correctly, the bounty was awarded
to saaadhu, who I assume is Senthil Kumar Selvaraj.  Senthil has been
a GCC contributor for a while with some 70 committed patches.  But I
wouldn't describe them as a GCC project insider.  They are not a GCC
maintainer or reviewer.



> We all know that reproducing such things in order to have an informed 
> opinion/vote costs terribly high amounts of time. The simplified method would 
> be:
>
> * enter the issues here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c9
> * then, just try to validate the until then available patch
>   * => you'll fail, as no stable environment is available (major failure of 
> the steering comitee, which should insist "all targets need to have an 
> functioning CI"
> * => here you start integrating a dev/ci environment, try to find reference 
> points/versions etc., etc.
>
> @ Steering Committee
>
> A functioning CI across targets is a non-disputable must requirement in 
> todays IT landscape:
>
> * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98574
>
> Or at least reference-repos, like e.g. this one:
>
> * https://github.com/abebeos/avr-gnu
>
> We would not have this topic here, if the gcc-project had a decent CI, or a 
> build-setup used by all developers.

I agree that having a good CI for GCC would be really great.  It's
also really hard.  GCC generates code for many different targets, and
the nature of GCC is such that running tests on a simulator rather
than real hardware, while helpful, is simply not good enough in
practice.  So a good CI for GCC requires supporting a large variety of
hardware.  That is very desirable.  It's also very hard and very
expensive.  The GCC project must rely on volunteers for this work.
You can see the available support at
https://gcc.gnu.org/wiki/CompileFarm and on the gcc-testresults
mailing list.  Should the project have better CI?  Yes, absolutely.
Who is going to put in the time, effort, and money to make that
happen?


In any case, this is not the right place to raise your concerns about
Bountysource.  That is not part of the GCC project.

Ian

[PATCH] c++: dependent operator expression lookup [PR51577]

[Patrick Palka via Gcc-patches]

This unconditionally enables the maybe_save_operator_binding mechanism
for all function templates, so that when resolving a dependent operator
expression from a function template we ignore later-declared
namespace-scope bindings that weren't visible at template definition
time.  This patch additionally makes the mechanism apply to dependent
comma and compound-assignment operator expressions.

Note that this doesn't fix the testcases in PR83035 or PR99692 because
there the dependent operator expressions aren't at function scope.  I'm
not sure how exactly to fix these testcases using the current approach,
since although we'll in both testcases have a TEMPLATE_DECL to associate
the lookup result with, at instantiation time we won't have an
appropriate binding level to push to.  I wonder we could instead encode
dependent operator expressions as appropriately-flagged CALL_EXPRs?

Bootstrapped and regtested on x86_64-pc-linux-gnu, and tested on cmcstl2
and range-v3 and numerous boost libraries, does this look OK for trunk?

gcc/cp/ChangeLog:

PR c++/51577
* name-lookup.c (maybe_save_operator_binding): Unconditionally
enable for all function templates, not just generic lambdas.
* typeck.c (build_x_compound_expr): Call maybe_save_operator_binding
in the type-dependent case.
(build_x_modify_expr): Likewise.  Move declaration of 'op'
closer to its first use.

gcc/testsuite/ChangeLog:

PR c++/51577
* g++.dg/lookup/operator-3.C: New test.
---
 gcc/cp/name-lookup.c |  15 ++--
 gcc/cp/typeck.c  |  17 ++--
 gcc/testsuite/g++.dg/lookup/operator-3.C | 109 +++
 3 files changed, 128 insertions(+), 13 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/lookup/operator-3.C

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 4e84e2f9987..a6c9e68a19e 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -9116,7 +9116,7 @@ static const char *const op_bind_attrname = "operator 
bindings";
 void
 maybe_save_operator_binding (tree e)
 {
-  /* This is only useful in a generic lambda.  */
+  /* This is only useful in a template.  */
   if (!processing_template_decl)
 return;
 
@@ -9124,13 +9124,12 @@ maybe_save_operator_binding (tree e)
   if (!cfn)
 return;
 
-  /* Do this for lambdas and code that will emit a CMI.  In a module's
- GMF we don't yet know whether there will be a CMI.  */
-  if (!module_has_cmi_p () && !global_purview_p () && !current_lambda_expr())
- return;
-
-  tree fnname = ovl_op_identifier (false, TREE_CODE (e));
-  if (!fnname)
+  tree fnname;
+  if(TREE_CODE (e) == MODOP_EXPR)
+fnname = ovl_op_identifier (true, TREE_CODE (TREE_OPERAND (e, 1)));
+  else
+fnname = ovl_op_identifier (false, TREE_CODE (e));
+  if (!fnname || fnname == assign_op_identifier)
 return;
 
   tree attributes = DECL_ATTRIBUTES (cfn);
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 50d0f1e6a62..6826fcf139c 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -7272,7 +7272,11 @@ build_x_compound_expr (location_t loc, tree op1, tree 
op2,
 {
   if (type_dependent_expression_p (op1)
  || type_dependent_expression_p (op2))
-   return build_min_nt_loc (loc, COMPOUND_EXPR, op1, op2);
+   {
+ result = build_min_nt_loc (loc, COMPOUND_EXPR, op1, op2);
+ maybe_save_operator_binding (result);
+ return result;
+   }
   op1 = build_non_dependent_expr (op1);
   op2 = build_non_dependent_expr (op2);
 }
@@ -8936,7 +8940,6 @@ build_x_modify_expr (location_t loc, tree lhs, enum 
tree_code modifycode,
   tree orig_lhs = lhs;
   tree orig_rhs = rhs;
   tree overload = NULL_TREE;
-  tree op = build_nt (modifycode, NULL_TREE, NULL_TREE);
 
   if (lhs == error_mark_node || rhs == error_mark_node)
 return cp_expr (error_mark_node, loc);
@@ -8946,9 +8949,12 @@ build_x_modify_expr (location_t loc, tree lhs, enum 
tree_code modifycode,
   if (modifycode == NOP_EXPR
  || type_dependent_expression_p (lhs)
  || type_dependent_expression_p (rhs))
-return build_min_nt_loc (loc, MODOP_EXPR, lhs,
-build_min_nt_loc (loc, modifycode, NULL_TREE,
-  NULL_TREE), rhs);
+   {
+ tree op = build_min_nt_loc (loc, modifycode, NULL_TREE, NULL_TREE);
+ tree rval = build_min_nt_loc (loc, MODOP_EXPR, lhs, op, rhs);
+ maybe_save_operator_binding (rval);
+ return rval;
+   }
 
   lhs = build_non_dependent_expr (lhs);
   rhs = build_non_dependent_expr (rhs);
@@ -8956,6 +8962,7 @@ build_x_modify_expr (location_t loc, tree lhs, enum 
tree_code modifycode,
 
   if (modifycode != NOP_EXPR)
 {
+  tree op = build_nt (modifycode, NULL_TREE, NULL_TREE);
   tree rval = build_new_op (loc, MODIFY_EXPR, LOOKUP_NORMAL,
lhs, rhs, op, , complain);
 

Re: [GOVERNANCE] Where to file complaints re project-maintainers?

[Eric Botcazou]

> It is a gcc issue, see the very first link you've quoted (
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729).

IIUC you're complaining about the bounty process, not about the GCC PR, so 
this technical list is not the appropriate place to do it.  AFAICS you have 
already filed a complaint with Bountysource, so it's up to them to decide 
whether to accept or reject it.

-- 
Eric Botcazo

Re: [GOVERNANCE] Where to file complaints re project-maintainers?

[abebeos via Gcc-patches]

On Sun, 9 May 2021 at 20:32, Koning, Paul  wrote:

>
>
> > On May 9, 2021, at 11:33 AM, abebeos via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
> >
> > Thank you for your quick response.
> >
> > ...
> > The Issue:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
> >
> > The Bounty (a bit higher than $7K)
> >
> >
> https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
> >
> > The Complaint re Voting Process:
> >
> > https://github.com/bountysource/core/issues/1532
>
> I don't understand why you're coming to the GCC lists to debate this.  The
> issue you're talking about isn't a GCC issue at all.

[...]

It is a gcc issue, see the very first link you've quoted (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729).

Re: [r12-397 Regression] Failed to bootstrap on Linux/x86_64

[Alexandre Oliva via Gcc-patches]

On May  9, 2021, "sunil.k.pandey"  wrote:

> On Linux/x86_64,
> da9e6e63d1ae22e530ec7baf59f6ed028bf05776 is the first bad commit

Thanks, this fallout from a commit race was fixed in
commit 5fbe6a8e73b52c6ebc28b9111456226c1cda6472
Author: Prathamesh Kulkarni 
Date:   Tue May 4 11:11:18 2021 +0530

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [GOVERNANCE] Where to file complaints re project-maintainers?

[Koning, Paul via Gcc-patches]

> On May 9, 2021, at 11:33 AM, abebeos via Gcc-patches 
>  wrote:
> 
> Thank you for your quick response.
> 
> ...
> The Issue:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
> 
> The Bounty (a bit higher than $7K)
> 
> https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
> 
> The Complaint re Voting Process:
> 
> https://github.com/bountysource/core/issues/1532

I don't understand why you're coming to the GCC lists to debate this.  The 
issue you're talking about isn't a GCC issue at all.  You need to take it up 
with the group with which you have the dispute.

paul

Re: [PATCH] abstract the on entry cache.

[Aldy Hernandez via Gcc-patches]

 }
 
-// Return a reference to the ssa_block_cache for NAME.  If it has not been

-// accessed yet, allocate it first.
+// Set the range for NAME on entry to block BB to R.
+// If it has not been // accessed yet, allocate it first.
 


There's a spurious // in there.


+// Provide a hunk of memory from the obstack
+inline void *
+irange_allocator::get_memory (unsigned num_bytes)
+


Missing final period.

Aldy

[r12-438 Regression] FAIL: g++.dg/gomp/clause-3.C -std=c++98 (test for errors, line 59) on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

1580fc764423bf89e9b853aaa8c65999e37ccb8b is the first bad commit
commit 1580fc764423bf89e9b853aaa8c65999e37ccb8b
Author: Tobias Burnus 
Date:   Tue May 4 13:38:03 2021 +0200

OpenMP: Support complex/float in && and || reduction

caused

FAIL: g++.dg/gomp/clause-3.C  -std=c++14  (test for errors, line 59)
FAIL: g++.dg/gomp/clause-3.C  -std=c++17  (test for errors, line 59)
FAIL: g++.dg/gomp/clause-3.C  -std=c++2a  (test for errors, line 59)
FAIL: g++.dg/gomp/clause-3.C  -std=c++98  (test for errors, line 59)

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-438/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=g++.dg/gomp/clause-3.C --target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=g++.dg/gomp/clause-3.C --target_board='unix{-m32\ 
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=g++.dg/gomp/clause-3.C --target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=g++.dg/gomp/clause-3.C --target_board='unix{-m64\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r12-514 Regression] FAIL: gcc.target/i386/pr98218-2a.c (test for excess errors) on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

f3661f2d63fbc5fd30c24d22137691e16b0a0a17 is the first bad commit
commit f3661f2d63fbc5fd30c24d22137691e16b0a0a17
Author: Uros Bizjak 
Date:   Wed May 5 15:07:25 2021 +0200

i386: Implement integer vector compares for 64bit vectors [PR98218]

caused

FAIL: gcc.dg/pr97238.c (internal compiler error)
FAIL: gcc.dg/pr97238.c (test for excess errors)
FAIL: gcc.dg/vect/bb-slp-49.c -flto -ffat-lto-objects (internal compiler error)
FAIL: gcc.dg/vect/bb-slp-49.c -flto -ffat-lto-objects (test for excess errors)
FAIL: gcc.dg/vect/bb-slp-49.c (internal compiler error)
FAIL: gcc.dg/vect/bb-slp-49.c (test for excess errors)
FAIL: gcc.target/i386/pr96827.c (internal compiler error)
FAIL: gcc.target/i386/pr96827.c (test for excess errors)
FAIL: gcc.target/i386/pr98218-1a.c (internal compiler error)
FAIL: gcc.target/i386/pr98218-1a.c (test for excess errors)
FAIL: gcc.target/i386/pr98218-2a.c (internal compiler error)
FAIL: gcc.target/i386/pr98218-2a.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-514/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr97238.c 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/bb-slp-49.c --target_board='unix{-m64\ 
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr96827.c --target_board='unix{-m64\ 
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr98218-1a.c --target_board='unix{-m64\ 
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr98218-2a.c --target_board='unix{-m64\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r12-574 Regression] FAIL: g++.dg/debug/dwarf2/thunk1.C -std=gnu++98 scan-assembler-times LFB3 5 on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

e69ac0203725fb8da83a1cc88d32191b7a0b2c0c is the first bad commit
commit e69ac0203725fb8da83a1cc88d32191b7a0b2c0c
Author: Bernd Edlinger 
Date:   Tue Jan 12 16:27:53 2021 +0100

Add line debug info for virtual thunks

caused

FAIL: g++.dg/debug/dwarf2/thunk1.C  -std=gnu++14  scan-assembler-times LFB3 5
FAIL: g++.dg/debug/dwarf2/thunk1.C  -std=gnu++17  scan-assembler-times LFB3 5
FAIL: g++.dg/debug/dwarf2/thunk1.C  -std=gnu++2a  scan-assembler-times LFB3 5
FAIL: g++.dg/debug/dwarf2/thunk1.C  -std=gnu++98  scan-assembler-times LFB3 5

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-574/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dwarf2.exp=g++.dg/debug/dwarf2/thunk1.C 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dwarf2.exp=g++.dg/debug/dwarf2/thunk1.C 
--target_board='unix{-m32\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

Re: [GOVERNANCE] Where to file complaints re project-maintainers?

[abebeos via Gcc-patches]

Thank you for your quick response.

To me this sounds quite like an "disorganized mess, where bullies, abusers
and even IT-fascists can thrive".

It is clear to me that some gcc project maintainers, the steering committee
and bountysource are crossing ethical (if not legal) boundaries.

The Issue:

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

The Bounty (a bit higher than $7K)

https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases

The Complaint re Voting Process:

https://github.com/bountysource/core/issues/1532

Bountysource may write whatever they want in their terms-of-service - the
relevant law is still above. And of course OSS-ethics, which are more that
a basic code-monkey-mentality of the kind "only code is work, only patch
authors are workers".

* there is a bounty
* I start work (working around a major gcc project deficit, which is a
missing CI, testing testing testing, concluding, "reviving" and existent
patch)
* I claim 50%
* a dispute starts, which is then aborted non-transparently by some
anonymous coward, without waiting for the major backers votes,  and all gcc
participants simply keep silence.

I am aware that the effort to fight for 50% of a $7K bounty is not worth it
- even the distraction for opening a discussion here is essentially not
worth the effort.

I cared more or less only on what Microchip ($5K contibution to the bounty)
had to say, and the other two top backers. And I'm still curious about this.

If they too say "research, analysis and integration work is no work" and
"effort to validate abandoned patches and reuse of them is no work" - well,
then I guess I'll rest my case.

But at least it gets "on file", so other people which struggle with gcc
(especially in combination with bountysource) have a point-of-reference.

Very disappointing all this.

I mean really? An OSS project which brute-force aborts a voting-procedure
(=IT-fascism)? Just to award a monetary value to an gcc-project insider?

And everyone keeps silence?

Shame on you people.

P.S.:

We all know that reproducing such things in order to have an informed
opinion/vote costs terribly high amounts of time. The simplified method
would be:

* enter the issues here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c9
* then, just try to validate the until then available patch
  * => you'll fail, as no stable environment is available (major failure of
the steering comitee, which should insist "all targets need to have an
functioning CI"
* => here you start integrating a dev/ci environment, try to find reference
points/versions etc., etc.

@ Steering Committee

A functioning CI across targets is a non-disputable must requirement in
todays IT landscape:

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

Or at least reference-repos, like e.g. this one:

* https://github.com/abebeos/avr-gnu

We would not have this topic here, if the gcc-project had a decent CI, or a
build-setup used by all developers.



On Sun, 9 May 2021 at 05:06, Ian Lance Taylor  wrote:

> On Sat, May 8, 2021 at 8:49 AM abebeos via Gcc-patches
>  wrote:
> >
> > Is there any private email where one can file complaints re
> > project-maintainers (or "those who are supervising the maintainers") ?
> >
> > Is there any information about the process for such complaints?
> >
> > Related Issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480
> >
> > (please note that this complaint will most possibly escalate up to the
> > person(s) who are responsible for policies/rules)
>
> The GCC project does not have a code of conduct, and it does not have
> a managing hierarchy.  Nobody supervises the maintainers.  GCC has a
> minimum of non-technical policies/rules, and it has no enforcement
> mechanism.  There really isn't any place to file a complaint.  You can
> complain to the GCC steering committee if you like
> (https://gcc.gnu.org/steering.html; I am a member), but there are a
> very limited number of actions that the steering committee could take,
> and it is very unlikely that the committee would actually do anything.
>
> Basically, GCC is a cooperative project.  It's not a company.  People
> don't work for GCC.
>
> I'm sorry you are having trouble, but I don't think there is much that
> the GCC project can do to help.
>
> Ian
>

Re: [PATCH][_GLIBCXX_DEBUG] libbacktrace integration

[François Dumont via Gcc-patches]

On 07/05/21 4:26 pm, Jonathan Wakely wrote:

On 05/05/21 12:33 +0100, Jonathan Wakely wrote:

On 24/04/21 15:46 +0200, François Dumont via Libstdc++ wrote:

Hi

    Here is the patch to add backtrace generation on _GLIBCXX_DEBUG 
assertions thanks to libbacktrace.


Ville pointed out that we'll need to use libbacktrace for
std::stacktrace  anyway, and it would be
useful if/when we add support for C++ Contracts to the lirbary.

So let's integrate libbacktrace into libstdc++ properly. Jakub
suggested doing it how libsanitizer does it, which is to rebuild the
libbacktrace sources as part of the libsanitizer build, using the
preprocessor to rename the symbols so that they use reserved names.
e.g. rename backtrace_full to __glibcxx_backtrace_full or something
like that.

I'll work on getting it building as part of libstdc++ (or maybe as a
separate static library for now, as we do for libstdc++fs.a) and then
you can rework your Debug Mode patch to depend on the private version
of libbacktrace included with libstdc++ (instead of expecting users to
provide it themselves).


Ok, thanks for the info.

I will perhaps extract the non-backtrace related stuff from this patch 
then and I'll rework the backtrace part later.

[r12-397 Regression] Failed to bootstrap on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

da9e6e63d1ae22e530ec7baf59f6ed028bf05776 is the first bad commit
commit da9e6e63d1ae22e530ec7baf59f6ed028bf05776
Author: Alexandre Oliva 
Date:   Mon May 3 22:48:47 2021 -0300

introduce try store by multiple pieces

caused build failure when configured with:

../gcc/configure  --enable-clocale=gnu --with-system-zlib --enable-shared 
--enable-cet --with-demangler-in-ld --enable-libmpx --with-fpmath=sse 

Build log(last 100 lines):

g++ -std=c++11  -fno-PIE -c   -g -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc 
-I../../../gcc/gcc/. -I../../../gcc/gcc/../include 
-I../../../gcc/gcc/../libcpp/include -I../../../gcc/gcc/../libcody  
-I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/bid 
-I../libdecnumber -I../../../gcc/gcc/../libbacktrace   -o df-core.o -MT 
df-core.o -MMD -MP -MF ./.deps/df-core.TPo ../../../gcc/gcc/df-core.c
g++ -std=c++11  -fno-PIE -c   -g -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc 
-I../../../gcc/gcc/. -I../../../gcc/gcc/../include 
-I../../../gcc/gcc/../libcpp/include -I../../../gcc/gcc/../libcody  
-I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/bid 
-I../libdecnumber -I../../../gcc/gcc/../libbacktrace   -o df-problems.o -MT 
df-problems.o -MMD -MP -MF ./.deps/df-problems.TPo 
../../../gcc/gcc/df-problems.c
g++ -std=c++11  -fno-PIE -c   -g -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc 
-I../../../gcc/gcc/. -I../../../gcc/gcc/../include 
-I../../../gcc/gcc/../libcpp/include -I../../../gcc/gcc/../libcody  
-I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/bid 
-I../libdecnumber -I../../../gcc/gcc/../libbacktrace   -o df-scan.o -MT 
df-scan.o -MMD -MP -MF ./.deps/df-scan.TPo ../../../gcc/gcc/df-scan.c
g++ -std=c++11  -fno-PIE -c   -g -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common -Wno-strict-aliasing -DHAVE_CONFIG_H -I. 
-I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include 
-I../../../gcc/gcc/../libcpp/include -I../../../gcc/gcc/../libcody  
-I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/bid 
-I../libdecnumber -I../../../gcc/gcc/../libbacktrace   -o dfp.o -MT dfp.o -MMD 
-MP -MF ./.deps/dfp.TPo ../../../gcc/gcc/dfp.c
g++ -std=c++11  -fno-PIE -c   -g -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc 
-I../../../gcc/gcc/. -I../../../gcc/gcc/../include 
-I../../../gcc/gcc/../libcpp/include -I../../../gcc/gcc/../libcody  
-I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/bid 
-I../libdecnumber -I../../../gcc/gcc/../libbacktrace   -o digraph.o -MT 
digraph.o -MMD -MP -MF ./.deps/digraph.TPo ../../../gcc/gcc/digraph.cc
g++ -std=c++11  -fno-PIE -c   -g -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc 
-I../../../gcc/gcc/. -I../../../gcc/gcc/../include 
-I../../../gcc/gcc/../libcpp/include -I../../../gcc/gcc/../libcody  
-I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/bid 
-I../libdecnumber -I../../../gcc/gcc/../libbacktrace   -o dojump.o -MT dojump.o 
-MMD -MP -MF ./.deps/dojump.TPo ../../../gcc/gcc/dojump.c
g++ -std=c++11  -fno-PIE -c   -g -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros