[Bug c++/100111] New: `-fno-elide-constructors` causes ICE in GCC 10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100111
Bug ID: 100111
Summary: `-fno-elide-constructors` causes ICE in GCC 10.3
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Created attachment 50610
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50610=edit
minimum testcase
```
lh_mouse@lhmouse-ideapad ~/Desktop $ cat ice.cc
// g++-10 -fno-elide-constructors ice.cc
struct b {};
struct j : b {
int e;
constexpr j(b k) : b(k), e() {}
};
struct g {
j h;
constexpr g() : h({}) {}
} a;
lh_mouse@lhmouse-ideapad ~/Desktop $ g++-10 -fno-elide-constructors ice.cc
ice.cc:11:3: in ‘constexpr’ expansion of ‘a.g::g()’
ice.cc:10:23: in ‘constexpr’ expansion of ‘((g*)this)->g::h.j::j((b(), b()))’
ice.cc:11:3: internal compiler error: in cxx_eval_store_expression, at
cp/constexpr.c:4939
11 | } a;
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
```
```
lh_mouse@lhmouse-ideapad ~/Desktop $ g++-10 -v
Using built-in specs.
COLLECT_GCC=g++-10
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
10.3.0-1ubuntu1~20.04~2' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-10-S8Osas/gcc-10-10.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-S8Osas/gcc-10-10.3.0/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1~20.04~2)
```
[Bug fortran/100110] New: Parameterized Derived Types, problems with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100110 Bug ID: 100110 Summary: Parameterized Derived Types, problems with global variable Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: xiao@compiler-dev.com Target Milestone: --- the test case is, program p implicit none type t(n) integer, len :: n integer :: arr(n, n) end type type(t(2)) :: obj print *, obj%n print *, shape(obj%arr) call test() contains subroutine test() print *, obj%n print *, shape(obj%arr) end subroutine end program expected result is 2 2 2 2 2 2 but is 0 0 0 0 0 0
[Bug c++/100079] [9/10/11 Regression] Non-type template parameter, itself a nested template, rejected with internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100079
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:89c863488bc8c7315596bcb753173aa2fd8be727
commit r11-8207-g89c863488bc8c7315596bcb753173aa2fd8be727
Author: Jason Merrill
Date: Wed Apr 14 17:27:19 2021 -0400
c++: C++20 class NTTP trailing zero-init [PR100079]
The new testcase was breaking because constexpr evaluation was simplifying
Bar{Baz<42>{}} to Bar{empty}, but then we weren't treating them as
equivalent. Poking at this revealed that the code for eliding trailing
zero-initialization in class non-type template argument mangling was pretty
broken, including the test, mangle71.
I dealt with the FIXME to support RANGE_EXPR, and fixed the confusion
between a list-initialized temporary mangled as written (i.e. in the
signature of a function template) and a template parameter object mangled
as
the value representation of the object. I'm distinguishing between these
using COMPOUND_LITERAL_P. A later patch will adjust the use of
COMPOUND_LITERAL_P to be more useful for this distinction, but it works now
for distinguishing these cases in mangling.
gcc/cp/ChangeLog:
PR c++/100079
* cp-tree.h (first_field): Declare.
* mangle.c (range_expr_nelts): New.
(write_expression): Improve class NTTP mangling.
* pt.c (get_template_parm_object): Clear TREE_HAS_CONSTRUCTOR.
* tree.c (zero_init_expr_p): Improve class NTTP handling.
* decl.c: Adjust comment.
gcc/testsuite/ChangeLog:
PR c++/100079
* g++.dg/abi/mangle71.C: Fix expected mangling.
* g++.dg/abi/mangle77.C: New test.
* g++.dg/cpp2a/nontype-class-union1.C: Likewise.
* g++.dg/cpp2a/nontype-class-equiv1.C: Removed.
* g++.dg/cpp2a/nontype-class44.C: New test.
[pushed] c++: C++20 class NTTP trailing zero-init [PR100079]
The new testcase was breaking because constexpr evaluation was simplifying
Bar{Baz<42>{}} to Bar{empty}, but then we weren't treating them as
equivalent. Poking at this revealed that the code for eliding trailing
zero-initialization in class non-type template argument mangling was pretty
broken, including the test, mangle71.
I dealt with the FIXME to support RANGE_EXPR, and fixed the confusion
between a list-initialized temporary mangled as written (i.e. in the
signature of a function template) and a template parameter object mangled as
the value representation of the object. I'm distinguishing between these
using COMPOUND_LITERAL_P. A later patch will adjust the use of
COMPOUND_LITERAL_P to be more useful for this distinction, but it works now
for distinguishing these cases in mangling.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/100079
* cp-tree.h (first_field): Declare.
* mangle.c (range_expr_nelts): New.
(write_expression): Improve class NTTP mangling.
* pt.c (get_template_parm_object): Clear TREE_HAS_CONSTRUCTOR.
* tree.c (zero_init_expr_p): Improve class NTTP handling.
* decl.c: Adjust comment.
gcc/testsuite/ChangeLog:
PR c++/100079
* g++.dg/abi/mangle71.C: Fix expected mangling.
* g++.dg/abi/mangle77.C: New test.
* g++.dg/cpp2a/nontype-class-union1.C: Likewise.
* g++.dg/cpp2a/nontype-class-equiv1.C: Removed.
* g++.dg/cpp2a/nontype-class44.C: New test.
---
gcc/cp/cp-tree.h | 1 +
gcc/cp/decl.c | 2 +-
gcc/cp/mangle.c | 40 ++-
gcc/cp/pt.c | 3 ++
gcc/cp/tree.c | 28 -
gcc/testsuite/g++.dg/abi/mangle71.C | 12 +++---
gcc/testsuite/g++.dg/abi/mangle77.C | 31 ++
.../g++.dg/cpp2a/nontype-class-equiv1.C | 25
.../g++.dg/cpp2a/nontype-class-union1.C | 2 +-
gcc/testsuite/g++.dg/cpp2a/nontype-class44.C | 25
10 files changed, 117 insertions(+), 52 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/abi/mangle77.C
delete mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-class-equiv1.C
create mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-class44.C
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index e42b82ae5a4..23a77a2b2e0 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6695,6 +6695,7 @@ extern void initialize_artificial_var (tree,
vec *);
extern tree check_var_type (tree, tree, location_t);
extern tree reshape_init(tree, tree, tsubst_flags_t);
extern tree next_initializable_field (tree);
+extern tree first_field(const_tree);
extern tree fndecl_declared_return_type(tree);
extern bool undeduced_auto_decl(tree);
extern bool require_deduced_type (tree, tsubst_flags_t =
tf_warning_or_error);
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 1cb47313923..d40b7a7da5f 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6152,7 +6152,7 @@ struct reshape_iter
static tree reshape_init_r (tree, reshape_iter *, tree, tsubst_flags_t);
-/* FIELD is a FIELD_DECL or NULL. In the former case, the value
+/* FIELD is an element of TYPE_FIELDS or NULL. In the former case, the value
returned is the next FIELD_DECL (possibly FIELD itself) that can be
initialized. If there are no more such fields, the return value
will be NULL. */
diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 4399165ee23..49f1266bef3 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -2940,6 +2940,16 @@ write_base_ref (tree expr, tree base = NULL_TREE)
return true;
}
+/* The number of elements spanned by a RANGE_EXPR. */
+
+unsigned HOST_WIDE_INT
+range_expr_nelts (tree expr)
+{
+ tree lo = TREE_OPERAND (expr, 0);
+ tree hi = TREE_OPERAND (expr, 1);
+ return tree_to_uhwi (hi) - tree_to_uhwi (lo) + 1;
+}
+
/* ::=
::=
::=
@@ -3284,8 +3294,14 @@ write_expression (tree expr)
write_type (etype);
}
- bool nontriv = !trivial_type_p (etype);
- if (nontriv || !zero_init_expr_p (expr))
+ /* If this is an undigested initializer, mangle it as written.
+COMPOUND_LITERAL_P doesn't actually distinguish between digested and
+undigested braced casts, but it should work to use it to distinguish
+between braced casts in a template signature (undigested) and template
+parm object values (digested), and all CONSTRUCTORS that get here
+should be one of those two cases. */
+ bool undigested = braced_init || COMPOUND_LITERAL_P (expr);
+ if (undigested || !zero_init_expr_p (expr))
{
/* Convert braced initializer lists to STRING_CSTs so that
Re: removing toxic emailers
Ian Lance Taylor : > Patronizing or infantilizing anybody doesn't come into this at all. I am not even *remotely* persuaded of this. This whole attitude that if a woman is ever exposed to a man with less than perfect American upper-middle-class manners it's a calamity requiring intervention and mass shunning, that *reeks* of infantilizing women. > We want free software to succeed. Free software is more likely to > succeed if more people work on it. If you are a volunteer, as many > are, you can choose to spend your time on the project where you have > to short-stop unwelcome advances, where you are required to deal with > "men with poor social skills." Or you can choose to spend your time > on the project where people treat you with respect. Which one do you > choose? The one where your expected satisfaction is higher, with boorishness from autistic males factored in as one of the overheads. Don't try to tell me that's a deal-killer, I've known too many women who would laugh at you for that assumption. > Or perhaps you have a job that requires you to work on free software. > Now, if you work on a project where the people act like RMS, you are > being forced by your employer to work in a space where you face > unwelcome advances and men who have "trouble recognizing boundaries." > That's textbook hostile environment, and a set up for you to sue your > employer. So your employer will never ask anyone to work on a project > where people act like that--at least, they won't do it more than once. Here's what happens in the real world (and I'm not speculating, I was a BoD member of a tech startup at one time, stuff like this came up). You say "X is being a jerk - can I work on something else?" Your employer, rightly terrified of the next step, is not going to "force" you to do a damn thing. He's going to bend over backwards to accommodate you. > (Entirely separately, I don't get the slant of your whole e-mail. You > can put up with RMS despite the boorish behavior you describe. Great. > You're a saint. Why do you expect everyone else to be a saint? I'm no saint, I'm merely an adult who takes responsibility for my own choices when dealing with people who have minimal-brain-damage syndromes. OK, I have probably acquired a bit more tolerance for their quirks than average from long experience, but I don't believe I'm an extreme outlier that way. What I am pushing for is for everyone to recognize that *women are adults* - they have their own agency and are in general perfectly capable of treating an RMS-class jerk as at worst a minor annoyance. Behaving as though he's some sort of icky monster who should be shunned by all right-thinking people and taints everything he touches is ... just unbelievably disconnected from reality. Bizarre neo-Puritan virtue signaling of no help to anyone. If I needed more evidence that many Americans lead pampered, cossetted, hyper-insulated lives that require them to make up their own drama, this whole flap would be it. -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: removing toxic emailers
On Fri Apr 16, 2021 at 4:19 AM BST, Ian Lance Taylor wrote:
> On Thu, Apr 15, 2021 at 8:02 PM Frosku wrote:
> >
> > > We want free software to succeed. Free software is more likely to
> > > succeed if more people work on it. If you are a volunteer, as many
> > > are, you can choose to spend your time on the project where you have
> > > to short-stop unwelcome advances, where you are required to deal with
> > > "men with poor social skills." Or you can choose to spend your time
> > > on the project where people treat you with respect. Which one do you
> > > choose?
> >
> > The one where technical excellence is prioritized over social skills,
> > personally. If I have a choice between partaking in a project where I
> > have to walk on eggshells for fear of people coming with torches and
> > pitchforks to expel me because I was a bit too harsh in my critique or
> > posted an opinion on my personal blog which wasn't something they
> > agreed with, or a project where some of the other people are people I
> > wouldn't share a beer with but the technical standard is high and free
> > expression is generally valued, I would choose the latter.
>
> Those are not the only two possible ways that a project can work.
>
> Also, you seem to be making the implicit assumption that there is some
> sort of trade off between technical excellence and social skills.
> That is false. They are independent axes.
I shouldn't really use the term 'social skills' when what I really mean is
conformance to a specific set of cultural norms. I don't necessarily think
that social skills are quantifiable in the way that i.e. writing performant
and secure code is. Someone could be highly compliant with social norms in
their own culture, in their first language, without necessarily being as
conformant with foreign cultural norms in a second language, for example.
I agree with you that a project which creates a hostile atmosphere to women
would drive people away, not just women but men with a sense of decency. I
would not want to be a part of such a project. I would differ from you on
whether RMS has created such a thing given his seemingly limited
interactions with the project spaces. If I am wrong, and he has been here
harassing women, or on other project-related spaces, I am very willing to
admit I'm wrong.
On the other hand, I also think that a project which goes too far in
policing speech, especially speech unrelated to the project, will drive away
talented people who are more than willing to comply with the project's norms
within the project's spaces. Trying to enforce the 'California cultural
standard' on not only someone's interactions with the project but their
entire life (which may be lived in a very different cultural setting) seems
very invasive and culturally exclusionary.
I'd be interested to know where you draw the line as to what behavior is
related to the project, or if you don't draw a line, why volunteers in China,
Russia, Poland etc should be expected to accept an entire political doctrine
over their life to contribute to a compiler toolchain.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
[Bug target/100056] [9/10 Regression] orr + lsl vs. [us]bfiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100056 --- Comment #11 from Luc Van Oostenryck --- Works nicely now. Thank you.
[Bug target/100028] [9/10 Regression] arm64 failure to generate bfxil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100028 --- Comment #8 from Luc Van Oostenryck --- Woks nicely now. Thanks
[Bug c++/100109] New: ICE: unexpected expression 'E' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100109
Bug ID: 100109
Summary: ICE: unexpected expression 'E' of kind
template_parm_index
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
https://godbolt.org/z/Go1W7YrYs
template
void f() {
[] { enum e { e = E }; };
}
template void f<>();
:3:13: internal compiler error: unexpected expression 'E' of kind
template_parm_index
3 | [] { enum e { e = E }; };
| ^
0x1d02849 internal_error(char const*, ...)
???:0
0x7a74bd build_enumerator(tree_node*, tree_node*, tree_node*, tree_node*,
unsigned int)
???:0
0x92c3c8 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
???:0
0x9182fd tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x9183a7 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x94b882 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x91e1df instantiate_decl(tree_node*, bool, bool)
???:0
0x9600bb instantiate_pending_templates(int)
???:0
0x7cd579 c_parse_final_cleanups()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Re: [PATCH] c++: ICE with bogus late return type [PR99803]
On 4/15/21 10:02 PM, Marek Polacek wrote:
On Thu, Apr 15, 2021 at 03:31:24PM -0400, Jason Merrill wrote:
On 4/14/21 9:21 PM, Marek Polacek wrote:
Here we ICE when compiling this code in C++20, because we're trying to
slam a 'typename' after the ->. The cp_parser_template_id call just
before the spot I'm changing parsed A::template A as a BASELINK
that contains a constructor, but make_typename_type crashes on that.
My fix is the same as c++/88325, add an is_overloaded_fn check.
Instead of handling this in various callers, maybe make_typename_type should
handle the error, like it already does for e.g.
struct A { template static T t; };
A(unsigned) -> A:: template t;
Okay, done.
Incidentally, in the testcase for 88325:
A::A () // { dg-error "partial specialization" }
this error is misleading; this isn't a partial specialization, it's
redundant template arguments while trying to define the primary template. I
wouldn't worry about fixing the compiler now, but let's not test for the
wrong error.
Makes sense.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
Here we ICE when compiling this code in C++20, because we're trying to
slam a 'typename' after the ->. The cp_parser_template_id call just
before the spot I'm changing parsed A::template A as a BASELINK
that contains a constructor, but make_typename_type crashes on that.
This patch makes make_typename_type more robust instead of checking
for is_overloaded_fn prior calling it.
gcc/cp/ChangeLog:
PR c++/99803
* decl.c (make_typename_type): Give an error and return when
name is is_overloaded_fn.
* parser.c (cp_parser_class_name): Don't check is_overloaded_fn
before calling make_typename_type.
gcc/testsuite/ChangeLog:
PR c++/99803
* g++.dg/cpp2a/typename14.C: Don't expect particular error
messages.
* g++.dg/cpp2a/typename19.C: New test.
---
gcc/cp/decl.c | 8 +++-
gcc/cp/parser.c | 4 +---
gcc/testsuite/g++.dg/cpp2a/typename14.C | 4 ++--
gcc/testsuite/g++.dg/cpp2a/typename19.C | 5 +
4 files changed, 15 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/typename19.C
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 1cb47313923..6668a65acbf 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -4055,6 +4055,12 @@ make_typename_type (tree context, tree name, enum
tag_types tag_type,
error ("%qD used without template arguments", name);
return error_mark_node;
}
+ else if (is_overloaded_fn (name))
+{
+ if (complain & tf_error)
+ error ("%qD is a function, not a type", name);
+ return error_mark_node;
+}
gcc_assert (identifier_p (name));
gcc_assert (TYPE_P (context));
@@ -4066,7 +4072,7 @@ make_typename_type (tree context, tree name, enum tag_types tag_type,
error ("%q#T is not a class", context);
return error_mark_node;
}
-
+
/* When the CONTEXT is a dependent type, NAME could refer to a
dependent base class of CONTEXT. But look inside it anyway
if CONTEXT is a currently open scope, in case it refers to a
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 940751b5f05..3640ae51331 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -24730,9 +24730,7 @@ cp_parser_class_name (cp_parser *parser,
decl = cp_parser_maybe_treat_template_as_class (decl, class_head_p);
/* If this is a typename, create a TYPENAME_TYPE. */
- if (typename_p
- && decl != error_mark_node
- && !is_overloaded_fn (decl))
+ if (typename_p && decl != error_mark_node)
{
decl = make_typename_type (scope, decl, typename_type,
/*complain=*/tf_error);
diff --git a/gcc/testsuite/g++.dg/cpp2a/typename14.C
b/gcc/testsuite/g++.dg/cpp2a/typename14.C
index 8d82b6b8d34..ba7dad8245f 100644
--- a/gcc/testsuite/g++.dg/cpp2a/typename14.C
+++ b/gcc/testsuite/g++.dg/cpp2a/typename14.C
@@ -8,7 +8,7 @@ template struct A
template
template
-A::A () // { dg-error "partial specialization" }
+A::A () // { dg-error "" }
{
}
@@ -19,7 +19,7 @@ template struct B
template
template
-B::foo(int) // { dg-error "partial specialization|declaration" }
+B::foo(int) // { dg-error "" }
{
return 1;
}
diff --git a/gcc/testsuite/g++.dg/cpp2a/typename19.C
b/gcc/testsuite/g++.dg/cpp2a/typename19.C
new file mode 100644
index 000..320a14d6a0c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/typename19.C
@@ -0,0 +1,5 @@
+// PR c++/99803
+// { dg-do compile { target c++20 } }
+
+struct A { template A(T); };
+auto A(unsigned) -> A::template A; // { dg-error "not a type" }
base-commit: ee351f7fdbd82f8947fe9a0e74cea65d216a8549
Re: removing toxic emailers
On Thu, Apr 15, 2021 at 8:02 PM Frosku wrote: > > > We want free software to succeed. Free software is more likely to > > succeed if more people work on it. If you are a volunteer, as many > > are, you can choose to spend your time on the project where you have > > to short-stop unwelcome advances, where you are required to deal with > > "men with poor social skills." Or you can choose to spend your time > > on the project where people treat you with respect. Which one do you > > choose? > > The one where technical excellence is prioritized over social skills, > personally. If I have a choice between partaking in a project where I > have to walk on eggshells for fear of people coming with torches and > pitchforks to expel me because I was a bit too harsh in my critique or > posted an opinion on my personal blog which wasn't something they > agreed with, or a project where some of the other people are people I > wouldn't share a beer with but the technical standard is high and free > expression is generally valued, I would choose the latter. Those are not the only two possible ways that a project can work. Also, you seem to be making the implicit assumption that there is some sort of trade off between technical excellence and social skills. That is false. They are independent axes. Ian
Re: removing toxic emailers
On Fri Apr 16, 2021 at 3:47 AM BST, Ian Lance Taylor via Gcc wrote:
> This is about work. There are social aspects to free software, but
> it's not fundamentally a social activity. It's about getting
> something done, and for many people it's their job. For the sake of
> argument, I'm going to temporarily set aside all consideration of how
> people should behave in a professional setting, not because it doesn't
> matter, but just to try to clarify matters. Let's just think about
> the project.
>
> We want free software to succeed. Free software is more likely to
> succeed if more people work on it. If you are a volunteer, as many
> are, you can choose to spend your time on the project where you have
> to short-stop unwelcome advances, where you are required to deal with
> "men with poor social skills." Or you can choose to spend your time
> on the project where people treat you with respect. Which one do you
> choose?
The one where technical excellence is prioritized over social skills,
personally. If I have a choice between partaking in a project where I
have to walk on eggshells for fear of people coming with torches and
pitchforks to expel me because I was a bit too harsh in my critique or
posted an opinion on my personal blog which wasn't something they
agreed with, or a project where some of the other people are people I
wouldn't share a beer with but the technical standard is high and free
expression is generally valued, I would choose the latter.
This comes down to culture. I did not grow up in a culture where I was
taught that other people need to wrap me in cotton wool. I grew up in a
culture where arguments were judged on merit and generally as people we
accepted other peoples' rights to hold shitty opinions. For many of us,
the latter is more comfortable.
> Or perhaps you have a job that requires you to work on free software.
> Now, if you work on a project where the people act like RMS, you are
> being forced by your employer to work in a space where you face
> unwelcome advances and men who have "trouble recognizing boundaries."
> That's textbook hostile environment, and a set up for you to sue your
> employer. So your employer will never ask anyone to work on a project
> where people act like that--at least, they won't do it more than once.
I have never seen RMS act like that in a technical setting though, and
if he did, I think that would be a valid reason to remove him from the
mailing list and demand that GNU chooses someone else to represent
itself when communicating with GCC.
> In other words, having people who act in the way that you describe RMS
> as acting is actively harmful for a free software project, because it
> will discourage people from working on it.
>
> (Entirely separately, I don't get the slant of your whole e-mail. You
> can put up with RMS despite the boorish behavior you describe. Great.
> You're a saint. Why do you expect everyone else to be a saint? I
> don't meet with people who act like that, not more than once. Life is
> too short. I'll work with them if I must, but not if I don't have
> to.)
I don't think anyone needs to be a saint, but we do need to be able to
collaborate with people from different cultural, political, and personal
backgrounds to our own. Enforcing a social code which is exclusive to
the coasts of the United States on a global community seems to me to be
even more exclusionary than allowing people with poor social skills.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
On Thu, Apr 15, 2021 at 4:29 PM Eric S. Raymond wrote: > > *grumble* Get *over* yourselves. You want to be "welcoming" to > women? Don't patronize or infantilize them - respect their ability to > tell off RMS for themselves *and then keep working with him*! Thank you for sharing your experiences. I just want to note that I think this last paragraph misses the point. Patronizing or infantilizing anybody doesn't come into this at all. This is about work. There are social aspects to free software, but it's not fundamentally a social activity. It's about getting something done, and for many people it's their job. For the sake of argument, I'm going to temporarily set aside all consideration of how people should behave in a professional setting, not because it doesn't matter, but just to try to clarify matters. Let's just think about the project. We want free software to succeed. Free software is more likely to succeed if more people work on it. If you are a volunteer, as many are, you can choose to spend your time on the project where you have to short-stop unwelcome advances, where you are required to deal with "men with poor social skills." Or you can choose to spend your time on the project where people treat you with respect. Which one do you choose? Or perhaps you have a job that requires you to work on free software. Now, if you work on a project where the people act like RMS, you are being forced by your employer to work in a space where you face unwelcome advances and men who have "trouble recognizing boundaries." That's textbook hostile environment, and a set up for you to sue your employer. So your employer will never ask anyone to work on a project where people act like that--at least, they won't do it more than once. In other words, having people who act in the way that you describe RMS as acting is actively harmful for a free software project, because it will discourage people from working on it. (Entirely separately, I don't get the slant of your whole e-mail. You can put up with RMS despite the boorish behavior you describe. Great. You're a saint. Why do you expect everyone else to be a saint? I don't meet with people who act like that, not more than once. Life is too short. I'll work with them if I must, but not if I don't have to.) Ian
Re: [PATCH] c++: ICE with bogus late return type [PR99803]
On Thu, Apr 15, 2021 at 03:31:24PM -0400, Jason Merrill wrote:
> On 4/14/21 9:21 PM, Marek Polacek wrote:
> > Here we ICE when compiling this code in C++20, because we're trying to
> > slam a 'typename' after the ->. The cp_parser_template_id call just
> > before the spot I'm changing parsed A::template A as a BASELINK
> > that contains a constructor, but make_typename_type crashes on that.
> >
> > My fix is the same as c++/88325, add an is_overloaded_fn check.
>
> Instead of handling this in various callers, maybe make_typename_type should
> handle the error, like it already does for e.g.
>
> struct A { template static T t; };
> A(unsigned) -> A:: template t;
Okay, done.
> Incidentally, in the testcase for 88325:
>
> > A::A () // { dg-error "partial specialization" }
>
> this error is misleading; this isn't a partial specialization, it's
> redundant template arguments while trying to define the primary template. I
> wouldn't worry about fixing the compiler now, but let's not test for the
> wrong error.
Makes sense.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we ICE when compiling this code in C++20, because we're trying to
slam a 'typename' after the ->. The cp_parser_template_id call just
before the spot I'm changing parsed A::template A as a BASELINK
that contains a constructor, but make_typename_type crashes on that.
This patch makes make_typename_type more robust instead of checking
for is_overloaded_fn prior calling it.
gcc/cp/ChangeLog:
PR c++/99803
* decl.c (make_typename_type): Give an error and return when
name is is_overloaded_fn.
* parser.c (cp_parser_class_name): Don't check is_overloaded_fn
before calling make_typename_type.
gcc/testsuite/ChangeLog:
PR c++/99803
* g++.dg/cpp2a/typename14.C: Don't expect particular error
messages.
* g++.dg/cpp2a/typename19.C: New test.
---
gcc/cp/decl.c | 8 +++-
gcc/cp/parser.c | 4 +---
gcc/testsuite/g++.dg/cpp2a/typename14.C | 4 ++--
gcc/testsuite/g++.dg/cpp2a/typename19.C | 5 +
4 files changed, 15 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/typename19.C
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 1cb47313923..6668a65acbf 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -4055,6 +4055,12 @@ make_typename_type (tree context, tree name, enum
tag_types tag_type,
error ("%qD used without template arguments", name);
return error_mark_node;
}
+ else if (is_overloaded_fn (name))
+{
+ if (complain & tf_error)
+ error ("%qD is a function, not a type", name);
+ return error_mark_node;
+}
gcc_assert (identifier_p (name));
gcc_assert (TYPE_P (context));
@@ -4066,7 +4072,7 @@ make_typename_type (tree context, tree name, enum
tag_types tag_type,
error ("%q#T is not a class", context);
return error_mark_node;
}
-
+
/* When the CONTEXT is a dependent type, NAME could refer to a
dependent base class of CONTEXT. But look inside it anyway
if CONTEXT is a currently open scope, in case it refers to a
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 940751b5f05..3640ae51331 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -24730,9 +24730,7 @@ cp_parser_class_name (cp_parser *parser,
decl = cp_parser_maybe_treat_template_as_class (decl, class_head_p);
/* If this is a typename, create a TYPENAME_TYPE. */
- if (typename_p
- && decl != error_mark_node
- && !is_overloaded_fn (decl))
+ if (typename_p && decl != error_mark_node)
{
decl = make_typename_type (scope, decl, typename_type,
/*complain=*/tf_error);
diff --git a/gcc/testsuite/g++.dg/cpp2a/typename14.C
b/gcc/testsuite/g++.dg/cpp2a/typename14.C
index 8d82b6b8d34..ba7dad8245f 100644
--- a/gcc/testsuite/g++.dg/cpp2a/typename14.C
+++ b/gcc/testsuite/g++.dg/cpp2a/typename14.C
@@ -8,7 +8,7 @@ template struct A
template
template
-A::A () // { dg-error "partial specialization" }
+A::A () // { dg-error "" }
{
}
@@ -19,7 +19,7 @@ template struct B
template
template
-B::foo(int) // { dg-error "partial specialization|declaration" }
+B::foo(int) // { dg-error "" }
{
return 1;
}
diff --git a/gcc/testsuite/g++.dg/cpp2a/typename19.C
b/gcc/testsuite/g++.dg/cpp2a/typename19.C
new file mode 100644
index 000..320a14d6a0c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/typename19.C
@@ -0,0 +1,5 @@
+// PR c++/99803
+// { dg-do compile { target c++20 } }
+
+struct A { template A(T); };
+auto A(unsigned) -> A::template A; // { dg-error "not a type" }
base-commit: ee351f7fdbd82f8947fe9a0e74cea65d216a8549
--
2.30.2
[Bug target/100108] New: [10 Regression] powerpc: recognize 32-bit CPU as POWER9 with -misel option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108
Bug ID: 100108
Summary: [10 Regression] powerpc: recognize 32-bit CPU as
POWER9 with -misel option
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rin at NetBSD dot org
Target Milestone: ---
Created attachment 50609
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50609=edit
Fix for this regression
GCC10 wrongly recognizes CPU as POWER9 if -misel is specified, even when
it is configured for 32-bit processors:
% cat test.c
int main(void)
{
return 0;
}
% gcc10 -misel -S test.c -o test10.S
% gcc9 -misel -S test.c -o test9.S
% diff -u test9.S test10.S
--- test.9 2021-04-16 10:53:47.116917225 +0900
+++ test.10 2021-04-16 10:53:38.075282430 +0900
@@ -1,5 +1,5 @@
.file "test.c"
- .machine ppc
+ .machine power9
.section".text"
.align 2
.globl main
...(snip)...
This is because rs6000_machine_from_flags() assumes ISEL instructions
are supported only by POWER9 and successors. However, ISEL is also
implemented for 32-bit processors like e500.
Please apply the attached patch to fix the problem.
% gcc10 -v
Using built-in specs.
COLLECT_GCC=/build/tools.broken/bin/powerpc--netbsd-gcc
COLLECT_LTO_WRAPPER=/build/tools.broken/libexec/gcc/powerpc--netbsd/10.3.0/lto-wrapper
Target: powerpc--netbsd
Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc/dist/configure
--target=powerpc--netbsd --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/support/send-pr.html
--with-pkgversion='NetBSD nb1 20210411' --with-system-zlib --without-isl
--enable-__cxa_atexit --enable-libstdcxx-time=rt --enable-libstdcxx-threads
--with-diagnostics-color=auto-if-env --with-default-libstdcxx-abi=new
--with-sysroot=/build/dest/evbppc-powerpc --with-mpc=/build/tools.broken
--with-mpfr=/build/tools.broken --with-gmp=/build/tools.broken --disable-nls
--disable-multilib --program-transform-name='s,^,powerpc--netbsd-,'
--enable-languages='c c++ objc' --prefix=/build/tools.broken
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (NetBSD nb1 20210411)
% gcc9 -v
Using built-in specs.
COLLECT_GCC=/build/tools.9/bin/powerpc--netbsd-gcc
COLLECT_LTO_WRAPPER=/build/tools.9/libexec/gcc/powerpc--netbsd/9.3.0/lto-wrapper
Target: powerpc--netbsd
Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/configure
--target=powerpc--netbsd --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/support/send-pr.html
--with-pkgversion='NetBSD nb1 20200907' --with-system-zlib --without-isl
--enable-__cxa_atexit --enable-libstdcxx-time=rt --enable-libstdcxx-threads
--with-diagnostics-color=auto-if-env --with-default-libstdcxx-abi=new
--with-sysroot=/build/dest/evbppc-powerpc --with-mpc=/build/tools.9
--with-mpfr=/build/tools.9 --with-gmp=/build/tools.9 --disable-nls
--disable-multilib --program-transform-name='s,^,powerpc--netbsd-,'
--enable-languages='c c++ objc' --prefix=/build/tools.9
Thread model: posix
gcc version 9.3.0 (NetBSD nb1 20200907)
[Bug middle-end/100104] std::transform is 1.5 times faster than std::copy with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100104 --- Comment #4 from 康桓瑋 --- And Build "copy" with -O2 on ARM64 is identical with -O3 (https://godbolt.org/z/5hjKGbrTd): .LC0: .string "vector::_M_realloc_insert" transform(std::vector > const&): stp x29, x30, [sp, -64]! mov x29, sp stp x19, x20, [sp, 16] mov x19, x8 ldp x20, x0, [x0] stp xzr, xzr, [x8] str xzr, [x8, 16] sub x0, x0, x20 cmp x0, 0 ble .L19 mov x1, 0 str x21, [sp, 32] asr x21, x0, 3 mov x0, 0 b .L23 .L35: str w2, [x0], 4 add x20, x20, 8 subsx21, x21, #1 str x0, [x19, 8] beq .L34 .L36: ldp x0, x1, [x19, 8] .L23: ldr d0, [x20] fcvtzs w2, d0 str w2, [sp, 60] cmp x1, x0 bne .L35 add x2, sp, 60 mov x0, x19 bl void std::vector >::_M_realloc_insert(__gnu_cxx::__normal_iterator > >, int&&) add x20, x20, 8 subsx21, x21, #1 bne .L36 .L34: ldr x21, [sp, 32] .L19: mov x0, x19 ldp x19, x20, [sp, 16] ldp x29, x30, [sp], 64 ret ldr x2, [x19] ldr x1, [x19, 16] mov x19, x0 sub x1, x1, x2 cbz x2, .L25 mov x0, x2 bl operator delete(void*, unsigned long) .L25: mov x0, x19 bl _Unwind_Resume DW.ref.__gxx_personality_v0: .xword __gxx_personality_v0 === However, "transform" has been further optimized under -O3 (https://godbolt.org/z/5hjKGbrTd): .LC0: .string "vector::_M_realloc_insert" transform(std::vector > const&): stp x29, x30, [sp, -96]! mov x29, sp stp x19, x20, [sp, 16] stp x21, x22, [sp, 32] mov x21, x8 ldp x20, x22, [x0] stp xzr, xzr, [x8] str xzr, [x8, 16] cmp x22, x20 beq .L1 mov x19, 0 stp x23, x24, [sp, 48] stp x25, x26, [sp, 64] mov x25, 2305843009213693951 stp x27, x28, [sp, 80] mov x28, 0 b .L13 .L32: str w27, [x19], 4 add x20, x20, 8 str x19, [x21, 8] cmp x22, x20 beq .L31 .L13: ldr d0, [x20] fcvtzs w27, d0 cmp x19, x28 bne .L32 ldr x24, [x21] sub x23, x19, x24 asr x1, x23, 2 cmp x1, x25 beq .L33 cmp x1, 0 csinc x0, x1, xzr, ne addsx0, x0, x1 bcs .L7 cbnzx0, .L34 mov x28, 0 mov x26, 0 .L9: add x19, x23, 4 str w27, [x26, x23] add x19, x26, x19 cmp x23, 0 bgt .L35 cbnzx24, .L36 .L12: add x20, x20, 8 stp x26, x19, [x21] str x28, [x21, 16] cmp x22, x20 bne .L13 .L31: ldp x23, x24, [sp, 48] ldp x25, x26, [sp, 64] ldp x27, x28, [sp, 80] .L1: mov x0, x21 ldp x19, x20, [sp, 16] ldp x21, x22, [sp, 32] ldp x29, x30, [sp], 96 ret .L35: mov x1, x24 mov x2, x23 mov x0, x26 bl memmove ldr x1, [x21, 16] sub x1, x1, x24 .L11: mov x0, x24 bl operator delete(void*, unsigned long) b .L12 .L36: ldr x1, [x21, 16] sub x1, x1, x24 b .L11 .L34: cmp x0, x25 cselx0, x0, x25, ls lsl x28, x0, 2 .L8: mov x0, x28 bl operator new(unsigned long) mov x26, x0 add x28, x0, x28 b .L9 .L7: mov x28, 9223372036854775804 b .L8 .L33: adrpx0, .LC0 add x0, x0, :lo12:.LC0 bl std::__throw_length_error(char const*) ldr x2, [x21] mov x19, x0 ldr x1, [x21, 16] sub x1, x1, x2 cbz x2, .L16 mov x0, x2 bl operator delete(void*, unsigned long) .L16: mov x0, x19 bl _Unwind_Resume DW.ref.__gxx_personality_v0: .xword __gxx_personality_v0
[Bug target/100107] New: [10 Regression] powerpc: redundant .machine directive clobbers CPU flags to assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100107
Bug ID: 100107
Summary: [10 Regression] powerpc: redundant .machine directive
clobbers CPU flags to assembler
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rin at NetBSD dot org
Target Milestone: ---
Created attachment 50608
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50608=edit
Fix for this regression
GCC10 miscompiles inline assembler codes for 403/405 processors:
% cat mfpid.c
unsigned mfpid(void)
{
unsigned pid;
__asm volatile("mfpid %0" : "=r"(pid));
return pid;
}
% gcc10 -m403 -c mfpid.c -o mfpid10.o && objdump -D403 mfpid10.o > mfpid10.dump
% gcc9 -m403 -c mfpid.c -o mfpid9.o && objdump -D403 mfpid9.o > mfpid9.dump
% diff -u mfpid9.dump mfpid10.dump
...(snip)...
- c: 7d 31 ea a6 mfpid r9
+ c: 7d 30 0a a6 mfspr r9,48
...(snip)...
This is because redundant .machine directive, introduced by commit
2d94f7dea9c73ef3c116a0ddc722724578a860fe:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2d94f7dea9c73ef3c116a0ddc722724578a860fe
clobbers CPU flags passed to assembler (-m403 in this case). Actually, diff
b/w .S files generated by GCC9 and 10 reads:
% diff -u mfpid9.S mfpid10.S
--- mfpid9.S2021-04-16 10:21:47.688171347 +0900
+++ mfpid10.S 2021-04-16 10:21:37.262150628 +0900
@@ -1,4 +1,5 @@
.file "mfpid.c"
+ .machine ppc
.section".text"
.align 2
.globl mfpid
...(snip)...
By reverting that commit with attached patch, this file can be successfully
compiled again with GCC10.
% gcc10 -v
Using built-in specs.
COLLECT_GCC=/build/tools.broken/bin/powerpc--netbsd-gcc
COLLECT_LTO_WRAPPER=/build/tools.broken/libexec/gcc/powerpc--netbsd/10.3.0/lto-wrapper
Target: powerpc--netbsd
Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc/dist/configure
--target=powerpc--netbsd --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/support/send-pr.html
--with-pkgversion='NetBSD nb1 20210411' --with-system-zlib --without-isl
--enable-__cxa_atexit --enable-libstdcxx-time=rt --enable-libstdcxx-threads
--with-diagnostics-color=auto-if-env --with-default-libstdcxx-abi=new
--with-sysroot=/build/dest/evbppc-powerpc --with-mpc=/build/tools.broken
--with-mpfr=/build/tools.broken --with-gmp=/build/tools.broken --disable-nls
--disable-multilib --program-transform-name='s,^,powerpc--netbsd-,'
--enable-languages='c c++ objc' --prefix=/build/tools.broken
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (NetBSD nb1 20210411)
% gcc9 -v
Using built-in specs.
COLLECT_GCC=/build/tools.9/bin/powerpc--netbsd-gcc
COLLECT_LTO_WRAPPER=/build/tools.9/libexec/gcc/powerpc--netbsd/9.3.0/lto-wrapper
Target: powerpc--netbsd
Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/configure
--target=powerpc--netbsd --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/support/send-pr.html
--with-pkgversion='NetBSD nb1 20200907' --with-system-zlib --without-isl
--enable-__cxa_atexit --enable-libstdcxx-time=rt --enable-libstdcxx-threads
--with-diagnostics-color=auto-if-env --with-default-libstdcxx-abi=new
--with-sysroot=/build/dest/evbppc-powerpc --with-mpc=/build/tools.9
--with-mpfr=/build/tools.9 --with-gmp=/build/tools.9 --disable-nls
--disable-multilib --program-transform-name='s,^,powerpc--netbsd-,'
--enable-languages='c c++ objc' --prefix=/build/tools.9
Thread model: posix
gcc version 9.3.0 (NetBSD nb1 20200907)
[Bug middle-end/100104] std::transform is 1.5 times faster than std::copy with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100104 --- Comment #3 from 康桓瑋 --- Build "copy" with -O2 on x86-64 (https://godbolt.org/z/Gja6xrq9G): .LC0: .string "vector::_M_realloc_insert" copy(std::vector > const&): pushr15 pxorxmm0, xmm0 pushr14 pushr13 pushr12 mov r12, rdi pushrbp pushrbx sub rsp, 40 mov r13, QWORD PTR [rsi+8] mov rbx, QWORD PTR [rsi] movups XMMWORD PTR [rdi], xmm0 mov QWORD PTR [rdi+16], 0 cmp rbx, r13 je .L1 xor r8d, r8d xor ecx, ecx jmp .L13 .L31: mov DWORD PTR [rcx], ebp add rbx, 8 add rcx, 4 mov QWORD PTR [r12+8], rcx cmp r13, rbx je .L1 .L13: cvttsd2si ebp, QWORD PTR [rbx] cmp rcx, r8 jne .L31 movabs rax, 2305843009213693951 mov r15, QWORD PTR [r12] sub rcx, r15 mov rdx, rcx mov r14, rcx sar rdx, 2 cmp rdx, rax je .L32 testrdx, rdx mov eax, 1 cmovne rax, rdx add rax, rdx jc .L7 testrax, rax jne .L33 xor r8d, r8d xor edi, edi .L9: lea rcx, [rdi+4+r14] movqxmm0, rdi mov DWORD PTR [rdi+r14], ebp movqxmm1, rcx punpcklqdq xmm0, xmm1 testr14, r14 jg .L34 testr15, r15 jne .L35 .L12: add rbx, 8 mov QWORD PTR [r12+16], r8 movups XMMWORD PTR [r12], xmm0 cmp r13, rbx jne .L13 .L1: add rsp, 40 mov rax, r12 pop rbx pop rbp pop r12 pop r13 pop r14 pop r15 ret .L34: mov rsi, r15 mov rdx, r14 mov QWORD PTR [rsp+8], r8 mov QWORD PTR [rsp], rcx movaps XMMWORD PTR [rsp+16], xmm0 callmemmove mov rsi, QWORD PTR [r12+16] mov rcx, QWORD PTR [rsp] mov r8, QWORD PTR [rsp+8] movdqa xmm0, XMMWORD PTR [rsp+16] sub rsi, r15 .L11: mov rdi, r15 mov QWORD PTR [rsp+8], r8 mov QWORD PTR [rsp], rcx movaps XMMWORD PTR [rsp+16], xmm0 calloperator delete(void*, unsigned long) movdqa xmm0, XMMWORD PTR [rsp+16] mov r8, QWORD PTR [rsp+8] mov rcx, QWORD PTR [rsp] jmp .L12 .L35: mov rsi, QWORD PTR [r12+16] sub rsi, r15 jmp .L11 .L33: movabs rdx, 2305843009213693951 cmp rax, rdx cmova rax, rdx sal rax, 2 mov QWORD PTR [rsp], rax mov rdi, rax .L8: calloperator new(unsigned long) mov r8, QWORD PTR [rsp] mov rdi, rax add r8, rax jmp .L9 .L7: movabs rax, 9223372036854775804 mov QWORD PTR [rsp], rax mov rdi, rax jmp .L8 .L32: mov edi, OFFSET FLAT:.LC0 callstd::__throw_length_error(char const*) mov rbp, rax jmp .L15 copy(std::vector > const&) [clone .cold]: === with -O3: .LC0: .string "vector::_M_realloc_insert" copy(std::vector > const&): pushr15 pxorxmm0, xmm0 pushr14 pushr13 pushr12 mov r12, rdi pushrbp pushrbx sub rsp, 40 mov r13, QWORD PTR [rsi+8] mov rbx, QWORD PTR [rsi] movups XMMWORD PTR [rdi], xmm0 mov QWORD PTR [rdi+16], 0 cmp rbx, r13 je .L1 xor r8d, r8d xor ecx, ecx jmp .L13 .L31: mov DWORD PTR [rcx], ebp add rbx, 8 add rcx, 4 mov QWORD PTR [r12+8], rcx cmp r13, rbx je .L1 .L13: cvttsd2si ebp, QWORD PTR [rbx] cmp rcx, r8 jne .L31 movabs rax, 2305843009213693951 mov r15, QWORD PTR [r12] sub rcx, r15 mov rdx, rcx mov r14, rcx sar rdx, 2 cmp rdx, rax je .L32 testrdx, rdx mov eax, 1 cmovne rax, rdx add rax, rdx jc .L7 testrax, rax jne .L33 xor r8d, r8d xor edi, edi .L9: lea rcx, [rdi+4+r14] movqxmm0, rdi mov DWORD PTR [rdi+r14], ebp movqxmm1, rcx punpcklqdq xmm0, xmm1 testr14, r14
[Bug middle-end/100104] std::transform is 1.5 times faster than std::copy with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100104 --- Comment #2 from 康桓瑋 --- Build "copy" with -O2 on x86-64 (https://godbolt.org/z/Gja6xrq9G): .LC0: .string "vector::_M_realloc_insert" copy(std::vector > const&): pushr15 pxorxmm0, xmm0 pushr14 pushr13 pushr12 mov r12, rdi pushrbp pushrbx sub rsp, 40 mov r13, QWORD PTR [rsi+8] mov rbx, QWORD PTR [rsi] movups XMMWORD PTR [rdi], xmm0 mov QWORD PTR [rdi+16], 0 cmp rbx, r13 je .L1 xor r8d, r8d xor ecx, ecx jmp .L13 .L31: mov DWORD PTR [rcx], ebp add rbx, 8 add rcx, 4 mov QWORD PTR [r12+8], rcx cmp r13, rbx je .L1 .L13: cvttsd2si ebp, QWORD PTR [rbx] cmp rcx, r8 jne .L31 movabs rax, 2305843009213693951 mov r15, QWORD PTR [r12] sub rcx, r15 mov rdx, rcx mov r14, rcx sar rdx, 2 cmp rdx, rax je .L32 testrdx, rdx mov eax, 1 cmovne rax, rdx add rax, rdx jc .L7 testrax, rax jne .L33 xor r8d, r8d xor edi, edi .L9: lea rcx, [rdi+4+r14] movqxmm0, rdi mov DWORD PTR [rdi+r14], ebp movqxmm1, rcx punpcklqdq xmm0, xmm1 testr14, r14 jg .L34 testr15, r15 jne .L35 .L12: add rbx, 8 mov QWORD PTR [r12+16], r8 movups XMMWORD PTR [r12], xmm0 cmp r13, rbx jne .L13 .L1: add rsp, 40 mov rax, r12 pop rbx pop rbp pop r12 pop r13 pop r14 pop r15 ret .L34: mov rsi, r15 mov rdx, r14 mov QWORD PTR [rsp+8], r8 mov QWORD PTR [rsp], rcx movaps XMMWORD PTR [rsp+16], xmm0 callmemmove mov rsi, QWORD PTR [r12+16] mov rcx, QWORD PTR [rsp] mov r8, QWORD PTR [rsp+8] movdqa xmm0, XMMWORD PTR [rsp+16] sub rsi, r15 .L11: mov rdi, r15 mov QWORD PTR [rsp+8], r8 mov QWORD PTR [rsp], rcx movaps XMMWORD PTR [rsp+16], xmm0 calloperator delete(void*, unsigned long) movdqa xmm0, XMMWORD PTR [rsp+16] mov r8, QWORD PTR [rsp+8] mov rcx, QWORD PTR [rsp] jmp .L12 .L35: mov rsi, QWORD PTR [r12+16] sub rsi, r15 jmp .L11 .L33: movabs rdx, 2305843009213693951 cmp rax, rdx cmova rax, rdx sal rax, 2 mov QWORD PTR [rsp], rax mov rdi, rax .L8: calloperator new(unsigned long) mov r8, QWORD PTR [rsp] mov rdi, rax add r8, rax jmp .L9 .L7: movabs rax, 9223372036854775804 mov QWORD PTR [rsp], rax mov rdi, rax jmp .L8 .L32: mov edi, OFFSET FLAT:.LC0 callstd::__throw_length_error(char const*) mov rbp, rax jmp .L15 copy(std::vector > const&) [clone .cold]: === with -O3: .LC0: .string "vector::_M_realloc_insert" copy(std::vector > const&): pushr15 pxorxmm0, xmm0 pushr14 pushr13 pushr12 mov r12, rdi pushrbp pushrbx sub rsp, 40 mov r13, QWORD PTR [rsi+8] mov rbx, QWORD PTR [rsi] movups XMMWORD PTR [rdi], xmm0 mov QWORD PTR [rdi+16], 0 cmp rbx, r13 je .L1 xor r8d, r8d xor ecx, ecx jmp .L13 .L31: mov DWORD PTR [rcx], ebp add rbx, 8 add rcx, 4 mov QWORD PTR [r12+8], rcx cmp r13, rbx je .L1 .L13: cvttsd2si ebp, QWORD PTR [rbx] cmp rcx, r8 jne .L31 movabs rax, 2305843009213693951 mov r15, QWORD PTR [r12] sub rcx, r15 mov rdx, rcx mov r14, rcx sar rdx, 2 cmp rdx, rax je .L32 testrdx, rdx mov eax, 1 cmovne rax, rdx add rax, rdx jc .L7 testrax, rax jne .L33 xor r8d, r8d xor edi, edi .L9: lea rcx, [rdi+4+r14] movqxmm0, rdi mov DWORD PTR [rdi+r14], ebp movqxmm1, rcx punpcklqdq xmm0, xmm1 testr14, r14
Re: removing toxic emailers
> Sent: Friday, April 16, 2021 at 12:16 PM > From: "Joseph Myers" > To: "Frosku" > Cc: e...@thyrsus.com, "Christopher Dimech" , "GCC > Development" > Subject: Re: removing toxic emailers > > On Fri, 16 Apr 2021, Frosku wrote: > > > Right now, the ultimate oversight of GCC sits with GNU & > > FSF -- both institutions with a mandate to represent the ecosystem based > > on level of membership and time spent fighting for free software. > > I think the oversight of glibc by development working through discussion > seeking consensus, and rejecting any attempt to override such consensus > "from above", is much more effective than any attempt GNU or FSF makes at > oversight. An umbrella organization for the toolchain should not act as > an "above" that can override the community at all; it should provide > services to the toolchain (e.g. legal support) as needed. It should act as an umbrella organization for distributing useful code under robust legal theory during the production of software in commons. That's my position, anyway. > -- > Joseph S. Myers > jos...@codesourcery.com >
Re: removing toxic emailers
> Sent: Friday, April 16, 2021 at 11:52 AM > From: "Eric S. Raymond" > To: "Christopher Dimech" > Cc: "Frosku" , "GCC Development" > Subject: Re: removing toxic emailers > > Christopher Dimech via Gcc : > > The commercial use of free software is our hope, not our fear. When people > > at IBM began to come to free software, wanting to recommend it and use it, > > and maybe distribute it themselves or encourage other people to distribute > > it for them, we did not criticise them for not being non-profit virtuous > > enough, or said "we are suspicious of you", let alone threatening them. > > Actually, some of us did *exactly* those things late in the last century. When I worked in ocean acoustics, everything was kept secret. Yet russian oceanographers (e.g. Leonid Brekhovshkikh who was working in the Sea Japan) had themselves figured out the same phenomena independently at around the same time. > One of the challenges I faced in my early famous years was persuading > the hacker culture as a whole to treat the profit-centered parts of the > economy as allies rather than enemies. > > I won't say that a *majority* of us were resistent to this, but I > did have to work hard on the problem for a while, between 1997 > and about 2003. About ten years ago, free software was chosen as the operating system of the International Space Station. Things have been changing, but I agree that there is much work to be done. Our approach has been a noticeable proposition, not just to us - though we understand why it is socially and politically desirable that the world works this way. > -- > http://www.catb.org/~esr/;>Eric S. Raymond > > >
Re: removing toxic emailers
On Fri Apr 16, 2021 at 1:16 AM BST, Joseph Myers wrote:
> On Fri, 16 Apr 2021, Frosku wrote:
>
> > Right now, the ultimate oversight of GCC sits with GNU &
> > FSF -- both institutions with a mandate to represent the ecosystem based
> > on level of membership and time spent fighting for free software.
>
> I think the oversight of glibc by development working through discussion
> seeking consensus, and rejecting any attempt to override such consensus
> "from above", is much more effective than any attempt GNU or FSF makes
> at
> oversight. An umbrella organization for the toolchain should not act as
> an "above" that can override the community at all; it should provide
> services to the toolchain (e.g. legal support) as needed.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
The way I see it, the developers represent the interests of the developers,
and FSF/GNU represent the interests of the users. The users should always
have some level of representation in any steering discussion, especially
for a project like GCC where any poor decision could have a negative effect
on so many other free software projects.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
I fully agree with your assessment. Have in the past organised meetings for him and never seen any bs. Having led the discussions, RMS was always cooperative and at no point disrupted procedure. This was 2017-2018 when I was in Barcelona coordinating all this - leading to the CaixaForum conversation on digital cities with Barcelona City Council Chief of Technology Francesca Bria. And other interactions, e.g. with Behavioral Expert Dr Diane Hamilton. If anyone thinks the two women needed white-knighting, people who think this way, should go and get their head tested. Although the 14th century is long past, many educated people today are either uneducated, or education has educated them out of it. - Christopher Dimech General Administrator - Naiad Informatics - GNU Project (Geocomputation) - Geophysical Simulation - Geological Subsurface Mapping - Disaster Preparedness and Mitigation - Natural Resource Exploration and Production - Free Software Advocacy > Sent: Friday, April 16, 2021 at 11:28 AM > From: "Eric S. Raymond" > To: "David Malcolm" > Cc: gcc@gcc.gnu.org, "Nathan Sidwell" , "Joseph Myers" > > Subject: Re: removing toxic emailers > > David Malcolm : > > > I will, however, point out that it is a very *different* point from > > > "RMS has iupset some people and should therefore be canceled". > > > > Eric: I don't know if you're just being glib, or you're deliberately > > trying to caricature those of us who are upset by RMS's behavior. > > My intent was not caricature. I was being dismissive and snarky > because I genuinely consider the personality complaints against RMS to > be pretty trivial. Not the managerial ones Joseph Myers listed; those > are serious. But they're not the cause of the current ruckus. > > To make the "triviality" point in the most forceful possible way, I > will take the bull by the horns and directly address RMS's behavior towards > women. And I will reveal a few things that I haven't talked about in > public for 40 years. > > I've known RMS since 1979; I'm fully aware of how obnoxious he can be > towards both men and women. There have been occasions on which I have > thought the state of the universe would have been improved if he'd > gotten a swift slap in the face. > > In fact, the first or second time I met him face to face it was > because he was rather determinedly pursuing my then-girlfriend. > A hostile witness might have said he was creeping on her, though > that slang for it wouldn't be invented until much later. > > I think an explanation of how how I reasoned about that situation has > some value in light of the current attempt to ostracize RMS. > > I paid very careful attention to whether my girlfriend appeared to > need any help dealing with him. I regarded her as an adult fully > capable of making her own decisions. One of those decisions could > have been to slap his face. If a more severe sanction had been > required, and she had yelled for help, I would cheerfully have > punched his lights out. > > No fisticuffs were required. She gently discouraged him, and we both > established friendly relations with him. In later years RMS and I > remained fairly close long after I broke up with that girlfriend. He > made passes at at least two of my later girlfriends that I know of, > including the woman I am still married to. In all cases, I trusted > these ladies to handle the situation like adults, and they did. It > really would not have occurred to me to do otherwise. > > I hear a lot of talk about RMS's behavior towards women being some sort > of vast horrible transgression that will drive all women everywhere to > flee from ever being contributors to FSF projects. To me this seems > just silly, and very infantilizing of women in general. My > girlfriends were emtirely able to > > (1) short-stop his advances when they became unwelcome > > (2) understand that some men have poor social skills and > trouble recognizing boundaries, > > (3) and *stay on friendly terms with him anyway*. > > I mean I saw this not just more than once, but every single time it > came up. > > I don't assume that any adult female is incapable of these things; I > respect women as fully capable of asserting and defending their > interests, I *expect* women to do that, and I thus consider a lot of the > white-knighting on their behalf to be at best empty virtue signaling > and at worst a cover for much more discreditable motives. > > Of course, he offends men too. When I deal with RMS, I know that I'm > going to have to cope with a certain amount of unpleasantness because > he has autism-like deficits amplified by some unfortunate personal > history. Yes. So what? He's one of my oldest friends anyway. He > has many admirable qualities; I respect and value him even when I have > to argue with him. And I can work with him when I need to. > > Why in the *hell* should I assume anyone with female genitalia is > incapable of doing the same?
Re: removing toxic emailers
On Fri, 16 Apr 2021, Frosku wrote: > Right now, the ultimate oversight of GCC sits with GNU & > FSF -- both institutions with a mandate to represent the ecosystem based > on level of membership and time spent fighting for free software. I think the oversight of glibc by development working through discussion seeking consensus, and rejecting any attempt to override such consensus "from above", is much more effective than any attempt GNU or FSF makes at oversight. An umbrella organization for the toolchain should not act as an "above" that can override the community at all; it should provide services to the toolchain (e.g. legal support) as needed. -- Joseph S. Myers jos...@codesourcery.com
[Bug tree-optimization/91470] [10/11 Regression] bogus uninitialized warning in trans-intrinsic.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470
Martin Sebor changed:
What|Removed |Added
Known to fail||10.2.0, 11.0
Last reconfirmed|2019-08-27 00:00:00 |2021-4-15
CC||msebor at gcc dot gnu.org
--- Comment #5 from Martin Sebor ---
Reconfirmed with GCC 11 and a reduced/corrected test case and slightly enhanced
output:
$ cat pr91470.c && gcc -O2 -S -Wall pr91470.c
int i1;
int* f1 (int);
void f2 (int, int);
void g2 (int, void *);
void f0 (void)
{
int *p;
for (int i = 0; i < 2; i++)
{
f2 (0, 0);
f2 (0, 0);
f2 (0, 0);
f2 (0, 0);
g2 (i1, 0);
if (i == 0)
p = f1 (0);
}
g2 (i1, p);
}
void f0 ()
{
int i;
int * p;
int i1.0_1;
int i1.1_2;
int _6;
[local count: 357878152]:
[local count: 715863673]:
# p_26 = PHI
# i_27 = PHI <_6(6), 0(2)>
# .MEM_28 = PHI <.MEM_25(6), .MEM_10(D)(2)>
# .MEM_12 = VDEF <.MEM_28>
f2 (0, 0);
# .MEM_13 = VDEF <.MEM_12>
f2 (0, 0);
# .MEM_14 = VDEF <.MEM_13>
f2 (0, 0);
# .MEM_15 = VDEF <.MEM_14>
f2 (0, 0);
# VUSE <.MEM_15>
i1.0_1 = i1;
# .MEM_16 = VDEF <.MEM_15>
g2 (i1.0_1, 0B);
_6 = i_27 + 1;
if (_6 == 1)
goto ; [21.69%]
else
goto ; [78.31%]
[local count: 155270830]:
# .MEM_17 = VDEF <.MEM_16>
p_18 = f1 (0);
goto ; [100.00%]
[local count: 560592843]:
if (_6 != 2)
goto ; [36.16%]
else
goto ; [63.84%]
[local count: 202714689]:
[local count: 357985519]:
# p_4 = PHI
# .MEM_25 = PHI <.MEM_16(8), .MEM_17(4)>
goto ; [100.00%]
[local count: 357878152]:
# VUSE <.MEM_16>
i1.1_2 = i1;
# .MEM_11 = VDEF <.MEM_16>
g2 (i1.1_2, p_26); [tail call]
# VUSE <.MEM_11>
return;
}
pr91470.c: In function ‘f0’:
pr91470.c:23:3: warning: ‘p’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
23 | g2 (i1, p);
| ^~
pr91470.c:9:8: note: used when ‘i + 1 != 1 && i + 1 != 2 || i + 1 != 1 && i + 1
== 2’
9 | int *p;
|^
pr91470.c:9:8: note: ‘p’ was declared here
Re: removing toxic emailers
On Fri Apr 16, 2021 at 12:52 AM BST, Eric S. Raymond wrote:
> Christopher Dimech via Gcc :
> > The commercial use of free software is our hope, not our fear. When people
> > at IBM began to come to free software, wanting to recommend it and use it,
> > and maybe distribute it themselves or encourage other people to distribute
> > it for them, we did not criticise them for not being non-profit virtuous
> > enough, or said "we are suspicious of you", let alone threatening them.
>
> Actually, some of us did *exactly* those things late in the last
> century.
>
> One of the challenges I faced in my early famous years was persuading
> the hacker culture as a whole to treat the profit-centered parts of the
> economy as allies rather than enemies.
>
> I won't say that a *majority* of us were resistent to this, but I
> did have to work hard on the problem for a while, between 1997
> and about 2003.
ESR,
My criticism has nothing to do with profit and everything to do with
accountability. GCC is a project which is used by almost everyone in the
ecosystem, and whose future direction is important to almost everyone in
the ecosystem. Right now, the ultimate oversight of GCC sits with GNU &
FSF -- both institutions with a mandate to represent the ecosystem based
on level of membership and time spent fighting for free software.
GCC forking away from those institutions removes that oversight, and
unless something which is equally or more representative is brought in to
replace that oversight role, I find it difficult to believe that this
doesn't represent a huge step backwards in terms of who ultimately has
an input into the future direction of GCC. It should be, at the very
minimum, challenging for representatives of Google, Red Hat and other
corporations to convince anyone -- after wrestling the project away from
GCC -- that their interests are not at odds with GCC users'.
I would say *exactly* the same thing if you replaced Google/Red Hat with
nonprofits which have less trust in free software than GNU/FSF.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
On Fri, 16 Apr 2021, Frosku wrote: > There is a colossal difference between commercial use and commercial > entities buying control of projects currently governed by entities > which are answerable to the grassroots (GNU) and then toppling that RMS's notion of GNU is as something under his personal direction and control, not answerable to the grassroots at all. For answerability to the grassroots, whatever organization the toolchain falls under, it's better for it to *explicitly* act only as an umbrella organization, serving the toolchain community rather than having any authority to direct it. -- Joseph S. Myers jos...@codesourcery.com
Re: removing toxic emailers
On Fri Apr 16, 2021 at 12:52 AM BST, Paul Koning wrote:
>
>
> > On Apr 15, 2021, at 7:44 PM, Frosku wrote:
> >
> > On Fri Apr 16, 2021 at 12:36 AM BST, Christopher Dimech wrote:
> >>
> >> The commercial use of free software is our hope, not our fear. When
> >> people
> >> at IBM began to come to free software, wanting to recommend it and use
> >> it,
> >> and maybe distribute it themselves or encourage other people to
> >> distribute
> >> it for them, we did not criticise them for not being non-profit virtuous
> >> enough, or said "we are suspicious of you", let alone threatening them.
> >>
> >
> > There is a colossal difference between commercial use and commercial
> > entities buying control of projects currently governed by entities
> > which are answerable to the grassroots (GNU) and then toppling that
> > governance structure in favor of one which is only answerable to
> > boardrooms in Silicon Valley and Seattle WA.
>
> There are, or would be if that were a real issue. It's not something
> that is feasible with GPL licensed code, whether the copyright is held
> by the FSF as it is for GCC, or by all the authors as for Linux.
>
> paul
Paul,
Short of maintaining the FSF branch of the fork, I don't see a way to
keep the project's direction accountable to end users.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
Christopher Dimech via Gcc : > The commercial use of free software is our hope, not our fear. When people > at IBM began to come to free software, wanting to recommend it and use it, > and maybe distribute it themselves or encourage other people to distribute > it for them, we did not criticise them for not being non-profit virtuous > enough, or said "we are suspicious of you", let alone threatening them. Actually, some of us did *exactly* those things late in the last century. One of the challenges I faced in my early famous years was persuading the hacker culture as a whole to treat the profit-centered parts of the economy as allies rather than enemies. I won't say that a *majority* of us were resistent to this, but I did have to work hard on the problem for a while, between 1997 and about 2003. -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: removing toxic emailers
> On Apr 15, 2021, at 7:44 PM, Frosku wrote: > > On Fri Apr 16, 2021 at 12:36 AM BST, Christopher Dimech wrote: >> >> The commercial use of free software is our hope, not our fear. When >> people >> at IBM began to come to free software, wanting to recommend it and use >> it, >> and maybe distribute it themselves or encourage other people to >> distribute >> it for them, we did not criticise them for not being non-profit virtuous >> enough, or said "we are suspicious of you", let alone threatening them. >> > > There is a colossal difference between commercial use and commercial > entities buying control of projects currently governed by entities > which are answerable to the grassroots (GNU) and then toppling that > governance structure in favor of one which is only answerable to > boardrooms in Silicon Valley and Seattle WA. There are, or would be if that were a real issue. It's not something that is feasible with GPL licensed code, whether the copyright is held by the FSF as it is for GCC, or by all the authors as for Linux. paul
Re: removing toxic emailers
On Fri Apr 16, 2021 at 12:36 AM BST, Christopher Dimech wrote:
>
> The commercial use of free software is our hope, not our fear. When
> people
> at IBM began to come to free software, wanting to recommend it and use
> it,
> and maybe distribute it themselves or encourage other people to
> distribute
> it for them, we did not criticise them for not being non-profit virtuous
> enough, or said "we are suspicious of you", let alone threatening them.
>
There is a colossal difference between commercial use and commercial
entities buying control of projects currently governed by entities
which are answerable to the grassroots (GNU) and then toppling that
governance structure in favor of one which is only answerable to
boardrooms in Silicon Valley and Seattle WA.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
> Sent: Friday, April 16, 2021 at 11:11 AM
> From: "Frosku"
> To: "Ian Lance Taylor" , chris.punc...@silogroup.org
> Cc: "GCC Development"
> Subject: Re: removing toxic emailers
>
> On Thu Apr 15, 2021 at 9:51 PM BST, Ian Lance Taylor via Gcc wrote:
> > On Thu, Apr 15, 2021 at 1:26 PM Chris Punches via Gcc
> > wrote:
> > >
> > > Every single proponent of this argument that I have seen so far is
> > > employed by one of the same 5 companies and "really isn't doing it on
> > > behalf of my company I swear".
> > >
> > > Why is it almost exclusively that specific crowd saying it here, then?
> >
> > For better or for worse, since the early '90s the majority of people
> > who do serious work on GCC have been hired by companies that want to
> > do serious work on GCC. After all, it's a win-win: the company gets
> > work done, the GCC programmer gets well paid. The effect is that most
> > of the major GCC contributors work for a relatively small number of
> > companies. There are of course many exceptions, but that is the
> > general rule.
> >
> > Ian
>
> In my view, if people employed by a small number of American companies
> succeed in disassociating GCC from GNU/FSF, which is representative of
> the free software grassroots community, this is not a win-win. This is
> powerful US corporations removing something our community created from
> our community's oversight and moving it into a space where it's governed
> by representatives of Silicon Valley rather than a membership-based non
> profit.
>
> Whilst everyone's contributions to the software should be welcomed, I
> don't think you'll find many FSF members celebrating the impact of paid
> Corporate engineers on GCC if this sorry state of affairs comes to be.
The commercial use of free software is our hope, not our fear. When people
at IBM began to come to free software, wanting to recommend it and use it,
and maybe distribute it themselves or encourage other people to distribute
it for them, we did not criticise them for not being non-profit virtuous
enough, or said "we are suspicious of you", let alone threatening them.
> >>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
>
Re: [PATCH v10] Practical improvement to libgcc complex divide
- ping [A sincere and special thanks for the sustained perseverance of the reviewers in pointing me in the proper direction to get this patch polished. The original proposal was June 1, 2020 and only covered double precision. The current version is dramatically better, both from extending coverage to most precisions, improving the computation for accuracy and speed, and from improving the code maintainability. - Patrick McGehearty] On 4/7/2021 3:21 PM, Patrick McGehearty via Gcc-patches wrote: Changes in this version from Version 9: Replaced all uses of alloca with XALLOCAVEC in c_cpp_builtins() in c-cppbuiltin.c Did not replace alloca elsewhere in the same file. Fixed type of name_len. Fixed prototypes for abort & exit in new test programs. Fixed spelling errors and omitted words in comments. Changed XMTYPE to AMTYPE to avoid confusion with extended types. Removed XCTYPE as unused. (A for additional) Correctness and performance test programs used during development of this project may be found in the attachment to: https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg254210.html Summary of Purpose This patch to libgcc/libgcc2.c __divdc3 provides an opportunity to gain important improvements to the quality of answers for the default complex divide routine (half, float, double, extended, long double precisions) when dealing with very large or very small exponents. The current code correctly implements Smith's method (1962) [2] further modified by c99's requirements for dealing with NaN (not a number) results. When working with input values where the exponents are greater than *_MAX_EXP/2 or less than -(*_MAX_EXP)/2, results are substantially different from the answers provided by quad precision more than 1% of the time. This error rate may be unacceptable for many applications that cannot a priori restrict their computations to the safe range. The proposed method reduces the frequency of "substantially different" answers by more than 99% for double precision at a modest cost of performance. Differences between current gcc methods and the new method will be described. Then accuracy and performance differences will be discussed. Background This project started with an investigation related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714. Study of Beebe[1] provided an overview of past and recent practice for computing complex divide. The current glibc implementation is based on Robert Smith's algorithm [2] from 1962. A google search found the paper by Baudin and Smith [3] (same Robert Smith) published in 2012. Elen Kalda's proposed patch [4] is based on that paper. I developed two sets of test data by randomly distributing values over a restricted range and the full range of input values. The current complex divide handled the restricted range well enough, but failed on the full range more than 1% of the time. Baudin and Smith's primary test for "ratio" equals zero reduced the cases with 16 or more error bits by a factor of 5, but still left too many flawed answers. Adding debug print out to cases with substantial errors allowed me to see the intermediate calculations for test values that failed. I noted that for many of the failures, "ratio" was a subnormal. Changing the "ratio" test from check for zero to check for subnormal reduced the 16 bit error rate by another factor of 12. This single modified test provides the greatest benefit for the least cost, but the percentage of cases with greater than 16 bit errors (double precision data) is still greater than 0.027% (2.7 in 10,000). Continued examination of remaining errors and their intermediate computations led to the various tests of input value tests and scaling to avoid under/overflow. The current patch does not handle some of the rare and most extreme combinations of input values, but the random test data is only showing 1 case in 10 million that has an error of greater than 12 bits. That case has 18 bits of error and is due to subtraction cancellation. These results are significantly better than the results reported by Baudin and Smith. Support for half, float, double, extended, and long double precision is included as all are handled with suitable preprocessor symbols in a single source routine. Since half precision is computed with float precision as per current libgcc practice, the enhanced algorithm provides no benefit for half precision and would cost performance. Further investigation showed changing the half precision algorithm to use the simple formula (real=a*c+b*d imag=b*c-a*d) caused no loss of precision and modest improvement in performance. The existing constants for each precision: float: FLT_MAX, FLT_MIN; double: DBL_MAX, DBL_MIN; extended and/or long double: LDBL_MAX, LDBL_MIN are used for avoiding the more common overflow/underflow cases. This use is made generic by defining appropriate __LIBGCC2_* macros in c-cppbuiltin.c. Tests are added for when both parts of the denominator have exponents small enough
Re: removing toxic emailers
David Malcolm : > > I will, however, point out that it is a very *different* point from > > "RMS has iupset some people and should therefore be canceled". > > Eric: I don't know if you're just being glib, or you're deliberately > trying to caricature those of us who are upset by RMS's behavior. My intent was not caricature. I was being dismissive and snarky because I genuinely consider the personality complaints against RMS to be pretty trivial. Not the managerial ones Joseph Myers listed; those are serious. But they're not the cause of the current ruckus. To make the "triviality" point in the most forceful possible way, I will take the bull by the horns and directly address RMS's behavior towards women. And I will reveal a few things that I haven't talked about in public for 40 years. I've known RMS since 1979; I'm fully aware of how obnoxious he can be towards both men and women. There have been occasions on which I have thought the state of the universe would have been improved if he'd gotten a swift slap in the face. In fact, the first or second time I met him face to face it was because he was rather determinedly pursuing my then-girlfriend. A hostile witness might have said he was creeping on her, though that slang for it wouldn't be invented until much later. I think an explanation of how how I reasoned about that situation has some value in light of the current attempt to ostracize RMS. I paid very careful attention to whether my girlfriend appeared to need any help dealing with him. I regarded her as an adult fully capable of making her own decisions. One of those decisions could have been to slap his face. If a more severe sanction had been required, and she had yelled for help, I would cheerfully have punched his lights out. No fisticuffs were required. She gently discouraged him, and we both established friendly relations with him. In later years RMS and I remained fairly close long after I broke up with that girlfriend. He made passes at at least two of my later girlfriends that I know of, including the woman I am still married to. In all cases, I trusted these ladies to handle the situation like adults, and they did. It really would not have occurred to me to do otherwise. I hear a lot of talk about RMS's behavior towards women being some sort of vast horrible transgression that will drive all women everywhere to flee from ever being contributors to FSF projects. To me this seems just silly, and very infantilizing of women in general. My girlfriends were emtirely able to (1) short-stop his advances when they became unwelcome (2) understand that some men have poor social skills and trouble recognizing boundaries, (3) and *stay on friendly terms with him anyway*. I mean I saw this not just more than once, but every single time it came up. I don't assume that any adult female is incapable of these things; I respect women as fully capable of asserting and defending their interests, I *expect* women to do that, and I thus consider a lot of the white-knighting on their behalf to be at best empty virtue signaling and at worst a cover for much more discreditable motives. Of course, he offends men too. When I deal with RMS, I know that I'm going to have to cope with a certain amount of unpleasantness because he has autism-like deficits amplified by some unfortunate personal history. Yes. So what? He's one of my oldest friends anyway. He has many admirable qualities; I respect and value him even when I have to argue with him. And I can work with him when I need to. Why in the *hell* should I assume anyone with female genitalia is incapable of doing the same? More to the point, why is anybody else making such a silly, reductive assumption and then turning it into a galloping moral panic that somehow justifies stoning RMS and driving him out of the village? *grumble* Get *over* yourselves. You want to be "welcoming" to women? Don't patronize or infantilize them - respect their ability to tell off RMS for themselves *and then keep working with him*! -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: removing toxic emailers
On Thu, Apr 15, 2021 at 6:30 PM David Malcolm via Gcc wrote: > On Thu, 2021-04-15 at 16:26 -0400, Chris Punches wrote: > > What I see here in sum is another high level tightly integrated Red > > Hat > > employee saying the gist of "I'm really not saying it out of my > > employer's interest and it has nothing to do with my personal > > feelings". > > I'm not sure I'm "high level", but I guess I'll take that as a > compliment. > > I stated that the opinions in my screed were my own, but I'm a former > FLOSS enthusiast in the fortunate position of being paid to work on > GCC. I've tried to be open about my biases. Then let me offer my perspective, again. I am not affiliated with RedHat, IBM, or what have you. I do not work for them, never have worked for them, and have contributed to the C, C++, and other Systems Programming communities entirely out-of-pocket or through scholarship and donation. I submitted my Copyright Revocation to the Free Software Foundation after giving the greenlight to merge the last of my already-submitted patches into GCC. Stallman is an exceptionally poor leader for Free Software. We routinely complain about LLVM here but Stallman had the chance to get on top of LLVM and guide it into the Free Software world; he missed the e-mail and "found" it 10 years later. Stallman was horrible to the people employed by the Free Software Foundation and apparently the board was barely able to keep him in check, resulting in his employees needing to have Shop Stewards with a Union in order to keep it workable for employees. Stallman is terrible at his job, and this group's inability to have a secondary or tertiary copyright assignment has cost them my contributions for the foreseeable future. Stallman's defenders are ableist, because Stallman himself - in the FSF book and more - have publicly stated that he is not autistic or neurodivergent. Stallman has also stated this publicly, but the fact that Bruce Perens, Eric S. Raymond, and more feel the need to show up and claim on behalf of all Neuroatypical people and Neurodivergent people that they are fighting for us while pushing a disgusting, ableist theory that "Neurodivergent == Definitely An Asshole And Needs To Be Deprived Of Agency For Their Actions" is disgusting. That people feel the need to stereotype neurodivergent people like me for the sake of Stallman's defense is horrible. That people would stand by and claim this is some kind of great advocacy for someone like me is a series of mental gymnastics I do not want to be apart of. This place is fetid, and contrary to Raymond's idea that toxicity has no cost, it most certainly did cost it myself and many other people like me. Sincerely, JeanHeyd
[Bug tree-optimization/99971] GCC generates partially vectorized and scalar code at once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99971 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #7 from Dávid Bolvanský --- Still bad for -O3 -march=skylake-avx512 https://godbolt.org/z/azb8aTG43
Re: removing toxic emailers
On Thu Apr 15, 2021 at 9:51 PM BST, Ian Lance Taylor via Gcc wrote:
> On Thu, Apr 15, 2021 at 1:26 PM Chris Punches via Gcc
> wrote:
> >
> > Every single proponent of this argument that I have seen so far is
> > employed by one of the same 5 companies and "really isn't doing it on
> > behalf of my company I swear".
> >
> > Why is it almost exclusively that specific crowd saying it here, then?
>
> For better or for worse, since the early '90s the majority of people
> who do serious work on GCC have been hired by companies that want to
> do serious work on GCC. After all, it's a win-win: the company gets
> work done, the GCC programmer gets well paid. The effect is that most
> of the major GCC contributors work for a relatively small number of
> companies. There are of course many exceptions, but that is the
> general rule.
>
> Ian
In my view, if people employed by a small number of American companies
succeed in disassociating GCC from GNU/FSF, which is representative of
the free software grassroots community, this is not a win-win. This is
powerful US corporations removing something our community created from
our community's oversight and moving it into a space where it's governed
by representatives of Silicon Valley rather than a membership-based non
profit.
Whilst everyone's contributions to the software should be welcomed, I
don't think you'll find many FSF members celebrating the impact of paid
Corporate engineers on GCC if this sorry state of affairs comes to be.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
[Bug middle-end/86172] [meta-bug] issues with -Wnull-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172 Bug 86172 depends on bug 89202, which changed state. Bug 89202 Summary: missing -Wnonnull-dereference or -Wuninitialized for a certain bug (CCP) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89202 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/18501] [8/9/10/11 Regression] Missing 'used uninitialized' warning (CCP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 --- Comment #96 from Martin Sebor --- *** Bug 89202 has been marked as a duplicate of this bug. ***
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 89202, which changed state. Bug 89202 Summary: missing -Wnonnull-dereference or -Wuninitialized for a certain bug (CCP) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89202 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/89202] missing -Wnonnull-dereference or -Wuninitialized for a certain bug (CCP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89202 Martin Sebor changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Martin Sebor --- Agreed, it's dupe of pr18501. -Wnull-dereference would benefit from the same predicate analysis as -Wmaybe-uninitialized. *** This bug has been marked as a duplicate of bug 18501 ***
[Bug middle-end/90844] missing -Wmaybe-uninitialized with -flto and optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90844
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Summary|Another case of missing use |missing
|of uninitialized variable |-Wmaybe-uninitialized with
|warning (inlining, CCP) |-flto and optimization
Last reconfirmed|2019-06-12 00:00:00 |2021-4-15
Known to fail||10.2.0, 11.0, 8.3.0, 9.3.0
--- Comment #3 from Martin Sebor ---
The late uninit pass doesn't run with -flto; all that runs is the early
uninitialized pass and it disables the "conditional" -Wmaybe-uninitialized when
optimization is enabled:
static unsigned int
execute_early_warn_uninitialized (void)
{
/* Currently, this pass runs always but
execute_late_warn_uninitialized only runs with optimization. With
optimization we want to warn about possible uninitialized as late
as possible, thus don't do it here. However, without
optimization we need to warn here about "may be uninitialized". */
calculate_dominance_info (CDI_POST_DOMINATORS);
warn_uninitialized_vars (/*warn_maybe_uninitialized=*/!optimize);
^
Changing that like so lets the warning do its thing even with -flto:
@@ -3086,7 +3079,8 @@ execute_early_warn_uninitialized (void)
optimization we need to warn here about "may be uninitialized". */
calculate_dominance_info (CDI_POST_DOMINATORS);
- warn_uninitialized_vars (/*warn_maybe_uninitialized=*/!optimize);
+ bool wmaybe_uninit = !optimize || flag_lto;
+ warn_uninitialized_vars (wmaybe_uninit);
/* Post-dominator information cannot be reliably updated. Free it
after the use. */
Re: removing toxic emailers
On Thu Apr 15, 2021 at 3:40 PM BST, Eric S. Raymond wrote:
> I intended the weaker observation that driving away a large number of
> smart autistic assholes (and non-assholes with poor social skills)
> is not necessarily a good trade for the people the project might
> recruit by being "more welcoming".
>
> Possibly that *would* be a good trade. I have decades of experience
> that makes me doubt this. I think the claim needs to be examined
> skeptically, not just uncritically accepted because we value being
> "nice".
I'm not even sure that this only applies to autists, over the years
I've had various interactions where I've thought someone was being
an asshole but it turned out English wasn't their first language and
they just lacked the depth of vocabulary to express a point politely.
There are also huge disparities in what cultures deem to be polite vs
impolite (high context vs low context cultures, cultural sensitivities
to particular phrases or concepts, etc). I remain unconvinced that
trying to define 'jerks' by a narrow-minded west coast American ideal
and enforce that on a global community is not, itself, jerkish.
More often than not, strict speech codes just encourage people to
assume bad faith of each other, and to tone police each other instead
of engaging in substantive debate on the issues. I also cannot remember
ever seeing one enforced equally against everyone, rather than become
a tool of an entrenched majority culture against a minority culture.
I have yet to see a project where a strict speech code has improved the
dialectic, rather than degraded it.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
On 4/15/2021 2:26 PM, Chris Punches via Gcc wrote: What I see here in sum is another high level tightly integrated Red Hat employee saying the gist of "I'm really not saying it out of my employer's interest and it has nothing to do with my personal feelings". Every single proponent of this argument that I have seen so far is employed by one of the same 5 companies and "really isn't doing it on behalf of my company I swear". Why is it almost exclusively that specific crowd saying it here, then? I just don't buy it. Please say anything that would not support the emerging theory that these companies are using integrated employees to try to emulate justification/pretext for a rift to attack the free software world. Anything at all. [ Again, speaking or myself, not my employer or for the steering committee. ] So first, my employer (Tachyum) has had absolutely no clue what's going on with this discussion until yesterday afternoon when I mentioned it in passing. We're much more focused on getting our bits where they need to be rather than policy, procedures and politics of the upstream projects. However they have repeatedly, up to the CEO level emphasized that upstreaming our work and being good players in the various relevant communities is important and the various concerns I raised around that prior to joining were answered to my satisfaction. Second, I was the technical lead for Red Hat's tools team until about a month ago. I've also held management positions in Red Hat (and Cygnus prior to the acquisition) during my 25+ year career there. Red Hat and Cygnus have consistently worked through the years to be good stewards for the GNU tools. Management has consistently had a hands-off approach to the upstream community, allowing engineers to exercise their own judgment on if when and how to engage in various discussions. The only time management got involved in these kinds of discussions was to throw support behind EGCS -- including being supportive of bringing in outside advisors for what ultimately became the steering committee. You may not buy it, but that's OK. That's ultimately your decision to make. I do buy it. It's consistent with what I've seen over nearly three decades of dealing with GNU tools and what I've *directly observed* as part of the leadership and management teams. Jeff
gcc-8-20210415 is now available
Snapshot gcc-8-20210415 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20210415/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 revision 76b6aa67489132e725af34f14938e9d8d6ef4a67 You'll find: gcc-8-20210415.tar.xzComplete GCC SHA256=d391b3d3c4dff9933b32db5366a1a6ca3e0f575970a267e9b2202139799d3d0b SHA1=5da5b1afb5d8cb706a8403623c21b8bd1a6c41f5 Diffs from 8-20210408 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 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: removing toxic emailers
On Thu, 15 Apr 2021 at 21:26, Chris Punches via Gcc wrote: > > What I see here in sum is another high level tightly integrated Red Hat > employee saying the gist of "I'm really not saying it out of my > employer's interest and it has nothing to do with my personal > feelings". > > Every single proponent of this argument that I have seen so far is > employed by one of the same 5 companies and "really isn't doing it on > behalf of my company I swear". > > Why is it almost exclusively that specific crowd saying it here, then? > > I just don't buy it. Please say anything that would not support the > emerging theory that these companies are using integrated employees to > try to emulate justification/pretext for a rift to attack the free > software world. Anything at all. > One reason you might be seeing this is people who (a) are not paid to work on GCC, and (b) found RMS and parts of the GNU community unpleasant to work with, left years ago. Chris
Re: [PATCH] c++: Fix up handling of structured bindings in extract_locals_r [PR99833]
On 4/14/21 3:10 PM, Jakub Jelinek wrote:
Hi!
The following testcase ICEs in tsubst_decomp_names because the assumptions
that the structured binding artificial var is followed in DECL_CHAIN by
the corresponding structured binding vars is violated.
I've tracked it to extract_locals* which is done for the constexpr
IF_STMT. extract_locals_r when it sees a DECL_EXPR adds that decl
into a hash set so that such decls aren't returned from extract_locals*,
but in the case of a structured binding that just means the artificial var
and not the vars corresponding to structured binding identifiers.
The following patch fixes it by pushing not just the artificial var
for structured bindings but also the other vars.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
2021-04-14 Jakub Jelinek
PR c++/99833
* pt.c (extract_locals_r): When handling DECL_EXPR of a structured
binding, add to data.internal also all corresponding structured
binding decls.
* g++.dg/cpp1z/pr99833.C: New test.
* g++.dg/cpp2a/pr99833.C: New test.
--- gcc/cp/pt.c.jj 2021-04-14 10:48:41.322103670 +0200
+++ gcc/cp/pt.c 2021-04-14 12:52:53.116896754 +0200
@@ -12811,7 +12811,27 @@ extract_locals_r (tree *tp, int */*walk_
tp = _NAME (*tp);
if (TREE_CODE (*tp) == DECL_EXPR)
-data.internal.add (DECL_EXPR_DECL (*tp));
+{
+ tree decl = DECL_EXPR_DECL (*tp);
+ data.internal.add (decl);
+ if (VAR_P (decl)
+ && DECL_DECOMPOSITION_P (decl)
+ && TREE_TYPE (decl) != error_mark_node)
+ {
+ gcc_assert (DECL_NAME (decl) == NULL_TREE);
+ for (tree decl2 = DECL_CHAIN (decl);
+ decl2
+ && VAR_P (decl2)
+ && DECL_DECOMPOSITION_P (decl2)
+ && DECL_NAME (decl2)
+ && TREE_TYPE (decl2) != error_mark_node;
+ decl2 = DECL_CHAIN (decl2))
+ {
+ gcc_assert (DECL_DECOMP_BASE (decl2) == decl);
+ data.internal.add (decl2);
+ }
+ }
+}
else if (TREE_CODE (*tp) == LAMBDA_EXPR)
{
/* Since we defer implicit capture, look in the parms and body. */
--- gcc/testsuite/g++.dg/cpp1z/pr99833.C.jj 2021-04-14 13:03:14.654879632
+0200
+++ gcc/testsuite/g++.dg/cpp1z/pr99833.C2021-04-14 13:03:39.599598004
+0200
@@ -0,0 +1,11 @@
+// PR c++/99833
+// { dg-do compile { target c++17 } }
+
+struct S { int a, b; };
+template
+void
+foo ()
+{
+ [](auto d) { if constexpr (auto [a, b]{d}; sizeof (a) > 0) a++; } (S{});
+}
+template void foo ();
--- gcc/testsuite/g++.dg/cpp2a/pr99833.C.jj 2021-04-14 13:04:08.975266383
+0200
+++ gcc/testsuite/g++.dg/cpp2a/pr99833.C2021-04-14 13:04:23.191105881
+0200
@@ -0,0 +1,18 @@
+// PR c++/99833
+// { dg-do compile { target c++20 } }
+
+#include
+
+auto f(auto&& x)
+{
+ [&](auto...) {
+auto y = std::tuple{ "what's happening here?", x };
+if constexpr (auto [_, z] = y; requires { z; })
+ return;
+ }();
+}
+
+int main()
+{
+ f(42);
+}
Jakub
[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 Bug 89180 depends on bug 99972, which changed state. Bug 99972 Summary: missing -Wunused-result on a call to a locally redeclared warn_unused_result function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99972 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/99972] missing -Wunused-result on a call to a locally redeclared warn_unused_result function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99972 Martin Sebor changed: What|Removed |Added Target Milestone|--- |11.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Sebor --- Fix committed in r11-8205.
[Bug c/99420] [11 Regression] bogus -Warray-parameter on a function redeclaration in function scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99420 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Martin Sebor --- Fix committed in r11-8205.
[Bug c/99420] [11 Regression] bogus -Warray-parameter on a function redeclaration in function scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99420 --- Comment #7 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:da879e01ecd35737c18be1da3324f4560aba1961 commit r11-8205-gda879e01ecd35737c18be1da3324f4560aba1961 Author: Martin Sebor Date: Thu Apr 15 15:49:30 2021 -0600 Propagate type attribute when merging extern declarations at local scope. Resolves: PR c/99420 - bogus -Warray-parameter on a function redeclaration in function scope PR c/99972 - missing -Wunused-result on a call to a locally redeclared warn_unused_result function gcc/c/ChangeLog: PR c/99420 PR c/99972 * c-decl.c (pushdecl): Always propagate type attribute. gcc/testsuite/ChangeLog: PR c/99420 PR c/99972 * gcc.dg/Warray-parameter-9.c: New test. * gcc.dg/Wnonnull-6.c: New test. * gcc.dg/Wreturn-type3.c: New test. * gcc.dg/Wunused-result.c: New test. * gcc.dg/attr-noreturn.c: New test. * gcc.dg/attr-returns-nonnull.c: New test.
[Bug c/99972] missing -Wunused-result on a call to a locally redeclared warn_unused_result function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99972 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:da879e01ecd35737c18be1da3324f4560aba1961 commit r11-8205-gda879e01ecd35737c18be1da3324f4560aba1961 Author: Martin Sebor Date: Thu Apr 15 15:49:30 2021 -0600 Propagate type attribute when merging extern declarations at local scope. Resolves: PR c/99420 - bogus -Warray-parameter on a function redeclaration in function scope PR c/99972 - missing -Wunused-result on a call to a locally redeclared warn_unused_result function gcc/c/ChangeLog: PR c/99420 PR c/99972 * c-decl.c (pushdecl): Always propagate type attribute. gcc/testsuite/ChangeLog: PR c/99420 PR c/99972 * gcc.dg/Warray-parameter-9.c: New test. * gcc.dg/Wnonnull-6.c: New test. * gcc.dg/Wreturn-type3.c: New test. * gcc.dg/Wunused-result.c: New test. * gcc.dg/attr-noreturn.c: New test. * gcc.dg/attr-returns-nonnull.c: New test.
Re: Gcc as callable libraries (was: removing toxic emailers)
On Thu, 2021-04-15 at 17:31 -0400, David Malcolm via Gcc wrote: > On Thu, 2021-04-15 at 21:48 +0200, Thomas Koenig wrote: [...snip...] > > > Perhaps a pronouncement like: "try to make everything be > > consumable as > > > libraries with APIs, as well as as standalone binaries" might > > have > > > helped (and still could; can we do that please?) > > > > That makes perfect sense, as LLVM shows, and is something that the > > steering committee could decide for the project (or rather, it > > could > > issue a pronouncement that this will not be opposed if some > > volunteer > > does it). > > > > I think this could be as close to an unanimous decision as there > > can > > be among such a diverse community as the gcc developers. If the > > FSF > > takes umbrage at this, the ball is in their court. > > I deliberately added the weasel-words "try to", because these things > are, of course, much easier said that done. > > I attempted to reduce gcc's use of global state back in 2013 with a > view to making it a shared library, but eventually the sheer size of > the task overwhelmed me. In libgccjit I hid everything behind a > separate API, with a bug mutex guarding all of gcc's global state, ~~~ big, I meant to write. > which feels like something of a cop-out. libgccjit calls into as and ld, which shows up in the profile, so another idea I dabbled in the whole "libraries rather than just executables" area is to make as and ld buildable as shared libraries; hence this 2015 experiment: "[PATCH 00/16] RFC: Embedding as and ld inside gcc driver and into libgccjit" crossposted between gcc-patches and binutils here: https://gcc.gnu.org/legacy-ml/gcc-patches/2015-06/msg00116.html https://sourceware.org/legacy-ml/binutils/2015-06/msg00010.html (admittedly my prototype had a barely-existent API, but it gave me a 5x speedup on a synthetic benchmark, which was dominated by the overhead of dynamically linking libbfd into as and ld on each invocation IIRC; better to do it once when libgccjit is linked into the process). > > One idea I had would be to refactor out our diagnostics code into a > libdiagnostics (or similar), so that all of the source- > printing/underlining/fix-it logic etc could be used outside of gcc, and > the use of diagnostic_context might help towards that. But even "just" > that's decidedly non-trivial. > > Hope this is constructive > Dave > >
[Bug middle-end/85563] [8/9/10/11 regression] -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
Martin Sebor changed:
What|Removed |Added
Keywords||missed-optimization
Last reconfirmed|2018-04-30 00:00:00 |2021-4-15
CC||msebor at gcc dot gnu.org
Known to fail|8.0.1 |10.2.0, 11.0, 8.3.0, 9.3.0
--- Comment #18 from Martin Sebor ---
Reconfirming with GCC 11.
Inverting the reachability expression:
((CONSP (Vframe_list)) ? (void) 0 : __builtin_unreachable ());
to
(!(CONSP (Vframe_list)) ? __builtin_unreachable () : (void) 0);
or changing it to a corresponding if statement avoids the warning and improves
the emitted code, implying there is a missed optimization opportunity there
somewhere.
I also reduced the test from comment #6 a bit further to make it easier to
read:
struct A
{
struct A *p, *q;
};
extern void *p;
inline _Bool
f (void* a)
{
return ((__INTPTR_TYPE__) (a) & ~(- (1 << 3))) == 3;
}
inline struct A *
g (void* a)
{
return (struct A *)((char *)a - 3);
}
extern void* foo (void*);
void bar (void)
{
#if NOWARN
if (!f (p))
__builtin_unreachable ();
#else
f (p) ? (void)0 : __builtin_unreachable ();
#endif
void* q;
for (void *r = p; f (r) && ((q = g (r)->p), 1); r = g (r)->q)
;
foo (q);
}
Re: Gcc as callable libraries (was: removing toxic emailers)
On Thu, 2021-04-15 at 21:48 +0200, Thomas Koenig wrote: > David, > > for some reason or other, I did not get your mail, so I will > just reply copying in from the archive. > > First, thanks for injecting some sanity into the discussion. Thanks Thomas > I will not discuss RMS' personal shortcomings or the lack of them. > In today's toxic political climate, such allegations are often > made up and weaponized without an effective defense for the > alleged wrongdoer. I don't know the truth of the matter, and I make > a point of not finding out. Fair enough. > > In many ways the last 8 years of my career have been > > an attempt to get gcc to respond to the appearance of LLVM/clang > (I've > > added JIT-compilation, improved diagnostics, and I'm implementing > a > > static analysis pass) > > And this is highly welcome, and has made gcc (including gfortran) a > much > better compiler. I well remember how you implemented the much better > colored error messages that gfortran has now. I've added a bunch of features to the C and C++ frontends (underlined ranges, labelling of such reanges, fix-it hints, etc), but I don't have the Fortran skills to know what would be appropriate to gfortran. Let me know if you have ideas for specific improvements to how gfortran diagnostics work that I might be able to help implement. > > > Perhaps a pronouncement like: "try to make everything be > consumable as > > libraries with APIs, as well as as standalone binaries" might have > > helped (and still could; can we do that please?) > > That makes perfect sense, as LLVM shows, and is something that the > steering committee could decide for the project (or rather, it could > issue a pronouncement that this will not be opposed if some volunteer > does it). > > I think this could be as close to an unanimous decision as there can > be among such a diverse community as the gcc developers. If the FSF > takes umbrage at this, the ball is in their court. I deliberately added the weasel-words "try to", because these things are, of course, much easier said that done. I attempted to reduce gcc's use of global state back in 2013 with a view to making it a shared library, but eventually the sheer size of the task overwhelmed me. In libgccjit I hid everything behind a separate API, with a bug mutex guarding all of gcc's global state, which feels like something of a cop-out. One idea I had would be to refactor out our diagnostics code into a libdiagnostics (or similar), so that all of the source- printing/underlining/fix-it logic etc could be used outside of gcc, and the use of diagnostic_context might help towards that. But even "just" that's decidedly non-trivial. Hope this is constructive Dave
Re: Gcc as callable libraries (was: removing toxic emailers)
On Thu, Apr 15, 2021 at 5:04 PM Thomas Koenig via Gcc wrote: > > David, > > for some reason or other, I did not get your mail, so I will > just reply copying in from the archive. > > First, thanks for injecting some sanity into the discussion. > > I will not discuss RMS' personal shortcomings or the lack of them. > In today's toxic political climate, such allegations are often > made up and weaponized without an effective defense for the > alleged wrongdoer. I don't know the truth of the matter, and I make > a point of not finding out. > > > In many ways the last 8 years of my career have been > > an attempt to get gcc to respond to the appearance of LLVM/clang (I've > > added JIT-compilation, improved diagnostics, and I'm implementing a > > static analysis pass) > > And this is highly welcome, and has made gcc (including gfortran) a much > better compiler. I well remember how you implemented the much better > colored error messages that gfortran has now. > > > Perhaps a pronouncement like: "try to make everything be consumable as > > libraries with APIs, as well as as standalone binaries" might have > > helped (and still could; can we do that please?) > > That makes perfect sense, as LLVM shows, and is something that the > steering committee could decide for the project (or rather, it could > issue a pronouncement that this will not be opposed if some volunteer > does it). > > I think this could be as close to an unanimous decision as there can > be among such a diverse community as the gcc developers. If the FSF > takes umbrage at this, the ball is in their court. Andrew Macleod led a BOF at GNU Cauldron 2013 that discussed re-architecting and modularizing GCC along these same lines. The header flattening was one step. Thanks, David
Re: removing toxic emailers
On Thu, 2021-04-15 at 16:26 -0400, Chris Punches wrote: > What I see here in sum is another high level tightly integrated Red > Hat > employee saying the gist of "I'm really not saying it out of my > employer's interest and it has nothing to do with my personal > feelings". I'm not sure I'm "high level", but I guess I'll take that as a compliment. I stated that the opinions in my screed were my own, but I'm a former FLOSS enthusiast in the fortunate position of being paid to work on GCC. I've tried to be open about my biases. > > Every single proponent of this argument that I have seen so far is > employed by one of the same 5 companies and "really isn't doing it on > behalf of my company I swear". > > Why is it almost exclusively that specific crowd saying it here, > then? Because, sadly, there's only a small group of companies that employ GCC developers. These developers tend to have an emotional attachment to the project (e.g. a broad agreement with the professed goals of the FSF). Part of the reason I work at Red Hat is that its own internal culture aligns with mine, much of the time, anyway (and I know we're not perfect). Hence there's some correlation between those with strong opinions on the project and those who are being paid to work on it. I don't see that as malicious or a conspiracy - just that we, reasonably, care about the work we do and its context. It's not necessarily just a job for me. > > I just don't buy it. Please say anything that would not support the > emerging theory that these companies are using integrated employees > to > try to emulate justification/pretext for a rift to attack the free > software world. Anything at all. I hope I just did. Dave
Re: removing toxic emailers
> Sent: Friday, April 16, 2021 at 8:51 AM > From: "Ian Lance Taylor via Gcc" > To: chris.punc...@silogroup.org > Cc: "GCC Development" > Subject: Re: removing toxic emailers > > On Thu, Apr 15, 2021 at 1:26 PM Chris Punches via Gcc wrote: > > > > Every single proponent of this argument that I have seen so far is > > employed by one of the same 5 companies and "really isn't doing it on > > behalf of my company I swear". > > > > Why is it almost exclusively that specific crowd saying it here, then? > > For better or for worse, since the early '90s the majority of people > who do serious work on GCC have been hired by companies that want to > do serious work on GCC. After all, it's a win-win: the company gets > work done, the GCC programmer gets well paid. The effect is that most > of the major GCC contributors work for a relatively small number of > companies. There are of course many exceptions, but that is the > general rule. > > Ian Such contributions are valued, and companies where talent is allowed to flow towards the public is commendable, even for those with a history of exploitation. Many of us pay their taxes, not because we see crowds of people sent to jail. But because spontaneous compliance is the way for things to work. That's what I hope for.
[Bug target/100106] [10/11 Regression] ICE in gen_movdi, at config/arm/arm.md:6187 since r10-2840-g70cdb21e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100106 Alex Coplan changed: What|Removed |Added Target||arm Keywords||ice-on-valid-code Known to fail||10.2.1, 11.0 Target Milestone|--- |10.4 Known to work||9.2.1
[Bug target/100106] New: [10/11 Regression] ICE in gen_movdi, at config/arm/arm.md:6187 since r10-2840-g70cdb21e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100106
Bug ID: 100106
Summary: [10/11 Regression] ICE in gen_movdi, at
config/arm/arm.md:6187 since r10-2840-g70cdb21e
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat test.c
union a {
float _Complex b;
long long c;
};
void g(union a);
void e() {
union a f = {1.0f};
g(f);
}
$ gcc/xgcc -B gcc test.c -c -O
during RTL pass: expand
test.c: In function ‘e’:
test.c:9:11: internal compiler error: in gen_movdi, at config/arm/arm.md:6187
9 | union a f = {1.0f};
| ^
0x1de9e64 gen_movdi(rtx_def*, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/config/arm/arm.md:6187
0xdb9086 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
/home/alecop01/toolchain/src/gcc/gcc/recog.h:407
0xd8ff58 emit_move_insn_1(rtx_def*, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:3766
0xd909ca emit_move_insn(rtx_def*, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:3936
0xd69cbb store_bit_field_1
/home/alecop01/toolchain/src/gcc/gcc/expmed.c:804
0xd6b8bb store_bit_field(rtx_def*, poly_int<1u, unsigned long>, poly_int<1u,
unsigned long>, poly_int<1u, unsigned long>, poly_int<1u, unsigned long>,
machine_mode, rtx_def*, bool)
/home/alecop01/toolchain/src/gcc/gcc/expmed.c:1183
0xd9eaef store_field
/home/alecop01/toolchain/src/gcc/gcc/expr.c:7353
0xd95ddf expand_assignment(tree_node*, tree_node*, bool)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:5482
0xbf2c4e expand_gimple_stmt_1
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:3910
0xbf303d expand_gimple_stmt
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:4008
0xbfbaa3 expand_gimple_basic_block
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:6045
0xbfd954 execute
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:6729
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
Re: removing toxic emailers
> >> === > >> > >> So .. in summary: > >> > >> 1/ I propose that we do have written guidelines, to which someone behaving > >> in a > >> non-constructive manner can be pointed. > >> > >> 2/ if those guidelines *are the consensus* of this group and someone is > >> unable to > >> follow them (given some reasonable chance to amend as is customary in > >> matters > >> such as employment law here, at least), then they are treated no > >> differently from > >> any other spam. > > > > Proposing the guidelines essentially means that the community accepts the > > fact > > that many of us are incapable of navigate everyday problems and dilemmas > > by making > > “right” decisions based on the use of good judgment and values rather > > than sterile > > sets of rules and conventions that typically disregard the individual, > > the particular, > > or the discrete. > > However, that isn’t what I wrote - what I wrote was the opposite; that > history shows > that almost everyone communicating on these lists can do so constructively > *without* > recourse to written guidelines. > > It is not the general case that has precipitated this discussion but, > rather, the exceptional. There have been many discussions emanating from Nathan's messages, that toxity is endemic. I disagree with that in practice as you do. But there are some discussions that potentially lead to the opposite. I feel that when the issues at hand produce a series of contrasting views that are significant. taking a guideline approach could result > > Thusly, it is wrong to suggest that the problems are simply associated > > with RMS, FSF and GNU. > > My mail contains no reference to any of these, but simply to identifying > processes > that have failed to work in discussions (about those topics, granted). No, your message did not reference that. But was a general assessment of what I have seen developing. Indeed, the discussion started with the same person suggesting "white male privilege", the source of all toxicity coming from one individual and those associated with him, etc. > > Human beings have the capacity to be wise and develop their thoughts on > > wise > > decision-making skills that evolve from a combination of experience, > > empathy, > > and intellect. Many times, this means having the capacity to break those > > guidelines and rules. > > “rules are for the obedience of fools and the guidance of wise men”? > > As noted above, 99.99% (guessed of course) of the list traffic is carried > out in > the guise you mention, and probably would continue to be so… > > … the proposal is to have a mechanism to deal with the exceptional. That depends on the arguments of the discussion. It is acceptable at times to respond roughly to some kinds of discursive treatment. Although Nathan was allowed to write, he was surely aware of the implications - that a schism was likely. > > In the World Trade Center Disaster, many people who were used to following > > the rules died because they did what they were told by authority figures. > > I know about these things as part of my industrial work experience. > > Probably almost no-one “here” would be able to substantiate or deny this - > am I to > take it that it is a serious data point suggesting that absence of control > is a better > process? There have been numerous historical instances - let's say in the journalistic realm where I do operate - when that was true. Still, I am not against moderation when required in principle. Indeed, it is part of the job as maintainer (and co-maintainers, etc.) to exercise authority on these points when they arise. Personally, I am not afraid to exercise them when associated with my own work. Customarily, I would not oppose to intervention, except on special instances when the assessments was faulty - I specifically mention Gnu Health and the arguments Dr. Luis Falcon had with Savannah regarding package admin. May I remind everybody that Argentina opted for GNU Health for COVID19 observatory and contact tracing. At the time, I was also doing my own work on COVID19 and considered my intervention necessary. > There is no counter experiment to determine the outcome in the case that > there > were no authority figures and no rules (nor would anyone wish to conduct > such an > experiment). > > To me this is spurious input, I cannot see how it could be used to make any > guidance > to the progress here. > > Iain > > > > >>* although one might lose some notionally valuable input, the judgement > >> here is that > >>the net benefit of such input is negative. > >> > >> 3/ I would recommend on the basis of another online community (about > >> music) > >> to > >>which I belong, to suggest that Politics (party or international) and > >> Religion are better > >>discussed in other forums and are exceedingly unlikely to affect a > >> technical decision > >>on the progress of
[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797 --- Comment #9 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-April/055935.html
Re: removing toxic emailers
On Thu, Apr 15, 2021 at 1:26 PM Chris Punches via Gcc wrote: > > Every single proponent of this argument that I have seen so far is > employed by one of the same 5 companies and "really isn't doing it on > behalf of my company I swear". > > Why is it almost exclusively that specific crowd saying it here, then? For better or for worse, since the early '90s the majority of people who do serious work on GCC have been hired by companies that want to do serious work on GCC. After all, it's a win-win: the company gets work done, the GCC programmer gets well paid. The effect is that most of the major GCC contributors work for a relatively small number of companies. There are of course many exceptions, but that is the general rule. Ian
[PATCH] PR fortran/63797 - Bogus ambiguous reference to 'sqrt'
Hello everybody,
we currently write the interface for intrinsic procedures to module
files although that should not be necessary. (F2018:15.4.2.1 actually
states that interfaces e.g. of intrinsic procedures are 'explicit'.)
This lead to bogus errors due to an apparently bogus ambiguity.
A simple solution is to just avoid writing that (redundant) information
to the module file.
Regtested on x86_64-pc-linux-gnu. OK for (current) mainline?
Or rather wait after 11 release?
Thanks,
Harald
PR fortran/63797 - Bogus ambiguous reference to 'sqrt'
The interface of an intrinsic procedure is automatically explicit.
Do not write it to the module file.
gcc/fortran/ChangeLog:
* module.c (write_symtree): Do not write interface of intrinsic
procedure to module file.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr63797.f90: New test.
diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index 4db0a3ac76d..b4b7b437f86 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -6218,6 +6218,9 @@ write_symtree (gfc_symtree *st)
if (check_unique_name (st->name))
return;
+ if (strcmp (sym->module, "(intrinsic)") == 0)
+return;
+
p = find_pointer (sym);
if (p == NULL)
gfc_internal_error ("write_symtree(): Symbol not written");
diff --git a/gcc/testsuite/gfortran.dg/pr63797.f90 b/gcc/testsuite/gfortran.dg/pr63797.f90
new file mode 100644
index 000..1131e8167b1
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr63797.f90
@@ -0,0 +1,60 @@
+! { dg-do compile }
+! PR63797 - Bogus ambiguous reference to 'sqrt'
+
+module mod1
+ implicit none
+ real, parameter :: z = sqrt (0.0)
+ real:: w = sqrt (1.0)
+ interface
+ pure real function sqrt_ifc (x)
+ real, intent(in) :: x
+ end function sqrt_ifc
+ end interface
+contains
+ pure function myroot () result (f)
+procedure(sqrt_ifc), pointer :: f
+intrinsic :: sqrt
+f => sqrt
+ end function myroot
+end module mod1
+
+module mod2
+ implicit none
+ type t
+ real :: a = 0.
+ end type
+ interface sqrt
+ module procedure sqrt
+ end interface
+contains
+ elemental function sqrt (a)
+type(t), intent(in) :: a
+type(t) :: sqrt
+sqrt% a = a% a
+ end function sqrt
+end module mod2
+
+module mod3
+ implicit none
+ abstract interface
+ function real_func (x)
+ real :: real_func
+ real, intent (in) :: x
+ end function real_func
+ end interface
+ intrinsic :: sqrt
+ procedure(real_func), pointer :: real_root => sqrt
+end module mod3
+
+program test
+ use mod1
+ use mod2
+ use mod3
+ implicit none
+ type(t) :: x, y
+ procedure(sqrt_ifc), pointer :: root
+ root => myroot ()
+ y= sqrt (x)
+ y% a = sqrt (x% a) + z - w + root (x% a)
+ y% a = real_root (x% a)
+end program test
[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797 --- Comment #8 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #7) > which looks like a default initialization. Does sqrt need to be > recorded into the module? If not, then your patch is probably ok. My patch actually does not have any affect on the module file generated for your testcase. I'll add it to my testcase and submit.
Committed: gcc.dg/pr84877.c: Xfail for cris-*-*
Unfortunately it appears that this PR is on nobody's radar.
Xfailing it to get an arguably artificial zero regression
state (since T0=2007-01-05) helps my autotester.
Caveat: the pass/fail state of this test, as long as stack
alignment isn't adjusted, is dependent on the alignment of
the stack at the entry of main, so depending on the target,
e.g. the size and number of environment variables at
invocation time can affect the result (including simulator
runs where environment variables are propagated to the
target).
gcc/testsuite:
PR middle-end/84877
* gcc.dg/pr84877.c: Xfail for cris-*-*.
---
gcc/testsuite/gcc.dg/pr84877.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/pr84877.c b/gcc/testsuite/gcc.dg/pr84877.c
index 8a34dd4fb66d..8551d27bcbb8 100644
--- a/gcc/testsuite/gcc.dg/pr84877.c
+++ b/gcc/testsuite/gcc.dg/pr84877.c
@@ -1,4 +1,4 @@
-/* { dg-do run } */
+/* { dg-do run { xfail { cris-*-* } } } */
/* { dg-options "-O2" } */
#include
--
2.11.0
[Bug middle-end/84877] Local stack copy of BLKmode parameter on the stack is not aligned when the requested alignment exceeds MAX_SUPPORTED_STACK_ALIGNMENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84877 --- Comment #22 from CVS Commits --- The master branch has been updated by Hans-Peter Nilsson : https://gcc.gnu.org/g:58fe131b91007793c0f12f5fe6cab3f1a017d0fa commit r11-8204-g58fe131b91007793c0f12f5fe6cab3f1a017d0fa Author: Hans-Peter Nilsson Date: Thu Apr 15 21:51:08 2021 +0200 gcc.dg/pr84877.c: Xfail for cris-*-* Unfortunately it appears that this PR is on nobody's radar. Xfailing it to get an arguably artificial zero regression state (since T0=2007-01-05) helps my autotester. Caveat: the pass/fail state of this test, as long as stack alignment isn't adjusted, is dependent on the alignment of the stack at the entry of main, so depending on the target, e.g. the size and number of environment variables at invocation time can affect the result (including simulator runs where environment variables are propagated to the target). gcc/testsuite: PR middle-end/84877 * gcc.dg/pr84877.c: Xfail for cris-*-*.
[Bug demangler/100105] New: stack exhaust by recursion in cxxfilt demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100105 Bug ID: 100105 Summary: stack exhaust by recursion in cxxfilt demangler Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: rding at gatech dot edu Target Milestone: --- Created attachment 50607 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50607=edit PoC for the crash Hi, A stack exhaustion bug has been found for cxxfilt on the HEAD of the master branch. I was pointed by the reply (https://sourceware.org/bugzilla/show_bug.cgi?id=27737) to report it here since the bug is from the demangler before imported into the codebase of Binutils. The version information is as follows: commit a15a276b46bf07323a1d270d7abece83ef1ea78f (HEAD -> master, origin/master, origin/HEAD) Author: Tom Tromey Date: Thu Apr 15 10:14:11 2021 -0600 cxxfilt --version GNU c++filt (GNU Binutils) 2.36.50.20210415 Copyright (C) 2021 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. The configuration of Binutils is: CC=/home/ren/tmp/afl-2.52b/afl-gcc CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address" ./configure --disable-gdb --disable-werror CC=/home/ren/tmp/afl-2.52b/afl-gcc CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address" make To trigger the bug: ./cxxfilt < poc ASAN:DEADLYSIGNAL = ==25277==ERROR: AddressSanitizer: stack-overflow on address 0x7fff13a95fb0 (pc 0x563d15ede61e bp 0x0fffe2752c2e sp 0x7fff13a95fb0 T0) #0 0x563d15ede61d in demangle_path rust-demangle.c:664 #1 0x563d15edfcfd in demangle_path rust-demangle.c:774 #2 0x563d15edfcfd in demangle_path rust-demangle.c:774 #3 0x563d15edfcfd in demangle_path rust-demangle.c:774 ... #248 0x563d15edfcfd in demangle_path rust-demangle.c:774 #249 0x563d15edfcfd in demangle_path rust-demangle.c:774 #250 0x563d15edfcfd in demangle_path rust-demangle.c:774 SUMMARY: AddressSanitizer: stack-overflow rust-demangle.c:664 in demangle_path ==25277==ABORTING The triggering environment we see is on Ubuntu 18.04 (bionic), with gcc version 7.5.0. Please find the PoC we provide in the attachment and let us know if you have any trouble reproducing the crash. Thank you! Credit: Ren Ding (rd...@gatech.edu) Hanqing Zhao (hanq...@gatech.edu)
[Bug c++/80456] [8/9/10 Regression] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80456 Jason Merrill changed: What|Removed |Added Known to work||11.0 Summary|[8/9/10/11 Regression] |[8/9/10 Regression] calling |calling constexpr member|constexpr member function |function from |from volatile-qualified |volatile-qualified member |member function: error: |function: error: ‘this’ is |‘this’ is not a constant |not a constant expression |expression Known to fail|11.0| --- Comment #10 from Jason Merrill --- Fixed for 11 so far.
[Bug c++/80456] [8/9/10/11 Regression] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80456 --- Comment #9 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:3682052e4ccf0a29d1f61df1c8e31f8190eafafe commit r11-8203-g3682052e4ccf0a29d1f61df1c8e31f8190eafafe Author: Jason Merrill Date: Thu Apr 15 15:13:18 2021 -0400 c++: constexpr and volatile member function [PR80456] When calling a static member function we still need to evaluate an explicit object argument. But we don't want to force a load of the entire object if the argument is volatile, so we take its address. If as a result it no longer has any side-effects, we don't need to evaluate it after all. gcc/cp/ChangeLog: PR c++/80456 * call.c (build_new_method_call_1): Check again for side-effects with a volatile object. gcc/testsuite/ChangeLog: PR c++/80456 * g++.dg/cpp0x/constexpr-volatile3.C: New test.
[pushed] c++: constexpr and volatile member function [PR80456]
When calling a static member function we still need to evaluate an explicit
object argument. But we don't want to force a load of the entire object
if the argument is volatile, so we take its address. If as a result it no
longer has any side-effects, we don't need to evaluate it after all.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/80456
* call.c (build_new_method_call_1): Check again for side-effects
with a volatile object.
gcc/testsuite/ChangeLog:
PR c++/80456
* g++.dg/cpp0x/constexpr-volatile3.C: New test.
---
gcc/cp/call.c| 3 ++-
gcc/testsuite/g++.dg/cpp0x/constexpr-volatile3.C | 15 +++
2 files changed, 17 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-volatile3.C
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index c9a8c0d305f..678e120a165 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -10793,7 +10793,8 @@ build_new_method_call_1 (tree instance, tree fns,
vec **args,
tree a = instance;
if (TREE_THIS_VOLATILE (a))
a = build_this (a);
- call = build2 (COMPOUND_EXPR, TREE_TYPE (call), a, call);
+ if (TREE_SIDE_EFFECTS (a))
+ call = build2 (COMPOUND_EXPR, TREE_TYPE (call), a, call);
}
else if (call != error_mark_node
&& DECL_DESTRUCTOR_P (cand->fn)
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-volatile3.C
b/gcc/testsuite/g++.dg/cpp0x/constexpr-volatile3.C
new file mode 100644
index 000..5c1e865e0ac
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-volatile3.C
@@ -0,0 +1,15 @@
+// PR c++/80456
+// { dg-do compile { target c++11 } }
+
+struct A {
+ static constexpr bool test() noexcept { return true; }
+
+ void f() volatile {
+constexpr bool b = test();
+ }
+};
+
+void g() {
+ A a;
+ a.f();
+}
base-commit: 2efbbba16a0630fac8cadcd6d9e0ffaabfadb79f
--
2.27.0
Re: [PATCH] propagate attributes to local redeclaration (PR 99420)
On Thu, 8 Apr 2021, Martin Sebor via Gcc-patches wrote:
> There's another similar piece of code in pushdecl() that I didn't
> touch, although I couldn't come up with a test case showing it's
> necessary. Both hunks go back ages so I wonder if they might have
> been obviated by other improvements.
The other similar code in pushdecl is executed in cases where there are
multiple declarations of the same identifier in the same scope, e.g.:
int f (void);
void
g (void)
{
int f (void);
int f (void);
}
That particular example isn't interesting, but the idea is that the type
the declaration ends up getting is based on only visible type information
(if an intermediate scope had a variable "int f;" with automatic scope,
for example, the file-scope declaration wouldn't be visible, so the type
within the scope of the inner declarations should be the composite only of
the types of those declarations and not that of the file-scope
declaration).
I expect that the attribute handling currently there for built-in
functions only is because there were problems in some cases if a built-in
function were referenced without its built-in attributes. As the
attributes don't affect the function type in standard terms, it's
certainly OK, and improves diagnostic quality, to include attributes from
declarations that aren't visible.
It's possible that the piece of code you're changing always ensures that
the attributes are copied from the built-in function to the first
declaration in the inner scope (even when any file scope / external scope
declaration is shadowed), and, if composite_type and duplicate_decls
always preserve attributes, this might mean the code you're not changing
doesn't actually need its attribute handling because the attributes are
always present (for all functions, given your patch, or for built-in
functions, without it) even without that handling. So if something
changed that did make that code unnecessary, it might have been a fix in
composite_type or duplicate_decls.
The patch is OK.
--
Joseph S. Myers
jos...@codesourcery.com
Re: removing toxic emailers
What I see here in sum is another high level tightly integrated Red Hat employee saying the gist of "I'm really not saying it out of my employer's interest and it has nothing to do with my personal feelings". Every single proponent of this argument that I have seen so far is employed by one of the same 5 companies and "really isn't doing it on behalf of my company I swear". Why is it almost exclusively that specific crowd saying it here, then? I just don't buy it. Please say anything that would not support the emerging theory that these companies are using integrated employees to try to emulate justification/pretext for a rift to attack the free software world. Anything at all. -C On Thu, 2021-04-15 at 13:31 -0400, David Malcolm via Gcc wrote: > On Thu, 2021-04-15 at 09:49 -0400, Eric S. Raymond wrote: > > Joseph Myers : > > > On Wed, 14 Apr 2021, Eric S. Raymond wrote: > > > > > > > I'm not judging RMS's behavior (or anyone else's) one way or > > > > another. I am simply pointing out that there is a Schelling > > > > point > > > > in > > > > possible community norms that is well expressed as "you shall > > > > judge > > > > by > > > > the code alone". This list is not full of contention from > > > > affirming > > > > that norm, but from some peoples' attempt to repudiate it. > > > > > > Since RMS, FSF and GNU are not contributing code to the toolchain > > > and > > > haven't been for a very long time, the most similar basis to > > > judge > > > them > > > would seem to be based on their interactions with toolchain > > > development. > > > I think those interactions generally show that FSF and GNU have > > > been > > > bad > > > umbrella organizations for the toolchain since at least when the > > > GCC > > > 4.4 > > > release was delayed waiting for a slow process of developing the > > > GCC > > > Runtime Library Exception. > > > > I do not have standing to argue this point. > > > > I will, however, point out that it is a very *different* point from > > "RMS has iupset some people and should therefore be canceled". > > [I'm sorry to everyone who's sick of these threads, but I feel I have > to respond to this one; sorry about writing another long email] > > Eric: I don't know if you're just being glib, or you're deliberately > trying to caricature those of us who are upset by RMS's behavior. > > I think the words "canceled" and "cancel culture" have effectively > become meaningless and should be avoided if we want to have a nuanced > discussion - no-one seems to have a definition of what counts as > "canceling" vs "consequences" vs "fair and measured responses". > > At one time, both you and RMS were heroes of mine, and I was a true > believer (of what, I'm no longer sure); I own copies of both "The > Cathedral and the Bazaar" and "Free Software - Free Society", though > both are currently in my attic, gathering dust. > > I've long felt that there was a massive hole in the GNU project and > FSF > where effective technical leadership should have been - various > maintainers on gcc, gdb, etc have been implementing things, and > things > were humming along, and those of us in Red Hat working on them tried > to > coordinate on features we felt were important - but where was the > top- > level response to, say, LLVM/clang? (to name just one of many changes > in the industry) In many ways the last 8 years of my career have > been > an attempt to get gcc to respond to the appearance of LLVM/clang > (I've > added JIT-compilation, improved diagnostics, and I'm implementing a > static analysis pass) - I'm lucky that my managers inside Red Hat are > happy to pay me to hack on this stuff and make GCC better - it helps > our customers, but it also helps GCC, and the broader FLOSS > communities > using both toolchains). > > Where has the technical leadership from RMS been? Instead the long- > standing opposition by RMS to exposing the compiler's IR has hobbled > GCC, and partly contributed to the pile of technical debt we have to > dig our way out of. The only "leadership" coming out of GNU/FSF seem > to me to be dictats from on high about ChangeLog formats and coding > conventions. The GNU project seems to me to be stuck in the 1980s. > Perhaps a pronouncement like: "try to make everything be consumable > as > libraries with APIs, as well as as standalone binaries" might have > helped (and still could; can we do that please?) > > Similarly, I agree with Joseph's observations of the ways that the > FSF > and GNU have been bad umbrella organizations for the toolchain. > > But beyond the failure of technical leadership, and the > organizational > incompetence/incoherence, is RMS's behavior, and the extent to which > it, as you put it "upset some people". > > RMS's defenders seem to have fixated on his 2019 comments on Marvin > Minsky, the uproar over those, and his responses to them (then and > recently), and seem keen to assure us that everything's OK now, or, > at > least on a road to
[committed] add tests for Bug 89230
The false positives have disappeared thanks to
g:520d5ad337eaa15860a5a964daf7ca46cf31c029. I have added the two
test cases in the attached diff in r11-8202 after testing on aarch64,
arm, powerpc64le, and x86_64, out of an abundance of caution.
Martin
commit 2dbbbe893f75f587c48111ab4c97cf5e74fb91bb
Author: Martin Sebor
Date: Thu Apr 15 14:09:56 2021 -0600
PR middle-end/89230 - Bogus uninited usage warning with printf
gcc/testsuite/ChangeLog:
* gcc.dg/uninit-pr89230-1.c: New test.
* gcc.dg/uninit-pr89230-2.c: Same.
diff --git a/gcc/testsuite/gcc.dg/uninit-pr89230-1.c b/gcc/testsuite/gcc.dg/uninit-pr89230-1.c
new file mode 100644
index 000..1c07c4f6d78
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/uninit-pr89230-1.c
@@ -0,0 +1,25 @@
+/* PR middle-end/89230 - Bogus uninited usage warning with printf
+ { dg-do compile }
+ { dg-options "-O2 -Wall" } */
+
+struct S { int i, j; };
+
+/* attribute__ ((malloc)) */ struct S* f (void);
+
+int g (void)
+{
+ struct S *p = f (), *q;
+
+ if (p->i || !(q = f ()) || p->j != q->i)
+ {
+ __builtin_printf ("%i", p->i);
+
+ if (p->i)
+ return 1;
+
+ if (!q)// { dg-bogus "\\\[-Wmaybe-uninitialized" }
+ return 2;
+ }
+
+ return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/uninit-pr89230-2.c b/gcc/testsuite/gcc.dg/uninit-pr89230-2.c
new file mode 100644
index 000..473d2da5d3d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/uninit-pr89230-2.c
@@ -0,0 +1,54 @@
+/* PR middle-end/89230 - Bogus uninited usage warning with printf
+ { dg-do compile }
+ { dg-options "-O2 -Wall" } */
+
+typedef __SIZE_TYPE__ size_t;
+
+extern void* memset (void*, int, size_t);
+extern int printf (const char*, ...);
+extern int rand (void);
+
+struct S
+{
+ int a;
+ int b;
+};
+
+struct H
+{
+ int c;
+ int d;
+};
+
+void getblk (void* blk)
+{
+ struct S* s = (struct S*) blk;
+ memset (blk, 0, 512);
+ s->a = rand () & 1;
+}
+
+struct H* gethdr (void* blk)
+{
+ memset (blk, 0, 512);
+ return rand () & 1 ? (struct H*) blk : 0;
+}
+
+int main (void)
+{
+ char blk[512], tmp[512];
+ struct S *s = (struct S*) blk;
+ struct H *h;
+
+ getblk (blk);
+
+ if (s->a || !(h = gethdr (tmp)) || s->a != h->d) {
+
+printf ("%d\n", s->b);
+if (s->a)
+ printf ("s->a = %d\n", s->a);
+else if (!h)
+ printf ("!h\n");
+else
+ printf ("h->d = %d\n", h->d);
+ }
+}
[Bug middle-end/89230] Bogus uninited usage warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89230 --- Comment #10 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:2dbbbe893f75f587c48111ab4c97cf5e74fb91bb commit r11-8202-g2dbbbe893f75f587c48111ab4c97cf5e74fb91bb Author: Martin Sebor Date: Thu Apr 15 14:09:56 2021 -0600 PR middle-end/89230 - Bogus uninited usage warning with printf gcc/testsuite/ChangeLog: * gcc.dg/uninit-pr89230-1.c: New test. * gcc.dg/uninit-pr89230-2.c: Same.
Re: [PATCH] c++: partially initialized constexpr array [PR99699]
On 4/15/21 3:51 PM, Patrick Palka wrote:
Here, reduced_constant_expression_p is incorrectly returning true for a
partially initialized array CONSTRUCTOR, because when the
CONSTRUCTOR_NO_CLEARING flag is set the predicate doesn't check that
every array element is initialized by the CONSTRUCTOR, it just checks
that every initializer within the CONSTRUCTOR is a valid constant
expression. This patch makes reduced_constant_expression_p check both
conditions in a single iteration over the CONSTRUCTOR elements.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
gcc/cp/ChangeLog:
PR c++/99700
* constexpr.c (reduced_constant_expression_p): Return false
if an array CONSTRUCTOR is missing an element at some array
index when the CONSTRUCTOR_NO_CLEARING flag is set.
gcc/testsuite/ChangeLog:
PR c++/99700
* g++.dg/cpp2a/constexpr-init21.C: New test.
---
gcc/cp/constexpr.c| 24 +++--
gcc/testsuite/g++.dg/cpp2a/constexpr-init21.C | 27 +++
2 files changed, 49 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-init21.C
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index c8d9dae36fb..b74bbac3cd2 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -46,6 +46,7 @@ do {
\
static HOST_WIDE_INT find_array_ctor_elt (tree ary, tree dindex,
bool insert = false);
+static int array_index_cmp (tree key, tree index);
/* Returns true iff FUN is an instantiation of a constexpr function
template or a defaulted constexpr function. */
@@ -2910,9 +2911,27 @@ reduced_constant_expression_p (tree t)
/* An initialized vector would have a VECTOR_CST. */
return false;
else if (cxx_dialect >= cxx20
- /* An ARRAY_TYPE doesn't have any TYPE_FIELDS. */
&& TREE_CODE (TREE_TYPE (t)) == ARRAY_TYPE)
- field = NULL_TREE;
+ {
+ /* There must be a valid constant initializer at every array
+index. */
+ tree min = TYPE_MIN_VALUE (TYPE_DOMAIN (TREE_TYPE (t)));
+ tree max = TYPE_MAX_VALUE (TYPE_DOMAIN (TREE_TYPE (t)));
+ tree cursor = min;
+ FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (t), i, idx, val)
+ {
+ if (!reduced_constant_expression_p (val))
+ return false;
+ if (array_index_cmp (cursor, idx) != 0)
+ return false;
+ if (TREE_CODE (idx) == RANGE_EXPR)
+ cursor = TREE_OPERAND (idx, 1);
+ cursor = int_const_binop (PLUS_EXPR, cursor, size_one_node);
+ }
+ if (find_array_ctor_elt (t, max) == -1)
+ return false;
+ goto ok;
+ }
else if (cxx_dialect >= cxx20
&& TREE_CODE (TREE_TYPE (t)) == UNION_TYPE)
{
@@ -2946,6 +2965,7 @@ reduced_constant_expression_p (tree t)
for (; field; field = next_initializable_field (DECL_CHAIN (field)))
if (!is_really_empty_class (TREE_TYPE (field), /*ignore_vptr*/false))
return false;
+ok:
if (CONSTRUCTOR_NO_CLEARING (t))
/* All the fields are initialized. */
CONSTRUCTOR_NO_CLEARING (t) = false;
diff --git a/gcc/testsuite/g++.dg/cpp2a/constexpr-init21.C
b/gcc/testsuite/g++.dg/cpp2a/constexpr-init21.C
new file mode 100644
index 000..47b4bff21b5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/constexpr-init21.C
@@ -0,0 +1,27 @@
+// PR c++/99700
+// { dg-do compile { target c++20 } }
+
+template
+struct A {
+ T c[5];
+ constexpr A(int skip = -1) {
+for (int i = 0; i < 5; i++)
+ if (skip != i)
+c[i] = {};
+ }
+};
+
+constexpr A a;
+constexpr A a0(0); // { dg-error "not a constant expression|incompletely
initialized" }
+constexpr A a1(1); // { dg-error "not a constant expression|incompletely
initialized" }
+constexpr A a2(2); // { dg-error "not a constant expression|incompletely
initialized" }
+constexpr A a3(3); // { dg-error "not a constant expression|incompletely
initialized" }
+constexpr A a4(4); // { dg-error "not a constant expression|incompletely
initialized" }
+
+struct s { int n; };
+constexpr A b;
+constexpr A b0(0); // { dg-error "not a constant expression|incompletely
initialized" }
+
+struct empty {};
+constexpr A c;
+constexpr A c0(0);
[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096 --- Comment #17 from Sascha Wilde --- (In reply to David Malcolm from comment #16) > (In reply to Sascha Wilde from comment #10) > > (In reply to David Malcolm from comment #8) > > > It would be good to know exactly where that error message is being > > > emitted. > > > > > > If you add: > > > gcc_jit_context_set_logfile (ctxt, stderr, 0, 0); > > > to the test code (e.g. immediately after the call to > > > gcc_jit_context_acquire), libgccjit ought to spew out a copious amount of > > > logging (see > > > https://gcc.gnu.org/onlinedocs/jit/internals/index.html#example-of-log-file) > > > > > > Can you attach the log you get please? > > > > With security.pax.mprotect.global=1 it produces no extra output. > > I'll attach the output produced when security.pax.mprotect.global is > > disabled. > > Thanks! I was wondering if the error message was: > (a) due to a problem dynamically linking libgccjit into the process, or > (b) a later problem with linking the code that libgccjit generates into > the process. > > Given that there's no extra log output at all with the protection flag, it > sounds like it's (a) - though you may run into a similar problem with (b) > if/when (a) gets solved. FWIW, the reason why I stumbled upon this problem is that I am testing the native compiling GNU Emacs branch[0] on the NetBSD system. (Which, by the way, can be build and works great once security.pax.mprotect.global is disabled) When security.pax.mprotect.global is enable the Emacs, linked with libgccjit can not be started at all, failing with the same error as the hello-world example. So this matches your analysis that the problem is triggered by dynamically linking libgccjit. [0] https://akrl.sdf.org/gccemacs.html
Re: removing toxic emailers
Christopher Dimech wrote: Sent: Friday, April 16, 2021 at 7:21 AM From: "Iain Sandoe" To: "GCC Development" Subject: Re: removing toxic emailers Paul Koning wrote: On Apr 15, 2021, at 11:17 AM, Iain Sandoe wrote: ... responding in general to this part of the thread. * The GCC environment is not hostile, and has not been for the 15 or so years I’ve been part of the community. * We would notice if it became so, I’m not sure about the idea that the wool can be so easily pulled over our eyes. responding to the thread in general.. * Please could we try to seek consensus? - it is disappointing to see people treating this as some kind of point-scoring game when to those working on the compiler day to day it is far from a game. I'm not sure what the consensus is you're looking for. Let us start from the observations above and try to add in the issues that have arisen in the recent threads - and end with a proposal * One could be glib and suggest that discussions about governance and project process should be directed to a different (new) mailing list - but that does not solve the problem(s) it just moves them. - (however, it might still be valuable to folks who wish to have an automatic filter for these topics or have no interest in them). * I think we are all clear about the primary role of the gcc@ and gcc-patches@ lists - primarily technical discussion about current and future projects and patch review respectively. - we have a history of politely redirecting usage questions to the help list (while often answering them anyway), likewise with the irc channel. - I believe we also have a history of encouraging input and discussing the technical issues (reasonably) calmly. - to the best of my recollection I have never seen an idea excluded on any basis than technical content. * Without a specific list to process input on governance and project process, this list is a reasonable choice. ——— The observations above, copied from my first email, together with a belief that most of the current and potential contributor to GCC would prefer to function in a constructive environment, lead to the following proposition: * that, since the lists are generally constructive without additional management, (OK. there are occasional heated technical debates), it implies that this community by-and-large is already able to function without heavy-handed moderation. * It has been postulated that there could be valued technical input from people who have difficulty in interacting in a constructive manner (through no fault of their own). * no-one else would be making valued input, either they would be a spammer or intentionally acting in a destructive manner. - Let us propose that someone capable of working on a complex system such as a compiler would be able to read and act on a set of guidelines. - ergo, I propose that we have a set of guidelines to which someone who is being disruptive can be pointed. * (Probably?) no-one has any issue with a spammer being thrown off the list, for which I guess there is a process already - it would be reasonable to expect that genuine contributors (even with difficulties) would make an effort to follow guidelines - and that someone who was making no effort to do so is not really any different from a spammer. Of course, guidelines require debate (but I doubt that the right set would be much different from the obvious for this group). is seems to me that most of the strife in the last two weeks comes from a few key things: - attacking the person delivering a message rather than debating the message - introducing topics spurious and unrelated to the actual debate - trying to equate the process of this project with party or international Politics. === So .. in summary: 1/ I propose that we do have written guidelines, to which someone behaving in a non-constructive manner can be pointed. 2/ if those guidelines *are the consensus* of this group and someone is unable to follow them (given some reasonable chance to amend as is customary in matters such as employment law here, at least), then they are treated no differently from any other spam. Proposing the guidelines essentially means that the community accepts the fact that many of us are incapable of navigate everyday problems and dilemmas by making “right” decisions based on the use of good judgment and values rather than sterile sets of rules and conventions that typically disregard the individual, the particular, or the discrete. However, that isn’t what I wrote - what I wrote was the opposite; that history shows that almost everyone communicating on these lists can do so constructively *without* recourse to written guidelines. It is not the general case that has precipitated this discussion but, rather, the exceptional. Thusly, it is wrong to
Re: removing toxic emailers
On Thu, Apr 15, 2021 at 12:45 PM Christopher Dimech via Gcc wrote: > > Proposing the guidelines essentially means that the community accepts the fact > that many of us are incapable of navigate everyday problems and dilemmas by > making > “right” decisions based on the use of good judgment and values rather than > sterile > sets of rules and conventions that typically disregard the individual, the > particular, > or the discrete. Thusly, it is wrong to suggest that the problems are simply > associated with RMS, FSF and GNU. I think you are conflating two different things. Iain was describing general guidelines for communication, not saying anything about RMS, FSF, or GNU. Personally I would say that the purpose of communication guidelines for GCC mailing lists is not for existing members of the community. As several people have said, the GCC mailing lists are normally civil. It is to provide a mechanism for blocking people whose goal is, for whatever reason, to disrupt the community. Such a mechanism requires a lot of sensitivity to context and care on the part of the moderators. But it still helps to have a set of guidelines to refer to. Ian
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 89230, which changed state. Bug 89230 Summary: Bogus uninited usage warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89230 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug middle-end/89230] Bogus uninited usage warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89230 Martin Sebor changed: What|Removed |Added Known to fail||10.2.0, 7.3.0, 8.3.0, 9.2.0 Target Milestone|--- |11.0 Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #9 from Martin Sebor --- GCC 11 doesn't issue warnings for the test cases in comment #4 or comment #5 anymore. It has disappeared with g:520d5ad337eaa15860a5a964daf7ca46cf31c029. Let me add the test cases to the test suite and resolve this report as fixed.
[Bug tree-optimization/81776] missing sprintf optimization due to pointer escape analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81776 Martin Sebor changed: What|Removed |Added Known to fail||10.2.0, 11.0, 8.3.0, 9.3.0 Last reconfirmed|2018-04-05 00:00:00 |2021-4-15 --- Comment #3 from Martin Sebor --- Reconfirmed with GCC 11. Even worse, since the integration of the sprintf pass into strlen in r274933 GCC doesn't eliminate the abort in g1().
[PATCH] c++: partially initialized constexpr array [PR99699]
Here, reduced_constant_expression_p is incorrectly returning true for a
partially initialized array CONSTRUCTOR, because when the
CONSTRUCTOR_NO_CLEARING flag is set the predicate doesn't check that
every array element is initialized by the CONSTRUCTOR, it just checks
that every initializer within the CONSTRUCTOR is a valid constant
expression. This patch makes reduced_constant_expression_p check both
conditions in a single iteration over the CONSTRUCTOR elements.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
PR c++/99700
* constexpr.c (reduced_constant_expression_p): Return false
if an array CONSTRUCTOR is missing an element at some array
index when the CONSTRUCTOR_NO_CLEARING flag is set.
gcc/testsuite/ChangeLog:
PR c++/99700
* g++.dg/cpp2a/constexpr-init21.C: New test.
---
gcc/cp/constexpr.c| 24 +++--
gcc/testsuite/g++.dg/cpp2a/constexpr-init21.C | 27 +++
2 files changed, 49 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-init21.C
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index c8d9dae36fb..b74bbac3cd2 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -46,6 +46,7 @@ do {
\
static HOST_WIDE_INT find_array_ctor_elt (tree ary, tree dindex,
bool insert = false);
+static int array_index_cmp (tree key, tree index);
/* Returns true iff FUN is an instantiation of a constexpr function
template or a defaulted constexpr function. */
@@ -2910,9 +2911,27 @@ reduced_constant_expression_p (tree t)
/* An initialized vector would have a VECTOR_CST. */
return false;
else if (cxx_dialect >= cxx20
- /* An ARRAY_TYPE doesn't have any TYPE_FIELDS. */
&& TREE_CODE (TREE_TYPE (t)) == ARRAY_TYPE)
- field = NULL_TREE;
+ {
+ /* There must be a valid constant initializer at every array
+index. */
+ tree min = TYPE_MIN_VALUE (TYPE_DOMAIN (TREE_TYPE (t)));
+ tree max = TYPE_MAX_VALUE (TYPE_DOMAIN (TREE_TYPE (t)));
+ tree cursor = min;
+ FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (t), i, idx, val)
+ {
+ if (!reduced_constant_expression_p (val))
+ return false;
+ if (array_index_cmp (cursor, idx) != 0)
+ return false;
+ if (TREE_CODE (idx) == RANGE_EXPR)
+ cursor = TREE_OPERAND (idx, 1);
+ cursor = int_const_binop (PLUS_EXPR, cursor, size_one_node);
+ }
+ if (find_array_ctor_elt (t, max) == -1)
+ return false;
+ goto ok;
+ }
else if (cxx_dialect >= cxx20
&& TREE_CODE (TREE_TYPE (t)) == UNION_TYPE)
{
@@ -2946,6 +2965,7 @@ reduced_constant_expression_p (tree t)
for (; field; field = next_initializable_field (DECL_CHAIN (field)))
if (!is_really_empty_class (TREE_TYPE (field), /*ignore_vptr*/false))
return false;
+ok:
if (CONSTRUCTOR_NO_CLEARING (t))
/* All the fields are initialized. */
CONSTRUCTOR_NO_CLEARING (t) = false;
diff --git a/gcc/testsuite/g++.dg/cpp2a/constexpr-init21.C
b/gcc/testsuite/g++.dg/cpp2a/constexpr-init21.C
new file mode 100644
index 000..47b4bff21b5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/constexpr-init21.C
@@ -0,0 +1,27 @@
+// PR c++/99700
+// { dg-do compile { target c++20 } }
+
+template
+struct A {
+ T c[5];
+ constexpr A(int skip = -1) {
+for (int i = 0; i < 5; i++)
+ if (skip != i)
+c[i] = {};
+ }
+};
+
+constexpr A a;
+constexpr A a0(0); // { dg-error "not a constant expression|incompletely
initialized" }
+constexpr A a1(1); // { dg-error "not a constant expression|incompletely
initialized" }
+constexpr A a2(2); // { dg-error "not a constant expression|incompletely
initialized" }
+constexpr A a3(3); // { dg-error "not a constant expression|incompletely
initialized" }
+constexpr A a4(4); // { dg-error "not a constant expression|incompletely
initialized" }
+
+struct s { int n; };
+constexpr A b;
+constexpr A b0(0); // { dg-error "not a constant expression|incompletely
initialized" }
+
+struct empty {};
+constexpr A c;
+constexpr A c0(0);
--
2.31.1.298.g54a3917115
Gcc as callable libraries (was: removing toxic emailers)
David, for some reason or other, I did not get your mail, so I will just reply copying in from the archive. First, thanks for injecting some sanity into the discussion. I will not discuss RMS' personal shortcomings or the lack of them. In today's toxic political climate, such allegations are often made up and weaponized without an effective defense for the alleged wrongdoer. I don't know the truth of the matter, and I make a point of not finding out. > In many ways the last 8 years of my career have been > an attempt to get gcc to respond to the appearance of LLVM/clang (I've > added JIT-compilation, improved diagnostics, and I'm implementing a > static analysis pass) And this is highly welcome, and has made gcc (including gfortran) a much better compiler. I well remember how you implemented the much better colored error messages that gfortran has now. > Perhaps a pronouncement like: "try to make everything be consumable as > libraries with APIs, as well as as standalone binaries" might have > helped (and still could; can we do that please?) That makes perfect sense, as LLVM shows, and is something that the steering committee could decide for the project (or rather, it could issue a pronouncement that this will not be opposed if some volunteer does it). I think this could be as close to an unanimous decision as there can be among such a diverse community as the gcc developers. If the FSF takes umbrage at this, the ball is in their court.
Re: removing toxic emailers
> Sent: Friday, April 16, 2021 at 7:21 AM > From: "Iain Sandoe" > To: "GCC Development" > Subject: Re: removing toxic emailers > > Paul Koning wrote: > >> On Apr 15, 2021, at 11:17 AM, Iain Sandoe wrote: > >> > >> ... > >> responding in general to this part of the thread. > >> > >> * The GCC environment is not hostile, and has not been for the 15 or so > >> years I’ve been part of the community. > > >> * We would notice if it became so, I’m not sure about the idea that the > >> wool > >> can be so easily pulled over our eyes. > >> > > >> responding to the thread in general.. > >> > >> * Please could we try to seek consensus? > >> > >> - it is disappointing to see people treating this as some kind of > >> point-scoring game > >> when to those working on the compiler day to day it is far from a game. > > > > I'm not sure what the consensus is you're looking for. > > Let us start from the observations above and try to add in the issues that > have > arisen in the recent threads - and end with a proposal > > * One could be glib and suggest that discussions about governance and project >process should be directed to a different (new) mailing list > >- but that does not solve the problem(s) it just moves them. >- (however, it might still be valuable to folks who wish to have an > automatic filter > for these topics or have no interest in them). > > * I think we are all clear about the primary role of the gcc@ and > gcc-patches@ lists > >- primarily technical discussion about current and future projects and > patch review > respectively. > >- we have a history of politely redirecting usage questions to the help > list (while > often answering them anyway), likewise with the irc channel. > >- I believe we also have a history of encouraging input and discussing the > technical > issues (reasonably) calmly. > >- to the best of my recollection I have never seen an idea excluded on any > basis than > technical content. > > * Without a specific list to process input on governance and project > process, this >list is a reasonable choice. > > ——— > > The observations above, copied from my first email, together with a belief > that most of > the current and potential contributor to GCC would prefer to function in a > constructive > environment, lead to the following proposition: > >* that, since the lists are generally constructive without additional > management, > (OK. there are occasional heated technical debates), it implies that > this community > by-and-large is already able to function without heavy-handed moderation. > > * It has been postulated that there could be valued technical input from > people who > have difficulty in interacting in a constructive manner (through no fault > of their own). > > * no-one else would be making valued input, either they would be a spammer > or > intentionally acting in a destructive manner. > > - Let us propose that someone capable of working on a complex system such > as a > compiler would be able to read and act on a set of guidelines. > > - ergo, I propose that we have a set of guidelines to which someone who > is being > disruptive can be pointed. > >* (Probably?) no-one has any issue with a spammer being thrown off the > list, for which > I guess there is a process already - it would be reasonable to expect > that genuine > contributors (even with difficulties) would make an effort to follow > guidelines - and > that someone who was making no effort to do so is not really any > different from a > spammer. > > Of course, guidelines require debate (but I doubt that the right set would > be much > different from the obvious for this group). > > is seems to me that most of the strife in the last two weeks comes from a > few key > things: > >- attacking the person delivering a message rather than debating the > message >- introducing topics spurious and unrelated to the actual debate >- trying to equate the process of this project with party or international > Politics. > > === > > So .. in summary: > > 1/ I propose that we do have written guidelines, to which someone behaving > in a > non-constructive manner can be pointed. > > 2/ if those guidelines *are the consensus* of this group and someone is > unable to > follow them (given some reasonable chance to amend as is customary in > matters > such as employment law here, at least), then they are treated no > differently from > any other spam. Proposing the guidelines essentially means that the community accepts the fact that many of us are incapable of navigate everyday problems and dilemmas by making “right” decisions based on the use of good judgment and values rather than sterile sets of rules and conventions that typically disregard the individual, the particular, or the discrete.
Re: [PATCH] c++: Fix up C++23 [] <...> requires primary -> type {} parsing [PR99850]
On 4/14/21 3:18 PM, Jakub Jelinek wrote:
The requires clause parsing has code to suggest users wrapping
non-primary expressions in (), so if it e.g. parses a primary expression
and sees it is followed by ++, --, ., ( or -> among other things it
will try to reparse it as assignment expression or what and if that works
suggests wrapping it inside of parens.
When it is requires-clause that is after etc. it already
has an exception from that as ( can occur in valid C++20 expression there
- starting the parameters of the lambda.
In C++23 another case can occur, as the parameters with the ()s can be
omitted, requires C can be followed immediately by -> which starts a
trailing return type. Even in that case, we don't want to parse that
as C->...
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux (with
GXX_TESTSUITE_STDS=98,11,14,17,20,2b ), ok for trunk?
2021-04-14 Jakub Jelinek
PR c++/99850
* parser.c (cp_parser_constraint_requires_parens) :
If lambda_p, return pce_ok for C++23 or later instead of
pce_maybe_postfix.
* g++.dg/cpp23/lambda-specifiers2.C: New test.
--- gcc/cp/parser.c.jj 2021-04-14 10:48:41.318103715 +0200
+++ gcc/cp/parser.c 2021-04-14 14:52:03.220235527 +0200
@@ -28526,7 +28526,19 @@ cp_parser_constraint_requires_parens (cp
case CPP_PLUS_PLUS:
case CPP_MINUS_MINUS:
case CPP_DOT:
+ /* Unenclosed postfix operator. */
+ return pce_maybe_postfix;
+
case CPP_DEREF:
+ /* A primary constraint that precedes the lambda-declarator of a
+ lambda expression is followed by trailing return type.
+
+ [] requires C -> void {}
+
+ Don't try to re-parse this as a postfix expression in
+ C++23 and later. In C++20 ( needs to come in between. */
+ if (lambda_p && cxx_dialect >= cxx23)
+ return pce_ok;
I think let's not make this depend on cxx_dialect, since we allow this
in C++20 mode as well with a pedwarn. OK with that change.
/* Unenclosed postfix operator. */
return pce_maybe_postfix;
}
--- gcc/testsuite/g++.dg/cpp23/lambda-specifiers2.C.jj 2021-04-14
15:01:41.728714721 +0200
+++ gcc/testsuite/g++.dg/cpp23/lambda-specifiers2.C 2021-04-14
15:01:32.959813534 +0200
@@ -0,0 +1,7 @@
+// PR c++/99850
+// P1102R2 - Down with ()!
+// { dg-do compile { target c++23 } }
+
+auto l = [] requires true -> void {};
+template concept C = true;
+auto m = [] requires (C && ...) -> void {};
Jakub
Re: [PATCH] c++: ICE with bogus late return type [PR99803]
On 4/14/21 9:21 PM, Marek Polacek wrote:
Here we ICE when compiling this code in C++20, because we're trying to
slam a 'typename' after the ->. The cp_parser_template_id call just
before the spot I'm changing parsed A::template A as a BASELINK
that contains a constructor, but make_typename_type crashes on that.
My fix is the same as c++/88325, add an is_overloaded_fn check.
Instead of handling this in various callers, maybe make_typename_type
should handle the error, like it already does for e.g.
struct A { template static T t; };
A(unsigned) -> A:: template t;
Incidentally, in the testcase for 88325:
A::A () // { dg-error "partial specialization" }
this error is misleading; this isn't a partial specialization, it's
redundant template arguments while trying to define the primary
template. I wouldn't worry about fixing the compiler now, but let's not
test for the wrong error.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/cp/ChangeLog:
PR c++/99803
* parser.c (cp_parser_simple_type_specifier): Don't call
cp_parser_make_typename_type for is_overloaded_fn.
gcc/testsuite/ChangeLog:
PR c++/99803
* g++.dg/cpp2a/typename19.C: New test.
---
gcc/cp/parser.c | 2 +-
gcc/testsuite/g++.dg/cpp2a/typename19.C | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/typename19.C
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 3a107206318..3c506d891c9 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -18903,7 +18903,7 @@ cp_parser_simple_type_specifier (cp_parser* parser,
if (TREE_CODE (type) != TYPE_DECL)
{
/* ...unless we pretend we have seen 'typename'. */
- if (typename_p)
+ if (typename_p && !is_overloaded_fn (type))
type = cp_parser_make_typename_type (parser, type,
token->location);
else
diff --git a/gcc/testsuite/g++.dg/cpp2a/typename19.C
b/gcc/testsuite/g++.dg/cpp2a/typename19.C
new file mode 100644
index 000..bd7e5110e00
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/typename19.C
@@ -0,0 +1,5 @@
+// PR c++/99803
+// { dg-do compile { target c++20 } }
+
+struct A { template A(T); };
+auto A(unsigned) -> A::template A; // { dg-error "not name a type" }
base-commit: a87d3f964df31d4fbceb822c6d293e85c117d992
[Bug middle-end/100104] std::transform is 1.5 times faster than std::copy with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100104 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Component|c++ |middle-end --- Comment #1 from Andrew Pinski --- What target is this on?
Re: removing toxic emailers
> Sent: Friday, April 16, 2021 at 5:31 AM > From: "David Malcolm via Gcc" > To: e...@thyrsus.com, "Joseph Myers" > Cc: gcc@gcc.gnu.org, "Nathan Sidwell" > Subject: Re: removing toxic emailers > > On Thu, 2021-04-15 at 09:49 -0400, Eric S. Raymond wrote: > > Joseph Myers : > > > On Wed, 14 Apr 2021, Eric S. Raymond wrote: > > > > > > > I'm not judging RMS's behavior (or anyone else's) one way or > > > > another. I am simply pointing out that there is a Schelling point > > > > in > > > > possible community norms that is well expressed as "you shall judge > > > > by > > > > the code alone". This list is not full of contention from > > > > affirming > > > > that norm, but from some peoples' attempt to repudiate it. > > > > > > Since RMS, FSF and GNU are not contributing code to the toolchain and > > > haven't been for a very long time, the most similar basis to judge > > > them > > > would seem to be based on their interactions with toolchain > > > development. > > > I think those interactions generally show that FSF and GNU have been > > > bad > > > umbrella organizations for the toolchain since at least when the GCC > > > 4.4 > > > release was delayed waiting for a slow process of developing the GCC > > > Runtime Library Exception. > > > > I do not have standing to argue this point. > > > > I will, however, point out that it is a very *different* point from > > "RMS has iupset some people and should therefore be canceled". > > [I'm sorry to everyone who's sick of these threads, but I feel I have > to respond to this one; sorry about writing another long email] > > Eric: I don't know if you're just being glib, or you're deliberately > trying to caricature those of us who are upset by RMS's behavior. > > I think the words "canceled" and "cancel culture" have effectively > become meaningless and should be avoided if we want to have a nuanced > discussion - no-one seems to have a definition of what counts as > "canceling" vs "consequences" vs "fair and measured responses". > > At one time, both you and RMS were heroes of mine, and I was a true > believer (of what, I'm no longer sure); I own copies of both "The > Cathedral and the Bazaar" and "Free Software - Free Society", though > both are currently in my attic, gathering dust. > > I've long felt that there was a massive hole in the GNU project and FSF > where effective technical leadership should have been - various > maintainers on gcc, gdb, etc have been implementing things, and things > were humming along, and those of us in Red Hat working on them tried to > coordinate on features we felt were important - but where was the top- > level response to, say, LLVM/clang? (to name just one of many changes > in the industry) In many ways the last 8 years of my career have been > an attempt to get gcc to respond to the appearance of LLVM/clang (I've > added JIT-compilation, improved diagnostics, and I'm implementing a > static analysis pass) I don't see a problem with improvements in appearance when valuable and useful. It is not easy to work with as it could be. One can also complain about what's missing in LLVM. I am however not a proponent of C++, and closely relate to Eric's comment about the unfortunate decline of C. Have worked on C++ myself in the oil, gas and mining industry, and in other things like underwater acoustics. Where the difficulties of working with object oriented programming made working with some kinds of algorithms impossible to track adequately. > - I'm lucky that my managers inside Red Hat are > happy to pay me to hack on this stuff and make GCC better - it helps > our customers, but it also helps GCC, and the broader FLOSS communities > using both toolchains). > > Where has the technical leadership from RMS been? Instead the long- > standing opposition by RMS to exposing the compiler's IR has hobbled > GCC, and partly contributed to the pile of technical debt we have to > dig our way out of. The only "leadership" coming out of GNU/FSF seem > to me to be dictats from on high about ChangeLog formats and coding > conventions. The GNU project seems to me to be stuck in the 1980s. > Perhaps a pronouncement like: "try to make everything be consumable as > libraries with APIs, as well as as standalone binaries" might have > helped (and still could; can we do that please?) > > Similarly, I agree with Joseph's observations of the ways that the FSF > and GNU have been bad umbrella organizations for the toolchain. > > But beyond the failure of technical leadership, and the organizational > incompetence/incoherence, is RMS's behavior, and the extent to which > it, as you put it "upset some people". > > RMS's defenders seem to have fixated on his 2019 comments on Marvin > Minsky, the uproar over those, and his responses to them (then and > recently), and seem keen to assure us that everything's OK now, or, at > least on a road to improvement. I have seen much discussion and arguments emanating from that.
Re: removing toxic emailers
Paul Koning wrote: On Apr 15, 2021, at 11:17 AM, Iain Sandoe wrote: ... responding in general to this part of the thread. * The GCC environment is not hostile, and has not been for the 15 or so years I’ve been part of the community. * We would notice if it became so, I’m not sure about the idea that the wool can be so easily pulled over our eyes. responding to the thread in general.. * Please could we try to seek consensus? - it is disappointing to see people treating this as some kind of point-scoring game when to those working on the compiler day to day it is far from a game. I'm not sure what the consensus is you're looking for. Let us start from the observations above and try to add in the issues that have arisen in the recent threads - and end with a proposal * One could be glib and suggest that discussions about governance and project process should be directed to a different (new) mailing list - but that does not solve the problem(s) it just moves them. - (however, it might still be valuable to folks who wish to have an automatic filter for these topics or have no interest in them). * I think we are all clear about the primary role of the gcc@ and gcc-patches@ lists - primarily technical discussion about current and future projects and patch review respectively. - we have a history of politely redirecting usage questions to the help list (while often answering them anyway), likewise with the irc channel. - I believe we also have a history of encouraging input and discussing the technical issues (reasonably) calmly. - to the best of my recollection I have never seen an idea excluded on any basis than technical content. * Without a specific list to process input on governance and project process, this list is a reasonable choice. ——— The observations above, copied from my first email, together with a belief that most of the current and potential contributor to GCC would prefer to function in a constructive environment, lead to the following proposition: * that, since the lists are generally constructive without additional management, (OK. there are occasional heated technical debates), it implies that this community by-and-large is already able to function without heavy-handed moderation. * It has been postulated that there could be valued technical input from people who have difficulty in interacting in a constructive manner (through no fault of their own). * no-one else would be making valued input, either they would be a spammer or intentionally acting in a destructive manner. - Let us propose that someone capable of working on a complex system such as a compiler would be able to read and act on a set of guidelines. - ergo, I propose that we have a set of guidelines to which someone who is being disruptive can be pointed. * (Probably?) no-one has any issue with a spammer being thrown off the list, for which I guess there is a process already - it would be reasonable to expect that genuine contributors (even with difficulties) would make an effort to follow guidelines - and that someone who was making no effort to do so is not really any different from a spammer. Of course, guidelines require debate (but I doubt that the right set would be much different from the obvious for this group). is seems to me that most of the strife in the last two weeks comes from a few key things: - attacking the person delivering a message rather than debating the message - introducing topics spurious and unrelated to the actual debate - trying to equate the process of this project with party or international Politics. === So .. in summary: 1/ I propose that we do have written guidelines, to which someone behaving in a non-constructive manner can be pointed. 2/ if those guidelines *are the consensus* of this group and someone is unable to follow them (given some reasonable chance to amend as is customary in matters such as employment law here, at least), then they are treated no differently from any other spam. * although one might lose some notionally valuable input, the judgement here is that the net benefit of such input is negative. 3/ I would recommend on the basis of another online community (about music) to which I belong, to suggest that Politics (party or international) and Religion are better discussed in other forums and are exceedingly unlikely to affect a technical decision on the progress of GCC - such discussions almost never end well. (I’d believe that any valid exception to the need to heed some political situation would be readily recognised by the participants here). 4/ It is likely that we can extract much of the basic guidelines from any other writing on communicating constructively - after all, it is how 99.99% of this list traffic is managed without
Re: removing toxic emailers
On Thu, Apr 15, 2021 at 10:31 AM David Malcolm via Gcc wrote: > > I still admire much of what RMS has written, and have spent much of my > career trying to implement part of a vision inspired by him. I'm sad > about the way things have turned out. Twitter seems to turn everything > into a pitched battle between two camps. I hope there's room for a > nuanced view of him - the good and the less good. I don't know what > role he should have, but I think it should not be a leadership one, and > I think the FSF and GNU need to greatly change to stay relevant, > including on governance and on succession plans. None of us are > getting any younger, and the vision of the FSF and GNU seems to me to > be stuck in the 1990s (or earlier). Thanks, that is well put. That describes my own feelings as well. To be very blunt, I don't know how to read https://www.fsf.org/news/rms-addresses-the-free-software-community and think "the person who wrote this should be in a leadership role." I don't think RMS is a bad person. I think that RMS can still have a great deal to contribute to free software as a programmer and as a philosopher. But those are not the words of a leader. Leadership is about people: understanding what people need, understanding how to motivate them toward a shared goal. What I see in that essay is somebody who doesn't understand people very well, and is not all that interested in learning. Ian
[Bug c++/80456] [8/9/10/11 Regression] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80456 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Known to work||7.5.0 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/100101] [11 Regression] ICE with -Wzero-as-null-pointer-constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100101 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2efbbba16a0630fac8cadcd6d9e0ffaabfadb79f commit r11-8201-g2efbbba16a0630fac8cadcd6d9e0ffaabfadb79f Author: Jason Merrill Date: Thu Apr 15 13:38:54 2021 -0400 c++: noexcept error recursion [PR100101] Here instantiating the noexcept-specifier for bar() means instantiating A::value, which complains about the conversion from 0 to int* in the default argument of foo. Since my patch for PR99583, printing the error context involves looking at C::type, which again wants to instantiate A::value, which breaks. For now at least, let's break this recursion by avoiding looking into the noexcept-specifier in find_typenames, and limit that to just the uses_parameter_packs case that PR99583 cares about. gcc/cp/ChangeLog: PR c++/100101 PR c++/99583 * pt.c (find_parameter_packs_r) [FUNCTION_TYPE]: Walk into TYPE_RAISES_EXCEPTIONS here. * tree.c (cp_walk_subtrees): Not here. gcc/testsuite/ChangeLog: PR c++/100101 * g++.dg/cpp0x/noexcept67.C: New test.
[Bug c++/100101] [11 Regression] ICE with -Wzero-as-null-pointer-constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100101 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jason Merrill --- Fixed.
[Bug c++/99583] Parameter packs not expanded in lambda noexcept specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99583 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2efbbba16a0630fac8cadcd6d9e0ffaabfadb79f commit r11-8201-g2efbbba16a0630fac8cadcd6d9e0ffaabfadb79f Author: Jason Merrill Date: Thu Apr 15 13:38:54 2021 -0400 c++: noexcept error recursion [PR100101] Here instantiating the noexcept-specifier for bar() means instantiating A::value, which complains about the conversion from 0 to int* in the default argument of foo. Since my patch for PR99583, printing the error context involves looking at C::type, which again wants to instantiate A::value, which breaks. For now at least, let's break this recursion by avoiding looking into the noexcept-specifier in find_typenames, and limit that to just the uses_parameter_packs case that PR99583 cares about. gcc/cp/ChangeLog: PR c++/100101 PR c++/99583 * pt.c (find_parameter_packs_r) [FUNCTION_TYPE]: Walk into TYPE_RAISES_EXCEPTIONS here. * tree.c (cp_walk_subtrees): Not here. gcc/testsuite/ChangeLog: PR c++/100101 * g++.dg/cpp0x/noexcept67.C: New test.
[pushed] c++: noexcept error recursion [PR100101]
Here instantiating the noexcept-specifier for bar() means
instantiating A::value, which complains about the conversion from 0 to
int* in the default argument of foo. Since my patch for PR99583, printing
the error context involves looking at C::type, which again wants to
instantiate A::value, which breaks. For now at least, let's break
this recursion by avoiding looking into the noexcept-specifier in
find_typenames, and limit that to just the uses_parameter_packs case that
PR99583 cares about.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/100101
PR c++/99583
* pt.c (find_parameter_packs_r) [FUNCTION_TYPE]: Walk into
TYPE_RAISES_EXCEPTIONS here.
* tree.c (cp_walk_subtrees): Not here.
gcc/testsuite/ChangeLog:
PR c++/100101
* g++.dg/cpp0x/noexcept67.C: New test.
---
gcc/cp/pt.c | 11 +++
gcc/cp/tree.c | 5 -
gcc/testsuite/g++.dg/cpp0x/noexcept67.C | 26 +
3 files changed, 37 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept67.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 0f119a55272..2190f83882a 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -3890,6 +3890,10 @@ find_parameter_packs_r (tree *tp, int *walk_subtrees,
void* data)
(struct find_parameter_pack_data*)data;
bool parameter_pack_p = false;
+#define WALK_SUBTREE(NODE) \
+ cp_walk_tree (&(NODE), _parameter_packs_r, \
+ ppd, ppd->visited) \
+
/* Don't look through typedefs; we are interested in whether a
parameter pack is actually written in the expression/type we're
looking at, not the target type. */
@@ -4070,10 +4074,17 @@ find_parameter_packs_r (tree *tp, int *walk_subtrees,
void* data)
ppd, ppd->visited);
return NULL_TREE;
+case FUNCTION_TYPE:
+case METHOD_TYPE:
+ WALK_SUBTREE (TYPE_RAISES_EXCEPTIONS (t));
+ break;
+
default:
return NULL_TREE;
}
+#undef WALK_SUBTREE
+
return NULL_TREE;
}
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 13cc61c3123..dca947bf52a 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -5415,11 +5415,6 @@ cp_walk_subtrees (tree *tp, int *walk_subtrees_p,
walk_tree_fn func,
}
break;
-case FUNCTION_TYPE:
-case METHOD_TYPE:
- WALK_SUBTREE (TYPE_RAISES_EXCEPTIONS (*tp));
- break;
-
default:
return NULL_TREE;
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept67.C
b/gcc/testsuite/g++.dg/cpp0x/noexcept67.C
new file mode 100644
index 000..7f061034323
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/noexcept67.C
@@ -0,0 +1,26 @@
+// PR c++/100101
+// { dg-do compile { target c++11 } }
+
+template struct A
+{
+template static char foo(U*, int* = 0);
+static const bool value = sizeof(foo(static_cast(nullptr))) > 0;
+};
+
+template struct B
+{
+static const bool value = b;
+};
+
+template struct C
+{
+typedef B::value> type;
+};
+
+template
+void bar() noexcept(A::value && C::type::value) {}
+
+void baz()
+{
+ bar();
+}
base-commit: a25590f29d07a88f6bf1b2c1ab0e4e012725db98
--
2.27.0
[Bug c++/99683] Deduction failure when using CTAD of CNTTP inside a deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99683 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93383 Status|UNCONFIRMED |NEW CC||ppalka at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-04-15 --- Comment #2 from Patrick Palka --- Thanks for the reduced testcases, confirmed. Closely related to PR93383 I think.
Re: [PATCH] aarch64: Fix up 2 other combine opt regressions vs. GCC8 [PR100075]
On Thu, Apr 15, 2021 at 07:11:11PM +0100, Richard Sandiford wrote: > Jakub Jelinek writes: > > --- gcc/config/aarch64/aarch64.md.jj2021-04-15 10:45:02.798853095 > > +0200 > > +++ gcc/config/aarch64/aarch64.md 2021-04-15 13:28:04.734754364 +0200 > > @@ -3572,6 +3572,18 @@ (define_insn "*neg__si2_uxtw" > >[(set_attr "autodetect_type" "alu_shift__op2")] > > ) > > > > +(define_insn "*neg_asr_si2_extr" > > + [(set (match_operand:SI 0 "register_operand" "r") > > + (neg:SI (match_operator 4 "subreg_lowpart_operator" > > Very minor, but it might be better to have the :SI on the match_operator > too, like in the pattern below. Fixed, thanks for catching that (and the "r" -> "=r"; I've actually tested a patch that didn't have any constraints on the first define_insn because I started with a define_split that didn't work, and it happened to work during testing, only noticed I've missed them afterwards. > > @@ -5382,6 +5394,22 @@ (define_insn "*extrsi5_insn_uxtw_alt" > >"extr\\t%w0, %w1, %w2, %4" > >[(set_attr "type" "rotate_imm")] > > ) > > + > > +(define_insn "*extrsi5_insn_di" > > + [(set (match_operand:SI 0 "register_operand" "=r") > > + (ior:SI (ashift:SI (match_operand:SI 1 "register_operand" "r") > > + (match_operand 3 "const_int_operand" "n")) > > + (match_operator:SI 6 "subreg_lowpart_operator" > > + [(zero_extract:DI > > +(match_operand:DI 2 "register_operand" "r") > > +(match_operand 5 "const_int_operand" "n") > > +(match_operand 4 "const_int_operand" "n"))])))] > > + "UINTVAL (operands[3]) < 32 > > + && UINTVAL (operands[3]) + UINTVAL (operands[4]) == 32 > > + && UINTVAL (operands[4]) + UINTVAL (operands[5]) - 32 <= 64" > > Could you explain this condition? With operand 5 being the size > and operand 4 being the position, I was expecting something like: The first two conditions are like those on *extr5_insn except that GET_MODE_BITSIZE (mode) is hardcoded as 32. Like in *extr5_insn, we have two shift counts, because aarch64 is !BITS_BIG_ENDIAN the last operand of zero_extract is a shift count too. The UINTVAL (operands[4]) + UINTVAL (operands[5]) - 32 <= 64 (should have been <= 32 actually) meant to test IN_RANGE (UINTVAL (operands[4]) + UINTVAL (operands[5]), 32, 64) because I mistakenly thought or maybe just UINTVAL (operands[4]) + UINTVAL (operands[5]) >= 32 was meant to test that the zero_extract extracts at least as many bits that it doesn't mask any bits above that. But the subreg:SI actually applies to the zero_extract result and therefore operands[2] >> operands[4] rather than before that, so you're right it needs to be == 32 rather than >= 32. So, either it can be "UINTVAL (operands[3]) < 32 && UINTVAL (operands[3]) + UINTVAL (operands[4]) == 32 && UINTVAL (operands[4]) + UINTVAL (operands[5]) == 32" or what you wrote: > "UINTVAL (operands[3]) < 32 >&& UINTVAL (operands[3]) == UINTVAL (operands[5]) >&& UINTVAL (operands[4]) + UINTVAL (operands[5]) == 32" or it could be: "UINTVAL (operands[3]) < 32 && UINTVAL (operands[3]) + UINTVAL (operands[4]) == 32 && INTVAL (operands[3]) == INTVAL (operands[5])" Jakub
[Bug target/100085] Bad code for union transfer from __float128 to vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085 --- Comment #3 from Segher Boessenkool --- The rotates in 6 and 7 are not merged, and neither are the vec_selects in 8 and 9. Both should be pretty easy to do, there is no unspec in sight, etc.
Patch, fortran] PR fortran/100103 - Automatic reallocation fails inside select rank
Hi All!
Proposed patch to:
PR100103 - Automatic reallocation fails inside select rank
Patch tested only on x86_64-pc-linux-gnu.
Add select rank temporary associated names as possible targets of
automatic reallocation.
The patch depends on PR100097 and PR100098.
Thank you very much.
Best regards,
José Rui
Fortran: Fix automatic reallocation inside select rank [PR100103]
gcc/fortran/ChangeLog:
PR fortran/100103
* trans-array.c (gfc_is_reallocatable_lhs): add select rank
temporary associate names as possible targets of automatic
reallocation.
gcc/testsuite/ChangeLog:
PR fortran/100103
* gfortran.dg/PR100103.f90: New test.
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index be5eb89350f..99225e70d5d 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -10048,7 +10048,7 @@ gfc_is_reallocatable_lhs (gfc_expr *expr)
/* An allocatable class variable with no reference. */
if (sym->ts.type == BT_CLASS
- && !sym->attr.associate_var
+ && (!sym->attr.associate_var || sym->attr.select_rank_temporary)
&& CLASS_DATA (sym)->attr.allocatable
&& expr->ref
&& ((expr->ref->type == REF_ARRAY && expr->ref->u.ar.type == AR_FULL
@@ -10063,7 +10063,7 @@ gfc_is_reallocatable_lhs (gfc_expr *expr)
/* An allocatable variable. */
if (sym->attr.allocatable
- && !sym->attr.associate_var
+ && (!sym->attr.associate_var || sym->attr.select_rank_temporary)
&& expr->ref
&& expr->ref->type == REF_ARRAY
&& expr->ref->u.ar.type == AR_FULL)
diff --git a/gcc/testsuite/gfortran.dg/PR100103.f90 b/gcc/testsuite/gfortran.dg/PR100103.f90
new file mode 100644
index 000..756fd5824c9
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR100103.f90
@@ -0,0 +1,81 @@
+! { dg-do run }
+!
+! Test the fix for PR100103
+!
+
+program main_p
+
+ implicit none
+
+ integer:: i
+ integer, parameter :: n = 11
+
+ type :: foo_t
+integer :: i
+ end type foo_t
+
+ type(foo_t), parameter :: a(*) = [(foo_t(i), i=1,n)]
+
+ type(foo_t), allocatable :: bar_d(:)
+ class(foo_t), allocatable :: bar_p(:)
+ class(*), allocatable :: bar_u(:)
+
+
+ call foo_d(bar_d)
+ if(.not.allocated(bar_d)) stop 1
+ if(any(bar_d%i/=a%i)) stop 2
+ deallocate(bar_d)
+ call foo_p(bar_p)
+ if(.not.allocated(bar_p)) stop 3
+ if(any(bar_p%i/=a%i)) stop 4
+ deallocate(bar_p)
+ call foo_u(bar_u)
+ if(.not.allocated(bar_u)) stop 5
+ select type(bar_u)
+ type is(foo_t)
+if(any(bar_u%i/=a%i)) stop 6
+ class default
+stop 7
+ end select
+ deallocate(bar_u)
+ stop
+
+contains
+
+ subroutine foo_d(that)
+type(foo_t), allocatable, intent(out) :: that(..)
+
+select rank(that)
+rank(1)
+ that = a
+rank default
+ stop 8
+end select
+return
+ end subroutine foo_d
+
+ subroutine foo_p(that)
+class(foo_t), allocatable, intent(out) :: that(..)
+
+select rank(that)
+rank(1)
+ that = a
+rank default
+ stop 9
+end select
+return
+ end subroutine foo_p
+
+ subroutine foo_u(that)
+class(*), allocatable, intent(out) :: that(..)
+
+select rank(that)
+rank(1)
+ that = a
+rank default
+ stop 10
+end select
+return
+ end subroutine foo_u
+
+end program main_p
