[Bug c/97748] Preincrement of _Complex gives bogus warning = "value computed is not used"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97748
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Adjusted testcase:
/* PR c/97748 */
/* { dg-do compile } */
/* { dg-options "-Wunused-value" } */
double _Complex
foo (double _Complex x)
{
++x; /* { dg-bogus "value computed is not used" } */
return x;
}
double _Complex
bar (double _Complex x)
{
--x; /* { dg-bogus "value computed is not used" } */
return x;
}
The tree that is not used is a COMPLEX_EXPR:
(void) COMPLEX_EXPR < ++REALPART_EXPR , IMAGPART_EXPR >
which would be used only if the result of the post increment or decrement would
be actually used.
So, either we should mark the COMPLEX_EXPR created for the pre-increments
TREE_NO_WARNING, or the -Wunused-value would need to look through the
COMPLEX_EXPR.
[Bug c/97748] Preincrement of _Complex gives bogus warning = "value computed is not used"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97748
--- Comment #2 from Jakub Jelinek ---
Untested WIP patch, though C++ FE needs some extra work:
--- gcc/c-family/c-common.h.jj 2020-11-03 11:15:07.170681001 +0100
+++ gcc/c-family/c-common.h 2020-11-07 09:37:48.597233063 +0100
@@ -1362,7 +1362,7 @@ extern void warn_tautological_cmp (const
tree, tree);
extern void warn_logical_not_parentheses (location_t, enum tree_code, tree,
tree);
-extern bool warn_if_unused_value (const_tree, location_t);
+extern bool warn_if_unused_value (const_tree, location_t, bool = false);
extern bool strict_aliasing_warning (location_t, tree, tree);
extern void sizeof_pointer_memaccess_warning (location_t *, tree,
vec *, tree *,
--- gcc/c-family/c-warn.c.jj2020-10-26 10:53:56.533885147 +0100
+++ gcc/c-family/c-warn.c 2020-11-07 09:40:51.011170825 +0100
@@ -585,7 +585,7 @@ warn_logical_not_parentheses (location_t
(potential) location of the expression. */
bool
-warn_if_unused_value (const_tree exp, location_t locus)
+warn_if_unused_value (const_tree exp, location_t locus, bool quiet)
{
restart:
if (TREE_USED (exp) || TREE_NO_WARNING (exp))
@@ -633,7 +633,7 @@ warn_if_unused_value (const_tree exp, lo
goto restart;
case COMPOUND_EXPR:
- if (warn_if_unused_value (TREE_OPERAND (exp, 0), locus))
+ if (warn_if_unused_value (TREE_OPERAND (exp, 0), locus, quiet))
return true;
/* Let people do `(foo (), 0)' without a warning. */
if (TREE_CONSTANT (TREE_OPERAND (exp, 1)))
@@ -648,6 +648,13 @@ warn_if_unused_value (const_tree exp, lo
return false;
goto warn;
+case COMPLEX_EXPR:
+ /* Warn only if both operands are unused. */
+ if (warn_if_unused_value (TREE_OPERAND (exp, 0), locus, true)
+ && warn_if_unused_value (TREE_OPERAND (exp, 1), locus, true))
+ goto warn;
+ return false;
+
case INDIRECT_REF:
/* Don't warn about automatic dereferencing of references, since
the user cannot control it. */
@@ -671,6 +678,8 @@ warn_if_unused_value (const_tree exp, lo
return false;
warn:
+ if (quiet)
+ return true;
return warning_at (locus, OPT_Wunused_value, "value computed is not
used");
}
}
--- gcc/testsuite/c-c++-common/Wunused-value-1.c.jj 2020-11-07
09:51:46.407757100 +0100
+++ gcc/testsuite/c-c++-common/Wunused-value-1.c2020-11-07
10:15:34.295574782 +0100
@@ -0,0 +1,33 @@
+/* PR c/97748 */
+/* { dg-do compile } */
+/* { dg-options "-Wunused-value" } */
+
+double _Complex f ();
+double _Complex *p;
+
+double _Complex
+foo (double _Complex x)
+{
+ ++x; /* { dg-bogus "value computed is not used" } */
+ --x; /* { dg-bogus "value computed is not used" } */
+ x += 1; /* { dg-bogus "value computed is not used" } */
+ x += 1.0iF; /* { dg-bogus "value computed is not used" } */
+ x++; /* { dg-bogus "value computed is not used" } */
+ x--; /* { dg-bogus "value computed is not used" } */
+ x + 1; /* { dg-warning "value computed is not used" } */
+ (void) (x + 1); /* { dg-bogus "value computed is not used" } */
+ 1 + f ();/* { dg-warning "value computed is not used" } */
+ f () + f (); /* { dg-warning "value computed is not used" }
*/
+ f () + f (), f (); /* { dg-warning "value computed is not used" } */
+ f ();
+ (void) f ();
+ *p++;/* { dg-warning "value computed is not used" }
*/
+ ++*p;/* { dg-bogus "value computed is not used" } */
+ (*p ? f () : 0);
+ ({ f (); });
+ ({ f () + 1; });
+ ({ f (); 0; });
+ ({ f () + 1; 0; }); /* { dg-warning "value computed is not used" } */
+ 1 + ({ f (); }); /* { dg-warning "value computed is not used" } */
+ return x;
+}
[Bug target/83562] broken destructors of thread_local objects on i686 mingw targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562 Liu Hao changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Liu Hao --- https://github.com/gcc-mirror/gcc/commit/7fc0f78c3f43af1967cb7b1ee8f4947f3b890aa2
[Bug middle-end/97738] Optimizing division by value & - value for HAKMEM 175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97738 --- Comment #5 from Thomas Koenig --- (In reply to Jakub Jelinek from comment #4) > What about a version that still sets lowest_bit to value & -value; rather > than 1 < ctz? I think this would be ideal, or close to it. > Also, I'm not sure you can safely do the (changed_bits >> ctz) >> 2 to > changed_bits >> (ctz + 2) transformation, while because of the division one > can count on value not being 0 (otherwise UB), value & -value can still be > e.g. 1U << 31 and then ctz 31 too, and changed_bits >> (31 + 2) being UB, > while > (changed_bits >> 31) >> 2 well defined returning 0. OK. > So, I think we could e.g. during expansion (or isel) based on target cost > optimize > x / (y & -y) to x >> __builtin_ctz (y) (also assuming the optab for ctz > exists), but anything else looks complicated. I think this would solve the issue for the original code (which is what people will find on the web if they google for HAKMEM 175).
[Bug ada/97557] [11 regression] several ada test case failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97557 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #1 from Eric Botcazou --- Try to delete your previous installation in the install tree.
[Bug tree-optimization/97750] New: ICE in during GIMPLE pass: wrestrict on commit e0af865ab9d9d5b6b3ac7fdde26cf9bbf635b6b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97750 Bug ID: 97750 Summary: ICE in during GIMPLE pass: wrestrict on commit e0af865ab9d9d5b6b3ac7fdde26cf9bbf635b6b4 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hedmoo at yahoo dot com Target Milestone: --- hi for me vlc fails with : during GIMPLE pass: wrestrict video_chroma/copy.c: In function ‘CopyFromUswc’: video_chroma/copy.c:141:13: internal compiler error: Segmentation fault 141 | static void CopyFromUswc(uint8_t *dst, size_t dst_pitch, | ^~~~ 0x15fda3f internal_error(char const*, ...) ???:0 0x1585bc5 operator_cast::op1_range(irange&, tree_node*, irange const&, irange const&) const ???:0 0x149e23a gori_compute::compute_name_range_op(irange&, gimple*, irange const&, tree_node*) ???:0 0x14a1ac6 gori_compute_cache::compute_operand_range(irange&, gimple*, irange const&, tree_node*) ???:0 0x149ecb9 gori_compute::compute_operand1_range(irange&, gimple*, irange const&, tree_node*) ???:0 0x14a1ac6 gori_compute_cache::compute_operand_range(irange&, gimple*, irange const&, tree_node*) ???:0 0x149ecb9 gori_compute::compute_operand1_range(irange&, gimple*, irange const&, tree_node*) ???:0 0x14a1ac6 gori_compute_cache::compute_operand_range(irange&, gimple*, irange const&, tree_node*) ???:0 0x149ecb9 gori_compute::compute_operand1_range(irange&, gimple*, irange const&, tree_node*) ???:0 0x14a1ac6 gori_compute_cache::compute_operand_range(irange&, gimple*, irange const&, tree_node*) ???:0 0x14a00d7 gori_compute::outgoing_edge_range_p(irange&, edge_def*, tree_node*) ???:0 0x149c67d ranger_cache::propagate_cache(tree_node*) ???:0 0x149cfdc ranger_cache::fill_block_cache(tree_node*, basic_block_def*, basic_block_def*) ???:0 0x149d46f ranger_cache::block_range(irange&, basic_block_def*, tree_node*, bool) ???:0 0x14952a5 gimple_ranger::range_on_entry(irange&, basic_block_def*, tree_node*) ???:0 0x1495af4 gimple_ranger::range_of_expr(irange&, tree_node*, gimple*) ???:0 0x1496f61 gimple_ranger::range_of_range_op(irange&, gimple*) ???:0 0x1499357 gimple_ranger::calc_stmt(irange&, gimple*, tree_node*) ???:0 0x14998f3 gimple_ranger::range_of_stmt(irange&, gimple*, tree_node*) ???:0 0x1495b78 gimple_ranger::range_of_expr(irange&, tree_node*, gimple*) ???:0 Please submit a full bug report, as this is my first bug report for you please correct me with the wrongs i am doing .
[Bug tree-optimization/97750] ICE in during GIMPLE pass: wrestrict on commit e0af865ab9d9d5b6b3ac7fdde26cf9bbf635b6b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97750 --- Comment #1 from andreas --- Created attachment 49518 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49518&action=edit flags and system
[Bug tree-optimization/97750] ICE in during GIMPLE pass: wrestrict on commit e0af865ab9d9d5b6b3ac7fdde26cf9bbf635b6b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97750 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- See https://gcc.gnu.org/bugs/ , we need the preprocessed source + gcc options used to compile that. Add -save-temps to whatever command line is copy.c compiled with and attach copy.i + say the command line.
[Bug c++/97751] New: C++20 NTTP: class template argument deduction failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97751
Bug ID: 97751
Summary: C++20 NTTP: class template argument deduction failed
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janpmoeller at gmx dot de
Target Milestone: ---
The following code results in a hard compile error in gcc-10.2 and the latest
trunk:
/
template
struct use_as_nttp {};
template
struct has_nttp {};
template
using has_nttp_2 = has_nttp;
/
This is the output:
#
:8:34: error: class template argument deduction failed:
8 | using has_nttp_2 = has_nttp;
| ^
:8:34: error: no matching function for call to
'use_as_nttp(use_as_nttp<...auto...>)'
:2:8: note: candidate: 'template use_as_nttp()-> use_as_nttp'
2 | struct use_as_nttp {};
|^~~
:2:8: note: template argument deduction/substitution failed:
:8:34: note: candidate expects 0 arguments, 1 provided
8 | using has_nttp_2 = has_nttp;
| ^
:2:8: note: candidate: 'template use_as_nttp(use_as_nttp)->
use_as_nttp'
2 | struct use_as_nttp {};
|^~~
:2:8: note: template argument deduction/substitution failed:
:8:34: note: mismatched types 'use_as_nttp' and
'use_as_nttp<...auto...>'
8 | using has_nttp_2 = has_nttp;
| ^
Compiler returned: 1
#
gcc was invoked with "-std=c++20 -Wall -Wextra -Wpedantic". The error can also
be observed on compiler explorer: https://godbolt.org/z/xbPrjj
I believe that this is valid C++20 and should compile (but not generate any
assembly, since none of the types are actually instantiated).
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 Fabian Groffen changed: What|Removed |Added CC||grobian at gentoo dot org --- Comment #11 from Fabian Groffen --- Is there a patch or WIP somewhere I can try out or attempt to bring forwards? My attempts at porting the 4.2.1 Apple changes to 10.1 seem to have failed as I get some weird "byref undeclared" errors whenever a __block var is encountered. I must admit I'm not really well versed with GCC's code. Thanks
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #12 from Iain Sandoe --- (In reply to Fabian Groffen from comment #11) > Is there a patch or WIP somewhere I can try out or attempt to bring forwards? I need to bring forward my patches to the latest master, will post a link here when that is done (it won't be soon - mainly because all time is being soaked up with work on the arm64 port for Apple Silicon). At present, I am also trying to resolve some of the other (smaller) objective-c issues preventing us from parsing the system headers. > My attempts at porting the 4.2.1 Apple changes to 10.1 seem to have failed > as I get some weird "byref undeclared" errors whenever a __block var is > encountered. I must admit I'm not really well versed with GCC's code. The apple-4.2.1 branch is, indeed, too far removed from current trunk - and as far as I understand, we would not be permitted to apply those patches anyway, since they were not counted as contributed (not present on the FSF servers). IANAL - but that's how I understand the rules. It would be great to have more than one person working on this - I will post here when the current WIP is published somewhere.
[Bug d/97644] FAIL: gdc.dg/gdc204.d due to ICE in finish_thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644 --- Comment #11 from Iain Buclaw --- (In reply to Jan Hubicka from comment #10) > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644 > > > > --- Comment #9 from Iain Buclaw --- > > (In reply to Jan Hubicka from comment #8) > > > > Current workaround I'm using locally for the time being is to call > > > > thunk_info::process_early_thunks if the particular branch where this ICE > > > > happens is hit. > > > > > > Why D frontend needs to expand the thunk early and does not rely on > > > backend to handle it same way as C++ does? It would be most practical > > > if both was finalizing same way. > > > > > > If there is good reason for not doing so and there is no PCH in D > > > frontend we could just add argument to expand_thunk to avoid the game o > > > putting things into a vector. > > > > > > > Not discounting that I may be doing it wrong. The call to expand_thunk is > > there so that thunks for externally defined methods are generated. > > > > As the backend usually doesn't emit such thunks, a gimple generated thunk is > > forced by the frontend. > > > > I have seen linker errors in the past when this was not done, however there > > could be some alignment with what C++ does to handle this though. > > Aha, thanks for explanation. > In C++ thunks was always connected to the actual function so for > external symbols we indeed do not produce the thunk. > > How does the symbols look like? So you have external symbol and a thunk > associated to it with different visibility? What it is? Because this is what the reference D compiler does, thunks are static (in the C sense) and connected with the class definition, where it is referenced by the class vtable symbol. However, I have for the past week been trialling out thunks that are global and emitted only if the function has a definition as well as per what you described about C++ thunks. The only drawback I've found so far is that thunks for extern(C++) classes are left undefined, however I can resolve this by implementing mangle support in the D front-end so that the C++ generated thunks can be referenced directly.
[Bug c++/97752] New: incorrect address to inherited object in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97752
Bug ID: 97752
Summary: incorrect address to inherited object in constexpr
context
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: steven.vandersch...@nextlevel-electronics.com
Target Milestone: ---
Created attachment 49519
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49519&action=edit
C++ code to trigger the bug
When working on a project I discovered a function where gcc, when in a
constexpr context, seems to incorrectly compute the value of a pointer.
Attached is a reduced example that triggers the bug.
I defined a class Derived that inherits from two classes Base1 and Base2. A
member function in Base1 will downcast its this pointer to Derived*, which is
than casted to Base2*. When dereferencing the Base2* pointer in a constexpr
context gcc reports: modification of ‘*(((Derived*)(&
derived.Derived::)) + 18446744073709551612)’ is not a
constant expression. The code attached to this bug report has a some template
magic around the described behaviour. When I tried to remove the template magic
I failed to get this bug to be triggered.
Note this only fails when explicitly executing in a constexpr context. When the
constexpr keyword on line 178 is removed the resulting binary seems correct:
:
0: b8 4a 04 00 00 mov$0x44a,%eax
5: c3 retq
Also the code seems to compile fine in a constexpr context using clang:
https://cpp.godbolt.org/z/n3c3ea
gcc version: 10.2.1 20201016
System: Fedora 33 x86_64
Command: g++ -v -std=c++17 -O3 -Wextra -pedantic test.cpp
Response when running g++:
--
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20201016 (Red Hat 10.2.1-6) (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=c++17' '-O3' '-Wextra' '-Wpedantic' '-c' '-o'
'test.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/10/cc1plus -quiet -v -D_GNU_SOURCE
./test.cpp -quiet -dumpbase test.cpp -mtune=generic -march=x86-64
-auxbase-strip test.o -O3 -Wextra -Wpedantic -std=c++17 -version -o
/tmp/ccIaE47Z.s
GNU C++17 (GCC) version 10.2.1 20201016 (Red Hat 10.2.1-6)
(x86_64-redhat-linux)
compiled by GNU C version 10.2.1 20201016 (Red Hat 10.2.1-6), GMP
version 6.2.0, MPFR version 4.1.0, MPC version 1.1.0, isl version
isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/10/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/10/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10
/usr/lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/backward
/usr/lib/gcc/x86_64-redhat-linux/10/include
/usr/local/include
/usr/include
End of search list.
GNU C++17 (GCC) version 10.2.1 20201016 (Red Hat 10.2.1-6)
(x86_64-redhat-linux)
compiled by GNU C version 10.2.1 20201016 (Red Hat 10.2.1-6), GMP
version 6.2.0, MPFR version 4.1.0, MPC version 1.1.0, isl version
isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: bc4d6419b2bc73981424827b3550eaef
./test.cpp: In function ‘int test()’:
./test.cpp:178:27: in ‘constexpr’ expansion of ‘f.test()::()’
./test.cpp:175:11: in ‘constexpr’ expansion of ‘(& obj)->Base1 >::test()’
./test.cpp:26:16: in ‘constexpr’ expansion of ‘Base1
>::callCallbacks::test:: >(callbacks, 987)’
./test.cpp:42:16: in ‘constexpr’ expansion of ‘Base1
>::callCallbacks::test::, 0>(callbacks, payload,
(std::make_index_sequence<1>{}, std::make_index_sequence<1>()))’
./test.cpp:37:26: in ‘constexpr’ expansion of ‘(& std::g
[Bug c++/97752] incorrect address to inherited object in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97752
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-11-07
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
Reduced:
template struct b { static constexpr int c = a; };
template struct g : b {};
template struct g : b {};
template struct j { typedef e af; };
template struct j { typedef k af; };
template using ah = typename j::af;
template constexpr bool ak = g::c;
template struct l;
template using ao = typename l::af;
template struct m;
struct n {
typedef m<0> ar;
};
template struct o {};
template struct p;
template struct p> {
typedef o ar;
};
template using aw = typename p::ar;
template using ax = o;
template using ay = aw;
template struct ba {
template constexpr ba(bb q) : bd(q) {}
static constexpr az be(ba &q) { return q.bd; }
az bd;
};
template struct bg;
template struct bg : ba {
template constexpr bg(bb q) : ba(q) {}
};
template class r : public bg<0, bo...> {
public:
template constexpr r(bm... q) : bg<0, bo...>(q...) {}
};
template struct l> {
typedef az af;
};
template constexpr az bt(bg &q) {
return bg::be(q);
}
template constexpr ao> bu(r q) {
return bt(q);
}
template constexpr r bv(bo... q) {
return r(q...);
}
template struct by {
template static constexpr bool ca = (... || ak);
};
class s;
template class t {
public:
using bx = by;
constexpr void cf() {
auto callbacks = cg().template ch([](auto &ci) { return ci.cf(6); });
cj(callbacks, 7);
}
constexpr void ck(int q) { cl = q; }
int cl;
template
constexpr void cj(r q, int p2, ax) {
(bu(q)(p2), ...);
}
template constexpr void cj(r q, int p2) {
cj(q, p2, ay{});
}
constexpr auto &cg() { return *static_cast(this); }
};
template typename...> class Q;
template class u {
public:
using bx = by;
template constexpr auto cf(bz) {
return [this](auto) {
auto &ci = cg();
ci.ck(1);
};
}
int i;
constexpr auto &cg() { return *static_cast *>(this); }
};
template typename... cp> class Q : public cp>...
{
struct L {
template static typename cr::bx cs(int);
template using by = decltype(cs(0));
};
template struct v {
template using cv = v;
template using cw = v;
};
template struct v {
template
using cw =
ah::template ca, typename v<>::template cv,
typename v::template cw>;
};
template struct w;
template struct w> {
static constexpr auto &da(Q &q) { return (q.bu(), ...); }
template static constexpr auto dd(Q &q, dc p2) {
return bv(p2(q.bu())...);
}
};
public:
template constexpr auto &bu() {
return *static_cast(this);
}
template constexpr auto &de() {
return w...>::template cw>::da(*this);
}
template constexpr auto ch(dc q) {
return w...>::template cw>::dd(*this, q);
}
};
void f() {
auto f = [] {
Q derived{};
auto &df = derived.de();
df.cf();
return df;
};
constexpr auto dg = f();
}
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #13 from Eric Gallager --- (In reply to Iain Sandoe from comment #12) > (In reply to Fabian Groffen from comment #11) > > Is there a patch or WIP somewhere I can try out or attempt to bring > > forwards? > > I need to bring forward my patches to the latest master, will post a link > here when that is done (it won't be soon - mainly because all time is being > soaked up with work on the arm64 port for Apple Silicon). At present, I am > also trying to resolve some of the other (smaller) objective-c issues > preventing us from parsing the system headers. > > > My attempts at porting the 4.2.1 Apple changes to 10.1 seem to have failed > > as I get some weird "byref undeclared" errors whenever a __block var is > > encountered. I must admit I'm not really well versed with GCC's code. > > The apple-4.2.1 branch is, indeed, too far removed from current trunk - and > as far as I understand, we would not be permitted to apply those patches > anyway, since they were not counted as contributed (not present on the FSF > servers). IANAL - but that's how I understand the rules. If we could get in touch with an actual lawyer to review which laws specifically are getting in the way here, that could be helpful. I won my election to the New Hampshire State Legislature so if there's any legislation I could pass to make it legal to apply those patches here in NH, I'd love to know how to write it. > > It would be great to have more than one person working on this - I will post > here when the current WIP is published somewhere.
[Bug testsuite/97680] [11 Regression] new test case c-c++-common/zero-scratch-regs-10.c in r11-4578 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680 --- Comment #5 from Iain Sandoe --- I added xfail-if for powerpc-darwin (8,9, 10 and 11). https://gcc.gnu.org/pipermail/gcc-cvs/2020-November/336720.html Since i don't think I will have time this cycle to implement it (there are much more pressing demands on the time) - at least the tests will then XPASS if/when the impl. is done. Presumably anyone else in the same situation could append their target to the XFAIL.
[Bug c/97746] ice in vect_init_pattern_stmt, at tree-vect-patterns.c:116
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97746
Zhendong Su changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
--- Comment #1 from Zhendong Su ---
Another reproducer for the same crash with "-O1 -ftree-slp-vectorize":
[566] % gcctk -O1 -ftree-slp-vectorize small.c
during GIMPLE pass: slp
small.c: In function ‘d’:
small.c:6:6: internal compiler error: in vect_init_pattern_stmt, at
tree-vect-patterns.c:116
6 | void d() {
| ^
0x18be859 vect_init_pattern_stmt
../../gcc-trunk/gcc/tree-vect-patterns.c:115
0x18bfeee vect_set_pattern_stmt
../../gcc-trunk/gcc/tree-vect-patterns.c:133
0x18bfeee vect_mark_pattern_stmts
../../gcc-trunk/gcc/tree-vect-patterns.c:5327
0x18bfeee vect_pattern_recog_1
../../gcc-trunk/gcc/tree-vect-patterns.c:5443
0x18c86e1 vect_pattern_recog(vec_info*)
../../gcc-trunk/gcc/tree-vect-patterns.c:5583
0x10054a2 vect_slp_analyze_bb_1
../../gcc-trunk/gcc/tree-vect-slp.c:4124
0x10054a2 vect_slp_region
../../gcc-trunk/gcc/tree-vect-slp.c:4226
0x1006a8a vect_slp_bbs
../../gcc-trunk/gcc/tree-vect-slp.c:4374
0x1006fcc vect_slp_function(function*)
../../gcc-trunk/gcc/tree-vect-slp.c:4460
0x10090f2 execute
../../gcc-trunk/gcc/tree-vectorizer.c:1437
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/97753] New: ice in operator[], at vec.h:880
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97753
Bug ID: 97753
Summary: ice in operator[], at vec.h:880
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C++ code:
long a[6];
void d() {
for (int c; c; c++)
for (int b = 0; b < 8; b++)
((char *)&a[c])[b] = c;
}
compiled by recent gcc trunk and compiler flag -O3, does this:
during GIMPLE pass: vect
bug669.cc: In function ‘void d()’:
bug669.cc:2:6: internal compiler error: in operator[], at vec.h:880
2 | void d() {
| ^
0x861070 vec<_slp_tree*, va_heap, vl_embed>::operator[](unsigned int)
../../trunk.git/gcc/vec.h:880
0x861070 vec<_slp_tree*, va_heap, vl_ptr>::operator[](unsigned int)
../../trunk.git/gcc/vec.h:1451
0x861070 vectorizable_induction(_loop_vec_info*, _stmt_vec_info*, gimple**,
_slp
_tree*, vec*)
../../trunk.git/gcc/tree-vect-loop.c:7929
0x1487820 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
../../trunk.git/gcc/tree-vect-stmts.c:10782
The problem first seems to appear sometime between 20201104 and 20201105.
[Bug middle-end/94083] inefficient soft-float x!=Inf code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083
The original bug report was apparently lost in the sourceware/gcc migration
back in the spring and I didn't notice until now.
This testcase
int foo(void) {
volatile float f, g;
intn;
f = __builtin_huge_valf();
g = __builtin_huge_valf();
n += 1 - (f != __builtin_huge_valf());
return n;
}
compiled for soft-float with -O2, and looking at the original tree dump I see
f = Inf;
g = Inf;
SAVE_EXPR ;, n =
SAVE_EX
PR + n;;
So the C front end converted the f != Inf compare to a f u<=
compare, but the problem here is that the !=
operation is a single libcall, but u<= is two libcalls. So code that should
have a single soft-float libcall ends up with two. First a call to __unordsf2,
then a compare and branch, and then a call to __lesf2. This is a
de-optimization.
Perhaps we can convert the f u<= back to f != Inf in
the optimization to get a single libcall. Or maybe we can add unordered
soft-float libcalls like ulesf2.
[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #38 from CVS Commits ---
The releases/gcc-10 branch has been updated by Peter Bergner
:
https://gcc.gnu.org/g:06a191027749834e628f2c2bdd2256108bf532e9
commit r10-8992-g06a191027749834e628f2c2bdd2256108bf532e9
Author: Richard Biener
Date: Wed Oct 21 14:28:45 2020 -0500
rs6000: MMA type causes an ICE in ranger pass due to incompatible types
PR97360 shows a problem in how we create our PXI and POI modes that cause
an ICE in the ranger pass. The problem seems to be that the extra call
to build_distinct_type_copy() also creates new TYPE_{MIN,MAX}_VALUEs that
are not compatible/the same as the base type itself. The simple "fix" is
to actually remove the unneeded build_distinct_type_copy(), since according
to richi, the types returned from make_unsigned_type() are already
distinct.
gcc/
2020-10-21 Richard Biener
PR target/97360
* config/rs6000/rs6000-call.c (rs6000_init_builtins): Remove call
to
build_distinct_type_copy().
gcc/testsuite/
2020-10-21 Martin Liska
PR target/97360
* gcc.target/powerpc/pr97360.c: New test.
Co-authored-by: Andrew MacLeod
Co-authored-by: Martin Liska
(cherry picked from commit 84cc3370d6d5972fe495b2114fb32f7b4a49a98d)
[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360 Peter Bergner changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #39 from Peter Bergner --- I pushed the fix to the GCC 10 release brnahc, so this is fixed everywhere now.
[Bug libgcc/97754] New: arm/lib1funcs.S (RETLDM): CFI may be incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97754
Bug ID: 97754
Summary: arm/lib1funcs.S (RETLDM): CFI may be incorrect
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: martingalvan at sourceware dot org
Target Milestone: ---
Hi all, I'm looking at the RETLDM macro for the ARM libgcc code:
.macro RETLDM regs=, cond=, unwind=, dirn=ia
#if defined (__INTERWORKING__)
.ifc "\regs",""
ldr\condlr, [sp], #8
.else
# if defined(__thumb2__)
pop\cond{\regs, lr}
# else
ldm\cond\dirn sp!, {\regs, lr}
# endif
.endif
.ifnc "\unwind", ""
/* Mark LR as restored. */
97: cfi_pop 97b - \unwind, 0xe, 0x0
.endif
bx\cond lr
#else
<...>
.endm
Here we can see that for the __INTERWORKING__ case, some CFI data is emitted if
we have an 'unwind' argument. However, I believe this may be wrong if a RETLDM
macro appears in the middle of another function. For the __INTERWORKING__ case,
the resulting output would be e.g:
pop {r4, r5, lr}
cfi_pop <...>
bx lr
Here, 'cfi_pop' would affect the rest of the function unless the caller is
careful enough to restore the CFI status for lr after doing RETLDM. This can
happen e.g. if we pass a 'cond' argument, which means the branch may not be
taken.
Unless I'm mistaken, the way to fix this would be to introduce a couple of
.cfi_remember/restore_state directives:
.ifnc "\unwind", ""
/* Mark LR as restored. */
.cfi_remember_state
97: cfi_pop 97b - \unwind, 0xe, 0x0
.endif
bx\cond lr
.ifnc "\unwind", ""
.cfi_restore_state
.endif
If this is correct, I'll send in a patch to add this change.
Speaking of this file, I have a couple more questions:
1. The file is defining macros like cfi_start, cfi_push, etc which insert the
CFI data directly in binary form. Why can't we use gas' .cfi_* directives as we
do elsewhere? If we can, I'll send a separate patch to add this change as well.
2. Why is the __INTERWORKING__ macro only defined for ARMv4t? I'm not saying
that this is wrong, just curious.
Thanks.
