[Bug tree-optimization/85497] [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85497 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-23 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r257441.
[Bug testsuite/85483] Many failures on test gcc.target/aarch64/sve/vcond_1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85483 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- So fixed.
[Bug c/85487] Support '#pragma region' and '#pragma endregion' to allow code folding with Visual Studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85487 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-23 Component|preprocessor|c Version|unknown |8.0.1 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Richard Biener --- Confirmed.
[Bug c++/85498] Unable to resolve function name with inferred return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85498 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener --- dup *** This bug has been marked as a duplicate of bug 85499 ***
[Bug c++/85499] Unable to resolve function with inferred return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85499 --- Comment #2 from Richard Biener --- *** Bug 85498 has been marked as a duplicate of this bug. ***
[Bug middle-end/85496] [6/7/8 Regression] internal compiler error: in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85496 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-23 Ever confirmed|0 |1
[Bug tree-optimization/85497] [8/9 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85497 Richard Biener changed: What|Removed |Added Keywords||deferred Priority|P3 |P2 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |9.0 Summary|[8 Regression] [graphite] |[8/9 Regression] [graphite] |ICE in set_codegen_error, |ICE in set_codegen_error, |at |at |graphite-isl-ast-to-gimple. |graphite-isl-ast-to-gimple. |c:206 |c:206 --- Comment #2 from Richard Biener --- This touches more cases where SCOP analysis only is checking scev_analyzable_p () but code-gen uses scalar_evolution_in_region with a loop != def-loop. The artificial scev-max-expr-size makes one succeed and the other fail. Note more complex cases could ICE because of the same reason or because some use site is really not analyzable. IMHO scev_analyzable_p should get a 'loop' arg. Nothing for 8.1.
[Bug middle-end/85496] [6/7/8 Regression] internal compiler error: in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85496
Jakub Jelinek changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org,
||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
template class complex;
template complex operator* (complex, complex);
template <> struct complex { _Complex float f; };
struct A { complex g, h; complex &foo () { return h; } };
void
bar (complex a, complex c)
{
A b;
b.foo () = c * a;
}
expand_normal returns an expression of the right mode:
(parallel:SC [
(expr_list:REG_DEP_TRUE (reg:DI 104)
(const_int 0 [0]))
])
but we do:
6987 /* Handle calls that return values in multiple non-contiguous
locations.
6988 The Irix 6 ABI has examples of this. */
6989 if (GET_CODE (temp) == PARALLEL)
6990{
6991 HOST_WIDE_INT size = int_size_in_bytes (TREE_TYPE (exp));
6992 scalar_int_mode temp_mode
6993= smallest_int_mode_for_size (size * BITS_PER_UNIT);
6994 rtx temp_target = gen_reg_rtx (temp_mode);
6995 emit_group_store (temp_target, temp, TREE_TYPE (exp), size);
6996 temp = temp_target;
6997}
and starting from that temp has a wrong mode (DImode) rather than the desired
one (SCmode). I must say I really don't understanding this change, before that
temp_mode was GET_MODE (temp) except when it was BLKmode or VOIDmode.
Eric, can you please have a look?
[Bug middle-end/85496] [6/7/8 Regression] internal compiler error: in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85496 Jakub Jelinek changed: What|Removed |Added Severity|critical|normal
[Bug tree-optimization/85478] ICE with single element vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85478 --- Comment #7 from Andreas Krebbel --- The cross from comment #6 did not trigger the problem because I accidentally built it with --disable-checking. Dropping this and adding --with-long-double-128 triggers the ICE on a full cross as well as on a cross without sysroot.
[Bug c++/85500] New: auto specifier incorrectly defining new function when initializing from function identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85500 Bug ID: 85500 Summary: auto specifier incorrectly defining new function when initializing from function identifier Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: aaron_sami_abassi at hotmail dot com Target Milestone: --- When initializing an auto variable from a function identifier, GNU C++ is incorrectly defining a new function. The statement: auto variable_name = function_name; Will define a function or nested function depending on the scope of reference named variable_name. This is not a pedantically correct interpretation of the C++ source code as only variables can be initialized. Also be careful in your bug correction: auto function_name; Should still be treated as a function declaration when initialization is not present (as of C++14).
[Bug c++/65923] False positive for warning about literal operator suffix and using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65923 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |8.0
[Bug libstdc++/66689] comp_ellint_3 and ellint_3 return garbage values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66689 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |8.0
[Bug middle-end/85496] [6/7/8 Regression] internal compiler error: in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85496 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou --- Fixing.
[Bug libstdc++/85494] implementation of random_device on mingw is useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85494 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-23 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to ookawa_mi from comment #0) > As the main purpose of random_device is seed of mt19937, it is inappropriate. It has more uses than just that. > Please replace to REAL random number generator by rand_s or CryptoAPI. Confirmed.
[Bug middle-end/85496] [6/7/8 Regression] internal compiler error: in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85496
--- Comment #3 from Eric Botcazou ---
> but we do:
> 6987/* Handle calls that return values in multiple non-contiguous
> locations.
> 6988 The Irix 6 ABI has examples of this. */
> 6989if (GET_CODE (temp) == PARALLEL)
> 6990 {
> 6991HOST_WIDE_INT size = int_size_in_bytes (TREE_TYPE (exp));
> 6992scalar_int_mode temp_mode
> 6993 = smallest_int_mode_for_size (size * BITS_PER_UNIT);
> 6994rtx temp_target = gen_reg_rtx (temp_mode);
> 6995emit_group_store (temp_target, temp, TREE_TYPE (exp), size);
> 6996temp = temp_target;
> 6997 }
>
> and starting from that temp has a wrong mode (DImode) rather than the
> desired one (SCmode). I must say I really don't understanding this change,
> before that temp_mode was GET_MODE (temp) except when it was BLKmode or
> VOIDmode.
As stated in the ChangeLog, the point was to avoid clobbering MODE, but I agree
that it's probably a little too bold.
[Bug tree-optimization/85478] ICE with single element vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85478 --- Comment #8 from Andreas Krebbel --- The problem is similar to PR83753 but with a different call-chain. Richard Sandiford fixed it by adding: /* First cope with the degenerate case of a single-element vector. */ if (known_eq (TYPE_VECTOR_SUBPARTS (vectype), 1U)) *memory_access_type = VMAT_CONTIGUOUS; to get_group_load_store_type. This prevents vect_grouped_store_supported from being called for single element vectors. For this PR vect_grouped_store_supported is called from vect_analyze_loop_2. I don't know if there is also a better way to deal with it in the caller?! But regardless I think vect_grouped_store_supported should return false for single element vectors as proposed in: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00758.html
[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-04-23 Ever confirmed|0 |1 --- Comment #14 from Jonathan Wakely --- Installing your own glibc in a new location and trying to point GCC to it with -I /FaF/glibc/include is not "the default settings". As has been explained, you need to rebuild GCC to use the new glibc. To do that you also need the Linux kernel headers in the same sysroot tree, i.e. /FaF/glibc Did you try that yet?
[Bug c++/85499] Unable to resolve function with inferred return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85499 --- Comment #3 from Jonathan Wakely --- This is an exact dup of an older bug that I can't find right now.
[Bug c++/85500] auto specifier incorrectly defining new function when initializing from function identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85500
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Jonathan Wakely ---
This is not a valid bug report, see https://gcc.gnu.org/bugs/ for what we
require.
(In reply to ASA from comment #0)
> When initializing an auto variable from a function identifier, GNU C++ is
> incorrectly defining a new function.
>
> The statement:
>
> auto variable_name = function_name;
>
> Will define a function or nested function depending on the scope of
> reference named variable_name. This is not a pedantically correct
> interpretation of the C++ source code as only variables can be initialized.
Here's a complete program:
#include
int function_name() { return 0; }
auto variable_name = function_name;
static_assert(std::is_pointer::value, "");
int main()
{
return (*variable_name)();
}
This shows that your statement is not creating a new function, it's a pointer
to function. You cannot copy functions or declare them as variables, so the
'auto' declaration performs function-to-pointer decay and so deduces a function
pointer type not a function type.
>
> Also be careful in your bug correction:
>
> auto function_name;
>
> Should still be treated as a function declaration when initialization is not
> present (as of C++14).
No, that's not valid as a function declaration.
[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80506 --- Comment #2 from Jonathan Wakely --- This is fixed on trunk, I'm wondering whether to backport it to gcc-6-branch and gcc-7-branch.
[Bug target/85486] [og7, nvptx] ref-1.C fails with vector length 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85486 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Tom de Vries --- https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=708bb8f7b274553d29242a2d28684b2bc5e734bb : ... [nvptx] Force vl32 if calling vector-partitionable routines 2018-04-23 Tom de Vries PR target/85486 * omp-offload.c (oacc_fn_attrib_level): Remove static. * omp-offload.h (oacc_fn_attrib_level): Declare. * config/nvptx/nvptx.c (has_vector_partitionable_routine_calls_p): New function. (nvptx_goacc_validate_dims): Force vector length 32 if offloading function calls vector-partitionable routines. * testsuite/libgomp.oacc-c-c++-common/pr85486-2.c: New test. * testsuite/libgomp.oacc-c-c++-common/pr85486-3.c: New test. * testsuite/libgomp.oacc-c-c++-common/pr85486.c: New test. ... Patch with test-cases committed. Marking resolved-fixed.
[Bug libstdc++/82644] Non-standard hypergeometric special functions defined in strict modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82644 --- Comment #4 from Jonathan Wakely --- This is only fixed on trunk, but I think I planned to fix it for gcc-7 too.
[Bug c++/64194] [C++14] for function template with auto return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64194 Jonathan Wakely changed: What|Removed |Added CC||gcc at dcousens dot com --- Comment #6 from Jonathan Wakely --- *** Bug 85499 has been marked as a duplicate of this bug. ***
[Bug c++/85499] Unable to resolve function with inferred return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85499 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Jonathan Wakely --- Ah it's one I reported myself. *** This bug has been marked as a duplicate of bug 64194 ***
[Bug c++/69260] C++14 template instantiation problem in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69260 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- Almost certainly a dup of PR 64194 *** This bug has been marked as a duplicate of bug 64194 ***
[Bug c++/64194] [C++14] for function template with auto return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64194 Jonathan Wakely changed: What|Removed |Added CC||wuyongwei at gmail dot com --- Comment #7 from Jonathan Wakely --- *** Bug 69260 has been marked as a duplicate of this bug. ***
[Bug c++/64194] [C++14] for function template with auto return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64194
--- Comment #8 from Jonathan Wakely ---
Slightly different testcase from PR 69620 which is probably the same issue:
struct function {
template
function(F);
};
template
auto sum(T1 x, T2 y)
{
return x + y;
}
template
auto sum(T1 x, T2 y, Targ... args)
{
return sum(x + y, args...);
}
int main()
{
//(void)sum;
function f = sum;
}
ded.cc: In function 'int main()':
ded.cc:21:18: error: conversion from '' to
non-scalar type 'function' requested
function f = sum;
^~
It works if the function is instantiated first by uncommenting the first line
in main.
[Bug c++/60531] template function not resolved when comparing functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60531 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-23 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- Confirmed. Possibly related to PR 64194 although that involves functions with deduced return types, and this one doesn't.
[Bug target/85491] [8 Regression] nbench LU Decomposition test 15% slower than GCC 7, 30% slower than peak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85491
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2018-04-23
Blocks|79703 |
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Summary|[8 Regression] scimark LU |[8 Regression] nbench LU
|Decomposition test 15% |Decomposition test 15%
|slower than GCC 7, 30% |slower than GCC 7, 30%
|slower than peak|slower than peak
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Err, nbench, not scimark2. So it is indeed r257734. With r257734 we use
avx128 instead of avx256 for nbench1.c:4293:
for(j=0;j
where the important difference over the polyhedron case is that the
stride step is constant and thus the AGU costs are cheaper. In addition
to that when using AVX128 the loop is unrolled by a factor of 8 putting
pressure on the FMA units where as you can see above the AVX256 variant
is unrolled by a factor of four only. When removing -funroll-loops
the performance difference is 6474.8 [6495.3] vs. 4946.8 [4779.1] [numbers
in brackets are those with -funroll-loops on the machine used for debugging].
Given the original case was with variable step an adjustment of the change
could look like
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 259556)
+++ gcc/config/i386/i386.c (working copy)
@@ -50550,8 +50550,9 @@ ix86_add_stmt_cost (void *data, int coun
construction cost by the number of elements involved. */
if (kind == vec_construct
&& stmt_info
- && stmt_info->type == load_vec_info_type
- && stmt_info->memory_access_type == VMAT_ELEMENTWISE)
+ && STMT_VINFO_TYPE (stmt_info) == load_vec_info_type
+ && STMT_VINFO_MEMORY_ACCESS_TYPE (stmt_info) == VMAT_ELEMENTWISE
+ && TREE_CODE (DR_STEP (STMT_VINFO_DATA_REF (stmt_info))) != INTEGER_CST)
{
stmt_cost = ix86_builtin_vectorization_cost (kind, vectype, misalign);
stmt_cost *= TYPE_VECTOR_SUBPARTS (vectype);
which restores performance.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79703
[Bug 79703] [meta-bug] SciMark 2.0 performance issues
[Bug target/85491] [8 Regression] nbench LU Decomposition test 15% slower than GCC 7, 30% slower than peak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85491 Richard Biener changed: What|Removed |Added Blocks||84037, 84016 --- Comment #2 from Richard Biener --- I'll throw it on our tester. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84016 [Bug 84016] [8 Regression] Spec2000 regression around Jan 14 and Jan 19 2018 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84037 [Bug 84037] [8 Regression] Speed regression of polyhedron benchmark since r256644
[Bug tree-optimization/85478] ICE with single element vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85478 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-23 CC||rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #9 from Richard Biener --- Ok, confirmed. The following fixes it: Index: gcc/tree-vect-loop.c === --- gcc/tree-vect-loop.c(revision 259558) +++ gcc/tree-vect-loop.c(working copy) @@ -2492,6 +2492,7 @@ again: unsigned int size = STMT_VINFO_GROUP_SIZE (vinfo); tree vectype = STMT_VINFO_VECTYPE (vinfo); if (! vect_store_lanes_supported (vectype, size, false) + && ! known_eq (TYPE_VECTOR_SUBPARTS (vectype), 1U) && ! vect_grouped_store_supported (vectype, size)) return false; FOR_EACH_VEC_ELT (SLP_INSTANCE_LOADS (instance), j, node) Andreas, can you test this? It's pre-approved if you make it before RC1.
[Bug c++/50462] poor diagnostics for missing parenthesis in call to method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50462
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=77711
--- Comment #3 from Jonathan Wakely ---
See PR 77711 comment 1 where I said:
>It's irrelevant that we can't resolve which overload to use, once name lookup
>finds that 'foo' is a function then a.foo is not a valid expression under any
>circumstances.
The same applies here. The expression 'v.size' (when not followed by
parentheses) is not valid C++. Instead of trying to resolve which operator<<
can be used for a nonsense expression we should just give an error immediately
after parsing v.size, which is what Clang does:
50462.cc:10:18: error: reference to non-static member function must be called;
did you mean to call it with no arguments?
{ std::cout << v.size; }
~~^~~~
()
50462.cc:5:6: note: possible target for call
int size() {};
^
50462.cc:6:6: note: possible target for call
int size() const {};
^
1 error generated.
[Bug tree-optimization/85501] New: missed if-conversion / phiopt trick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85501
Bug ID: 85501
Summary: missed if-conversion / phiopt trick
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Blocks: 53947, 85466
Target Milestone: ---
PR85466 shows
For the "if" case, llvm turns:
if (myVector[n] > 0.5){
result[n] = 0.8f;
}
else {
result[n] = 0.1f;
}
into
const float tab[2] = { .8f, .1f };
result[n] = tab[item > .5f];
which is a neat trick. Profitability is not without questions though
(if you'd do this to scalar code).
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85466
[Bug 85466] Performance is slow when doing 'branchless' conditional style math
operations
[Bug lto/85422] [openacc] ICE at cfgloop.c:468: segfault in flow_loops_find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85422 --- Comment #10 from Tom de Vries --- Created attachment 44006 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44006&action=edit Adjusted patch with testcase (In reply to Richard Biener from comment #9) > adjusted patch: Added testcase. Build x86_64 with nvptx accelerator on top of trunk r259523 and tested libgomp, no issues found. Doing x86_64 bootstrap and reg-test now.
[Bug c++/77711] Add fix-it hints for missing parentheses in member function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77711 --- Comment #8 from Jonathan Wakely --- My patch doesn't help for comment 2 because we never call invalid_nonstatic_member_fn when the nonsense expression refers to the name of an overloaded member function. Instead we perform overload resolution hoping that one of the overloads will disambiguate a.foo, which will never happen. See Bug 50462 for a case very similar to comment 2 where we end up with over 200 lines of noise simply because don't stop as soon as we see an invalid member function call, and try to perform overload resolution on it instead.
[Bug c++/80311] Bound member functions extension allows bogus conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80311
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-04-23
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> struct X {
> int i = 0;
> int f() { return i; }
> };
>
> int main() {
> X x;
> using fp = int (*)();
> auto f = (fp)(&X::f);
> return f();
> }
>
> This bogus attempt to use
> https://gcc.gnu.org/onlinedocs/gcc/Bound-member-functions.html fails,
> because there is no 'this' pointer provided for the call to the bound
> function.
I should have been clearer about how it "fails".
It compiles (and gives a warning about use of the extension unless you silence
it with -Wno-pmf-conversions) but then segfaults at runtime.
> G++ should notice this and give a diagnostic, even with -Wno-pmf-conversions.
The bug is that we shouldn't accept invalid uses of the extension. Valid uses
of the extension should give warnings that can be controlled by
-Wno-pmf-conversions as happens today, but invalid uses should be an error
(maybe controllable by -fpermissive) not produce code that is guaranteed to
segfault.
[Bug c++/50462] poor diagnostics for missing parenthesis in call to method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50462
--- Comment #4 from Jonathan Wakely ---
I think the original example in this bug is the same as PR 77711 comment 2. It
can be reduced to:
struct ostream { };
void operator<<(ostream, int) { }
void operator<<(ostream, void*) { }
void operator<<(ostream, char*) { }
struct V
{
int size() { return 0; };
};
void print(V v)
{ ostream() << v.size; }
Now GCC's output fits on a single page:
50462.cc: In function 'void print(V)':
50462.cc:14:13: error: no match for 'operator<<' (operand types are 'ostream'
and '')
{ ostream() << v.size; }
~~^
50462.cc:3:6: note: candidate: void operator<<(ostream, int)
void operator<<(ostream, int) { }
^~~~
50462.cc:3:6: note: no known conversion for argument 2 from '' to 'int'
50462.cc:4:6: note: candidate: void operator<<(ostream, void*)
void operator<<(ostream, void*) { }
^~~~
50462.cc:4:6: note: no known conversion for argument 2 from '' to 'void*'
50462.cc:5:6: note: candidate: void operator<<(ostream, char*)
void operator<<(ostream, char*) { }
^~~~
50462.cc:5:6: note: no known conversion for argument 2 from '' to 'char*'
But Clang still does better, not bothering to perform overload resolution
hoping v.size will turn into something meaningful. Clang just says:
50462.cc:10:18: error: reference to non-static member function must be called;
did you mean to call it with no arguments?
{ std::cout << v.size; }
~~^~~~
()
50462.cc:5:6: note: possible target for call
int size() {};
^
50462.cc:6:6: note: possible target for call
int size() const {};
^
1 error generated.
So it doesn't bother telling us that every overload of operator<< is unusable
for a nonsense expression, which is much better.
EDG says:
"50462.cc", line 14: error: a pointer to a bound function may only be used to
call the function
{ ostream() << v.size; }
^
1 error detected in the compilation of "50462.cc".
This is a little cryptic and suggests there might be some non-standard
extension confusing matters.
[Bug c++/19741] suboptimal error message for template functions (as opposed to non-templates)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19741
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2006-01-15 21:09:27 |2018-4-23
--- Comment #7 from Jonathan Wakely ---
Reduced to remove the irrelevant parts and demonstrate the difference between
calls to non-template and temploid functions:
template void Func( T ) { }
typedef bool (*op_func)( int );
void Exec( op_func ) { }
template
struct Op
{
static void Exec( op_func ) { }
};
int main( )
{
Exec( &Func );
Op::Exec( &Func );
}
t.cc:17:20: error: no matches converting function 'Func' to type 'op_func' {aka
'bool (*)(int)'}
Exec( &Func );
^
t.cc:1:27: note: candidate is: 'template void Func(T)'
template void Func( T ) { }
^~~~
t.cc:18:29: error: no matching function for call to 'Op::Exec()'
Op::Exec( &Func );
^
t.cc:10:15: note: candidate: 'static void Op::Exec(op_func) [with T = int;
op_func = bool (*)(int)]'
static void Exec( op_func ) { }
^~~~
t.cc:10:15: note: no known conversion for argument 1 from '' to 'op_func' {aka 'bool (*)(int)'}
[Bug lto/85422] [openacc] ICE at cfgloop.c:468: segfault in flow_loops_find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85422 Tom de Vries changed: What|Removed |Added Keywords||ice-on-valid-code, patch --- Comment #11 from Tom de Vries --- patch submitted: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01041.html
[Bug c++/16070] print something useful instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16070
--- Comment #8 from Jonathan Wakely ---
Reduced:
template struct basic_ios { };
template basic_ios& endl(basic_ios& x) { return x; }
template
voidBar(const T&) {}
voidBar(int) {}
int main() {
Bar(endl);
}
GCC trunk says:
16070.cc: In function 'int main()':
16070.cc:9:13: error: no matching function for call to 'Bar()'
Bar(endl);
^
16070.cc:5:9: note: candidate: 'template void Bar(const T&)'
voidBar(const T&) {}
^~~
16070.cc:5:9: note: template argument deduction/substitution failed:
16070.cc:9:13: note: couldn't deduce template parameter 'T'
Bar(endl);
^
16070.cc:6:9: note: candidate: 'void Bar(int)'
voidBar(int) {}
^~~
16070.cc:6:9: note: no known conversion for argument 1 from '' to 'int'
Clang says:
16070.cc:9:5: error: no matching function for call to 'Bar'
Bar(endl);
^~~
16070.cc:6:9: note: candidate function not viable: no overload of 'endl'
matching 'int' for 1st argument
voidBar(int) {}
^
16070.cc:5:9: note: candidate template ignored: couldn't infer template
argument 'T'
voidBar(const T&) {}
^
1 error generated.
EDG says:
"16070.cc", line 9: error: no instance of overloaded function "Bar" matches the
argument list
argument types are: ()
Bar(endl);
^
1 error detected in the compilation of "16070.cc".
I don't think there's *much* room for improvement in GCC's output (but see
below).
(In reply to Ivan Godard from comment #4)
> Hence what the compiler should produce is something like:
>
> Error: file crud line 234
> Cannot identify unique overload in call. Arguments are:
> Foo(void (*)(int))
> Foo(void (*)(char))
> note: some arguments are overloaded functions; at least one of the overloads
> must match in its argument position
This isn't possible in your example, because endl is a function template, not
just an overloaded function. That means the list of possible overloads is
infinite, so you can't possible list all the overloads. There's only one
function template, but an unbounded set of possible specializations of that
function template that could be deduced in correct code.
> overloads considered were:
>file foo line 17: ..; does not match because no possible
> argument satisfied the template at argument position 1
>file bar line 23: ..; does not match because no possible
> argument satisfied the template at argument position 1
>file baz line 5: ..; does not match because no argument 1 can
> be coerced to type int
This is pretty much what GCC does nowadays (and it can result in hundreds of
lines of output, which has its own problems, but at least all the information
is there for the user to inspect if they want to).
One possible improvement I can imagine would be to special case some
diagnostics to give a different message when there's an overload set involved.
That seems to be what Clang does. Instead of:
16070.cc:6:9: note: no known conversion for argument 1 from '' to 'int'
we could have a custom diagnostic for the case, like:
16070.cc:6:9: note: no overload of 'endl' can be converted to 'int'
Personally I don't find this any clearer, but maybe people less used to GCC's
errors would prefer it.
[Bug libitm/85489] config/x86/sjlj.S should use unsigned integer to unwind shadow stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85489 --- Comment #1 from hjl at gcc dot gnu.org --- Author: hjl Date: Mon Apr 23 12:29:00 2018 New Revision: 259559 URL: https://gcc.gnu.org/viewcvs?rev=259559&root=gcc&view=rev Log: x86/cet: Use unsigned integer to unwind shadow stack Use unsigned integer to unwind shadow stack by replacing jle with jbe and jg with ja. PR target/85489 * config/x86/sjlj.S (GTM_longjmp): Replace jle/jg with jbe/ja. Modified: trunk/libitm/ChangeLog trunk/libitm/config/x86/sjlj.S
[Bug libitm/85489] config/x86/sjlj.S should use unsigned integer to unwind shadow stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85489 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #2 from H.J. Lu --- Fixed.
[Bug target/81652] [meta-bug] -fcf-protection=full bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 Bug 81652 depends on bug 85489, which changed state. Bug 85489 Summary: config/x86/sjlj.S should use unsigned integer to unwind shadow stack https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85489 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/16070] print something useful instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16070 --- Comment #9 from Jonathan Wakely --- I suppose we could potentially have a special case for: 16070.cc:9:13: note: couldn't deduce template parameter 'T' It could say: 16070.cc:9:13: note: couldn't deduce template parameter 'T' from an overloaded function, because all overloads are equally good.
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #38 from rguenther at suse dot de --- On Fri, 20 Apr 2018, msebor at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 > > --- Comment #35 from Martin Sebor --- > Here are the proposed changes: > > Pointer Provenance: > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2219.htm#proposed-technical-corrigendum Mostly sound. It seems to mirror what GCC does in points-to analysis, also tracking pointers through integer (parts). I wonder about the Unary arithmetic operator restriction - consider 'long p' with single provenance, then +p has empty provenance. That's just odd. I'd have expected for example -(-p) to have the same provenance as p. GCC just uses the same provenance as the operand for unary operators. GCC also tracks provenance through floating-poing values (yes! matlab generated code passes pointers through two FP parameters...). The clarification to 6.5.9#6 is most welcome since it matches what GCC expects (and GCC doesn't implement -fno-provenance - well, I guess you could use -fno[-ipa]-pta. > Trap Representations: > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2220.htm#proposed-technical-corrigendum Not sure what the proposed change to 6.3.2.1p2 means (if there's similar wording when actually "reading" an uninitialized value elsewhere). Iff that makes reads from uninitialized memory well-defined I miss the definition of said well-defined behavior. In any case removing the dependence on address-taken or not is good. Instead of making it explicitely defined maybe remove this sentence. For 6.3.1.2 I'd say 'the behavior is undefined' instead of 'an unspecified value'. What's the reason to be not specific here when one doesn't want 'undefined' behavior? In particular in the light of 3.19.3 if the _Bool is a trap representation then this looks suspicious. So the idea is to make uninitialized reads return unspecified values but not invoke undefined behavior. Offhand I don't know a place where GCC would take advantage of the difference. I think for both we can derive 1 == uninitialized to be true or false statically as we like but we cannot infer a path to be not taken when it would access an uninitialized location (I think we don't do that at the moment). The change doesn't require us to compute x == x to true if x is uninitialized? > Unspecified Values: > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2221.htm#proposed-technical-corrigendum So for 3.4 GCC implements a more strict handling for example treating a * as not undefined given there's a value of a (zero) where the expression is fully defined. So with 3.4 '0 + ' invokes undefined behavior? That seems to contradict the proposed wording - there isn't any value of where the add invokes undefined behavior. More to the point why do they introduce undefined behavior here rather than an unspecified value? This means that on it's own is fine to use but computing + is not. And in 3.5 they go on and specify '0 * ' as unspecified?! So I think they go a bit too far here on several accounts. I'd like to keep reading from uninitialized memory invoking undefined behavior - if it's just unspecified how are sanitizers supposed to handle this given the compiler is now free to schedule such reads to places where they might not have been executed before. The changes do not seem to cover effective types and aliasing as far as I can see (or I missed a non-linked proposed corrigendum). N doesn't seem to have any.
Re: Wrong snprintf optimalization
On Sat, Apr 21, 2018 at 11:47:52AM +0200, Dávid Bolvanský wrote:
> Hello,
>
> #include
> int main(void)
> {
> char buf[10];
> return snprintf(buf, 0, "string");
> }
>
> GCC simplifies it to
> main:
> mov eax, 6
> ret
>
> but 0 is correct I think.
No, 6 seems to be the correct value:
If the output was truncated due to this limit, then the return value
is the number of characters (excluding the terminating null byte) which would
have been written
to the final string if enough space had been available.
Marek
[Bug target/85434] Address of stack protector guard spilled to stack on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434 --- Comment #7 from Thomas Preud'homme --- (In reply to Thomas Preud'homme from comment #6) > (In reply to Thomas Preud'homme from comment #3) > > > > My feeling is that the target patterns should also do the address > > computation, ie stack_protect_set and stack_protect_test would take that MEM > > of symbol_ref instead of expanding it first. > > The more I think about it the more I think it's the only way to guarantee > the guard's address does not end up in a register that could be spilled. The > spilling itself is more likely to happen when reading the GOT entry that > holds the guard's address is not represented by an UNSPEC because then the > address computed when setting the canari is reused when doing the > comparison. UNSPEC seems to prevent that (even though it's not > UNSPEC_VOLATILE). I'm experimenting with a patch to mark the MEM to access the GOT entry as volatile in ARM backend in order to prevent CSE. It works on this PR's testcase so will give bootstrap and regression testing a try. As I said, this doesn't fully solve the underlying issue IMO but together with implementation of stack_protect_set and stack_protect_test in ARM it should make stack protector as reliable on ARM targets as on AArch64.
bug ? : -Wpedantic -Wconversion 'short a=1; a-=1;' complaint
I really do not think a '-Wpedantic -Wconversion' warning should
be generated for the following code, but it is
(with GCC 6.4.1 and 7.3.1 on RHEL-7.5 Linux) :
$ echo '
typedef unsigned short U16_t;
static void f(void)
{ U16_t a = 1;
a-=1;
}' > t.C;
$ g++ -std=c++14 -Wall -Wextra -pedantic -Wc++11-compat \
-Wconversion -Wcast-align -Wcast-qual -Wfloat-equal \
-Wmissing-declarations -Wlogical-op -Wpacked -Wundef \
-Wuninitialized -Wvariadic-macros -Wwrite-strings \
-c t.C -o /dev/null
t.C:4:8: conversion to 'U16_t' {aka short unsigned int} from 'int' may \
alter its value.
I don't control the warning flags, as shown above,
that my code must compile against without warnings.
But I think the warning issued above is a GCC bug -
when I look at the code generated, (compile with -S -o t.S),
I see it actually does generate a 16-bit subtraction, which
is what I wanted:
.file "t.C"
.text
.globl _Z1fv
.type _Z1fv, @function
_Z1fv:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movw$1, -2(%rbp)
subw$1, -2(%rbp)
# this is a two-byte word subtract
nop
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size _Z1fv, .-_Z1fv
.ident "GCC: (GNU) 6.4.1 20180321"
.section.note.GNU-stack,"",@progbits
So why is it generating a warning about conversion from 'int' ?
I don't see any conversion going on in assembler output -
(cast 'a' to a temporary int, do 32-bit integer subtraction of '1'
from it, and store sign-extended low 16 bits in 'a' - this is NOT
what is going on here ) .
I'd like to remove either '-pedantic' or '-Wconversion' from the
warning flags, but this is not an option .
Please can GCC fix this warning bug eventually - I have to wade
through code that generates thousands of them per compilation.
Thanks & Best Regards,
Jason
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #39 from joseph at codesourcery dot com --- On Thu, 19 Apr 2018, jameskuyper at verizon dot net wrote: > Code which relies upon this feature to implement a C-style approximation to > inheritance has been fairly common, which is precisely why the C committee > decided to create this rule, to make sure such code had well-defined behavior. To make sure such code had well-defined behavior *notwithstanding the adjacent rule (in C90) that access to a non-current union member was otherwise implementation-defined*. Not overriding any other rule elsewhere in the standard that might make such accesses undefined, such as type-based aliasing, even though it's subsequently sometimes been interpreted in connection with such rules (and access to a non-current union member is now non-normatively specified in a footnote as type punning).
[Bug tree-optimization/85501] missed if-conversion / phiopt trick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85501 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- For scalar code or vector code? For the latter, it needs a gather load, which is expensive...
[Bug rtl-optimization/85423] [8 Regression] ICE in code_motion_process_successors, at sel-sched.c:6403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85423 --- Comment #5 from Andrey Belevantsev --- Author: abel Date: Mon Apr 23 15:19:06 2018 New Revision: 259563 URL: https://gcc.gnu.org/viewcvs?rev=259563&root=gcc&view=rev Log: PR rtl-optimization/85423 * sel-sched-ir.c (has_dependence_note_mem_dep): Only discard dependencies to debug insns when the previous insn is non-debug. * gcc.dg/pr85423.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr85423.c Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched-ir.c trunk/gcc/testsuite/ChangeLog
[Bug gcov-profile/85201] [GCOV] A statement with two && operators and a comma operator in the for loop body is wrongly marked in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85201 --- Comment #2 from Yibiao Yang --- @marxin Is this a real bug? or this bug is only default behavior?
[Bug target/85503] New: [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85503 Bug ID: 85503 Summary: [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- Created attachment 44007 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44007&action=edit preprocessed source seen with r259383 on the trunk, powerpc64le-linux-gnu, worked around with -O2: $ g++ -Wall -std=gnu++11 -c -O2 gasgraphics.ii during RTL pass: swaps : In function �int GasGraphicsItemcreateOnHoverHandler()�: :211:1: internal compiler error: in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 Please submit a full bug report, with preprocessed source if appropriate. gcc configured with --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --with-as=/usr/bin/powerpc64le-linux-gnu-as --with-ld=/usr/bin/powerpc64le-linux-gnu-ld --program-suffix=-8 --program-prefix=powerpc64le-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --enable-plugin --enable-default-pie --with-system-zlib --disable-libphobos --enable-objc-gc=auto --enable-secureplt --with-cpu=power8 --enable-targets=powerpcle-linux --disable-multilib --enable-multiarch --disable-werror --with-long-double-128 --enable-checking=release --build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu
[Bug target/85503] [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85503
--- Comment #1 from Matthias Klose ---
$ cat gasgraphics.ii
# 3 "" 3
namespace b {
template < int c > struct d { static constexpr int e = c; };
typedef d< false > f;
template < typename g > struct h { typedef g i; };
template < typename > class j;
template < bool, bool, typename... > struct aa;
struct k {
template < typename n, typename... q >
static h< decltype(n()(q()...)) > o(int);
};
template < typename p, typename... t > struct aa< false, false, p, t... > : k {
typedef decltype(o< p, t... >(0)) i;
};
template < typename p, typename... t >
struct ab : aa< f::e, f::e, p, t... >::i {};
template < typename p, typename... t > struct j< p(t...) > : ab< p, t... > {};
} enum { r, s };
typedef long x;
template < typename > struct ac;
template < typename y > struct ac< y & > { typedef y i; };
template < typename y > struct j { typedef typename b::j< y >::i i; };
template < typename > struct ad;
template < typename > struct ae;
template < typename > class af;
template < typename, int ag, int ah, int = 0, int = ag, int = ah > class ai;
template < typename > class aj;
template < typename, typename, typename > class ak;
template < typename > class al;
template < typename > struct am;
template < typename > struct an;
template < typename y > struct ao { typedef typename am< y >::i i; };
struct aq {
typedef const ai< double, 2, 1 > &ar;
};
template < typename as > struct at { typedef aj< as > i; };
template < typename as > struct au { typedef typename at< as >::i i; };
template < typename av > av aw(const typename an< av >::i *);
template < typename av, int > av az(const typename an< av >::i *ba) {
return aw< av >(ba);
}
typedef __attribute__((altivec(vector__))) double bb;
template <> struct am< double > { typedef bb i; };
template <> struct an< bb > { typedef double i; };
template <> bb aw(const double *ba) { return __builtin_vec_vsx_ld(0, ba); }
struct bc {
template < typename av > bd(av a) { bd(a); }
};
struct be {
double operator()(const, const);
};
template < typename as > class bf : public ae< as > {
public:
typedef typename ad< as >::bg bg;
ae< as >::bh;
enum { bi };
bg bj() const;
template < typename bk > bg bl(const bk &) const;
};
template < typename as > class aj : public bf< as > {
public:
bf< as >::bh;
template < typename bm > ak< be, const as, const bm > operator-(bm bn) {
return ak< be, const as, const bm >(bh(), bn);
}
bo() const;
al< as > array() { return bh(); }
};
template < typename as > struct ae {
const as &bh() const { return *static_cast< const as * >(this); }
};
template < typename > struct bp;
template < typename > struct bq;
template < typename y > struct br : bq< y > {
br(y bs) : bq< y >(bs) {}
};
template < typename y > struct br< const y > : br< y > {
br(const y &bs) : br< y >(bs) {}
};
template < typename as > struct br< af< as > > {
typedef as bt;
br(const bt &m) : bu(m.bv()) {}
template < int bw, typename ay > ay bx(x, x by) {
return az< ay, bw >(bu + by);
}
const typename bt::bg *bu;
};
template < typename bg, int u, int bz, int ca, int cb, int cc >
struct br< ai< bg, u, bz, ca, cb, cc > > : br< af< ai< bg, u, bz > > > {
typedef ai< bg, u, bz > cd;
br(const cd &m) : br< af< cd > >(m) {}
};
template < typename bk, typename ce, typename cf >
struct br< ak< bk, ce, cf > > : bp< ak< bk, ce, cf > > {
br(ak< bk, ce, cf > bs) : bp< ak< bk, ce, cf > >(bs) {}
};
template < typename bk, typename ce, typename cf >
struct bp< ak< bk, ce, cf > > {
bp(ak< bk, ce, cf > bs) : cg(), ch(bs.ci()) {}
template < int bw, typename ay > ay bx(x cj, x by) {
return ch.template bx< bw, ay >(cj, by);
}
ce cg;
br< cf > ch;
};
template < typename cd > struct v {
typedef typename ac< typename cd::ck >::i cl;
v(cl &arg) : cn(arg) {}
template < int bw, typename ay > ay bx(x cj, x by) {
return cn.template bx< bw, ay >(cj, by);
}
br< cl > cn;
};
template < typename cm > struct bq< al< cm > > : v< al< cm > > {
bq(al< cm > w) : v< al< cm > >(w.dd()) {}
};
template < typename as > class ap : public bf< as > {};
template < int ax > struct co { double array[ax]; };
template < int ax > class cq {
co< ax > bu;
public:
const double *bv() const { return bu.array; }
};
template < typename as > class af : public at< as >::i {
public:
typedef typename at< as >::i cp;
cq< cp::bi > cs;
const typename ad< as >::bg *bv() const { return cs.bv(); }
};
template < typename cr, int ag, int ah, int cu, int ct, int cw >
struct ad< ai< cr, ag, ah, cu, ct, cw > > {
typedef cr bg;
};
template < typename, int ag, int ah, int, int, int >
class ai : public af< ai< double, ag, ah > > {
typedef ai cv;
};
template < typename bk, typename ce, typename cf >
struct ad< ak< bk, ce, cf > > {
typedef typename j< bk(typename ce::bg, typename cf::bg) >::i bg;
};
template < typename, typename, typename > class z;
template < typename bk, typename cy, typename cx >
class ak : public z< bk, cy, cx >
[Bug target/85503] [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85503 Segher Boessenkool changed: What|Removed |Added Priority|P3 |P1 CC||segher at gcc dot gnu.org
[Bug c++/85470] [7/8 Regression] Strange error about "call to non-constexpr function"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85470 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/85503] [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85503 Segher Boessenkool changed: What|Removed |Added Target Milestone|--- |8.0
[Bug middle-end/85504] New: Bogus -Wrestrict warning with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85504 Bug ID: 85504 Summary: Bogus -Wrestrict warning with -fsanitize=undefined Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de Target Milestone: --- Created attachment 44008 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44008&action=edit unreduced test case This happens with current openssl trunk revision: ./config -fsanitize=undefined --strict-warnings $ gcc -I. -Icrypto/include -Iinclude -fPIC -pthread -m64 -Wa,--noexecstack -DDEBUG_UNUSED -DPEDANTIC -pedantic -Wno-long-long -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wswitch -Wsign-compare -Wmissing-prototypes -Wshadow -Wformat -Wtype-limits -Wundef -Werror -Wall -O3 -fsanitize=undefined -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -DNDEBUG -MMD -MF crypto/engine/eng_ctrl.d.tmp -MT crypto/engine/eng_ctrl.o -c -o crypto/engine/eng_ctrl.o crypto/engine/eng_ctrl.c crypto/engine/eng_ctrl.c: In function 'ENGINE_ctrl': crypto/engine/eng_ctrl.c:110:23: error: 'strcpy' source argument is the same as destination [-Werror=restrict] return strlen(strcpy(s, cdp->cmd_name)); ^~~~ while I can use -save-temps with this one (see attached test case) there is another file which does not show the error with -save-temps: $ gcc -I. -Iinclude -Iapps -pthread -m64 -Wa,--noexecstack -DDEBUG_UNUSED -DPEDANTIC -pedantic -Wno-long-long -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wswitch -Wsign-compare -Wmissing-prototypes -Wshadow -Wformat -Wtype-limits -Wundef -Werror -Wall -O3 -fsanitize=undefined -DNDEBUG -MMD -MF apps/s_client.d.tmp -MT apps/s_client.o -c -o apps/s_client.o apps/s_client.c In file included from /usr/include/string.h:635, from apps/s_client.c:15: apps/s_client.c: In function 's_client_main': apps/s_client.c:2585:13: error: '__builtin_strncpy' source argument is the same as destination [-Werror=restrict] strncpy(sbuf, mbuf, 2); ^~~ $ gcc -I. -Iinclude -Iapps -pthread -m64 -Wa,--noexecstack -DDEBUG_UNUSED -DPEDANTIC -pedantic -Wno-long-long -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wswitch -Wsign-compare -Wmissing-prototypes -Wshadow -Wformat -Wtype-limits -Wundef -Werror -Wall -O3 -fsanitize=undefined -DNDEBUG -MMD -MF apps/s_client.d.tmp -MT apps/s_client.o -c -o apps/s_client.o apps/s_client.c -save-temps
Re: bug ? : -Wpedantic -Wconversion 'short a=1; a-=1;' complaint
On 04/23/2018 07:11 AM, Jason Vas Dias wrote:
I really do not think a '-Wpedantic -Wconversion' warning should
be generated for the following code, but it is
(with GCC 6.4.1 and 7.3.1 on RHEL-7.5 Linux) :
$ echo '
typedef unsigned short U16_t;
static void f(void)
{ U16_t a = 1;
a-=1;
}' > t.C;
g...@gcc.gnu.org dropped as inappropriate. Note that gcc-bugs is output
from our bugzilla. Sending email here isn't very useful. If you want a
bug fixed, you have to open a bug report in bugzilla. You can ask gcc
questions on gcc help.
In the C language, operations on short and always performed as int, and
then converted back to short. Subtracting one may generated a negative
number, which converted to unsigned short will change its value. So the
warning seems appropriate.
Note that -Wconversion means different things in different gcc versions.
It current meaning is to warn for any implicit cast that may change a
value. This is not very useful in general, and is not an option that I
would recommend using by default. In old gcc versions, -Wconversion
warned for code that had different meaning in K&R C and ISO C. That was
useful, and some people used that option by default, but the option no
longer does that.
You can silence the warning by adding an explicit cast.
a = (U16_t) (a - 1);
Jim
[Bug target/85503] [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85503
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-04-23
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek ---
Can't reproduce on the original testcase, can on the reduced one, which isn't
really good (requires -fpermissive and has lots of UB in it).
Anyway, on that #c1 testcase this started with r254437.
Now, if I modify the reduced testcase this way, so it doesn't need -fpermissive
and has __builtin_unreachable () in the spots where falling through into the
end of a function/method returning non-void, it starts earlier with r253240:
namespace b {
template < int c > struct d { static constexpr int e = c; };
typedef d< false > f;
template < typename g > struct h { typedef g i; };
template < typename > class j;
template < bool, bool, typename... > struct aa;
struct k {
template < typename n, typename... q >
static h< decltype(n()(q()...)) > o(int);
};
template < typename p, typename... t > struct aa< false, false, p, t... > : k {
typedef decltype(o< p, t... >(0)) i;
};
template < typename p, typename... t >
struct ab : aa< f::e, f::e, p, t... >::i {};
template < typename p, typename... t > struct j< p(t...) > : ab< p, t... > {};
} enum { r, s };
typedef long x;
template < typename > struct ac;
template < typename y > struct ac< y & > { typedef y i; };
template < typename y > struct j { typedef typename b::j< y >::i i; };
template < typename > struct ad;
template < typename > struct ae;
template < typename > class af;
template < typename, int ag, int ah, int = 0, int = ag, int = ah > class ai;
template < typename > class aj;
template < typename, typename, typename > class ak;
template < typename > class al;
template < typename > struct am;
template < typename > struct an;
template < typename y > struct ao { typedef typename am< y >::i i; };
struct aq {
typedef const ai< double, 2, 1 > &ar;
};
template < typename as > struct at { typedef aj< as > i; };
template < typename as > struct au { typedef typename at< as >::i i; };
template < typename av > av aw(const typename an< av >::i *);
template < typename av, int > av az(const typename an< av >::i *ba) {
return aw< av >(ba);
}
typedef __attribute__((altivec(vector__))) double bb;
template <> struct am< double > { typedef bb i; };
template <> struct an< bb > { typedef double i; };
template <> bb aw(const double *ba) { return __builtin_vec_vsx_ld(0, ba); }
struct bc {
template < typename av > int bd(av a) { bd(a); __builtin_unreachable (); }
};
struct be {
double operator()(const int, const int);
};
template < typename as > class bf : public ae< as > {
public:
typedef typename ad< as >::bg bg;
using ae< as >::bh;
enum { bi };
bg bj() const;
template < typename bk > bg bl(const bk &) const;
};
template < typename as > class aj : public bf< as > {
public:
using bf< as >::bh;
template < typename bm > ak< be, const as, const bm > operator-(bm bn) {
return ak< be, const as, const bm >(bh(), bn);
}
int bo() const;
al< as > array() { return bh(); }
};
template < typename as > struct ae {
const as &bh() const { return *static_cast< const as * >(this); }
};
template < typename > struct bp;
template < typename > struct bq;
template < typename y > struct br : bq< y > {
br(y bs) : bq< y >(bs) {}
};
template < typename y > struct br< const y > : br< y > {
br(const y &bs) : br< y >(bs) {}
};
template < typename as > struct br< af< as > > {
typedef as bt;
br(const bt &m) : bu(m.bv()) {}
template < int bw, typename ay > ay bx(x, x by) {
return az< ay, bw >(bu + by);
}
const typename bt::bg *bu;
};
template < typename bg, int u, int bz, int ca, int cb, int cc >
struct br< ai< bg, u, bz, ca, cb, cc > > : br< af< ai< bg, u, bz > > > {
typedef ai< bg, u, bz > cd;
br(const cd &m) : br< af< cd > >(m) {}
};
template < typename bk, typename ce, typename cf >
struct br< ak< bk, ce, cf > > : bp< ak< bk, ce, cf > > {
br(ak< bk, ce, cf > bs) : bp< ak< bk, ce, cf > >(bs) {}
};
template < typename bk, typename ce, typename cf >
struct bp< ak< bk, ce, cf > > {
bp(ak< bk, ce, cf > bs) : cg(), ch(bs.ci()) {}
template < int bw, typename ay > ay bx(x cj, x by) {
return ch.template bx< bw, ay >(cj, by);
}
ce cg;
br< cf > ch;
};
template < typename cd > struct v {
typedef typename ac< typename cd::ck >::i cl;
v(cl &arg) : cn(arg) {}
template < int bw, typename ay > ay bx(x cj, x by) {
return cn.template bx< bw, ay >(cj, by);
}
br< cl > cn;
};
template < typename cm > struct bq< al< cm > > : v< al< cm > > {
bq(al< cm > w) : v< al< cm > >(w.dd()) {}
};
template < typename as > class ap : public bf< as > {};
template < int ax > struct co {
[Bug c++/85470] [7/8 Regression] Strange error about "call to non-constexpr function"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85470 --- Comment #4 from Jason Merrill --- Author: jason Date: Mon Apr 23 19:11:22 2018 New Revision: 259571 URL: https://gcc.gnu.org/viewcvs?rev=259571&root=gcc&view=rev Log: PR c++/85470 - wrong error with static data member. * decl.c (check_initializer): Check DECL_INITIALIZED_IN_CLASS_P. * typeck2.c (store_init_value): Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/extern_template-4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/typeck2.c
[Bug target/85503] [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85503
--- Comment #3 from Jakub Jelinek ---
base here is a constant pool constant, containing
(const:DI (plus:DI (symbol_ref:DI ("_ZN26OnHoverHandlerGraphicsItem7cornersE")
[flags 0xc0] )
(const_int 8 [0x8])))
so this fails both because the symbol_ref in there isn't a constant pool
address, but address of a static data member, but also because it isn't a
symbol_ref, but address within that static data member.
At least for now, I think easiest is to adjust const_load_sequence_p, so that
it better matches what replace_swapped_load_constant expects.
--- gcc/config/rs6000/rs6000-p8swap.c.jj2018-03-20 22:05:58.0
+0100
+++ gcc/config/rs6000/rs6000-p8swap.c 2018-04-23 21:12:22.259096174 +0200
@@ -593,8 +593,10 @@ const_load_sequence_p (swap_web_entry *i
remove this special test. */
rtx const_vector = get_pool_constant (base);
if (GET_CODE (const_vector) == SYMBOL_REF
- && !CONSTANT_POOL_ADDRESS_P (const_vector))
- return false;
+ && CONSTANT_POOL_ADDRESS_P (const_vector))
+ const_vector = get_pool_constant (const_vector);
+ if (GET_CODE (const_vector) != CONST_VECTOR)
+ return false;
}
}
}
[Bug c++/85505] New: Code accepted despite a variable using the same name as a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85505
Bug ID: 85505
Summary: Code accepted despite a variable using the same name
as a parameter
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: abbeyj+gcc at gmail dot com
Target Milestone: ---
The following code is accepted by GCC although I believe it should not be.
This happens on all versions and all platforms currently available on
https://gcc.godbolt.org/
Test case:
class C {
public:
~C();
};
void Foo(int data) {
switch (0) {
case 0:;
}
C b;
float data;
}
I would have expected an error here like:
error: declaration of 'float data' shadows a parameter
Note that you do get this error if you comment out (seemingly unrelated) lines
from the test case.
Shout out to https://embed.cs.utah.edu/creduce/ for providing the above reduced
test case.
[Bug target/85503] [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85503 --- Comment #4 from kelvin at gcc dot gnu.org --- Thanks for chasing down the cause of the problem. I agree with the patch proposed by jakub, assuming it passes regression testing. Would you like me to do the testing? (be glad to unless someone else has already started the effort.)
[Bug fortran/85506] New: ICE in gfc_assign_data_value, at fortran/data.c:448
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85506 Bug ID: 85506 Summary: ICE in gfc_assign_data_value, at fortran/data.c:448 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Extracted from pr70870, in consequence of pr70870 comment 7. $ cat z1.f90 program p type t integer :: n end type type(t), pointer :: z => null() data z%n / 3 / print *, z%n end $ gfortran-8-20180422 -c z1.f90 f951: internal compiler error: in gfc_assign_data_value, at fortran/data.c:448 0x68e5a9 gfc_assign_data_value(gfc_expr*, gfc_expr*, __mpz_struct*, __mpz_struct (*) [1]) ../../gcc/fortran/data.c:448 0x711339 check_data_variable ../../gcc/fortran/resolve.c:15477 0x711682 traverse_data_var ../../gcc/fortran/resolve.c:15606 0x71c151 resolve_data ../../gcc/fortran/resolve.c:15661 0x71c151 resolve_types ../../gcc/fortran/resolve.c:16479 0x7177ec gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16568 0x700f4a resolve_all_program_units ../../gcc/fortran/parse.c:6060 0x700f4a gfc_parse_file() ../../gcc/fortran/parse.c:6310 0x747e2f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/70870] Segmentation violation in gfc_assign_data_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70870 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #8 from G. Steinmetz --- > These should have a new PR opened for them. Done. This is now pr85506.
[Bug fortran/85507] New: [8 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2258
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85507 Bug ID: 85507 Summary: [8 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2258 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Introduced recently, between 20180325 and 20180422 : $ cat z1.f90 program p integer :: x[*] x[2] = x end $ cat z2.f90 subroutine sub (n, x) integer :: n, x[*] x[n] = x end $ cat z3.f90 subroutine sub (n, x) integer :: i, n, x[*] do i = 2, n x[i] = x end do end $ gfortran-8-20180325 -c z1.f90 -fcoarray=lib $ $ gfortran-8-20180422 -c z1.f90 -fcoarray=lib z1.f90:3:0: x[2] = x internal compiler error: in gfc_dep_resolver, at fortran/dependency.c:2258 0x7405a4 gfc_dep_resolver(gfc_ref*, gfc_ref*, gfc_reverse*) ../../gcc/fortran/dependency.c:2258 0x792595 conv_caf_send ../../gcc/fortran/trans-intrinsic.c:1863 0x798a8d gfc_conv_intrinsic_subroutine(gfc_code*) ../../gcc/fortran/trans-intrinsic.c:10981 0x74abb2 trans_code ../../gcc/fortran/trans.c:1887 0x771f99 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6507 0x701120 translate_all_program_units ../../gcc/fortran/parse.c:6121 0x701120 gfc_parse_file() ../../gcc/fortran/parse.c:6324 0x747e2f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug c++/85470] [7 Regression] Strange error about "call to non-constexpr function"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85470 --- Comment #5 from Jason Merrill --- Author: jason Date: Mon Apr 23 19:58:57 2018 New Revision: 259572 URL: https://gcc.gnu.org/viewcvs?rev=259572&root=gcc&view=rev Log: PR c++/85470 - wrong error with static data member. * decl.c (check_initializer): Check DECL_INITIALIZED_IN_CLASS_P. * typeck2.c (store_init_value): Likewise. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/extern_template-4.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/decl.c branches/gcc-7-branch/gcc/cp/typeck2.c
[Bug c++/85505] Code accepted despite a variable using the same name as a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85505 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-23 Ever confirmed|0 |1
[Bug c/85508] New: runtime error in config/i386/i386.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85508
Bug ID: 85508
Summary: runtime error in config/i386/i386.c
Product: gcc
Version: 8.0
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:
typedef char a;
typedef b;
c;
d(e) {
for (;; f()) {
a *g;
b h;
for (h = 0; h < 27; h++)
for (e = 0; e <= 26; ++e)
*g &= c;
}
}
compiled by a ubsan version of recent gcc trunk, I get this:
$ ~/gcc/results/bin/gcc -c -O3 -w bug431.c
../../trunk/gcc/config/i386/i386.c:43197:33: runtime error: left shift of
negative value -1
$ ~/gcc/results/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/dcb/gcc/results/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.259553.ubsan/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk/configure --prefix=/home/dcb/gcc/results.259553.ubsan
--with-build-config=bootstrap-ubsan --disable-multilib --disable-werror
--enable-checking=df,extra,fold,rtl,yes --enable-languages=c,c++,fortran
Thread model: posix
gcc version 8.0.1 20180422 (experimental) (GCC)
$
File ../../trunk/gcc/config/i386/i386.c line 43197 is
x = gen_int_mode (INTVAL (x) << 8, HImode);
[Bug target/85503] [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85503 --- Comment #5 from Jakub Jelinek --- Created attachment 44009 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44009&action=edit gcc8-pr85503.patch Full untested patch. I've started bootstrap/regtest on powerpc64-linux (power7, big endian), unfortunately gcc112 is down and so I can't test on powerpc64le-linux. If you could do that, I'd appreciate it.
[Bug c++/85470] [7 Regression] Strange error about "call to non-constexpr function"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85470 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed.
[Bug c++/85509] New: auto (function pointer) undermining inline expansion with GCC but not LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85509 Bug ID: 85509 Summary: auto (function pointer) undermining inline expansion with GCC but not LLVM Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: aaron_sami_abassi at hotmail dot com Target Milestone: --- Created attachment 44010 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44010&action=edit This code demonstrates the problem The attached code when compiled with optimizations in LLVM (I'm using 5.0.0) expands the call inline through the auto variables PerformQuickly and PerformSafely. Adding const solves the issue but GCC should be able to determine that the function pointer can never be modified and inline the function invocations as LLVM is doing.
[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744 --- Comment #15 from Peter VARGA --- (In reply to Jonathan Wakely from comment #14) > Installing your own glibc in a new location and trying to point GCC to it > with -I /FaF/glibc/include is not "the default settings". > > As has been explained, you need to rebuild GCC to use the new glibc. To do > that you also need the Linux kernel headers in the same sysroot tree, i.e. > /FaF/glibc > > Did you try that yet? It would be very much appreciated if you could provide me the missing settings for my configure command line arguments which look for the moment like this: --prefix=/FaF --infodir=/FaF/share/info --mandir=/FaF/share/man --libdir=/FaF/lib64 --libexecdir=/FaF/lib64 --enable-languages=c,c++ --enable-checking=release --with-gmp=/FaF/ --with-mpfr=/FaF --with-gmc=/FaF --with-gxx-include-dir=/FaF/include/c++/7.3 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-7.3 --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux --disable-multilib
[Bug c++/85500] INCORRECTLY REPORTED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85500
--- Comment #2 from ASA ---
(In reply to Jonathan Wakely from comment #1)
> This is not a valid bug report, see https://gcc.gnu.org/bugs/ for what we
> require.
>
> (In reply to ASA from comment #0)
> > When initializing an auto variable from a function identifier, GNU C++ is
> > incorrectly defining a new function.
> >
> > The statement:
> >
> > auto variable_name = function_name;
> >
> > Will define a function or nested function depending on the scope of
> > reference named variable_name. This is not a pedantically correct
> > interpretation of the C++ source code as only variables can be initialized.
>
>
> Here's a complete program:
>
> #include
>
> int function_name() { return 0; }
>
> auto variable_name = function_name;
>
> static_assert(std::is_pointer::value, "");
>
> int main()
> {
> return (*variable_name)();
> }
>
> This shows that your statement is not creating a new function, it's a
> pointer to function. You cannot copy functions or declare them as variables,
> so the 'auto' declaration performs function-to-pointer decay and so deduces
> a function pointer type not a function type.
>
> >
> > Also be careful in your bug correction:
> >
> > auto function_name;
> >
> > Should still be treated as a function declaration when initialization is not
> > present (as of C++14).
>
> No, that's not valid as a function declaration.
It was a late night. You are correct that it is producing a function pointer,
not a new function instance. I re-submitted the bug as id 85509 with correct
details and sample code. Thank you, my apologies for not sleeping before I
tried to submit a bug report.
[Bug middle-end/85496] [6/7/8 Regression] internal compiler error: in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85496 --- Comment #5 from Eric Botcazou --- Author: ebotcazou Date: Mon Apr 23 20:19:39 2018 New Revision: 259574 URL: https://gcc.gnu.org/viewcvs?rev=259574&root=gcc&view=rev Log: PR middle-end/85496 * expr.c (store_field): In the bitfield case, if the value comes from a function call and is returned in registers by means of a PARALLEL, do not change the mode of the temporary unless BLKmode and VOIDmode. Added: trunk/gcc/testsuite/g++.dg/torture/pr85496.C Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/85496] [6/7/8 Regression] internal compiler error: in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85496 --- Comment #6 from Eric Botcazou --- Author: ebotcazou Date: Mon Apr 23 20:29:22 2018 New Revision: 259576 URL: https://gcc.gnu.org/viewcvs?rev=259576&root=gcc&view=rev Log: PR middle-end/85496 * expr.c (store_field): In the bitfield case, if the value comes from a function call and is returned in registers by means of a PARALLEL, do not change the mode of the temporary unless BLKmode and VOIDmode. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr85496.C - copied unchanged from r259574, trunk/gcc/testsuite/g++.dg/torture/pr85496.C Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/expr.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug middle-end/85496] [6/7/8 Regression] internal compiler error: in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85496 --- Comment #7 from Eric Botcazou --- Author: ebotcazou Date: Mon Apr 23 20:31:17 2018 New Revision: 259577 URL: https://gcc.gnu.org/viewcvs?rev=259577&root=gcc&view=rev Log: PR middle-end/85496 * expr.c (store_field): In the bitfield case, if the value comes from a function call and is returned in registers by means of a PARALLEL, do not change the mode of the temporary unless BLKmode and VOIDmode. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr85496.C - copied unchanged from r259574, trunk/gcc/testsuite/g++.dg/torture/pr85496.C Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/expr.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug middle-end/85496] [6/7/8 Regression] internal compiler error: in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85496 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Eric Botcazou --- .
[Bug c++/68374] G++ -Wshadow doesn't warn about static member shadowing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68374 Paolo Carlini changed: What|Removed |Added Status|REOPENED|ASSIGNED CC|paolo.carlini at oracle dot com| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #6 from Paolo Carlini --- Mine.
[Bug c++/69560] x86_64: alignof(uint64_t) produces incorrect results with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560 --- Comment #21 from Jason Merrill --- Author: jason Date: Mon Apr 23 20:49:38 2018 New Revision: 259578 URL: https://gcc.gnu.org/viewcvs?rev=259578&root=gcc&view=rev Log: PR c++/69560 - wrong alignof(double) on x86. CWG 1879 - Inadequate definition of alignment requirement. * cp-tree.h (ALIGNOF_EXPR_STD_P): New. * typeck.c (cxx_sizeof_or_alignof_type): Add std_alignof parm. (cxx_sizeof_expr, cxx_sizeof_nowarn, cxx_alignas_expr) (cxx_alignof_expr): Pass it. * parser.c (cp_parser_unary_expression): Pass it. * pt.c (tsubst_copy): Copy it. (tsubst_copy_and_build): Pass it. * decl.c (fold_sizeof_expr): Pass it. Added: trunk/gcc/testsuite/g++.dg/abi/align2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/typeck.c trunk/libcc1/libcp1plugin.cc
[Bug target/85503] [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85503 --- Comment #6 from kelvin at gcc dot gnu.org --- I'll do regression testing on LE and BE (just to be safe) with the new regression test added to the test suite.
[Bug fortran/70870] Segmentation violation in gfc_assign_data_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70870 --- Comment #9 from Steve Kargl --- On Mon, Apr 23, 2018 at 07:46:59PM +, gs...@t-online.de wrote: > > --- Comment #8 from G. Steinmetz --- > > These should have a new PR opened for them. > Done. This is now pr85506. > Thanks. I had intended to open the new PR when I committed the patch, but a severe lack of time has caused a delay.
[Bug rtl-optimization/79916] ICE in Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79916 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #11 from Peter Bergner --- Is this fixed so we mark it as RESOLVED / FIXED ???
[Bug fortran/85510] New: Linking error when accessing a coindexed variable inside an associate block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85510 Bug ID: 85510 Summary: Linking error when accessing a coindexed variable inside an associate block Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: damian at sourceryinstitute dot org Target Milestone: --- The code below compiles without error with -fcoarray=single; whereas compiling with -fcoarray=lib generates the link-time error message shown with the gfortran 7.2.0 and with the trunk dated 20180412. The gfortran command comes from the output of the OpenCoarrays command 'caf --show'. Some of the paths have been shortened manually for presentation purposes: $ cat communicate-inside-associate.f90 module foo contains subroutine bar() integer, save :: i[*]=0 associate(n=>1) print*,i[1] end associate end subroutine end module use foo end $ gfortran -I/opt/opencoarrays/include/OpenCoarrays-2.0.0-26-g840374a_GNU-8.0.1 -fcoarray=lib -Wl,-rpath -Wl,/opt/mpich/3.2/lib -Wl,--enable-new-dtags communicate-inside-associate.f90 /opt/opencoarrays/lib/libcaf_mpi.a /opt/mpich/3.2/lib/libmpifort.so /opt/mpich/3.2/lib/libmpi.so /tmp/ccA8dGYe.o: In function `_caf_init.1.3816': communicate-inside-associate.f90:(.text+0x4d): undefined reference to `caf_token.0.3815' /tmp/ccA8dGYe.o: In function `__foo_MOD_bar': communicate-inside-associate.f90:(.text+0x153): undefined reference to `caf_token.0.3815' collect2: error: ld returned 1 exit status rouson@sourcery-VirtualBox:~/Desktop/Builds/adhoc/src/gnu/nrc/emulated-collectives$ gfortran --version GNU Fortran (GCC) 8.0.1 20180412 (experimental)
[Bug target/83402] PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83402
--- Comment #15 from pc at gcc dot gnu.org ---
Author: pc
Date: Mon Apr 23 21:14:38 2018
New Revision: 259582
URL: https://gcc.gnu.org/viewcvs?rev=259582&root=gcc&view=rev
Log:
rs6000: Fix _mm_slli_epi{32,64} for shift values 16 through 31 and negative
(PR84302)
The powerpc versions of _mm_slli_epi32 and __mm_slli_epi64 in emmintrin.h
do not properly handle shift values between 16 and 31, inclusive.
These are setting up the shift with vec_splat_s32, which only accepts
*5 bit signed* shift values, or a range of -16 to 15. Values above 15
produce an error:
error: argument 1 must be a 5-bit signed literal
Fix is to effectively reduce the range for which vec_splat_s32 is used
to < 32 and use vec_splats otherwise.
Also, __mm_slli_epi{16,32,64}, when given a negative shift value,
should always return a vector of {0}.
PR target/83402
* config/rs6000/emmintrin.h (_mm_slli_epi{16,32,64}):
Ensure that vec_splat_s32 is only called with 0 <= shift < 16.
Ensure negative shifts result in {0}.
gcc/testsuite/
PR target/83402
* gcc.target/powerpc/sse2-psllw-1.c: Refactor and add tests for
several values: positive, negative, and zero.
* gcc.target/powerpc/sse2-pslld-1.c: Same.
* gcc.target/powerpc/sse2-psllq-1.c: Same.
Modified:
branches/ibm/gcc-7-branch/gcc/ChangeLog
branches/ibm/gcc-7-branch/gcc/config/rs6000/emmintrin.h
branches/ibm/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/sse2-pslld-1.c
branches/ibm/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/sse2-psllq-1.c
branches/ibm/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/sse2-psllw-1.c
[Bug sanitizer/85394] [7 Regression] Unable to run sanitized executables on ppc64le Ubuntu and SLES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85394 Martin Liška changed: What|Removed |Added Status|RESOLVED|ASSIGNED Known to work||8.0.1 Resolution|FIXED |--- Assignee|seurer at gcc dot gnu.org |marxin at gcc dot gnu.org Summary|[8 Regression] Unable to|[7 Regression] Unable to |run sanitized executables |run sanitized executables |on ppc64le Ubuntu and SLES |on ppc64le Ubuntu and SLES Known to fail||7.3.0 --- Comment #5 from Martin Liška --- The patch has landed to LLVM repository. I bet it's older than GCC 8 regression, but I can't find any entry in changes where we mention that ASAN is available for ppc64. I'll backport that to GCC 7 at least.
[Bug fortran/85510] Linking error when accessing a coindexed variable inside an associate block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85510 --- Comment #1 from Damian Rouson --- As similar error message results if the associate construct is replaced with a block construct of the form block integer n n=1 print*,i[1] end block The error disappears if the 'block' and 'end block' statements are deleted.
[Bug c++/85500] INCORRECTLY REPORTED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85500 --- Comment #3 from ASA --- > No, that's not valid as a function declaration. Right, it's: auto function_name( params ... ); Again, I should have slept before posting.
[Bug inline-asm/85185] Wider-than-expected load for struct member used as operand of inline-asm with memory clobber at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-04-23
CC||wilson at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #7 from Jim Wilson ---
The problem is exposed in combine, where we take two instructions
(insn 9 8 10 2 (set (reg:DI 72 [ _2 ])
(sign_extend:DI (subreg:HI (reg:SI 75 [ SD.1554.PD.1553 ]) 0)))
"tmp.c"\
:12 92 {extendhidi2}
(expr_list:REG_DEAD (reg:SI 75 [ SD.1554.PD.1553 ])
(nil)))
(insn 10 9 0 2 (parallel [
(asm_operands/v ("magic %0") ("") 0 [
(subreg/s/u:HI (reg:DI 72 [ _2 ]) 0)
]
[
(asm_input:HI ("r") tmp.c:12)
]
[] tmp.c:12)
(clobber (mem:BLK (scratch) [0 A8]))
]) "tmp.c":12 -1
(expr_list:REG_DEAD (reg:DI 72 [ _2 ])
(nil)))
and then produce
insn 10 9 0 2 (parallel [
(asm_operands/v ("magic %0") ("") 0 [
(subreg:HI (reg:SI 75 [ SD.1554.PD.1553 ]) 0)
]
[
(asm_input:HI ("r") tmp.c:12)
]
[] tmp.c:12)
(clobber (mem:BLK (scratch) [0 A8]))
]) "tmp.c":12 -1
(expr_list:REG_DEAD (reg:SI 75 [ SD.1554.PD.1553 ])
(nil)))
We have now lost the truncation and sign-extension. The value passed to the
asm has correct value for the low 16 bits, but has garbage in the high 16 bits.
However, what combine did does not appear wrong by itself. One could argue
that the problem started with the asm, which is taking a HImode argument, even
though this makes little sense on RISC-V, since the only instructions operating
on HImode are the 16-bit load and store instructions. Maybe the asm should use
the sign-extended DImode value directly and assume a DImode input instead of a
HImode input? That would prevent the truncate and sign-extend from being
optimized away, but might be wrong if someone extends the RISC-V ISA to include
instructions that operate directly on HImode values.
I can work around the problem by explicitly casting the asm input to int.
asm("magic %0" :: "r" ((int)sub.a) : "memory");
and now the asm takes SImode input, and the truncate/sign extend can't be
optimized away. Asking the user to change their code doesn't seem like the
right solution though.
[Bug target/85511] New: [X86] Using __builtin_ia32_writeeflags_u32 in 64-bit mode causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85511
Bug ID: 85511
Summary: [X86] Using __builtin_ia32_writeeflags_u32 in 64-bit
mode causes internal compiler error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: craig.topper at gmail dot com
Target Milestone: ---
This code
void foo(unsigned bar) {
return __builtin_ia32_writeeflags_u32(bar);
}
Throws this error in 64-bit mode
during RTL pass: expand
: In function 'foo':
:2:10: internal compiler error: in copy_to_mode_reg, at explow.c:630
return __builtin_ia32_writeeflags_u32(bar);
^~~
mmap: Invalid argument
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug target/85511] [X86] Using __builtin_ia32_writeeflags_u32 in 64-bit mode causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85511
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-04-23
CC||sebastian.peryt at intel dot
com
Ever confirmed|0 |1
--- Comment #1 from H.J. Lu ---
This works:
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index dc80b34f302..427f4e907a6 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -37594,7 +37594,10 @@ rdseed_step:
arg0 = CALL_EXPR_ARG (exp, 0);
op0 = expand_normal (arg0);
if (!general_no_elim_operand (op0, word_mode))
- op0 = copy_to_mode_reg (word_mode, op0);
+ {
+op0 = convert_to_mode (word_mode, op0, 1);
+op0 = copy_to_mode_reg (word_mode, op0);
+ }
emit_insn (gen_push (op0));
emit_insn (gen_pop (gen_rtx_REG (word_mode, FLAGS_REG)));
[Bug target/83660] ICE with vec_extract inside expression statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660 --- Comment #17 from acsawdey at gcc dot gnu.org --- Author: acsawdey Date: Tue Apr 24 00:14:21 2018 New Revision: 259586 URL: https://gcc.gnu.org/viewcvs?rev=259586&root=gcc&view=rev Log: 2018-04-23 Aaron Sawdey Backport from mainline 2018-04-16 Aaron Sawdey PR target/83660 * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Mark vec_extract expression as having side effects to make sure it gets a cleanup point. 2018-04-23 Aaron Sawdey Backport from mainline 2018-04-16 Aaron Sawdey PR target/83660 * gcc.target/powerpc/pr83660.C: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr83660.C Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/rs6000/rs6000-c.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug target/83660] ICE with vec_extract inside expression statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660 --- Comment #18 from acsawdey at gcc dot gnu.org --- Author: acsawdey Date: Tue Apr 24 00:19:43 2018 New Revision: 259590 URL: https://gcc.gnu.org/viewcvs?rev=259590&root=gcc&view=rev Log: 2018-04-23 Aaron Sawdey Backport from mainline 2018-04-16 Aaron Sawdey PR target/83660 * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Mark vec_extract expression as having side effects to make sure it gets a cleanup point. 2018-04-23 Aaron Sawdey Backport from mainline 2018-04-16 Aaron Sawdey PR target/83660 * gcc.target/powerpc/pr83660.C: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr83660.C Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/rs6000/rs6000-c.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/85423] [8 Regression] ICE in code_motion_process_successors, at sel-sched.c:6403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85423 --- Comment #6 from Arseny Solokha --- I guess this PR can be closed now.
[Bug target/83660] ICE with vec_extract inside expression statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660 acsawdey at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #19 from acsawdey at gcc dot gnu.org --- Backported to gcc 7 and 6. Closing again.
[Bug target/85511] [X86] Using __builtin_ia32_writeeflags_u32 in 64-bit mode causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85511 --- Comment #2 from Craig Topper --- Should this builtin even be allowed in 64-bit mode?
[Bug c++/85509] auto (function pointer) undermining inline expansion with GCC but not LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85509 --- Comment #1 from ASA --- I should add that without the static storage duration specifier even without const specified, it does inline the function invocation.
[Bug other/30920] Incorrect splaying that not assures the caching property
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30920 --- Comment #1 from Eric Gallager --- Does the patch still apply?
