Re: [PATCH] Make std::list::iterator == and != global inline friend
On 10/09/2018 01:31 PM, Jonathan Wakely wrote: On 09/10/18 07:25 +0200, François Dumont wrote: As we talked one day I would like to make all iterator operators global for consistency. So here is the patch to do so for std::list iterators. By "global" you mean "non-member", right? Yes, committed with your advised change.
[Bug libstdc++/87544] alloc-size-larger-than incorrectly triggered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544 --- Comment #17 from Marc Glisse --- (In reply to Martin Sebor from comment #16) > The warning code considers just the argument to the call. It doesn't know > (and in the constant case can't tell) where the argument came from. It > would need to be reworked to tell the difference (e.g., along the lines of > -Wmaybe-uninitialized). It might be worth looking into at some point. In doubt, it would be possible to add "maybe" to the warning even in cases where it certainly does it. Otherwise, uninit's always_executed (check post-domination between function entry and the basic block of the instruction) is a simple 1-line check that allows to add 'maybe' only in some cases.
[Bug c++/72751] anonymous union within an anonymous union accepted without diagnostic (i.e. add -Wnested-anon-types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72751 Eric Gallager changed: What|Removed |Added Keywords||diagnostic Blocks||87403 Summary|anonymous union within an |anonymous union within an |anonymous union accepted|anonymous union accepted ||without diagnostic (i.e. ||add -Wnested-anon-types) --- Comment #2 from Eric Gallager --- Since implementing the warning that clang gives would count as a new warning, making this block the meta-bug for new warnings Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug middle-end/69971] repetitive code with __builtin_return_address with a large level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69971 --- Comment #3 from Eric Gallager --- (In reply to Martin Sebor from comment #2) > Yes, the warning does exist to warn about unsafe calls to the function (I > added it here: https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01702.html). > This bug was meant to suggest a way to make the built-in safer by expanding > it as a loop rather than stream of repetitive load instructions, while also > making the code more space efficient. But emitting a loop alone with no > other checks (except for the level) won't actually make the function safer. > The loop would also have to validate the address at each iteration. I'm not > sure how easy, efficient, or reliable this might be. In the of a corrupted > stack it certainly wouldn't be reliable. I dunno, it still doesn't really seem worth it to try to improve code that a warning is already discouraging users from writing... it seems like it would be easier simply to never write __builtin_return_address(1024) in the first place rather than trying to change how the compiler handles it.
Re: introduce --enable-mingw-full32 to default to --large-address-aware
On Oct 10, 2018, JonY <10wa...@gmail.com> wrote: > On 10/10/2018 03:24 AM, Alexandre Oliva wrote: >> On Oct 9, 2018, JonY <10wa...@gmail.com> wrote: >> Now, if you wish it to affect Cygwin as well, I could implement that, >> and drop -mingw from the option name. I'd retain the current defaults >> of each target, unless there's a strong reason to change them. > In that case, no objections then. Thanks. Now, before I proceed, please clarify: did you mean you had no objections to the patch I last proposed, or to the plan in my last paragraph above? -- Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain EngineerFree Software Evangelist
Re: introduce --enable-mingw-full32 to default to --large-address-aware
On 10/10/2018 03:24 AM, Alexandre Oliva wrote: > On Oct 9, 2018, JonY <10wa...@gmail.com> wrote: > >> It is fine to turn it on by default in 32bit MinGW (i686-*-mingw*), but >> leave the defaults as is for others like Cygwin, I am not too sure of >> the effects for Cygwin. > > Cygwin already has --large-address-aware enabled, without an option to > disable it. That makes sense, considering that Cygwin targets Unix > programs, unlikely to have Windows-specific pointer assumptions. > > That's why I phrased the option, and implemented it, as specific to > mingw. > > Now, if you wish it to affect Cygwin as well, I could implement that, > and drop -mingw from the option name. I'd retain the current defaults > of each target, unless there's a strong reason to change them. > In that case, no objections then. signature.asc Description: OpenPGP digital signature
Re: introduce --enable-mingw-full32 to default to --large-address-aware
On Oct 9, 2018, JonY <10wa...@gmail.com> wrote: > It is fine to turn it on by default in 32bit MinGW (i686-*-mingw*), but > leave the defaults as is for others like Cygwin, I am not too sure of > the effects for Cygwin. Cygwin already has --large-address-aware enabled, without an option to disable it. That makes sense, considering that Cygwin targets Unix programs, unlikely to have Windows-specific pointer assumptions. That's why I phrased the option, and implemented it, as specific to mingw. Now, if you wish it to affect Cygwin as well, I could implement that, and drop -mingw from the option name. I'd retain the current defaults of each target, unless there's a strong reason to change them. -- Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain EngineerFree Software Evangelist
[Bug libstdc++/87544] alloc-size-larger-than incorrectly triggered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544 --- Comment #16 from Martin Sebor --- The warning code considers just the argument to the call. It doesn't know (and in the constant case can't tell) where the argument came from. It would need to be reworked to tell the difference (e.g., along the lines of -Wmaybe-uninitialized). It might be worth looking into at some point.
[Bug c++/80351] Inconsistent warning for constexpr auto constant when using initializer list (-Wunused-variable)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80351 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||dodji at gcc dot gnu.org --- Comment #2 from Eric Gallager --- cc-ing diagnostics maintainers
[Bug c++/79707] missing -Wunused-result on an unused new expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79707 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=53215 --- Comment #2 from Eric Gallager --- Possible dup of bug 53215? Even if not, it's still probably at least related to it...
[Bug c++/87571] New: [8/9 Regression] ICE in friend_accessible_p, accessing protected member of template friend inside template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87571
Bug ID: 87571
Summary: [8/9 Regression] ICE in friend_accessible_p, accessing
protected member of template friend inside template
class
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Francois-R.Boyer at PolyMtl dot ca
Target Milestone: ---
The following code fails to compile with g++ 8.1, 8.2 and 9.0.0 20181007 on
godbolt, but compiles with g++ 7.3, clang, MSVC, etc.:
template struct A {
template struct B {
template friend class B;
protected:
int protected_member_;
public:
template int method(const B& other) const {
return other.protected_member_;
}
};
};
int main() {
A::B a;
A::B b;
a.method(b);
}
The error message is:
: In instantiation of 'int A< >::B<
>::method(const A< >::B&)
const [with T = char; = int;
= int]':
:16:13: required from here
:8:20: internal compiler error: in friend_accessible_p, at
cp/search.c:719
8 | return other.protected_member_;
| ~~^
Note that it compiles if we change any of these:
- the member is private instead of protected,
- struct A is not a template, or
- we explicitly 'friend class B;' instead or in addition of the template
friend.
[Bug c++/86747] [8/9 Regression] rejects-valid with redundant friend declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86747
François-R Boyer changed:
What|Removed |Added
CC||Francois-R.Boyer at PolyMtl
dot ca
--- Comment #3 from François-R Boyer ---
I'm not sure if this bug is related or if I should post it as a separate bug
report. I have the same error messages, with a friend class, but in my case it
is not redundant, and happens in a much more complicated case. Here is the
code:
template struct A {
template class> struct B {
template class> friend struct B;
};
};
template struct C { };
A::B b;
The above compiles on latest MSVC, clang, and most other compilers on godbolt,
including g++ 7.3. The error with g++ 8.1, 8.2 and 9.0.0 20181007 on godbolt
is:
: In instantiation of 'struct A::B':
:9:14: required from here
:2:32: error: template parameter 'template template
class'
2 | template class> struct B {
|^
:3:57: error: redeclared here as 'template
class'
3 | template class> friend struct B;
| ^
Note that if struct A is not a template, of if struct B has a simple type
parameter instead of a template template, it compiles.
[committed] Cleanup of libcpp diagnostic callbacks
This patch renames the "error" callback within libcpp to "diagnostic", and uses the pair of enums in cpplib.h, rather than passing two different kinds of "int" around. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Committed to trunk as r264999. gcc/c-family/ChangeLog: * c-common.c (c_option_controlling_cpp_error): Rename to... (c_option_controlling_cpp_diagnostic): ...this, and convert "reason" from int to enum. (c_cpp_error): Rename to... (c_cpp_diagnostic): ...this, converting level and reason to enums. * c-common.h (c_cpp_error): Rename to... (c_cpp_diagnostic): ...this, converting level and reason to enums. * c-opts.c (c_common_init_options): Update for renaming. gcc/fortran/ChangeLog: * cpp.c (gfc_cpp_init_0): Update for renamings. (cb_cpp_error): Rename to... (cb_cpp_diagnostic): ...this, converting level and reason to enums. gcc/ChangeLog: * genmatch.c (error_cb): Rename to... (diagnostic_cb): ...this, converting int params to enums. (fatal_at): Update for renaming. (warning_at): Likewise. (main): Likewise. * input.c (selftest::ebcdic_execution_charset::apply): Update for renaming of... (selftest::ebcdic_execution_charset::on_error): ...this, renaming to... (selftest::ebcdic_execution_charset::on_diagnostic): ...this, converting level and reason to enums. (class selftest::lexer_error_sink): Rename to... (class selftest::lexer_test_options): ...this, renaming field "m_errors" to "m_diagnostics". (selftest::lexer_test_options::apply): Update for renaming of... (selftest::lexer_test_options::on_error): ...this, renaming to... (selftest::lexer_test_options::on_diagnostic): ...this converting level and reason to enums. (selftest::test_lexer_string_locations_raw_string_unterminated): Update for renamings. * opth-gen.awk (struct cpp_reason_option_codes_t): Use enum for "reason". libcpp/ChangeLog: * charset.c (noop_error_cb): Rename to... (noop_diagnostic_cb): ...this, converting params to enums. (cpp_interpret_string_ranges): Update for renaming and enums. * directives.c (check_eol_1): Convert reason to enum. (do_diagnostic): Convert code and reason to enum. (do_error): Use CPP_W_NONE rather than 0. (do_pragma_dependency): Likewise. * errors.c (cpp_diagnostic_at): Convert level and reason to enums. Update for renaming. (cpp_diagnostic): Convert level and reason to enums. (cpp_error): Convert level to enum. (cpp_warning): Convert reason to enums. (cpp_pedwarning): Likewise. (cpp_warning_syshdr): Likewise. (cpp_diagnostic_with_line): Convert level and reason to enums. Update for renaming. (cpp_error_with_line): Convert level to enum. (cpp_warning_with_line): Convert reason to enums. (cpp_pedwarning_with_line): Likewise. (cpp_warning_with_line_syshdr): Likewise. (cpp_error_at): Convert level to enum. (cpp_errno): Likewise. (cpp_errno_filename): Likewise. * include/cpplib.h (enum cpp_diagnostic_level): Name this enum, and move to before struct cpp_callbacks. (enum cpp_warning_reason): Likewise. (cpp_callbacks::diagnostic): Convert params from int to enums. (cpp_error): Convert int param to enum cpp_diagnostic_level. (cpp_warning): Convert int param to enum cpp_warning_reason. (cpp_pedwarning): Likewise. (cpp_warning_syshdr): Likewise. (cpp_errno): Convert int param to enum cpp_diagnostic_level. (cpp_errno_filename): Likewise. (cpp_error_with_line): Likewise. (cpp_warning_with_line): Convert int param to enum cpp_warning_reason. (cpp_pedwarning_with_line): Likewise. (cpp_warning_with_line_syshdr): Likewise. (cpp_error_at): Convert int param to enum cpp_diagnostic_level. * macro.c (create_iso_definition): Convert int to enum. (_cpp_create_definition): Likewise. --- gcc/c-family/c-common.c | 17 +++--- gcc/c-family/c-common.h | 5 +- gcc/c-family/c-opts.c | 2 +- gcc/fortran/cpp.c | 15 +++-- gcc/genmatch.c | 15 ++--- gcc/input.c | 50 +++ gcc/opth-gen.awk| 6 +- libcpp/charset.c| 30 - libcpp/directives.c | 12 ++-- libcpp/errors.c | 66 +++- libcpp/include/cpplib.h | 158 ++-- libcpp/macro.c | 4 +- 12 files changed, 207 insertions(+), 173 deletions(-) diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c index 4bfb145..ac98c9b 100644 --- a/gcc/c-family/c-common.c +++ b/gcc/c-family/c-common.c @@ -6068,7 +6068,7 @@ c_parse_error
[PATCH] Optimize sin(atan(x)) and cos(atan(x)), take 3 (PR tree-optimization/86829)
Fixed all issues pointed in the previous iteration.
There is now a significant change regarding how the sin(atan(x))
constant is calculated, as now it checks for which values such that
computing 1 + x*x won't overflow. There are two reasons for this
change: (1) Avoid an intermediate infinity value when optimizing
cos(atan(x)), and (2) avoid the requirement of separate constants for
sin(atan(x)) and cos(atan(x)), thus making easier to maintain the
code.
gcc/ChangeLog
2018-10-09 Giuliano Belinassi
PR tree-optimization/86829
* match.pd: Added sin(atan(x)) and cos(atan(x)) simplification rules.
* real.c (build_sinatan_real): New function to build a constant equal to the
largest value c such that 1 + c*c will not overflow.
* real.h (build_sinatan_real): Allows this function to be called externally.
gcc/testsuite/gcc.dg/ChangeLog
2018-10-09 Giuliano Belinassi
PR tree-optimization/86829
* gcc.dg/sinatan-1.c: New test.
* gcc.dg/sinatan-2.c: New test.
* gcc.dg/sinatan-3.c: New test.
There are no tests broken in trunk that seems related to this PR.
Index: gcc/match.pd
===
--- gcc/match.pd (revision 264941)
+++ gcc/match.pd (working copy)
@@ -4223,6 +4223,45 @@
(tans (atans @0))
@0)))
+ /* Simplify sin(atan(x)) -> x / sqrt(x*x + 1). */
+ (for sins (SIN)
+ atans (ATAN)
+ sqrts (SQRT)
+ copysigns (COPYSIGN)
+ (simplify
+ (sins (atans:s @0))
+ (with
+ {
+ REAL_VALUE_TYPE r_cst;
+ build_sinatan_real (_cst, type);
+ tree t_cst = build_real (type, r_cst);
+ tree t_one = build_one_cst (type);
+ }
+(if (SCALAR_FLOAT_TYPE_P (type))
+ (cond (le (abs @0) { t_cst; })
+ (rdiv @0 (sqrts (plus (mult @0 @0) { t_one; })))
+ (copysigns { t_one; } @0))
+
+/* Simplify cos(atan(x)) -> 1 / sqrt(x*x + 1). */
+ (for coss (COS)
+ atans (ATAN)
+ sqrts (SQRT)
+ copysigns (COPYSIGN)
+ (simplify
+ (coss (atans:s @0))
+ (with
+ {
+ REAL_VALUE_TYPE r_cst;
+ build_sinatan_real (_cst, type);
+ tree t_cst = build_real (type, r_cst);
+ tree t_one = build_one_cst (type);
+ tree t_zero = build_zero_cst (type);
+ }
+(if (SCALAR_FLOAT_TYPE_P (type))
+ (cond (le (abs @0) { t_cst; })
+ (rdiv { t_one; } (sqrts (plus (mult @0 @0) { t_one; })))
+ (copysigns { t_zero; } @0))
+
/* cabs(x+0i) or cabs(0+xi) -> abs(x). */
(simplify
(CABS (complex:C @0 real_zerop@1))
Index: gcc/real.c
===
--- gcc/real.c (revision 264941)
+++ gcc/real.c (working copy)
@@ -5279,3 +5279,29 @@
{
return HONOR_SIGN_DEPENDENT_ROUNDING (GET_MODE (x));
}
+
+/* Fills r with the largest value such that 1 + r*r won't overflow.
+ This is used in both sin (atan (x)) and cos (atan(x)) optimizations. */
+
+void
+build_sinatan_real (REAL_VALUE_TYPE * r, tree type)
+{
+ REAL_VALUE_TYPE maxval;
+ mpfr_t mpfr_const1, mpfr_c, mpfr_maxval;
+ machine_mode mode = TYPE_MODE (type);
+ const struct real_format * fmt = REAL_MODE_FORMAT (mode);
+
+ real_maxval (, 0, mode);
+
+ mpfr_inits (mpfr_const1, mpfr_c, mpfr_maxval, NULL);
+
+ mpfr_from_real (mpfr_const1, , GMP_RNDN);
+ mpfr_from_real (mpfr_maxval, , GMP_RNDN);
+
+ mpfr_sub (mpfr_c, mpfr_maxval, mpfr_const1, GMP_RNDN);
+ mpfr_sqrt (mpfr_c, mpfr_c, GMP_RNDZ);
+
+ real_from_mpfr (r, mpfr_c, fmt, GMP_RNDZ);
+
+ mpfr_clears (mpfr_const1, mpfr_c, mpfr_maxval, NULL);
+}
Index: gcc/real.h
===
--- gcc/real.h (revision 264941)
+++ gcc/real.h (working copy)
@@ -523,4 +523,8 @@
const wide_int_ref &, signop);
#endif
+/* Fills r with the largest value such that 1 + r*r won't overflow.
+ This is used in both sin (atan (x)) and cos (atan(x)) optimizations. */
+extern void build_sinatan_real (REAL_VALUE_TYPE *, tree);
+
#endif /* ! GCC_REAL_H */
Index: gcc/testsuite/gcc.dg/sinatan-1.c
===
--- gcc/testsuite/gcc.dg/sinatan-1.c (nonexistent)
+++ gcc/testsuite/gcc.dg/sinatan-1.c (working copy)
@@ -0,0 +1,101 @@
+/* { dg-do run } */
+/* { dg-options "-Ofast" } */
+
+extern float sinf (float);
+extern float cosf (float);
+extern float atanf (float);
+extern float sqrtf (float);
+extern float nextafterf (float, float);
+extern double sin (double);
+extern double cos (double);
+extern double atan (double);
+extern double sqrt (double);
+extern double nextafter (double, double);
+extern long double sinl (long double);
+extern long double cosl (long double);
+extern long double atanl (long double);
+extern long double sqrtl (long double);
+extern long double nextafterl (long double, long double);
+
+extern void abort ();
+
+double __attribute__ ((noinline, optimize("Ofast")))
+sinatan (double x)
+{
+return sin (atan (x));
+}
+
+double __attribute__ ((noinline, optimize("Ofast")))
Re: [RFC][PATCH IRA] Fix PR87507, IRA unnecessarily uses non-volatile registers during register assignment
On 10/08/2018 03:36 PM, Peter Bergner wrote:
PR87507 shows a problem where IRA assigns a non-volatile TImode reg pair to
a pseudo when there is a volatile reg pair available to use. This then
causes us to emit save/restore code for the non-volatile reg usage.
The problem here is that the only volatile reg pair that is available is an
odd/even reg pair (r7,r8) and ira-costs.c:ira_tune_allocno_costs() disparages
odd/even reg pairs by increasing their cost. That's fine, but an even/odd
non-volatile reg pair should still be more expensive than an odd/even reg
pair given the save/restore that we'd need to use it. However, the costs
used in assign_hard_reg() show that non-volatile reg pair (r30,r31) is
cheaper than odd/even reg pair (r7,r8) (15 versus 1000). That's a huge
disparity in costs, so looking at where the non-volatile cost comes from,
it comes from the code below in ira-color.c:assign_hard_reg():
if (!HONOR_REG_ALLOC_ORDER)
{
if ((saved_nregs = calculate_saved_nregs (hard_regno, mode)) != 0)
/* We need to save/restore the hard register in
epilogue/prologue. Therefore we increase the cost. */
{
rclass = REGNO_REG_CLASS (hard_regno);
add_cost = ((ira_memory_move_cost[mode][rclass][0]
+ ira_memory_move_cost[mode][rclass][1])
* saved_nregs / hard_regno_nregs (hard_regno,
mode) - 1);
cost += add_cost;
full_cost += add_cost;
}
}
I'm not sure I understand the "* saved_nregs / h_r_n (h_r, m) - 1" part
of the calculation. If saved_nregs is the number of hard regs that
need to be saved for hard_regno in mode MODE (ie, we don't need to
save a hard reg if it's already been saved, etc.), then why aren't we
just multiplying by saved_nregs? The other problem I see here is
that we're not scaling the cost by the basic block frequency of the
prologue/epilogue, which is what is causing the non-volatile reg
cost to be so low compared to the odd/even volatile reg use, which
is scaled. However, even if I fix that, improve_allocation() comes
along and undoes it, because it too does not correctly compute the
cost of non-volatiles, so that seems to me that it needs fixing too.
It would be right if we have only one pseudo using non-volatile regs.
But at this stage we don't know how many pseudos will use the
non-volatile reg. Once the non-volotile reg is used, it is free for all
other pseudo uses (and they can be in hot regions as loops).
The costs were heuristically tuned on SPEC2000 on x86/x86-64. As the
functions are bigger (now we have aggressive inlining), the only small
increase for non-volatile reg works better. That is why I don't like
small test RA PRs, the heuristics can be bad for them but they can work
better for real programs. When I change this code, I always check SPEC
because sometimes the results are opposite to the expected ones.
May be you could find better heuristics which works for small and big
functions.
I have the following work in progress patch I'd like some comments on.
Am I on the right track here? I noticed that assign_hard_reg() tracks
min_cost and min_full_cost, but min_cost is actually never used for
anything other than setting min_cost, so I removed it. I also don't
understand why we don't charge non-volatile usage for targets that define
HONOR_REG_ALLOC_ORDER. Why shouldn't we always account for save/restore
of non-volatile reg usage?
Once min_cost was used for different heuristics. Still it is useful for
debugging because full_cost calculations is very complicated (it is
affected by conflict allocnos preferences and allocnos connected
directly and indirectly by copies). Min_cost can be useful in debugging
to see the picture because its calculation is more straightforward.
A few years ago IRA did not use HONOR_REG_ALLOC_ORDER but people filled
a PR (I don't remember the number) and that is what behaviour they
exactly wanted.
[Bug libstdc++/87544] alloc-size-larger-than incorrectly triggered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544 --- Comment #15 from Jonathan Wakely --- Thanks Martin and Marc for the explanations. The warning sounds a lot more definite than "there is some possible execution where the value is too large". The phrasing of the warning makes it look like that's the only possible value. I'll try to take a look at the redundant checking.
[Bug fortran/83522] ICE on invalid allocatable string reference, string(:)(:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83522 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- This patch caused lots of regressions in the testsuite, see e.g. http://gcc.gnu.org/ml/gcc-regression/2018-10/msg00062.html
Re: [PATCH] C++: simplify output from suggest_alternatives_for
On Tue, Oct 9, 2018 at 1:19 PM David Malcolm wrote:
> + /* Emulation of a "move" constructor, but really a copy
> + constructor. */
> +
> + name_hint (const name_hint )
> + : m_suggestion (other.m_suggestion),
> +m_deferred (const_cast (other).take_deferred ())
> + {
> + }
> +
> + /* Emulation of "move" assigment, but really copy assignment. */
> +
> + name_hint& operator= (const name_hint )
> + {
> +m_suggestion = other.m_suggestion;
> +m_deferred = const_cast (other).take_deferred ();
> +return *this;
> + }
> +
> + /* Take ownership of this name_hint's deferred_diagnostic, for use
> + in chaining up deferred diagnostics. */
> + gnu::unique_ptr take_deferred () { return move
> (m_deferred); }
Why do you want to propagate this hackery into name_hint? I would
expect the defaulted special member functions to do the right thing
with m_deferred: in -std=c++98 the implicit copy ops call the
gnu::unique_ptr copy ops that actually move, and in -std=c++11 and up
we're calling the move constructor for std::unique_ptr, which does the
right thing.
This also doesn't limit the hack to C++98 mode the way unique-ptr.h does.
Jason
[Bug c++/87570] New: Rejects valid alias template usage (as a type pack size requirement)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87570
Bug ID: 87570
Summary: Rejects valid alias template usage (as a type pack
size requirement)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
MWE:
template
using limit_argnum = T;
template
struct tuple
{
template
tuple(limit_argnum&&...) {}
};
tuple a(1, 2);
GCC says:
-
:11:24: error: no matching function for call to 'tuple::tuple(int, int)'
11 | tuple a(1, 2);
|^
:8:5: note: candidate: 'template
tuple::tuple(limit_argnum&& ...)'
8 | tuple(limit_argnum&&...) {}
| ^
:8:5: note: template argument deduction/substitution failed:
:11:24: note: mismatched types 'limit_argnum' and 'int'
11 | tuple a(1, 2);
|^
:5:8: note: candidate: 'constexpr tuple::tuple(const
tuple&)'
5 | struct tuple
|^
:5:8: note: candidate expects 1 argument, 2 provided
:5:8: note: candidate: 'constexpr tuple::tuple(tuple&&)'
:5:8: note: candidate expects 1 argument, 2 provided
Note that the same thing but with a function works:
---
template
using limit_argnum = T;
template
void foo(limit_argnum&&...) {}
int main()
{
foo(1, 2);
}
Clang and MSVC are fine with both examples.
Re: ICE building a libsupc++ file, pdp11 target
> On Jul 17, 2018, at 9:36 AM, Richard Biener
> wrote:
>
> On Tue, Jul 17, 2018 at 3:08 PM Paul Koning wrote:
>>
>>
>>> On Jul 17, 2018, at 5:46 AM, Richard Biener
>>> wrote:
>>>
...
>>>
>>> There is not enough information for anyone to help you without
>>> reproducing the issue which is maybe too much to ask for ;)
>>>
>>> Can you debug_tree () the offending decl in gdb?
>>
>> Yes, here it is. I don't know anything about debugging in this area, so
>> tools like debug_tree are good to learn about. How would I interpret its
>> output?
>>
>> pkoning:gcc pkoning$ lldb ./cc1plus -- new_opa.ii -fno-implicit-templates
>> -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
>> -fdiagnostics-show-location=once -frandom-seed=new_opa.lo -g -O2 -std=gnu++1z
>> (lldb) target create "./cc1plus"
>> Current executable set to './cc1plus' (x86_64).
>> ...
>> Process 10880 stopped
>> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
>>frame #0: 0x000100c21378 cc1plus`internal_error(gmsgid="in %s, at
>> %s:%d") at diagnostic.c:1441 [opt]
>> 1438 internal_error (const char *gmsgid, ...)
>> 1439 {
>> 1440 va_list ap;
>> -> 1441 va_start (ap, gmsgid);
>> 1442 rich_location richloc (line_table, input_location);
>> 1443 diagnostic_impl (, -1, gmsgid, , DK_ICE);
>> 1444 va_end (ap);
>> Target 0: (cc1plus) stopped.
>> (lldb) frame sel 2
>> frame #2: 0x000100074b36
>> cc1plus`import_export_decl(decl=0x00014269c750) at decl2.c:2877 [opt]
>> 2874 gcc_assert (VAR_OR_FUNCTION_DECL_P (decl));
>> 2875 /* Any code that creates entities with TREE_PUBLIC cleared should
>> 2876 also set DECL_INTERFACE_KNOWN. */
>> -> 2877 gcc_assert (TREE_PUBLIC (decl));
>> 2878 if (TREE_CODE (decl) == FUNCTION_DECL)
>> 2879 gcc_assert (DECL_IMPLICIT_INSTANTIATION (decl)
>> 2880 || DECL_FRIEND_PSEUDO_TEMPLATE_INSTANTIATION (decl)
>> (lldb) call debug_tree(decl)
>> >type >size
>>unit-size
>>align:8 warn_if_not_align:0 symtab:150 alias-set -1 canonical-type
>> 0x1426aa5e8 precision:1 min max > 0x142502a08 1>>
>>readonly constant used static tree_1 tree_2 tree_3 unsigned nonlocal
>> in_system_header read decl_1 QI
>> /Users/pkoning/Documents/svn/buildpdp/pdp11-aout/libstdc++-v3/include/type_traits:59:28
>> size unit-size
>>align:8 warn_if_not_align:0 context > integral_constant> initial
>>template-info 0x1426a64e0 chain >
>> (lldb)
>
> lldb? eh ... ;)
>
> anyhow, this is
>
> namespace std
> {
>
> # 56
> "/Users/pkoning/Documents/svn/buildpdp/pdp11-aout/libstdc++-v3/include/type_traits"
> 3
> template
>struct integral_constant
>{
> static constexpr _Tp value = __v;
> ^^^
>
> which should have TREE_PUBLIC set. My next step would be to watch how
> this flag changes (if it does...)
>
> break at ggc-page.c:1442 (the return stmt of ggc_internal_alloc)
> conditional on result == 0x14269c750
> and then watch *>base.public_flag printing said flag when
> the watchpoint hits
> (because you're watching the whole integer containing the bitfield bit).
>
> If that doesn't go anywhere try reducing the source file using creduce
> or by other means.
>
> Maybe look at reset_decl_linkage () and visibility support in general.
I trimmed the file a bit.
Managed to find where public_flag is cleared. It is in cp/expr.c
maybe_commonize_var, line 5619, here:
else
{
/* While for initialized variables, we must use internal
linkage -- which means that multiple copies will not
be merged. */
TREE_PUBLIC (decl) = 0;
DECL_COMMON (decl) = 0;
Could it be related to the fact that I have an a.out (rather than ELF) target?
paul
[Bug c++/84423] [6/7/8/9 Regression] [concepts] ICE with invalid using declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84423 --- Comment #6 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Oct 9 21:16:09 2018 New Revision: 264996 URL: https://gcc.gnu.org/viewcvs?rev=264996=gcc=rev Log: /cp 2018-10-09 Paolo Carlini PR c++/84423 * pt.c (convert_template_argument): Immediately return error_mark_node if the second argument is erroneous. * parser.c (cp_parser_type_id): Add location_t * parameter. (cp_parser_type_id_1): Likewise. (cp_parser_alias_declaration): Adjust cp_parser_type_id call, obtain the location of the type and save it. (cp_parser_template_type_arg): Adjust. (cp_parser_trailing_type_id): Likewise. * decl.c (grokdeclarator): Improve error message for 'auto' in alias declaration. /testsuite 2018-10-09 Paolo Carlini PR c++/84423 * g++.dg/concepts/pr84423-1.C: New. * g++.dg/concepts/pr84423-2.C: Likewise. * g++.dg/cpp0x/auto39.C: Test location too. * g++.dg/cpp0x/auto9.C: Likewise. * g++.dg/cpp1y/pr60384.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/concepts/pr84423-1.C trunk/gcc/testsuite/g++.dg/concepts/pr84423-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/auto39.C trunk/gcc/testsuite/g++.dg/cpp0x/auto9.C trunk/gcc/testsuite/g++.dg/cpp1y/pr60384.C
[Bug target/86731] [8/9 Regression] Miscompiles vec_sl at -O3 with -fwrapv on ppc64el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86731 Will Schmidt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Will Schmidt --- (In reply to Segher Boessenkool from comment #4) > Is this fixed now? Backport to 8 has been committed. should be done with this one, thanks. :-)
[Bug target/86731] [8/9 Regression] Miscompiles vec_sl at -O3 with -fwrapv on ppc64el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86731 --- Comment #6 from Will Schmidt --- Author: willschm Date: Tue Oct 9 20:55:25 2018 New Revision: 264994 URL: https://gcc.gnu.org/viewcvs?rev=264994=gcc=rev Log: [gcc] 2018-10-09 Will Schmidt Backport from trunk. 2018-09-06 Will Schmidt PR target/86731 * config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Update logic around folding of vec_sl to handle out of range shift values. [testsuite] 2018-10-09 Will Schmidt Backport from trunk 2018-09-06 Will Schmidt PR target/86731 * gcc.target/powerpc/pr86731.c: New test. * gcc.target/powerpc/pr86731-longlong.c: New test. * gcc.target/powerpc/pr86731-fwrapv.c: New test. * gcc.target/powerpc/pr86731-fwrapv-longlong.c: New test. * gcc.target/powerpc/pr86731-nogimplefold.c: New test. * gcc.target/powerpc/pr86731-nogimplefold-longlong.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr86731-fwrapv-longlong.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr86731-fwrapv.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr86731-longlong.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr86731-nogimplefold-longlong.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr86731-nogimplefold.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr86731.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/rs6000/rs6000.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
Re: [PATCH] Remove dead functions and fix VMS target by moving back some functions.
On Tue, Oct 09 2018, Martin Liška wrote: > Hi. > > Utilizing rtags' --find-dead-functions I'm suggesting a removal of part > of the functions reported with the script. I built all cross compilers > defined in contrib/config-list.mk and I fixed VMS targets that I broke > in previous removal. > > If the folks are happy with the removal, I can probably continue with that > at some point in stage3 or so. > > Ready for trunk? > Thanks, > Martin > From f69d866da42a46783ab57181692583d2ecf30c49 Mon Sep 17 00:00:00 2001 > From: marxin > Date: Fri, 5 Oct 2018 16:59:07 +0200 > Subject: [PATCH] Remove dead functions and fix VMS target by moving back some > functions. > > gcc/ChangeLog: > > 2018-10-09 Martin Liska > > * attribs.c (register_attribute): Remove unused functions. > * cfganal.c (control_dependences::clear_control_dependence_bitmap): > Likewise. > (bitmap_union_of_succs): Likewise. > * cfganal.h (bitmap_union_of_succs): Likewise. > * cfgloop.c (loop_exits_to_bb_p): Likewise. > * cfgloop.h (loop_exits_to_bb_p): Likewise. > * cgraph.h (compute_call_stmt_bb_frequency): Likewise. > * cgraphbuild.c (compute_call_stmt_bb_frequency): Likewise. > * cselib.c (cselib_dummy_expand_value_rtx_cb): Likewise. > * cselib.h (cselib_dummy_expand_value_rtx_cb): Likewise. > * df-core.c (df_reg_defined): Likewise. > (df_reg_used): Likewise. > * df-scan.c (df_hard_reg_used_count): Likewise. > * df.h (df_reg_defined): Likewise. > (df_reg_used): Likewise. > (df_hard_reg_used_count): Likewise. > * dojump.c (init_pending_stack_adjust): Likewise. > * dojump.h (init_pending_stack_adjust): Likewise. > * dwarf2out.c (add_AT_vms_delta): Move function back after > removal. > (dwarf2out_set_demangle_name_func): REmove unused functions. > * dwarf2out.h (dwarf2out_set_demangle_name_func): Likewise. > * emit-rtl.c (emit_jump_insn_before_noloc): Likewise. > (emit_call_insn_before_noloc): Likewise. > (emit_barrier_before): Likewise. > (emit_call_insn_after_noloc): Likewise. > (emit_call_insn_after_setloc): Likewise. > (emit_jump_insn_before_setloc): Likewise. > (emit_call_insn_before_setloc): Likewise. > (emit_call_insn_before): Likewise. > * except.c (remove_eh_handler): Likewise. > (get_eh_region_from_rtx): Likewise. > * except.h (remove_eh_handler): Likewise. > (get_eh_region_from_rtx): Likewise. > * fold-const.c (div_if_zero_remainder): Likewise. > (fold_unary_to_constant): Likewise. > * fold-const.h (fold_unary_to_constant): Likewise. > (div_if_zero_remainder): Likewise. > * function.c (get_hard_reg_initial_reg): Likewise. > (get_last_funcdef_no): Likewise. > * function.h (get_hard_reg_initial_reg): Likewise. > (get_last_funcdef_no): Likewise. > * ggc-common.c (ggc_cleared_alloc_htab_ignore_args): Likewise. > (ggc_cleared_alloc_ptr_array_two_args): Likewise. > (ggc_splay_alloc): Likewise. > (ggc_splay_dont_free): Likewise. > * gimple-expr.c (is_gimple_address): Likewise. > * gimple-expr.h (is_gimple_address): Likewise. > * gimple-iterator.c (gsi_for_phi): Likewise. > * gimple-iterator.h (gsi_for_phi): Likewise. > * gimple-ssa-sprintf.c (struct format_result): Likewise. > (format_result::operator+=): Likewise. > (struct directive): Likewise. > * gimple-ssa-warn-alloca.c (struct alloca_type_and_limit): Likewise. > * gimple.c (gimple_unsigned_type): Likewise. > (gimple_call_builtin_p): Likewise. > * gimple.h (gimple_unsigned_type): Likewise. > (gimple_call_builtin_p): Likewise. > * gimplify.c (gimple_current_bind_expr): Likewise. > * gimplify.h (gimple_current_bind_expr): Likewise. > * haifa-sched.c (haifa_classify_insn): Likewise. > * hsa-common.c (hsa_add_kernel_dependency): Likewise. > (hsa_brig_function_name): Likewise. > * hsa-common.h (hsa_add_kernel_dependency): Likewise. > (hsa_brig_function_name): Likewise. > * ipa-cp.c (ipcp_vr_lattice::meet_with): Likewise. Interesting, I believe that a class representing a lattice should have a meet function with its own type. In this case it would mean moving the call to ipa_vr_operation_and_type_effects from the caller into the method to clearly describe the semantics. But perhaps it does not matter if we do not have the overload in the meantime. > * ipa-devirt.c (vtable_pointer_value_to_binfo): Likewise. > * ipa-icf-gimple.c (func_checker::compare_tree_ssa_label): Likewise. > * ipa-icf-gimple.h: Likewise. > * ipa-icf.c (sem_item::sem_item): Likewise. > (sem_function::sem_function): Likewise. > (sem_function::icf_handled_component_p): Likewise. > (sem_variable::sem_variable): Likewise. > * ipa-icf.h: Likewise. > * ipa-param-manipulation.c
Re: [PATCH] PR libgcc/60790: Avoid IFUNC resolver access to uninitialized data
* Jeff Law:
> On 03/29/2018 08:00 AM, Florian Weimer wrote:
>> This patch performs lazy initialization of the relevant CPUID feature
>> register value. It will needlessly invoke the CPUID determination code
>> on architectures which lack CPUID support or support for the feature
>> register, but I think it's not worth to avoid the complexity for that.
>>
>> I verified manually that the CMPXCHG16B implementation is still selected
>> for a 128-bit load after the change. I don't know how to write an
>> automated test for that.
>>
>> Thanks,
>> Florian
>>
>> pr60790.patch
>>
>>
>> Index: libatomic/ChangeLog
>> ===
>> --- libatomic/ChangeLog (revision 258952)
>> +++ libatomic/ChangeLog (working copy)
>> @@ -1,3 +1,18 @@
>> +2018-03-29 Florian Weimer
>> +
>> +PR libgcc/60790
>> +x86: Do not assume ELF constructors run before IFUNC resolvers.
>> +* config/x86/host-config.h (libat_feat1_ecx, libat_feat1_edx):
>> +Remove declarations.
>> +(__libat_feat1, __libat_feat1_init): Declare.
>> +(FEAT1_REGISTER): Define.
>> +(load_feat1): New function.
>> +(IFUNC_COND_1): Adjust.
>> +* config/x86/init.c (libat_feat1_ecx, libat_feat1_edx)
>> +(init_cpuid): Remove definitions.
>> +(__libat_feat1): New variable.
>> +(__libat_feat1_init): New function.
> OK.
Here is the backport to gcc-8-branch.
libatomic/ChangeLog
PR libgcc/60790
x86: Do not assume ELF constructors run before IFUNC resolvers.
* config/x86/host-config.h (libat_feat1_ecx, libat_feat1_edx):
Remove declarations.
(__libat_feat1, __libat_feat1_init): Declare.
(FEAT1_REGISTER): Define.
(load_feat1): New function.
(IFUNC_COND_1): Adjust.
* config/x86/init.c (libat_feat1_ecx, libat_feat1_edx)
(init_cpuid): Remove definitions.
(__libat_feat1): New variable.
(__libat_feat1_init): New function.
Index: libatomic/config/x86/host-config.h
===
--- libatomic/config/x86/host-config.h (revision 264990)
+++ libatomic/config/x86/host-config.h (working copy)
@@ -25,13 +25,39 @@
#if HAVE_IFUNC
#include
-extern unsigned int libat_feat1_ecx HIDDEN;
-extern unsigned int libat_feat1_edx HIDDEN;
+#ifdef __x86_64__
+# define FEAT1_REGISTER ecx
+#else
+# define FEAT1_REGISTER edx
+#endif
+/* Value of the CPUID feature register FEAT1_REGISTER for the cmpxchg
+ bit for IFUNC_COND1 below. */
+extern unsigned int __libat_feat1 HIDDEN;
+
+/* Initialize libat_feat1 and return its value. */
+unsigned int __libat_feat1_init (void) HIDDEN;
+
+/* Return the value of the relevant feature register for the relevant
+ cmpxchg bit, or 0 if there is no CPUID support. */
+static inline unsigned int
+__attribute__ ((const))
+load_feat1 (void)
+{
+ /* See the store in __libat_feat1_init. */
+ unsigned int feat1 = __atomic_load_n (&__libat_feat1, __ATOMIC_RELAXED);
+ if (feat1 == 0)
+/* Assume that initialization has not happened yet. This may get
+ called repeatedly if the CPU does not have any feature bits at
+ all. */
+feat1 = __libat_feat1_init ();
+ return feat1;
+}
+
#ifdef __x86_64__
-# define IFUNC_COND_1 (libat_feat1_ecx & bit_CMPXCHG16B)
+# define IFUNC_COND_1 (load_feat1 () & bit_CMPXCHG16B)
#else
-# define IFUNC_COND_1 (libat_feat1_edx & bit_CMPXCHG8B)
+# define IFUNC_COND_1 (load_feat1 () & bit_CMPXCHG8B)
#endif
#ifdef __x86_64__
Index: libatomic/config/x86/init.c
===
--- libatomic/config/x86/init.c (revision 264990)
+++ libatomic/config/x86/init.c (working copy)
@@ -26,13 +26,17 @@
#if HAVE_IFUNC
-unsigned int libat_feat1_ecx, libat_feat1_edx;
+unsigned int __libat_feat1;
-static void __attribute__((constructor))
-init_cpuid (void)
+unsigned int
+__libat_feat1_init (void)
{
- unsigned int eax, ebx;
- __get_cpuid (1, , , _feat1_ecx, _feat1_edx);
+ unsigned int eax, ebx, ecx, edx;
+ FEAT1_REGISTER = 0;
+ __get_cpuid (1, , , , );
+ /* See the load in load_feat1. */
+ __atomic_store_n (&__libat_feat1, FEAT1_REGISTER, __ATOMIC_RELAXED);
+ return FEAT1_REGISTER;
}
#endif /* HAVE_IFUNC */
Index: .
===
--- . (revision 264990)
+++ . (working copy)
Property changes on: .
___
Modified: svn:mergeinfo
## -0,0 +0,1 ##
Merged /trunk:r260603
[Bug c++/87567] constexpr evaluation rejects call to non-constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87567 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
Re: [C++ Patch] PR 84423 ("[6/7/8/9 Regression] [concepts] ICE with invalid using declaration")
OK. On Tue, Oct 9, 2018 at 1:49 PM Paolo Carlini wrote: > > Hi, > > On 09/10/18 17:17, Jason Merrill wrote: > > On Sat, Sep 29, 2018 at 3:27 PM Paolo Carlini > > wrote: > >> Hi again, > >> > >> On 9/28/18 9:15 PM, Paolo Carlini wrote: > >>> Thanks. About the location, you are certainly right, but doesn't seem > >>> trivial. Something we can do *now* is using > >>> declspecs->locations[ds_typedef] and declspecs->locations[ds_alias], > >>> but that gives us the location of the keyword 'typedef' and 'using', > >>> respectively, whereas I think that we would like to have the location > >>> of 'auto' itself. I could look into that as a follow-up piece work > >> In fact, completing the work turned out to be easy: ensure that > >> cp_parser_alias_declaration saves the location of the defining-type-id > >> too and then consistently use locations[ds_type_spec] in the error > >> messages. Tested x86_64-linux. Still Ok? ;) > > Hmm, I think you need to look past any cv-qualifiers at the beginning > > of the type-id. > > Ah, good point. The information is readily available in > cp_parser_type_id thus we can simply return it to > cp_parser_alias_declaration. I guess an alternate approach would be > adding a pointer to the whole cp_decl_specifier_seq parameter to > cp_parser_type_id (and cp_parser_type_id_1, etc), but that seems over > killing to me. > > Thanks! Paolo. > > / >
[Bug c/87569] New: defining type in ‘sizeof’ expression is invalid in C++ references wrong operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87569
Bug ID: 87569
Summary: defining type in ‘sizeof’ expression is invalid in C++
references wrong operator
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
While enhancing the C parser to recognize a new built-in similar to
alignof/sizeof/typeof I noticed the in_alignof, in_sizeof and in_typeof
handling by -Wc++-compat isn't quite right. The warning code uses the in_xxx
counters to reference the operator whose operand is a type definition, like
this:
warning_at (loc, OPT_Wc___compat,
"defining type in %qs expression is invalid in C++",
(in_sizeof
? "sizeof"
: (in_typeof ? "typeof" : "alignof")));
But this approach is inaccurate whew multiple counters are set because it fails
to consider that the current operator may be different between the same counter
values. Below is a test case that shows the problem (note the warning mentions
sizeof in both instances, even though only one of them defines a type in a
sizeof operand; the other one defines it in a typeof operand). To accurately
reflect the current operator the code would need to maintain a data structure
like a stack. It's not really a big deal but if one expects the message to
accurately reflect the operator (e.g., when writing tests for a new operator),
one realizes that this sort of accuracy is not possible with the current
design.
$ cat x.c && gcc -S -Wall -Wextra -Wc++-compat x.c
int i = sizeof (__typeof (enum { e0 })); // type defined in typeof
__typeof (sizeof (enum { e1 })) e; // type defined in sizeof
x.c:1:32: warning: defining type in ‘sizeof’ expression is invalid in C++
[-Wc++-compat]
1 | int i = sizeof (__typeof (enum { e0 })); // type defined in typeof
|^
x.c:3:24: warning: defining type in ‘sizeof’ expression is invalid in C++
[-Wc++-compat]
3 | __typeof (sizeof (enum { e1 })) e; // type defined in sizeof
|^
[Bug libstdc++/87544] alloc-size-larger-than incorrectly triggered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544 --- Comment #14 from Marc Glisse --- (In reply to Jonathan Wakely from comment #11) > Why does it think we're calling it with max_size()? _M_check_len contains a path (hopefully not taken, but gcc doesn't see that) where it returns max_size(), and we allocate 8 times the return value of _M_check_len. With optimizations, gcc thus sees a path where we allocate 8*max_size(), that is size_t(-1) rounded down to a multiple of 8. --- By the way, looking at an optimized dump of _M_realloc_insert, it almost starts with (_46 is the size): if (_46 == 0) goto ; [34.00%] else goto ; [66.00%] [local count: 77922475]: __len_51 = _46 * 2; if (_46 > __len_51) goto ; [53.03%] else goto ; [46.97%] [local count: 36599951]: if (__len_51 > 2305843009213693951) goto ; [73.39%] else goto ; [26.61%] [local count: 9724245]: if (__len_51 != 0) The tests _46 > __len_51 and __len_51 > 2305843009213693951 both check if the size is small enough, while the checks _46 == 0 and __len_51 != 0 both check if the size is 0. That's a bit too much redundancy for error-checking code on the hot path (I am not saying if that's the responsibility of the middle-end to optimize it, or of libstdc++ not to have it in the first place).
[Bug target/87561] [9 Regression] 416.gamess is slower by ~10% starting from r264866 with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87561
--- Comment #5 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #4)
> Another thing is the too complicated alias check where for
>
> (gdb) p debug_data_reference (dr_a.dr)
> #(Data Ref:
> # bb: 14
> # stmt: _28 = *xpqkl_172(D)[_27];
> # ref: *xpqkl_172(D)[_27];
> # base_object: *xpqkl_172(D);
> # Access function 0: {(((integer(kind=8)) mkl_203 + 1) * stride.33_148 +
> offset.34_149) + _480, +, stride.33_148}_6
> #)
> $9 = void
> (gdb) p debug_data_reference (dr_b.dr)
> #(Data Ref:
> # bb: 14
> # stmt: *xpqkl_172(D)[_50] = _65;
> # ref: *xpqkl_172(D)[_50];
> # base_object: *xpqkl_172(D);
> # Access function 0: {(((integer(kind=8)) mkl_203 + 1) * stride.33_148 +
> offset.34_149) + _486, +, stride.33_148}_6
> #)
>
> we generate
>
> (ssizetype) (((sizetype) integer(kind=8)) mkl_203 + 1) * stride.33_148 +
> offset.34_149) + (integer(kind=8)) (_19 + jpack_161)) + (sizetype)
> stride.33_148) * 8) < (ssizetype) ((sizetype) integer(kind=8)) mkl_203 +
> 1) * stride.33_148 + offset.34_149) + (integer(kind=8)) (_22 + lpack_164)) *
> 8) || (ssizetype) (((sizetype) integer(kind=8)) mkl_203 + 1) *
> stride.33_148 + offset.34_149) + (integer(kind=8)) (_22 + lpack_164)) +
> (sizetype) stride.33_148) * 8) < (ssizetype) ((sizetype)
> integer(kind=8)) mkl_203 + 1) * stride.33_148 + offset.34_149) +
> (integer(kind=8)) (_19 + jpack_161)) * 8)
>
> instead of simply _480 != _486 (well, OK, not _that_ simple).
>
> I guess we miss many of the "optimizations" we do when dealing with
> alias checks for constant steps. In this case sth obvious would be
> to special-case DR_STEP (dra) == DR_STEP (drb). Richard?
Not sure that would help much with the existing optimisations.
I think the closest we get is create_intersect_range_checks_index,
but "all" that avoids is scaling the index by the element size
and adding the common base. I guess the expensive bit here is
multiplying by the stride, but the index-based check would still
do that.
That said, create_intersect_range_checks_index does feel like it
might be a bit *too* conservative (but I'm not brave enough to relax it)
[Bug fortran/83522] ICE on invalid allocatable string reference, string(:)(:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83522 --- Comment #7 from Tobias Burnus --- Author: burnus Date: Tue Oct 9 18:03:31 2018 New Revision: 264990 URL: https://gcc.gnu.org/viewcvs?rev=264990=gcc=rev Log: 2018-10-09 Tobias Burnus PR fortran/83522 * resolve.c (resolve_ref): Reject nonscalar substring references. PR fortran/83522 * gfortran.dg/actual_array_substr_1.f90: Add dg-error, change to dg-do compile. * gfortran.dg/actual_array_substr_2.f90: Ditto. * gfortran.dg/array_initializer_1.f90: Use array element not size-one section. * gfortran.dg/array_substring.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/array_substring.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/actual_array_substr_1.f90 trunk/gcc/testsuite/gfortran.dg/actual_array_substr_2.f90
Re: [C++ Patch] PR 84423 ("[6/7/8/9 Regression] [concepts] ICE with invalid using declaration")
Hi,
On 09/10/18 17:17, Jason Merrill wrote:
On Sat, Sep 29, 2018 at 3:27 PM Paolo Carlini wrote:
Hi again,
On 9/28/18 9:15 PM, Paolo Carlini wrote:
Thanks. About the location, you are certainly right, but doesn't seem
trivial. Something we can do *now* is using
declspecs->locations[ds_typedef] and declspecs->locations[ds_alias],
but that gives us the location of the keyword 'typedef' and 'using',
respectively, whereas I think that we would like to have the location
of 'auto' itself. I could look into that as a follow-up piece work
In fact, completing the work turned out to be easy: ensure that
cp_parser_alias_declaration saves the location of the defining-type-id
too and then consistently use locations[ds_type_spec] in the error
messages. Tested x86_64-linux. Still Ok? ;)
Hmm, I think you need to look past any cv-qualifiers at the beginning
of the type-id.
Ah, good point. The information is readily available in
cp_parser_type_id thus we can simply return it to
cp_parser_alias_declaration. I guess an alternate approach would be
adding a pointer to the whole cp_decl_specifier_seq parameter to
cp_parser_type_id (and cp_parser_type_id_1, etc), but that seems over
killing to me.
Thanks! Paolo.
/
Index: cp/decl.c
===
--- cp/decl.c (revision 264985)
+++ cp/decl.c (working copy)
@@ -11879,6 +11879,7 @@ grokdeclarator (const cp_declarator *declarator,
/* If this is declaring a typedef name, return a TYPE_DECL. */
if (typedef_p && decl_context != TYPENAME)
{
+ bool alias_p = decl_spec_seq_has_spec_p (declspecs, ds_alias);
tree decl;
/* This declaration:
@@ -11901,7 +11902,12 @@ grokdeclarator (const cp_declarator *declarator,
if (type_uses_auto (type))
{
- error ("typedef declared %");
+ if (alias_p)
+ error_at (declspecs->locations[ds_type_spec],
+ "% not allowed in alias declaration");
+ else
+ error_at (declspecs->locations[ds_type_spec],
+ "typedef declared %");
type = error_mark_node;
}
@@ -11961,7 +11967,7 @@ grokdeclarator (const cp_declarator *declarator,
inlinep, friendp, raises != NULL_TREE,
declspecs->locations);
- if (decl_spec_seq_has_spec_p (declspecs, ds_alias))
+ if (alias_p)
/* Acknowledge that this was written:
`using analias = atype;'. */
TYPE_DECL_ALIAS_P (decl) = 1;
Index: cp/parser.c
===
--- cp/parser.c (revision 264985)
+++ cp/parser.c (working copy)
@@ -2216,12 +2216,12 @@ static tree cp_parser_late_return_type_opt
static tree cp_parser_declarator_id
(cp_parser *, bool);
static tree cp_parser_type_id
- (cp_parser *);
+ (cp_parser *, location_t * = NULL);
static tree cp_parser_template_type_arg
(cp_parser *);
static tree cp_parser_trailing_type_id (cp_parser *);
static tree cp_parser_type_id_1
- (cp_parser *, bool, bool);
+ (cp_parser *, bool, bool, location_t *);
static void cp_parser_type_specifier_seq
(cp_parser *, bool, bool, cp_decl_specifier_seq *);
static tree cp_parser_parameter_declaration_clause
@@ -19034,7 +19034,7 @@ static tree
cp_parser_alias_declaration (cp_parser* parser)
{
tree id, type, decl, pushed_scope = NULL_TREE, attributes;
- location_t id_location;
+ location_t id_location, type_location;
cp_declarator *declarator;
cp_decl_specifier_seq decl_specs;
bool member_p;
@@ -19086,7 +19086,7 @@ cp_parser_alias_declaration (cp_parser* parser)
G_("types may not be defined in alias template declarations");
}
- type = cp_parser_type_id (parser);
+ type = cp_parser_type_id (parser, _location);
/* Restore the error message if need be. */
if (parser->num_template_parameter_lists)
@@ -19120,6 +19120,7 @@ cp_parser_alias_declaration (cp_parser* parser)
set_and_check_decl_spec_loc (_specs,
ds_alias,
using_token);
+ decl_specs.locations[ds_type_spec] = type_location;
if (parser->num_template_parameter_lists
&& !cp_parser_check_template_parameters (parser,
@@ -21110,7 +2,7 @@ cp_parser_declarator_id (cp_parser* parser, bool o
static tree
cp_parser_type_id_1 (cp_parser* parser, bool is_template_arg,
-bool is_trailing_return)
+bool is_trailing_return, location_t * type_location)
{
cp_decl_specifier_seq type_specifier_seq;
cp_declarator *abstract_declarator;
@@ -21119,6 +21120,9 @@ cp_parser_type_id_1 (cp_parser* parser, bool is_te
cp_parser_type_specifier_seq (parser, /*is_declaration=*/false,
is_trailing_return,
_specifier_seq);
+ if (type_location)
+*type_location = type_specifier_seq.locations[ds_type_spec];
+
if
[Bug target/87370] [7/8/9 Regression] Inefficient return code of struct values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87370 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|9.0 |7.4 --- Comment #9 from H.J. Lu --- Fixed for GCC 9, GCC 8.3 and GCC 7.4.
[Bug target/87370] [7/8/9 Regression] Inefficient return code of struct values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87370 --- Comment #8 from hjl at gcc dot gnu.org --- Author: hjl Date: Tue Oct 9 17:23:06 2018 New Revision: 264989 URL: https://gcc.gnu.org/viewcvs?rev=264989=gcc=rev Log: i386: Use TImode for BLKmode values in 2 integer registers When passing and returning BLKmode values in 2 integer registers, use 1 TImode register instead of 2 DImode registers. Otherwise, V1TImode may be used to move and store such BLKmode values, which prevent RTL optimizations. gcc/ Backport from mainline PR target/87370 * config/i386/i386.c (construct_container): Use TImode for BLKmode values in 2 integer registers. gcc/testsuite/ Backport from mainline PR target/87370 * gcc.target/i386/pr87370.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr87370.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/i386/i386.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[PATCH] C++: simplify output from suggest_alternatives_for
In the C++ FE, after emitting various errors about unrecognized names, the parser can call suggest_alternatives_for and/or suggest_alternative_in_explicit_scope. These can issue zero or more suggestions for the unrecognized name, or various other "note" diagnostics suggesting how to fix the problem. For example, currently g++ emits: t.cc:12:3: error: 'gtk_widget_showall' was not declared in this scope 12 | gtk_widget_showall (w); | ^~ t.cc:12:3: note: suggested alternative: 'gtk_widget_show_all' 12 | gtk_widget_showall (w); | ^~ | gtk_widget_show_all This patch consolidates the common case when there is a single candidate, so that the error can issue a fix-it hint directly. This simplifies the above to: t.cc:12:3: error: 'gtk_widget_showall' was not declared in this scope; did you mean 'gtk_widget_show_all'? 12 | gtk_widget_showall (w); | ^~ | gtk_widget_show_all omitting the second "note" diagnostic. Doing so requires changing the above "suggest_" functions so that rather than being called after "error" and emitting a note directly, they are called before the "error", and return a name_hint, which can contain a suggestion and/or a deferred diagnostic. The "single candidate" case is handled via a suggestion, and the "multiple candidates" case via a new subclass of deferred_diagnostic. There was some complication due to the fact that we don't always have enough location information to issue a fix-it hint. Specifically, for the case in qualified_name_lookup_error, the location is that of the name, but the location of the qualifier prefix isn't reliably available. For some hints, e.g. spell-corrections, the replacement is of the name, and for others, e.g. parent namespaces, it's for the qualified name. The patch addresses this by splitting this case out into a new "suggest_alternatives_in_other_namespaces" function, for which fix-it hints aren't issued. Another complication is that of emitting a note when --param cxx-max-namespaces-for-diagnostic-help is reached. The patch emulates the existing behavior by emitting the note from a deferred_diagnostic. This potentially needs to co-exist with another deferred_diagnostic, so it works as a decorator around any other such deferred_diagnostic. Doing so requires slightly extending class name_hint. On adding test coverage for the various cases, I discovered that after emitting a "FOO is not a namespace-name" error, we also emit a "expected namespace-name before" error. The patch removes this second error for the case where it's redundant, simplifying this case from e.g.: spellcheck-ns.C:10:24: error: 'inner_ms' is not a namespace-name 10 | using namespace outer::inner_ms; |^~~~ spellcheck-ns.C:10:24: note: suggested alternative: 'inner_ns' 10 | using namespace outer::inner_ms; |^~~~ |inner_ns spellcheck-ns.C:10:32: error: expected namespace-name before ';' token 10 | using namespace outer::inner_ms; |^ to: spellcheck-ns.C:10:24: error: 'inner_ms' is not a namespace-name; did you mean 'inner_ns'? 10 | using namespace outer::inner_ms; |^~~~ |inner_ns Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu (on top of https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01272.html "v2: C++: suggestions for misspelled private members (PR c++/84993)") OK for trunk? gcc/c-family/ChangeLog: * name-hint.h (class name_hint): Add copy constructor and copy assignment operator. (name_hint::operator bool): Also return true if m_deferred is non-NULL. (name_hint::take_deferred): New member function. gcc/c/ChangeLog: * c-decl.c (implicit_decl_warning): Update "is there a suggestion" logic for change to name_hint::operator bool. (undeclared_variable): Likewise. * c-parser.c (c_parser_declaration_or_fndef): Likewise. (c_parser_parameter_declaration): Likewise. gcc/cp/ChangeLog: * cp-name-hint.h: New file. * cp-tree.h (expr_to_string): New decl. (suggest_alternatives_for): Move to cp-name-hint.h, changing return type from bool to name_hint. (suggest_alternative_in_explicit_scope): Likewise. * error.c: Define INCLUDE_UNIQUE_PTR. Include "cp-name-hint.h". (expr_to_string): Make non-static. (qualified_name_lookup_error): For the non-"::" case, take responsibity for issuing any suggestion from suggest_alternative_in_explicit_scope, as it changes from returning a bool to returning a name_hint. Replace fallback call to suggest_alternatives_for to a call to suggest_alternatives_in_other_namespaces, capturing the fact that we don't have enough location information to issue a fix-it hint for this case.
[Bug target/87370] [7/8/9 Regression] Inefficient return code of struct values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87370 --- Comment #7 from hjl at gcc dot gnu.org --- Author: hjl Date: Tue Oct 9 17:17:41 2018 New Revision: 264987 URL: https://gcc.gnu.org/viewcvs?rev=264987=gcc=rev Log: i386: Use TImode for BLKmode values in 2 integer registers When passing and returning BLKmode values in 2 integer registers, use 1 TImode register instead of 2 DImode registers. Otherwise, V1TImode may be used to move and store such BLKmode values, which prevent RTL optimizations. gcc/ Backport from mainline PR target/87370 * config/i386/i386.c (construct_container): Use TImode for BLKmode values in 2 integer registers. gcc/testsuite/ Backport from mainline PR target/87370 * gcc.target/i386/pr87370.c: New test. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/i386/i386.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968 Thomas Preud'homme changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-10-09 Assignee|unassigned at gcc dot gnu.org |thopre01 at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #10 from Thomas Preud'homme --- (In reply to Thomas Preud'homme from comment #8) > (In reply to Thomas Preud'homme from comment #7) > > (In reply to Thomas Preud'homme from comment #6) > > > Happens at expand time. Diving in. > > > > There's a giant if in expand_expr_real_1 with the following comment: > > > > /* In cases where an aligned union has an unaligned object > >as a field, we might be extracting a BLKmode value from > >an integer-mode (e.g., SImode) object. Handle this case > >by doing the extract into an object as wide as the field > >(which we know to be the width of a basic mode), then > >storing into memory, and changing the mode to BLKmode. */ > > > > The "if" is entered in the big endian unaligned case but not in the other > > case. In the aligned case, it continues after the if until the call to > > flip_storage_order which will generate the bswap. > > In the aligned case, the if is not taken because alignment of the memory Vs > access is sufficient. There is provision to call flip_storage_order but only > if the access is a RECORD and here the mode class is INT. > > Therefore unaligned access are handled by extract_bit_field. This in turns > call extract_bit_field_1 and later extract_integral_bit_field where things > are different between little endian and big endian. For little endian, it > goes in the following if block: > > /* If OP0 is a memory, try copying it to a register and seeing if a > cheap register alternative is available. */ > if (MEM_P (op0) & !reverse) > > For big endian it continues and calls extract_fixed_bit_field. I'm wondering > if an extra call to flip_storage_order when reverse is true would solve the > issue. Need to understand better whe is it safe to call flip_storage_order. It gives me the expected assembly but I need to convince myself that this is always safe.
[Bug tree-optimization/86659] [9 regression] gnat.dg/sso/q[23].adb FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86659 --- Comment #7 from Eric Botcazou --- Author: ebotcazou Date: Tue Oct 9 17:16:24 2018 New Revision: 264986 URL: https://gcc.gnu.org/viewcvs?rev=264986=gcc=rev Log: PR tree-optimization/86659 * gimple-match.h (gimple_match_op constructors): Initialize reverse. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-match.h
Re: [patch] Fix PR tree-optimization/86659
> 2018-09-28 Eric Botcazou
>
> PR tree-optimization/86659
> * gimple-match.h (struct gimple_match_op): Add reverse field.
Jonathan privately remarked that the new member should probably be initialized
in the constructors (thanks!). Done thusly, applied on mainline as obvious.
PR tree-optimization/86659
* gimple-match.h (gimple_match_op constructors): Initialize reverse.
--
Eric BotcazouIndex: gimple-match.h
===
--- gimple-match.h (revision 264942)
+++ gimple-match.h (working copy)
@@ -131,7 +131,8 @@ struct gimple_match_op
inline
gimple_match_op::gimple_match_op ()
- : cond (gimple_match_cond::UNCOND), type (NULL_TREE), num_ops (0)
+ : cond (gimple_match_cond::UNCOND), type (NULL_TREE), reverse (false),
+num_ops (0)
{
}
@@ -142,7 +143,8 @@ inline
gimple_match_op::gimple_match_op (const gimple_match_cond _in,
code_helper code_in, tree type_in,
unsigned int num_ops_in)
- : cond (cond_in), code (code_in), type (type_in), num_ops (num_ops_in)
+ : cond (cond_in), code (code_in), type (type_in), reverse (false),
+num_ops (num_ops_in)
{
}
@@ -152,7 +154,8 @@ inline
gimple_match_op::gimple_match_op (const gimple_match_cond _in,
code_helper code_in, tree type_in,
tree op0)
- : cond (cond_in), code (code_in), type (type_in), num_ops (1)
+ : cond (cond_in), code (code_in), type (type_in), reverse (false),
+num_ops (1)
{
ops[0] = op0;
}
@@ -161,7 +164,8 @@ inline
gimple_match_op::gimple_match_op (const gimple_match_cond _in,
code_helper code_in, tree type_in,
tree op0, tree op1)
- : cond (cond_in), code (code_in), type (type_in), num_ops (2)
+ : cond (cond_in), code (code_in), type (type_in), reverse (false),
+num_ops (2)
{
ops[0] = op0;
ops[1] = op1;
@@ -171,7 +175,8 @@ inline
gimple_match_op::gimple_match_op (const gimple_match_cond _in,
code_helper code_in, tree type_in,
tree op0, tree op1, tree op2)
- : cond (cond_in), code (code_in), type (type_in), num_ops (3)
+ : cond (cond_in), code (code_in), type (type_in), reverse (false),
+num_ops (3)
{
ops[0] = op0;
ops[1] = op1;
@@ -182,7 +187,8 @@ inline
gimple_match_op::gimple_match_op (const gimple_match_cond _in,
code_helper code_in, tree type_in,
tree op0, tree op1, tree op2, tree op3)
- : cond (cond_in), code (code_in), type (type_in), num_ops (4)
+ : cond (cond_in), code (code_in), type (type_in), reverse (false),
+num_ops (4)
{
ops[0] = op0;
ops[1] = op1;
@@ -195,7 +201,8 @@ gimple_match_op::gimple_match_op (const
code_helper code_in, tree type_in,
tree op0, tree op1, tree op2, tree op3,
tree op4)
- : cond (cond_in), code (code_in), type (type_in), num_ops (5)
+ : cond (cond_in), code (code_in), type (type_in), reverse (false),
+num_ops (5)
{
ops[0] = op0;
ops[1] = op1;
[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968 --- Comment #9 from Thomas Preud'homme --- (In reply to Thomas Preud'homme from comment #8) > (In reply to Thomas Preud'homme from comment #7) > > (In reply to Thomas Preud'homme from comment #6) > > > Happens at expand time. Diving in. > > > > There's a giant if in expand_expr_real_1 with the following comment: > > > > /* In cases where an aligned union has an unaligned object > >as a field, we might be extracting a BLKmode value from > >an integer-mode (e.g., SImode) object. Handle this case > >by doing the extract into an object as wide as the field > >(which we know to be the width of a basic mode), then > >storing into memory, and changing the mode to BLKmode. */ > > > > The "if" is entered in the big endian unaligned case but not in the other > > case. In the aligned case, it continues after the if until the call to > > flip_storage_order which will generate the bswap. > > In the aligned case, the if is not taken because alignment of the memory Vs > access is sufficient. There is provision to call flip_storage_order but only > if the access is a RECORD and here the mode class is INT. > > Therefore unaligned access are handled by extract_bit_field. This in turns > call extract_bit_field_1 and later extract_integral_bit_field where things > are different between little endian and big endian. For little endian, it > goes in the following if block: > > /* If OP0 is a memory, try copying it to a register and seeing if a > cheap register alternative is available. */ > if (MEM_P (op0) & !reverse) > > For big endian it continues and calls extract_fixed_bit_field. I'm wondering > if an extra call to flip_storage_order when reverse is true would solve the > issue. Need to understand better whe is it safe to call flip_storage_order. It gives me the expected assembly but I need to convince myself that this is always safe.
[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968 --- Comment #8 from Thomas Preud'homme --- (In reply to Thomas Preud'homme from comment #7) > (In reply to Thomas Preud'homme from comment #6) > > Happens at expand time. Diving in. > > There's a giant if in expand_expr_real_1 with the following comment: > > /* In cases where an aligned union has an unaligned object >as a field, we might be extracting a BLKmode value from >an integer-mode (e.g., SImode) object. Handle this case >by doing the extract into an object as wide as the field >(which we know to be the width of a basic mode), then >storing into memory, and changing the mode to BLKmode. */ > > The "if" is entered in the big endian unaligned case but not in the other > case. In the aligned case, it continues after the if until the call to > flip_storage_order which will generate the bswap. In the aligned case, the if is not taken because alignment of the memory Vs access is sufficient. There is provision to call flip_storage_order but only if the access is a RECORD and here the mode class is INT. Therefore unaligned access are handled by extract_bit_field. This in turns call extract_bit_field_1 and later extract_integral_bit_field where things are different between little endian and big endian. For little endian, it goes in the following if block: /* If OP0 is a memory, try copying it to a register and seeing if a cheap register alternative is available. */ if (MEM_P (op0) & !reverse) For big endian it continues and calls extract_fixed_bit_field. I'm wondering if an extra call to flip_storage_order when reverse is true would solve the issue. Need to understand better whe is it safe to call flip_storage_order.
Re: [PATCHv2] Handle not explicitly zero terminated strings in merge sections
> Which version exactly (pkg list entire) of Solaris 11 are you running? > I'm using gas 2.31 and /bin/ld on Solaris 11.4 resp. 11.5 Beta, where > Bernd's patch in PR bootstrap/87551 fixed the remaining regressions. Solaris 11.3 with Gas 2.30. -- Eric Botcazou
libgo patch committed: Skip testSetPanicOnFault when using LLVM
This patch by Cherry Zhang skips the testSetPanicOnFault tests when
using gollvm. LLVM doesn't support non-call exceptions. This test was
passing more or less by luck: if the faulting instruction is between
two calls with the same landing pad (in instruction layout order, not
the program's logic order), it generates a merged PC range that covers
the faulting instruction. If the instruction layout order changes, or
it uses two different (but may be degenerate) landing pads, this
doesn't work. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 264932)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-a9da4d34a2f878a5058f7e7d2beef52aa62471a1
+e32e9aaee598eeb43f9616cf6ca1d11acaa9d167
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
Index: libgo/go/runtime/runtime_test.go
===
--- libgo/go/runtime/runtime_test.go(revision 264813)
+++ libgo/go/runtime/runtime_test.go(working copy)
@@ -166,6 +166,9 @@ func TestSetPanicOnFault(t *testing.T) {
}
func testSetPanicOnFault(t *testing.T, addr uintptr, nfault *int) {
+ if strings.Contains(Version(), "llvm") {
+ t.Skip("LLVM doesn't support non-call exception")
+ }
if GOOS == "nacl" {
t.Skip("nacl doesn't seem to fault on high addresses")
}
[Bug fortran/87568] New: Gfortran compile fails with bogus error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87568 Bug ID: 87568 Summary: Gfortran compile fails with bogus error message. Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: david.sagan at gmail dot com Target Milestone: --- consider the following test program: subroutine tao_show_this () implicit none type b_struct integer, pointer :: good_user => null() end type type a_struct type (b_struct), allocatable :: value_ptr(:) end type type (a_struct) a a = a_struct() end subroutine Compiling gives: > gfortran -c test.f90 test.f90:4:13: type b_struct 1 Error: The rank of the element in the structure constructor at (1) does not match that of the component (0/1) I believe this error message is bogus. Ifort will compile this code without error. Note: This code will compile if modified in a number of ways: 1) Replace "value_ptr(:)" with "value_ptr" as the allocatable component of a_struct. 2) Replace "integer, pointer :: good_user => null()" with "integer :: good_user = 0" as the component of b_struct. 3) Replace "a = a_struct()" with "a = a_struct(null())".
[Bug fortran/87566] ICE with class(*) and select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-09 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (9.0). An instrumented compiler gives ../../work/gcc/fortran/resolve.c:8883:21: runtime error: member access within null pointer of type 'struct gfc_component'
[Bug target/87563] [9 regression ] ICE with -march=armv8-a+sve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87563 Renlin Li changed: What|Removed |Added Status|NEW |ASSIGNED CC||renlin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |renlin at gcc dot gnu.org
[Bug c++/87567] constexpr evaluation rejects call to non-constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87567 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-09 CC|redi at gcc dot gnu.org| Ever confirmed|0 |1
[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968 Thomas Preud'homme changed: What|Removed |Added CC||thopre01 at gcc dot gnu.org --- Comment #7 from Thomas Preud'homme --- (In reply to Thomas Preud'homme from comment #6) > Happens at expand time. Diving in. There's a giant if in expand_expr_real_1 with the following comment: /* In cases where an aligned union has an unaligned object as a field, we might be extracting a BLKmode value from an integer-mode (e.g., SImode) object. Handle this case by doing the extract into an object as wide as the field (which we know to be the width of a basic mode), then storing into memory, and changing the mode to BLKmode. */ The "if" is entered in the big endian unaligned case but not in the other case. In the aligned case, it continues after the if until the call to flip_storage_order which will generate the bswap.
[Bug c++/87567] New: constexpr evaluation rejects call to non-constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87567
Bug ID: 87567
Summary: constexpr evaluation rejects call to non-constexpr
function
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: raphael.kubo.da.costa at intel dot com
Target Milestone: ---
This is similar to bug 86678, and can be reproduced with trunk:
constexpr bool always_false() { return false; }
int f() { return 1; }
constexpr int g() {
while (always_false())
return f();
return 0;
}
: In function 'constexpr int g()':
:5:13: error: call to non-'constexpr' function 'int f()'
5 | return f();
|~^~
It works with MSVC, ICC and clang (GCC also works if `while' is replaced with
`if').
[Bug libstdc++/87544] alloc-size-larger-than incorrectly triggered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544 --- Comment #13 from Martin Sebor --- There is a call to malloc(SIZE_MAX - 15) in GIMPLE, as a result of the conditional and I believe jump threading. Just after thread1 we see this in the vrp1 dump: [local count: 32272892]: # _91 = PHI <_54(4), _6(6)> # iftmp.2_92 = PHI <1152921504606846975(4), 1152921504606846975(6)> size_94 = iftmp.2_92 * 16; result_96 = __builtin_malloc (size_94); goto ; [100.00%] and after cselim: [local count: 32272892]: # _91 = PHI <_54(4), _6(6)> size_94 = 18446744073709551600; result_96 = __builtin_malloc (size_94); goto ; [100.00%] which is then propagated into malloc. That's what the warning sees. I think the malloc folding would be fine (provided errno was set as well) but operator new probably wouldn't be because the operator is replaceable so it could be detected (unless the standard was changed to allow the elision).
[Bug target/87565] suboptimal memory-indirect tailcalls on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87565 --- Comment #2 from Alexander Monakov --- PLT trampolines all end with 'ldr pc, [ip, xxx]!', so do all calls via PLT suffer from poor branch prediction of such indirect jumps?
[Bug preprocessor/83256] inconsistent _Pragma behavior in multi-line macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83256 --- Comment #3 from joseph at codesourcery dot com --- Unless someone can identify a commit that deliberately fixed the bug *and added appropriate tests to the testsuite*, I'd strongly advise adding tests to the testsuite before marking FIXED on the basis of those tests now passing (if they are passing incidentally as a result of some other change that didn't add tests directly related to this bug).
Re: [C++ Patch] PR 84423 ("[6/7/8/9 Regression] [concepts] ICE with invalid using declaration")
On Sat, Sep 29, 2018 at 3:27 PM Paolo Carlini wrote: > Hi again, > > On 9/28/18 9:15 PM, Paolo Carlini wrote: > > Thanks. About the location, you are certainly right, but doesn't seem > > trivial. Something we can do *now* is using > > declspecs->locations[ds_typedef] and declspecs->locations[ds_alias], > > but that gives us the location of the keyword 'typedef' and 'using', > > respectively, whereas I think that we would like to have the location > > of 'auto' itself. I could look into that as a follow-up piece work > > In fact, completing the work turned out to be easy: ensure that > cp_parser_alias_declaration saves the location of the defining-type-id > too and then consistently use locations[ds_type_spec] in the error > messages. Tested x86_64-linux. Still Ok? ;) Hmm, I think you need to look past any cv-qualifiers at the beginning of the type-id. Jason
[Ada] Fix spurious -Wuninitialized warnings for small records
This change is aimed at getting rid of spurious -Wuninitialized warnings issued for small records passed by copy and containing default values for some of their components. The source of the problem is that the _Init parameter of the initialization routine is declared as an in/out parameter, so the uninitialized object is passed by copy to it and this can be flagged by -Wuninitialized. That's why the mode of the parameter is changed to out, except for the cases where information really needs to be passed in: unconstrained array types, protected and task types. For the following record type Rec! type Rec is record B : Boolean := True; end record; the initialization routine must now be: procedure r__recIP (_init : out r__rec1) is begin _init.b := true; return; end r__recIP; Tested on x86_64-pc-linux-gnu, committed on trunk 2018-10-09 Eric Botcazou gcc/ada/ * exp_ch3.adb (Is_Null_Statement_List): New predicate. (Build_Array_Init_Proc): Use it to find out whether the initialization procedure Is_Null_Init_Proc; if so, set Warnings_Off on the parameter. (Build_Init_Procedure): Likewise. (Init_Formals): Use an in/out first parameter only for unconstrained arrays and for records either containing or built for proteced types or task types; use an out parameter in all the other cases. * fe.h (Is_Init_Proc): Declare. * gcc-interface/decl.c (type_requires_init_of_formal): Do not return true for a discriminant in an unchecked union. (gnat_to_gnu_param): Do not create a PARM_DECL for the Out parameter of an initialization procedure.--- gcc/ada/exp_ch3.adb +++ gcc/ada/exp_ch3.adb @@ -202,6 +202,11 @@ package body Exp_Ch3 is -- Check if E is defined in the RTL (in a child of Ada or System). Used -- to avoid to bring in the overhead of _Input, _Output for tagged types. + function Is_Null_Statement_List (Stmts : List_Id) return Boolean; + -- Returns true if Stmts is made of null statements only, possibly wrapped + -- in a case statement, recursively. This latter pattern may occur for the + -- initialization procedure of an unchecked union. + function Is_User_Defined_Equality (Prim : Node_Id) return Boolean; -- Returns true if Prim is a user defined equality function @@ -529,6 +534,7 @@ package body Exp_Ch3 is Has_Default_Init : Boolean; Index_List : List_Id; Loc : Source_Ptr; + Parameters : List_Id; Proc_Id : Entity_Id; function Init_Component return List_Id; @@ -722,13 +728,14 @@ package body Exp_Ch3 is end if; Body_Stmts := Init_One_Dimension (1); + Parameters := Init_Formals (A_Type); Discard_Node ( Make_Subprogram_Body (Loc, Specification => Make_Procedure_Specification (Loc, Defining_Unit_Name => Proc_Id, - Parameter_Specifications => Init_Formals (A_Type)), + Parameter_Specifications => Parameters), Declarations => New_List, Handled_Statement_Sequence => Make_Handled_Sequence_Of_Statements (Loc, @@ -753,18 +760,14 @@ package body Exp_Ch3 is -- where we have to generate a null procedure in case it is called -- by a client with Initialize_Scalars set). Such procedures have -- to be generated, but do not have to be called, so we mark them - -- as null to suppress the call. + -- as null to suppress the call. Kill also warnings for the _Init + -- out parameter, which is left entirely uninitialized. Set_Init_Proc (A_Type, Proc_Id); - if List_Length (Body_Stmts) = 1 - - -- We must skip SCIL nodes because they may have been added to this - -- list by Insert_Actions. - - and then Nkind (First_Non_SCIL_Node (Body_Stmts)) = N_Null_Statement - then + if Is_Null_Statement_List (Body_Stmts) then Set_Is_Null_Init_Proc (Proc_Id); +Set_Warnings_Off (Defining_Identifier (First (Parameters))); else -- Try to build a static aggregate to statically initialize @@ -2803,18 +2806,14 @@ package body Exp_Ch3 is -- where we have to generate a null procedure in case it is called -- by a client with Initialize_Scalars set). Such procedures have -- to be generated, but do not have to be called, so we mark them - -- as null to suppress the call. + -- as null to suppress the call. Kill also warnings for the _Init + -- out parameter, which is left entirely uninitialized. Set_Init_Proc (Rec_Type, Proc_Id); - if List_Length (Body_Stmts) = 1 - - -- We must skip SCIL nodes because they may have been added to this - -- list by
[Ada] Ignore pragmas Compile_Time_Error/Warning in GNATprove mode
GNATprove does not have sometimes the precise information of the compiler about size of types and objects, so that it cannot evaluate the expressions in pragma Compile_Time_Error/Warning the same way the compiler does. Thus, these pragmas should be ignored in GNATprove mode, as it can neither verify them nor assume them (if the expression cannot be evaluated at compile time, then the semantics for GNAT is to ignore them). Tested on x86_64-pc-linux-gnu, committed on trunk 2018-10-09 Yannick Moy gcc/ada/ * sem_prag.adb (Process_Compile_Time_Warning_Or_Error): Rewrite pragmas as null statements in GNATprove mode.--- gcc/ada/sem_prag.adb +++ gcc/ada/sem_prag.adb @@ -7570,6 +7570,17 @@ package body Sem_Prag is -- Start of processing for Process_Compile_Time_Warning_Or_Error begin + -- In GNATprove mode, pragmas Compile_Time_Error and + -- Compile_Time_Warning are ignored, as the analyzer may not have the + -- same information as the compiler (in particular regarding size of + -- objects decided in gigi) so it makes no sense to issue an error or + -- warning in GNATprove. + + if GNATprove_Mode then +Rewrite (N, Make_Null_Statement (Loc)); +return; + end if; + Check_Arg_Count (2); Check_No_Identifiers; Check_Arg_Is_OK_Static_Expression (Arg2, Standard_String);
[Ada] Fix spurious error on derived record passed as Out parameter
This fixlet gets rid of a spurious error issued in the specific case of
a call to a subprogram taking an Out parameter of a discriminated record
type without default discriminants, if the actual parameter is the
result of the conversion to the record type of a variable whose type is
derived from the record and has a representation clause.
The compiler was failing to initialize the temporary made around the
call because of the representation clause, but this is required for a
type with discriminants because discriminants may be read by the called
subprogram.
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-10-09 Eric Botcazou
gcc/ada/
* exp_ch6.adb (Add_Call_By_Copy_Code): Initialize the temporary
made for an Out parameter if the formal type has discriminants.
gcc/testsuite/
* gnat.dg/derived_type5.adb, gnat.dg/derived_type5_pkg.ads: New
testcase.--- gcc/ada/exp_ch6.adb
+++ gcc/ada/exp_ch6.adb
@@ -1321,8 +1321,14 @@ package body Exp_Ch6 is
-- bounds of the actual and build an uninitialized temporary of the
-- right size.
+ -- If the formal is an out parameter with discriminants, the
+ -- discriminants must be captured even if the rest of the object
+ -- is in principle uninitialized, because the discriminants may
+ -- be read by the called subprogram.
+
if Ekind (Formal) = E_In_Out_Parameter
or else (Is_Array_Type (F_Typ) and then not Is_Constrained (F_Typ))
+ or else Has_Discriminants (F_Typ)
then
if Nkind (Actual) = N_Type_Conversion then
if Conversion_OK (Actual) then
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/derived_type5.adb
@@ -0,0 +1,10 @@
+-- { dg-do compile }
+
+with Derived_Type5_Pkg; use Derived_Type5_Pkg;
+
+procedure Derived_Type5 is
+ D : Derived;
+begin
+ Proc1 (Rec (D));
+ Proc2 (Rec (D));
+end;
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/derived_type5_pkg.ads
@@ -0,0 +1,27 @@
+package Derived_Type5_Pkg is
+
+ type T_Unsigned8 is new Natural range 0 .. (2 ** 8 - 1);
+
+ type Rec (Discriminant : T_Unsigned8) is record
+ Fixed_Field : T_Unsigned8;
+ case Discriminant is
+ when 0 =>
+Optional_Field : T_unsigned8;
+ when others =>
+null;
+ end case;
+ end record;
+
+ type Derived is new Rec (0);
+
+ for Derived use record
+ Fixed_Fieldat 0 range 0 .. 7;
+ Discriminant at 0 range 8 .. 15;
+ Optional_Field at 0 range 16 .. 23;
+ end record;
+
+ procedure Proc1 (R : in out Rec);
+
+ procedure Proc2 (R : out Rec);
+
+end Derived_Type5_Pkg;
[Ada] Fix strange warning when using Ada.Iterator_Interface
The back-end was recently changed to issue more -Wuninitialized warnings
on Out parameters and this has caught a case related to
Ada.Iterator_Interface.: This patchlet simply kills this uninteresting
warning.
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-10-09 Eric Botcazou
gcc/ada/
* exp_disp.adb (Make_Disp_Asynchronous_Select_Spec): Set
Warnings_Off on the B out parameter.
gcc/testsuite/
* gnat.dg/warn17.adb: New testcase.--- gcc/ada/exp_disp.adb
+++ gcc/ada/exp_disp.adb
@@ -2487,9 +2487,10 @@ package body Exp_Disp is
(Typ : Entity_Id) return Node_Id
is
Loc: constant Source_Ptr := Sloc (Typ);
- Def_Id : constant Node_Id:=
+ Def_Id : constant Entity_Id :=
Make_Defining_Identifier (Loc,
Name_uDisp_Asynchronous_Select);
+ B_Id : constant Entity_Id := Make_Defining_Identifier (Loc, Name_uB);
Params : constant List_Id:= New_List;
begin
@@ -2501,6 +2502,9 @@ package body Exp_Disp is
-- B : out Dummy_Communication_Block; -- Communication block dummy
-- F : out Boolean;-- Status flag
+ -- The B parameter may be left uninitialized
+ Set_Warnings_Off (B_Id);
+
Append_List_To (Params, New_List (
Make_Parameter_Specification (Loc,
@@ -2518,7 +2522,7 @@ package body Exp_Disp is
Parameter_Type => New_Occurrence_Of (RTE (RE_Address), Loc)),
Make_Parameter_Specification (Loc,
- Defining_Identifier => Make_Defining_Identifier (Loc, Name_uB),
+ Defining_Identifier => B_Id,
Parameter_Type =>
New_Occurrence_Of (RTE (RE_Dummy_Communication_Block), Loc),
Out_Present => True),
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/warn17.adb
@@ -0,0 +1,22 @@
+-- { dg-do compile }
+-- { dg-options "-Wall" }
+
+with Ada.Iterator_Interfaces;
+
+procedure Warn17 is
+
+ type Cursor is null record;
+
+ function Has_Element (Position : Cursor) return Boolean;
+
+ function Has_Element (Position : Cursor) return Boolean is (True);
+
+ package My_Iterator is
+ new Ada.Iterator_Interfaces (Cursor, Has_Element);
+
+ type Iterator is abstract new My_Iterator.Forward_Iterator with null record;
+
+ pragma Unreferenced (Iterator);
+begin
+ null;
+end Warn17;
[Ada] Internal error on inlined renaming of subprogram instance
This fixes a recent regression introduced in the compiler for the
inlined renaming of a subprogram instantiated in a package body. It was
wrongly clearing the Is_Public flag on the entity associated with the
body.
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-10-09 Eric Botcazou
gcc/ada/
* sem_ch7.adb (Has_Referencer): Add comment for the
N_Freeze_Entity case. Do not rely on
Has_Referencer_Of_Non_Subprograms to clear the Is_Public flag on
subprogram entities.
gcc/testsuite/
* gnat.dg/inline14.adb, gnat.dg/inline14_pkg.adb,
gnat.dg/inline14_pkg.ads: New testcase.--- gcc/ada/sem_ch7.adb
+++ gcc/ada/sem_ch7.adb
@@ -441,7 +441,13 @@ package body Sem_Ch7 is
Discard : Boolean;
pragma Unreferenced (Discard);
begin
- -- Inspect the actions to find references to subprograms
+ -- Inspect the actions to find references to subprograms.
+ -- We assume that the actions do not contain other kinds
+ -- of references and, therefore, we do not stop the scan
+ -- or set Has_Referencer_Of_Non_Subprograms here. Doing
+ -- it would pessimize common cases for which the actions
+ -- contain the declaration of an init procedure, since
+ -- such a procedure is automatically marked inline.
Discard :=
Has_Referencer (Actions (Decl),
@@ -470,7 +476,8 @@ package body Sem_Ch7 is
and then not Is_Exported (Decl_Id)
and then No (Interface_Name (Decl_Id))
and then
- (not Has_Referencer_Of_Non_Subprograms
+ ((Nkind (Decl) /= N_Subprogram_Declaration
+ and then not Has_Referencer_Of_Non_Subprograms)
or else (Nkind (Decl) = N_Subprogram_Declaration
and then not Subprogram_Table.Get (Decl_Id)))
then
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/inline14.adb
@@ -0,0 +1,9 @@
+-- { dg-do compile }
+-- { dg-options "-O -gnatn" }
+
+with Inline14_Pkg; use Inline14_Pkg;
+
+procedure Inline14 is
+begin
+ Proc;
+end;
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/inline14_pkg.adb
@@ -0,0 +1,16 @@
+package body Inline14_Pkg is
+
+ I : Integer;
+
+ generic procedure Inner;
+
+ procedure Inner is
+ begin
+I := 0;
+ end;
+
+ procedure My_Inner is new Inner;
+
+ procedure Proc renames My_Inner;
+
+end Inline14_Pkg;
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/inline14_pkg.ads
@@ -0,0 +1,6 @@
+package Inline14_Pkg is
+
+ procedure Proc;
+ pragma Inline (Proc);
+
+end Inline14_Pkg;
[Ada] Spurious error message on visibiliy change in aspect expression
This patch removes an improper error message on a visibility change in an aspect expression between the freeze point and the end of the declaration list, when the expression involves a call to a instance of Unchecked_Conversion and the enclosing package declaration has a package body with multiple subprogram bodies. The following must compile quietly: package body Par.Rep is procedure Nothing is begin null; end; procedure Rien is begin null; end; end; with Par.Loc; package Par.Rep is type Rec is record X, Y : Integer; end record with Volatile; Thing2 : Unsigned_32 := 15; Thing3 : Rec with Volatile, Address => To_Address (Par.Loc.Flash_Base); procedure Nothing; end; pragma Restrictions (No_Elaboration_Code); with interfaces; use interfaces; pragma unreferenced (interfaces); with Tp; use Tp; pragma unreferenced (Tp); package Par is end Par; with Ada.Unchecked_Conversion; with System; with Interfaces; use Interfaces; package Tp is subtype system_address is unsigned_32; function to_address is new ada.unchecked_conversion (system_address, system.address); function To_32 is new ada.unchecked_conversion (System.Address, System_Address); end; with TP; use TP; package Par.Loc is FLASH_BASE: constant system_address := 16#0800_#; end; Tested on x86_64-pc-linux-gnu, committed on trunk 2018-10-09 Ed Schonberg gcc/ada/ * sem_ch6.adb (Fully_Conformant_Expressions): Handle properly the conformance check on an aspect expression that includes a call to an instance of Unchecked_Conversion, or more generally a call to an intrinsic operation.--- gcc/ada/sem_ch6.adb +++ gcc/ada/sem_ch6.adb @@ -8932,7 +8932,17 @@ package body Sem_Ch6 is or else (Chars (Entity (E1)) = Chars (Entity (E2)) and then Ekind (Entity (E1)) = E_Loop_Parameter - and then Ekind (Entity (E2)) = E_Loop_Parameter); + and then Ekind (Entity (E2)) = E_Loop_Parameter) + + -- A call to an instantiation of Unchecked_Conversion is + -- rewritten with the name of the generated function + -- created for the instance, and this must be special-cased. + + or else + (Ekind (Entity (E1)) = E_Function + and then Is_Intrinsic_Subprogram (Entity (E1)) + and then Is_Generic_Instance (Entity (E1)) + and then Entity (E2) = Alias (Entity (E1))); elsif Nkind (E1) = N_Expanded_Name and then Nkind (E2) = N_Expanded_Name
[Bug target/87565] suboptimal memory-indirect tailcalls on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87565 --- Comment #1 from Richard Earnshaw --- Not a good idea. Modern CPUs often don't predict such operations correctly
[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968 --- Comment #6 from Thomas Preud'homme --- Happens at expand time. Diving in.
[Bug libstdc++/87544] alloc-size-larger-than incorrectly triggered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544 --- Comment #12 from Jonathan Wakely --- (In reply to Martin Sebor from comment #3) > At the same time, since the call malloc(SIZE_MAX) is guaranteed to fail, GCC > could fold it to zero But there is no call to malloc(SIZE_MAX), GCC is confused about the value. It would be bad to fold the call to malloc(8) to zero.
[Bug libstdc++/87544] alloc-size-larger-than incorrectly triggered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #11 from Jonathan Wakely ---
I can make these changes to libstdc++, but why is the compiler warning anyway?
It says:
In function ‘T* my_allocator::allocate(std::size_t, const void*) [with T =
int]’,
inlined from ‘void std::vector<_Tp,
_Alloc>::_M_realloc_insert(std::vector<_Tp, _Alloc>::iterator, _Args&& ...)
[with _Args = {int}; _Tp = int; _Alloc = my_allocator]’ at
/usr/include/c++/7/bits/alloc_traits.h:301:32:
alloc_limit.cpp:18:11: warning: argument 1 value ‘18446744073709551612’ exceeds
maximum object size 9223372036854775807 [-Walloc-size-larger-than=]
void *result = std::malloc(size);
^~
In file included from /usr/include/c++/7/cstdlib:75:0,
from alloc_limit.cpp:1:
/usr/include/stdlib.h: In member function ‘void std::vector<_Tp,
_Alloc>::_M_realloc_insert(std::vector<_Tp, _Alloc>::iterator, _Args&& ...)
[with _Args = {int}; _Tp = int; _Alloc = my_allocator]’:
/usr/include/stdlib.h:424:14: note: in a call to allocation function ‘void*
malloc(size_t)’ declared here
extern void *malloc (size_t __size) __THROW __attribute_malloc__ __wur;
But this is nonsense, the value is 1*sizeof(cplx) which is 8.
Why does it think we're calling it with max_size()?
Re: [PATCH][i386] Split reductions (was: Re: [PATCH][RFC][i386] Change sminmax reduction patterns)
On Tue, Oct 9, 2018 at 3:28 PM Richard Biener wrote:
>
> On Mon, 8 Oct 2018, Richard Biener wrote:
>
> > On Fri, 5 Oct 2018, Uros Bizjak wrote:
> >
> > > On Thu, Oct 4, 2018 at 2:05 PM Richard Biener wrote:
> > > >
> > > >
> > > > This tries to apply the same trick to sminmax reduction patterns
> > > > as for the reduc_plus_scal ones, namely reduce %zmm -> %ymm -> %xmm
> > > > first. On a microbenchmark this improves performance on Zen
> > > > by ~30% for AVX2 and on Skylake-SP by ~10% for AVX512 (for AVX2
> > > > there's no measurable difference).
> > > >
> > > > I guess I'm mostly looking for feedback on the approach I took
> > > > in not rewriting ix86_expand_reduc but instead "recurse" on the
> > > > expanders as well as the need to define recursion stops for
> > > > SSE modes previously not covered.
> > > >
> > > > I'll throw this on a bootstrap & regtest on x86_64-unknown-linux-gnu
> > > > later.
> > > >
> > > > Any comments sofar? Writing .md patterns is new for me ;)
> > >
> > > LGTM for the implementation.
> >
> > So this applies the method to all AVX2/AVX512 reduc_*_scal_* patterns
> > we have. I've inspected the assembly and it looks as expected.
> >
> > Note I tried relying on the vectorizer to perform this, thus delete
> > the patterns. Trying that for the reduc_plus_* ones reveals that
> > the final (SSE width) reduction step looks different and
> > unconditionally uses psrldq as the vectorizer expands the final
> > reduction step using whole-vector shifts. Well, it actually
> > generates permutes like
> >
> > vect_res_6.10_22 = VEC_PERM_EXPR <_21, { 0.0, 0.0, 0.0, 0.0 }, { 2, 3,
> > 4, 5 }>;
> >
> > but those end up using the vec_shr_ expander which puns
> > everything to V1TImode. Removing the vec_shr_ expander
> > also doesn't get us the desired movhlps instruction for the
> > above (but a vshufps). I'm not sure where to best fix that
> > (I think with good vec_perm expanders we shouldn't neeed the
> > vec_shr one - at least we'd keep the float/int domain), so I
> > kept all the reduc_* expanders we have now. But I'll note
> > those we do not have (luckily all non-FP) use that
> > "inefficient"(?) instructions. Like on Zen psrldq has a reciprocal
> > throughput of 1 while movhlps has one of 0.5, so using movhlps
> > would help loops with two reductions, on Skylake the opposite
> > seems to be the case...
> >
> > Boostrapped on x86_64-unknown-linux-gnu, testing in progress.
>
> Went fine after fixing ...
>
> > @@ -2585,9 +2556,14 @@ (define_expand "reduc__scal_
> > (match_operand:VI_256 1 "register_operand"))]
> >"TARGET_AVX2"
> > {
> > - rtx tmp = gen_reg_rtx (mode);
> > - ix86_expand_reduc (gen_3, tmp, operands[1]);
> > - emit_insn (gen_vec_extract (operands[0], tmp,
> > + rtx tmp = gen_reg_rtx (mode);
> > + emit_insn (gen_vec_extract_hi_ (tmp, operands[1]));
> > + rtx tmp2 = gen_reg_rtx (mode);
> > + emit_insn (gen_3
> > +(tmp2, tmp, gen_lowpart (mode, operands[1])));
> > + rtx tmp3 = gen_reg_rtx (mode);
> ^^^
>
> > + ix86_expand_reduc (gen_3, tmp3, tmp2);
> > + emit_insn (gen_vec_extract (operands[0], tmp3,
> ^^^
>
> to use the proper mode (fixed patch re-attached below).
>
> OK?
>
> Richard.
>
> 2018-10-08 Richard Biener
>
> * config/i386/sse.md (reduc_plus_scal_v8df, reduc_plus_scal_v4df,
> reduc_plus_scal_v2df, reduc_plus_scal_v16sf, reduc_plus_scal_v8sf,
> reduc_plus_scal_v4sf): Merge into pattern reducing to half width
> and recursing and pattern terminating the recursion on SSE
> vector width using ix86_expand_reduc.
> (reduc_sminmax_scal_): Split into part reducing to half
> width and recursing and SSE2 vector variant doing the final
> reduction with ix86_expand_reduc.
> (reduc_uminmax_scal_): Likewise for the AVX512 variants
> with terminating the recursion at AVX level, splitting that
> to SSE there.
OK.
Thanks,
Uros.
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index 692959b1666..9fc5819a863 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -2457,98 +2457,65 @@
> (set_attr "prefix_rep" "1,*")
> (set_attr "mode" "V4SF")])
>
> -(define_expand "reduc_plus_scal_v8df"
> - [(match_operand:DF 0 "register_operand")
> - (match_operand:V8DF 1 "register_operand")]
> - "TARGET_AVX512F"
> -{
> - rtx tmp = gen_reg_rtx (V8DFmode);
> - ix86_expand_reduc (gen_addv8df3, tmp, operands[1]);
> - emit_insn (gen_vec_extractv8dfdf (operands[0], tmp, const0_rtx));
> - DONE;
> -})
> +(define_mode_iterator REDUC_SSE_PLUS_MODE
> + [(V2DF "TARGET_SSE") (V4SF "TARGET_SSE")])
>
> -(define_expand "reduc_plus_scal_v4df"
> - [(match_operand:DF 0 "register_operand")
> - (match_operand:V4DF 1 "register_operand")]
> - "TARGET_AVX"
> +(define_expand "reduc_plus_scal_"
> + [(plus:REDUC_SSE_PLUS_MODE
> + (match_operand: 0 "register_operand")
> + (match_operand:REDUC_SSE_PLUS_MODE 1 "register_operand"))]
> + ""
> {
>
[Bug middle-end/86815] [8/9 regression] ICE on valid code on armhf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86815 Ramana Radhakrishnan changed: What|Removed |Added Keywords||needs-reduction CC||ramana at gcc dot gnu.org --- Comment #7 from Ramana Radhakrishnan --- (In reply to Gianfranco from comment #6) > Created attachment 44485 [details] > another failing output > > I'm attaching another file suffering from the same issue (mostly every cpp > file has this failure) > this file is only ~2Mb, so maybe reducing it might be easier Needs reduction.
[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #5 from Ramana Radhakrishnan --- (In reply to jos...@codesourcery.com from comment #4) > Any unaligned access things that don't work for big-endian ARM are > probably fallout from the issues with big-endian NEON (NEON architectural > lane numbers are different from the architecture-independent lane numbers > in GNU C vector extensions and GCC IR, and GCC expects each machine mode > to have a single defined memory layout and a single defined layout in any > given register, and to be able to move between core and NEON registers, > and between core registers and memory, in the respective layouts used for > those registers, but some NEON loads and stores for big-endian don't work > with those expectations, so unaligned vector operations are limited for > big-endian ARM). Correct, we don't allow misaligned access for Neon because of exactly the above mentioned reasons. I would have however expected misaligned access to work with -march=armv7-a -munaligned-access -mfpu=vfpv3-d16 -mfloat-abi=softfp/hard on the command line for the afore mentioned testcase as we do have a movmisalign pattern in arm.md that should kick in overriding the movmisalign pattern in neon.md. It probably needs a little more detailed investigation.
[Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263 --- Comment #30 from Oleg Endo --- (In reply to Eric Gallager from comment #29) > > So maybe it's worth splitting up into sub-issues? It'd be better to, yes. But at the moment I don't have a lot of time to go through all the cases and factor out the individual cases. Please leave this open. It will be useful if I (or others) get back to active SH development in the future.
[Bug fortran/87566] New: ICE with class(*) and select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566 Bug ID: 87566 Summary: ICE with class(*) and select Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- Created attachment 44818 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44818=edit Full test case Segmentation fault ICE compiling with 6.4. 7.3 or 8.2.0. subroutine AddArray() type Object_array_pointer class(*), pointer :: p(:) => null() end type Object_array_pointer class(*), pointer :: Pt => null() select type (Pt) class is (object_array_pointer) select type (Point=> Pt%P) end select end select end subroutine AddArray
[Bug c++/85153] _Pragma to disable -Wswitch-unreachable diagnostic not properly working when used within preprocessor macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85153
Peter Maydell changed:
What|Removed |Added
CC||peter.maydell at linaro dot org
--- Comment #5 from Peter Maydell ---
I was looking to see if this bug had been fixed in gcc trunk, and if you tell
godbolt to run the non-preprocessed original code on gcc trunk (ie the source
you get by following the godbolt link in comment 1), the compiler ICEs:
: In function 'int test7(int)':
:76:5: internal compiler error: in linemap_macro_map_loc_to_exp_point,
at libcpp/line-map.c:1063
76 | switch (val) {
| ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug target/87565] New: suboptimal memory-indirect tailcalls on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87565
Bug ID: 87565
Summary: suboptimal memory-indirect tailcalls on arm
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: arm-*-*
When tailcalling via a pointer that needs to be loaded from memory, gcc could
use 'ldr pc, [...]' instead of an ldr-bx sequence.
void foo(int a, int b, void (*p[])(int, int))
{
p[1](a, b);
}
I see at -Os
foo:
ldr r3, [r2, #4]
bx r3 @ indirect register sibling call
But afaict this could be simply
foo:
ldr pc, [r2, #4]
(x86 has memory-indirect jumps too and there GCC gets this right via dedicated
sibcall patterns)
Re: [PATCH] v2: C++: suggestions for misspelled private members (PR c++/84993)
On Mon, 2018-09-24 at 10:56 -0600, Martin Sebor wrote:
> On 09/21/2018 04:09 PM, David Malcolm wrote:
> > This is v2 of the patch; I managed to bit-rot my own patch due to
> > my
> > fix for r264335, which tightened up the "is this meaningful"
> > threshold
> > on edit distances when finding spelling correction candidates.
> >
> > The only change in this version is to rename various things in
> > the testcase so that they continue to be suggested
> > ("colour" vs "m_color" are no longer near enough, so I renamed
> > "colour" to "m_colour").
> >
> > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> >
> > OK for trunk?
> >
> > Blurb from v1:
> >
> > PR c++/84993 identifies a problem with our suggestions for
> > misspelled member names in the C++ FE for the case where the
> > member is private.
> >
> > For example, given:
> >
> > class foo
> > {
> > public:
> > double get_ratio() const { return m_ratio; }
> >
> > private:
> > double m_ratio;
> > };
> >
> > void test(foo *ptr)
> > {
> > if (ptr->ratio >= 0.5)
> > ;// etc
> > }
> >
> > ...we currently emit this suggestion:
> >
> > : In function 'void test(foo*)':
> > :12:12: error: 'class foo' has no member named 'ratio'; did
> > you mean 'm_ratio'?
> >if (ptr->ratio >= 0.5)
> > ^
> > m_ratio
> >
> > ...but if the user follows this suggestion, they get:
> >
> > : In function 'void test(foo*)':
> > :12:12: error: 'double foo::m_ratio' is private within this
> > context
> >if (ptr->m_ratio >= 0.5)
> > ^~~
> > :7:10: note: declared private here
> >double m_ratio;
> > ^~~
> > :12:12: note: field 'double foo::m_ratio' can be accessed
> > via 'double foo::get_ratio() const'
> >if (ptr->m_ratio >= 0.5)
> > ^~~
> > get_ratio()
> >
> > It feels wrong to be emitting a fix-it hint that doesn't compile,
> > so this
> > patch adds the accessor fix-it hint logic to this case, so that we
> > directly
> > offer a valid suggestion:
> >
> > : In function 'void test(foo*)':
> > :12:12: error: 'class foo' has no member named 'ratio'; did
> > you mean
> > 'double foo::m_ratio'? (accessible via 'double foo::get_ratio()
> > const')
> >if (ptr->ratio >= 0.5)
> > ^
> > get_ratio()
>
> I wonder if suggesting the inaccessible member is at all helpful
> if it cannot be used.
Of the two members "m_ratio" and "get_ratio", the winning candidate
based on edit-distance lookup was the inaccessible member; the accessor
is "further away" in terms of edit distance. I think it's useful to
the user to identify both, as this patch does.
> Would mentioning only the accessor be
> a better approach?
I think it's more helpful to the user to be explicit about what the
compiler is "thinking", and mention both. Consider the case where the
accessor has a wildy different name to the misspelled member:
class foo {
public:
int get_pertinent_data () { return m_val; }
private:
int m_val;
};
int test (foo *f)
{
return f->val;
}
The patch emits:
t.c: In function ‘int test(foo*)’:
t.c:11:14: error: ‘class foo’ has no member named ‘val’; did you mean
‘int foo::m_val’? (accessible via ‘int foo::get_pertinent_data()’)
11 |return f->val;
| ^~~
| get_pertinent_data()
which I think is clear and helpful.
> Also, to echo a comment made by someone else in a bug I don't
> remember, rather than phrasing the error in the form of
> a question ("did you mean x?") it might be better to either
> state what we know:
>
>error: 'class foo' has no member named 'ratio'; the nearest
> match is 'double foo::m_ratio' (accessible via 'double
> foo::get_ratio() const')
>
> or offer a suggestion:
>
>error: 'class foo' has no member named 'ratio'; suggest
> using 'double foo::get_ratio() const' instead
I think you're referring to PR 84890, though that bug was about this
kind of message:
note: ‘INT_MAX’ is defined in header ‘’; did you forget to
‘#include ’?
PR 84890 combines several concerns:
(a) is the message too verbose? (initial comment)
(b) is the message potentially annoying to the user? (comment 5)
(c) is it better to phrase the message as a suggestion, rather than as
a question? (comment 8)
Taking these in turn:
(a) may apply to the missing include message, but I think the "did you
mean 'foo'" is short and clear
(b) both styles of message refer to the user as "you", which has a risk
of making things personal. I think it's fine for the "did you mean"
case. I think there's an argument that the "did you forget" could be
annoying - but that's not a concern for this patch.
(c) of the various wordings:
(c.1) "did you mean 'foo'?" (as in the patch, and the status quo for
the rest of the C and C++ FE)
(c.2) "suggest using 'foo' instead" doesn't seem grammatically
correct to me, in that it sounds like the user is being asked to
suggest something, rather than to change their
[Bug preprocessor/83256] inconsistent _Pragma behavior in multi-line macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83256 Peter Maydell changed: What|Removed |Added CC||peter.maydell at linaro dot org --- Comment #1 from Peter Maydell --- I was investigating a similar gcc bug, and was pointed at this one. I note that the test case attached to this bug seems to be (according to the godbolt compilers) broken in gcc 7.3 but fixed by 8.1. 8.1 didn't fix everything in this area, though -- I have a rather similar kind of test case (which I'll attach), which seems to be still broken in 8.3 but fixed in gcc trunk.
[Bug c++/85890] [7 Regression] cc1plus runs out of memory in recursive Fibonacci computation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85890 --- Comment #3 from Jonathan Wakely --- And fixed on trunk by r258116
[Bug preprocessor/83256] inconsistent _Pragma behavior in multi-line macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83256 --- Comment #2 from Peter Maydell --- Created attachment 44817 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44817=edit repro for similar bug, apparently broken up to 8.3 but fixed in trunk?
[Bug ipa/82793] __attribute__((target("sse"))) causes call throught ifunc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82793 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Fixed on trunk with r264845.
[Bug gcov-profile/77698] Unrolled loop not considered hot after profiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77698 --- Comment #7 from Pat Haugen --- I also see the loop now being aligned when I apply your patch. srdi 10,10,2 mtctr 10 .p2align 4,,15 .L6: ld 9,0(11) ld 8,0(4)
Re: Building with old gcc
Hi,
On 09/10/18 15:33, Jonathan Wakely wrote:
On Tue, 9 Oct 2018 at 14:30, Paul Koning wrote:
I'm trying to build the current code on Linux with GCC 4.3.2 (stock compiler in
Fedora 10 which is my old test system). It fails like this:
In file included from
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/tree-data-ref.h:27,
from
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/gimple-loop-interchange.cc:44:
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h: In constructor
‘opt_result::opt_result(bool, opt_problem*)’:
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: class
‘opt_result’ does not have any field named ‘opt_wrapper’
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: no matching
function for call to ‘opt_wrapper::opt_wrapper()’
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:160: note: candidates are:
opt_wrapper::opt_wrapper(T, opt_problem*) [with T = bool]
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:147: note:
opt_wrapper::opt_wrapper(const opt_wrapper&)
make[3]: *** [gimple-loop-interchange.o] Error 1
Is 9.0 supposed to build with a build compiler this old?
Yes.
GCC 4.3 doesn't define the injected-class-name for the base, so this
patch is needed:
--- a/gcc/opt-problem.h
+++ b/gcc/opt-problem.h
@@ -214,7 +214,7 @@ class opt_result : public opt_wrapper
/* Private ctor. Instances should be created by the success and failure
static member functions. */
opt_result (wrapped_t result, opt_problem *problem)
- : opt_wrapper (result, problem)
+ : opt_wrapper (result, problem)
{}
};
At the end of August my colleague Jose Marchesi fixed another instance
of the same issue, affecting classes auto_edge_flag and auto_bb_flag. I
think we can commit this change too as obvious.
Paolo.
Re: Building with old gcc
On Tue, Oct 9, 2018 at 3:33 PM Jonathan Wakely wrote:
>
> On Tue, 9 Oct 2018 at 14:30, Paul Koning wrote:
> >
> > I'm trying to build the current code on Linux with GCC 4.3.2 (stock
> > compiler in Fedora 10 which is my old test system). It fails like this:
> >
> > In file included from
> > /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/tree-data-ref.h:27,
> > from
> > /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/gimple-loop-interchange.cc:44:
> > /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h: In constructor
> > ‘opt_result::opt_result(bool, opt_problem*)’:
> > /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: class
> > ‘opt_result’ does not have any field named ‘opt_wrapper’
> > /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: no
> > matching function for call to ‘opt_wrapper::opt_wrapper()’
> > /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:160: note: candidates
> > are: opt_wrapper::opt_wrapper(T, opt_problem*) [with T = bool]
> > /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:147: note:
> > opt_wrapper::opt_wrapper(const opt_wrapper&)
> > make[3]: *** [gimple-loop-interchange.o] Error 1
> >
> > Is 9.0 supposed to build with a build compiler this old?
>
> Yes.
>
> GCC 4.3 doesn't define the injected-class-name for the base, so this
> patch is needed:
OK.
> --- a/gcc/opt-problem.h
> +++ b/gcc/opt-problem.h
> @@ -214,7 +214,7 @@ class opt_result : public opt_wrapper
>/* Private ctor. Instances should be created by the success and failure
> static member functions. */
>opt_result (wrapped_t result, opt_problem *problem)
> - : opt_wrapper (result, problem)
> + : opt_wrapper (result, problem)
>{}
> };
[Bug middle-end/79768] `-Wmaybe-uninitialized' false positive with optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79768 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||marxin at gcc dot gnu.org --- Comment #9 from Martin Liška --- It has gone on trunk with r260350: SVN revision: 260350 Author: marxin Radically simplify emission of balanced tree for switch statements. 2018-05-18 Martin Liska * passes.def: Add pass_lower_switch and pass_lower_switch_O0. * tree-pass.h (make_pass_lower_switch_O0): New function. * tree-switch-conversion.c (node_has_low_bound): Remove. (node_has_high_bound): Likewise. (node_is_bounded): Likewise. (class pass_lower_switch): Make it a template type and create two instances. (pass_lower_switch::execute): Add template argument. (make_pass_lower_switch): New function. (make_pass_lower_switch_O0): New function. (do_jump_if_equal): Remove. (emit_case_nodes): Simplify to just handle all 3 cases and leave all the hard work to tree optimization passes. 2018-05-18 Martin Liska * gcc.dg/tree-ssa/vrp104.c: Adjust dump file that is scanned. * gcc.dg/tree-prof/update-loopch.c: Likewise.
Re: Building with old gcc
On Tue, 9 Oct 2018 at 14:30, Paul Koning wrote:
>
> I'm trying to build the current code on Linux with GCC 4.3.2 (stock compiler
> in Fedora 10 which is my old test system). It fails like this:
>
> In file included from
> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/tree-data-ref.h:27,
> from
> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/gimple-loop-interchange.cc:44:
> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h: In constructor
> ‘opt_result::opt_result(bool, opt_problem*)’:
> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: class
> ‘opt_result’ does not have any field named ‘opt_wrapper’
> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: no matching
> function for call to ‘opt_wrapper::opt_wrapper()’
> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:160: note: candidates
> are: opt_wrapper::opt_wrapper(T, opt_problem*) [with T = bool]
> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:147: note:
>opt_wrapper::opt_wrapper(const opt_wrapper&)
> make[3]: *** [gimple-loop-interchange.o] Error 1
>
> Is 9.0 supposed to build with a build compiler this old?
Yes.
GCC 4.3 doesn't define the injected-class-name for the base, so this
patch is needed:
--- a/gcc/opt-problem.h
+++ b/gcc/opt-problem.h
@@ -214,7 +214,7 @@ class opt_result : public opt_wrapper
/* Private ctor. Instances should be created by the success and failure
static member functions. */
opt_result (wrapped_t result, opt_problem *problem)
- : opt_wrapper (result, problem)
+ : opt_wrapper (result, problem)
{}
};
[Bug target/83409] arc: "internal compiler error: in extract_constrain_insn" with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83409 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-09 Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Looks very old, I see it also with GCC-5 branch.
Building with old gcc
I'm trying to build the current code on Linux with GCC 4.3.2 (stock compiler in Fedora 10 which is my old test system). It fails like this: In file included from /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/tree-data-ref.h:27, from /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/gimple-loop-interchange.cc:44: /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h: In constructor ‘opt_result::opt_result(bool, opt_problem*)’: /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: class ‘opt_result’ does not have any field named ‘opt_wrapper’ /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: no matching function for call to ‘opt_wrapper::opt_wrapper()’ /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:160: note: candidates are: opt_wrapper::opt_wrapper(T, opt_problem*) [with T = bool] /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:147: note: opt_wrapper::opt_wrapper(const opt_wrapper&) make[3]: *** [gimple-loop-interchange.o] Error 1 Is 9.0 supposed to build with a build compiler this old? The documentation on the GCC web page says an ISO C++ compiler is required but it doesn't tell me whether the C++ compiler in GCC 4.3.2 is adequate. Since many people will be installing GCC using an older version of GCC, it would be good for the documentation to state what the minimum version of GCC is. paul
Re: [PATCH][i386] Split reductions (was: Re: [PATCH][RFC][i386] Change sminmax reduction patterns)
On Mon, 8 Oct 2018, Richard Biener wrote:
> On Fri, 5 Oct 2018, Uros Bizjak wrote:
>
> > On Thu, Oct 4, 2018 at 2:05 PM Richard Biener wrote:
> > >
> > >
> > > This tries to apply the same trick to sminmax reduction patterns
> > > as for the reduc_plus_scal ones, namely reduce %zmm -> %ymm -> %xmm
> > > first. On a microbenchmark this improves performance on Zen
> > > by ~30% for AVX2 and on Skylake-SP by ~10% for AVX512 (for AVX2
> > > there's no measurable difference).
> > >
> > > I guess I'm mostly looking for feedback on the approach I took
> > > in not rewriting ix86_expand_reduc but instead "recurse" on the
> > > expanders as well as the need to define recursion stops for
> > > SSE modes previously not covered.
> > >
> > > I'll throw this on a bootstrap & regtest on x86_64-unknown-linux-gnu
> > > later.
> > >
> > > Any comments sofar? Writing .md patterns is new for me ;)
> >
> > LGTM for the implementation.
>
> So this applies the method to all AVX2/AVX512 reduc_*_scal_* patterns
> we have. I've inspected the assembly and it looks as expected.
>
> Note I tried relying on the vectorizer to perform this, thus delete
> the patterns. Trying that for the reduc_plus_* ones reveals that
> the final (SSE width) reduction step looks different and
> unconditionally uses psrldq as the vectorizer expands the final
> reduction step using whole-vector shifts. Well, it actually
> generates permutes like
>
> vect_res_6.10_22 = VEC_PERM_EXPR <_21, { 0.0, 0.0, 0.0, 0.0 }, { 2, 3,
> 4, 5 }>;
>
> but those end up using the vec_shr_ expander which puns
> everything to V1TImode. Removing the vec_shr_ expander
> also doesn't get us the desired movhlps instruction for the
> above (but a vshufps). I'm not sure where to best fix that
> (I think with good vec_perm expanders we shouldn't neeed the
> vec_shr one - at least we'd keep the float/int domain), so I
> kept all the reduc_* expanders we have now. But I'll note
> those we do not have (luckily all non-FP) use that
> "inefficient"(?) instructions. Like on Zen psrldq has a reciprocal
> throughput of 1 while movhlps has one of 0.5, so using movhlps
> would help loops with two reductions, on Skylake the opposite
> seems to be the case...
>
> Boostrapped on x86_64-unknown-linux-gnu, testing in progress.
Went fine after fixing ...
> @@ -2585,9 +2556,14 @@ (define_expand "reduc__scal_
> (match_operand:VI_256 1 "register_operand"))]
>"TARGET_AVX2"
> {
> - rtx tmp = gen_reg_rtx (mode);
> - ix86_expand_reduc (gen_3, tmp, operands[1]);
> - emit_insn (gen_vec_extract (operands[0], tmp,
> + rtx tmp = gen_reg_rtx (mode);
> + emit_insn (gen_vec_extract_hi_ (tmp, operands[1]));
> + rtx tmp2 = gen_reg_rtx (mode);
> + emit_insn (gen_3
> +(tmp2, tmp, gen_lowpart (mode, operands[1])));
> + rtx tmp3 = gen_reg_rtx (mode);
^^^
> + ix86_expand_reduc (gen_3, tmp3, tmp2);
> + emit_insn (gen_vec_extract (operands[0], tmp3,
^^^
to use the proper mode (fixed patch re-attached below).
OK?
Richard.
2018-10-08 Richard Biener
* config/i386/sse.md (reduc_plus_scal_v8df, reduc_plus_scal_v4df,
reduc_plus_scal_v2df, reduc_plus_scal_v16sf, reduc_plus_scal_v8sf,
reduc_plus_scal_v4sf): Merge into pattern reducing to half width
and recursing and pattern terminating the recursion on SSE
vector width using ix86_expand_reduc.
(reduc_sminmax_scal_): Split into part reducing to half
width and recursing and SSE2 vector variant doing the final
reduction with ix86_expand_reduc.
(reduc_uminmax_scal_): Likewise for the AVX512 variants
with terminating the recursion at AVX level, splitting that
to SSE there.
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 692959b1666..9fc5819a863 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -2457,98 +2457,65 @@
(set_attr "prefix_rep" "1,*")
(set_attr "mode" "V4SF")])
-(define_expand "reduc_plus_scal_v8df"
- [(match_operand:DF 0 "register_operand")
- (match_operand:V8DF 1 "register_operand")]
- "TARGET_AVX512F"
-{
- rtx tmp = gen_reg_rtx (V8DFmode);
- ix86_expand_reduc (gen_addv8df3, tmp, operands[1]);
- emit_insn (gen_vec_extractv8dfdf (operands[0], tmp, const0_rtx));
- DONE;
-})
+(define_mode_iterator REDUC_SSE_PLUS_MODE
+ [(V2DF "TARGET_SSE") (V4SF "TARGET_SSE")])
-(define_expand "reduc_plus_scal_v4df"
- [(match_operand:DF 0 "register_operand")
- (match_operand:V4DF 1 "register_operand")]
- "TARGET_AVX"
+(define_expand "reduc_plus_scal_"
+ [(plus:REDUC_SSE_PLUS_MODE
+ (match_operand: 0 "register_operand")
+ (match_operand:REDUC_SSE_PLUS_MODE 1 "register_operand"))]
+ ""
{
- rtx tmp = gen_reg_rtx (V2DFmode);
- emit_insn (gen_vec_extract_hi_v4df (tmp, operands[1]));
- rtx tmp2 = gen_reg_rtx (V2DFmode);
- emit_insn (gen_addv2df3 (tmp2, tmp, gen_lowpart (V2DFmode, operands[1])));
- rtx tmp3 = gen_reg_rtx (V2DFmode);
- emit_insn (gen_vec_interleave_highv2df (tmp3, tmp2,
[Bug lto/85574] [9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #6 from rguenther at suse dot de --- On Tue, 9 Oct 2018, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 > > --- Comment #5 from Martin Liška --- > Richi is it fixed? No.
[Bug target/87561] [9 Regression] 416.gamess is slower by ~10% starting from r264866 with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87561
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
CC||rsandifo at gcc dot gnu.org
--- Comment #4 from Richard Biener ---
Another thing is the too complicated alias check where for
(gdb) p debug_data_reference (dr_a.dr)
#(Data Ref:
# bb: 14
# stmt: _28 = *xpqkl_172(D)[_27];
# ref: *xpqkl_172(D)[_27];
# base_object: *xpqkl_172(D);
# Access function 0: {(((integer(kind=8)) mkl_203 + 1) * stride.33_148 +
offset.34_149) + _480, +, stride.33_148}_6
#)
$9 = void
(gdb) p debug_data_reference (dr_b.dr)
#(Data Ref:
# bb: 14
# stmt: *xpqkl_172(D)[_50] = _65;
# ref: *xpqkl_172(D)[_50];
# base_object: *xpqkl_172(D);
# Access function 0: {(((integer(kind=8)) mkl_203 + 1) * stride.33_148 +
offset.34_149) + _486, +, stride.33_148}_6
#)
we generate
(ssizetype) (((sizetype) integer(kind=8)) mkl_203 + 1) * stride.33_148 +
offset.34_149) + (integer(kind=8)) (_19 + jpack_161)) + (sizetype)
stride.33_148) * 8) < (ssizetype) ((sizetype) integer(kind=8)) mkl_203 + 1)
* stride.33_148 + offset.34_149) + (integer(kind=8)) (_22 + lpack_164)) * 8) ||
(ssizetype) (((sizetype) integer(kind=8)) mkl_203 + 1) * stride.33_148 +
offset.34_149) + (integer(kind=8)) (_22 + lpack_164)) + (sizetype)
stride.33_148) * 8) < (ssizetype) ((sizetype) integer(kind=8)) mkl_203 + 1)
* stride.33_148 + offset.34_149) + (integer(kind=8)) (_19 + jpack_161)) * 8)
instead of simply _480 != _486 (well, OK, not _that_ simple).
I guess we miss many of the "optimizations" we do when dealing with
alias checks for constant steps. In this case sth obvious would be
to special-case DR_STEP (dra) == DR_STEP (drb). Richard?
[Bug lto/85574] [9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #5 from Martin Liška --- Richi is it fixed?
[Bug c++/85890] [7 Regression] cc1plus runs out of memory in recursive Fibonacci computation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85890 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | Status|NEW |ASSIGNED CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Martin Liška --- Regressed with r255813.
[gomp5] Fix handling of task_reduction with variable length array sections
Hi!
As the following testcase additions show, even the TYPE_MAX_VALUE var needs
to be forced into temporary if it is a user variable, otherwise if that
variable is changed by the user before taskgroup ends, we don't handle it
correctly.
In addition to that, this patch removes useless NULL second argument from
create_tmp_var, forgot we do have a default argument here.
Tested on x86_64-linux, committed to gomp-5_0-branch.
2018-10-09 Jakub Jelinek
* omp-low.c (lower_omp_task_reductions): Force TYPE_MAX_VALUE into
a temporary in the start sequence and even when it is a decl already.
* omp-low.c (lower_rec_input_clauses, lower_reduction_clauses,
lower_omp_task_reductions): Remove second argument create_tmp_var
if it is NULL.
* gimplify.c (gimplify_omp_depend): Likewise.
* testsuite/libgomp.c-c++-common/task-reduction-5.c: Add further test
to verify the array bound var can be changed in taskgroup.
--- gcc/omp-low.c.jj2018-10-08 17:30:42.147353172 +0200
+++ gcc/omp-low.c 2018-10-09 14:19:54.672380754 +0200
@@ -4091,7 +4091,7 @@ lower_rec_input_clauses (tree clauses, g
gimple_seq_add_stmt (ilist, g);
}
- tree y1 = create_tmp_var (ptype, NULL);
+ tree y1 = create_tmp_var (ptype);
gimplify_assign (y1, y, ilist);
tree i2 = NULL_TREE, y2 = NULL_TREE;
tree body2 = NULL_TREE, end2 = NULL_TREE;
@@ -4102,14 +4102,14 @@ lower_rec_input_clauses (tree clauses, g
size_int (task_reduction_cnt_full
+ task_reduction_cntorig - 1),
NULL_TREE, NULL_TREE);
- y3 = create_tmp_var (ptype, NULL);
+ y3 = create_tmp_var (ptype);
gimplify_assign (y3, ref, ilist);
}
else if (OMP_CLAUSE_REDUCTION_PLACEHOLDER (c) || is_simd)
{
if (pass != 3)
{
- y2 = create_tmp_var (ptype, NULL);
+ y2 = create_tmp_var (ptype);
gimplify_assign (y2, y, ilist);
}
if (is_simd || OMP_CLAUSE_REDUCTION_OMP_ORIG_REF (c))
@@ -4126,23 +4126,23 @@ lower_rec_input_clauses (tree clauses, g
if (OMP_CLAUSE_REDUCTION_PLACEHOLDER (c)
&& OMP_CLAUSE_REDUCTION_OMP_ORIG_REF (c))
{
- y3 = create_tmp_var (ptype, NULL);
+ y3 = create_tmp_var (ptype);
gimplify_assign (y3, unshare_expr (ref), ilist);
}
if (is_simd)
{
- y4 = create_tmp_var (ptype, NULL);
+ y4 = create_tmp_var (ptype);
gimplify_assign (y4, ref, dlist);
}
}
}
- tree i = create_tmp_var (TREE_TYPE (v), NULL);
+ tree i = create_tmp_var (TREE_TYPE (v));
gimplify_assign (i, build_int_cst (TREE_TYPE (v), 0), ilist);
tree body = create_artificial_label (UNKNOWN_LOCATION);
gimple_seq_add_stmt (ilist, gimple_build_label (body));
if (y2)
{
- i2 = create_tmp_var (TREE_TYPE (v), NULL);
+ i2 = create_tmp_var (TREE_TYPE (v));
gimplify_assign (i2, build_int_cst (TREE_TYPE (v), 0), dlist);
body2 = create_artificial_label (UNKNOWN_LOCATION);
end2 = create_artificial_label (UNKNOWN_LOCATION);
@@ -5603,7 +5603,7 @@ lower_reduction_clauses (tree clauses, g
tree d = OMP_CLAUSE_DECL (c);
tree type = TREE_TYPE (d);
tree v = TYPE_MAX_VALUE (TYPE_DOMAIN (type));
- tree i = create_tmp_var (TREE_TYPE (v), NULL);
+ tree i = create_tmp_var (TREE_TYPE (v));
tree ptype = build_pointer_type (TREE_TYPE (type));
tree bias = TREE_OPERAND (d, 1);
d = TREE_OPERAND (d, 0);
@@ -5667,10 +5667,10 @@ lower_reduction_clauses (tree clauses, g
}
new_var = fold_convert_loc (clause_loc, ptype, new_var);
ref = fold_convert_loc (clause_loc, ptype, ref);
- tree m = create_tmp_var (ptype, NULL);
+ tree m = create_tmp_var (ptype);
gimplify_assign (m, new_var, stmt_seqp);
new_var = m;
- m = create_tmp_var (ptype, NULL);
+ m = create_tmp_var (ptype);
gimplify_assign (m, ref, stmt_seqp);
ref = m;
gimplify_assign (i, build_int_cst (TREE_TYPE (v), 0), stmt_seqp);
@@ -6896,22 +6896,24 @@ lower_omp_task_reductions (omp_context *
{
tree type = TREE_TYPE (new_var);
tree v = TYPE_MAX_VALUE (TYPE_DOMAIN
[PATCH] Define std::string and related typedefs outside __cxx11 namespace
The typedefs for common specializations of std::__cxx11::basic_string do
not need to be in the std::__cxx11 namespace. Those typedefs are never
used for linkage purposes so don't appear in mangled names, and so don't
need to be distinct from the equivalent typedefs for the COW
std::basic_string specializations. It is OK for the same typedef to
refer to different types in different translation units.
Defining them directly in namespace std improves diagnostics that use
those typedefs. For example:
error: could not convert '1' from 'int' to 'std::__cxx11::string' {aka
'std::__cxx11::basic_string'}
will now be printed as:
error: could not convert '1' from 'int' to 'std::string' {aka
'std::__cxx11::basic_string'}
The precise type is still shown, but the typedef is not obfuscated with
the inline namespace.
* include/bits/stringfwd.h (string, wstring, u16string, u32string):
Define typedefs outside of __cxx11 inline namespace.
* python/libstdcxx/v6/printers.py (register_type_printers): Also
register printers for typedefs in new location.
Tested x86_64-linux, committed to trunk.
commit ee47efe7b3620fcfd3d65548e027523ca26a3615
Author: Jonathan Wakely
Date: Tue Oct 9 12:19:29 2018 +0100
Define std::string and related typedefs outside __cxx11 namespace
The typedefs for common specializations of std::__cxx11::basic_string do
not need to be in the std::__cxx11 namespace. Those typedefs are never
used for linkage purposes so don't appear in mangled names, and so don't
need to be distinct from the equivalent typedefs for the COW
std::basic_string specializations. It is OK for the same typedef to
refer to different types in different translation units.
Defining them directly in namespace std improves diagnostics that use
those typedefs. For example:
error: could not convert '1' from 'int' to 'std::__cxx11::string' {aka
'std::__cxx11::basic_string'}
will now be printed as:
error: could not convert '1' from 'int' to 'std::string' {aka
'std::__cxx11::basic_string'}
The precise type is still shown, but the typedef is not obfuscated with
the inline namespace.
* include/bits/stringfwd.h (string, wstring, u16string, u32string):
Define typedefs outside of __cxx11 inline namespace.
* python/libstdcxx/v6/printers.py (register_type_printers): Also
register printers for typedefs in new location.
diff --git a/libstdc++-v3/include/bits/stringfwd.h
b/libstdc++-v3/include/bits/stringfwd.h
index 15eb7183633..2b7f4612cbc 100644
--- a/libstdc++-v3/include/bits/stringfwd.h
+++ b/libstdc++-v3/include/bits/stringfwd.h
@@ -69,6 +69,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
typename _Alloc = allocator<_CharT> >
class basic_string;
+_GLIBCXX_END_NAMESPACE_CXX11
+
/// A string of @c char
typedef basic_stringstring;
@@ -85,8 +87,6 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
typedef basic_string u32string;
#endif
-_GLIBCXX_END_NAMESPACE_CXX11
-
/** @} */
_GLIBCXX_END_NAMESPACE_VERSION
diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py
b/libstdc++-v3/python/libstdcxx/v6/printers.py
index afe1b325d87..827c87b70ea 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -1556,6 +1556,8 @@ def register_type_printers(obj):
# Add type printers for typedefs std::string, std::wstring etc.
for ch in ('', 'w', 'u16', 'u32'):
add_one_type_printer(obj, 'basic_string', ch + 'string')
+add_one_type_printer(obj, '__cxx11::basic_string', ch + 'string')
+# Typedefs for __cxx11::basic_string used to be in namespace __cxx11:
add_one_type_printer(obj, '__cxx11::basic_string',
'__cxx11::' + ch + 'string')
add_one_type_printer(obj, 'basic_string_view', ch + 'string_view')
@@ -1568,7 +1570,7 @@ def register_type_printers(obj):
for x in ('stringbuf', 'istringstream', 'ostringstream',
'stringstream'):
add_one_type_printer(obj, 'basic_' + x, ch + x)
-# types are in __cxx11 namespace, but typedefs aren'x:
+# types are in __cxx11 namespace, but typedefs aren't:
add_one_type_printer(obj, '__cxx11::basic_' + x, ch + x)
# Add type printers for typedefs regex, wregex, cmatch, wcmatch etc.
Re: [PATCHv2] Handle not explicitly zero terminated strings in merge sections
Hi Bernd,
>> * The merge-all-constants-2.c test doesn't FAIL on Solaris/SPARC with
>>/bin/as, although it lacks string merging support, too. The assembler
>>output contains
>>
>> .section".rodata"
>>
>>so the pattern currently used to check for .rodata is too
>>restrictive. There is assembler syntax beyond gas on x86 ;-)
>>
>
> For the test that failed with the quotes around .rodata. I think
> instead of looking for a end of line immediately after .rodata, it
> would be sufficient to make sure it does not continue with .str, so
> could you please try to add something like the following to your patch?
>
> Index: gcc/testsuite/gcc.dg/merge-all-constants-2.c
> ===
> --- gcc/testsuite/gcc.dg/merge-all-constants-2.c (revision 264888)
> +++ gcc/testsuite/gcc.dg/merge-all-constants-2.c (working copy)
> @@ -5,4 +5,4 @@
> const char str2[37] = "0123456789abcdefghijklmnopqrstuvwxyz";
> const char str3[10] = "0123456789abcdefghijklmnopqrstuvwxyz";
>
> -/* { dg-final { scan-assembler-not "\\.rodata\[\n\r\]" } } */
> +/* { dg-final { scan-assembler-not "\\.rodata\[^.]" } } */
to do this; I've temporarily disabled the string_merging requirement in
the test and ran it on sparc-sun-solaris2.11:
* With as (no string merging), there's
.section".rodata"
in the output and I get the expected
FAIL: gcc.dg/merge-all-constants-2.c scan-assembler-not \\.rodata[^.]
* With gas however (string merging supported), the output has the usual
.section.rodata.str1.8,"aMS",@progbits,1
and the test PASSes.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[Bug c/85870] [6/7/8/9 Regression][LTO1] ICE in linemap_line_start, at libcpp/line-map.c:794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870 --- Comment #11 from sudi at gcc dot gnu.org --- Yes I remember spending a while to get it to reduce further. But it needs a big constructor to fail.
[Bug target/87561] [9 Regression] 416.gamess is slower by ~10% starting from r264866 with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87561
Richard Biener changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #3 from Richard Biener ---
OK, so re-running perf gives me a more reasonable result (-march=native on
Haswell):
Overhead Samples Command Shared Object Symbol
15.59%754868 gamess_peak.amd gamess_peak.amd64-m64-gcc42-nn [.]
forms_
15.55%749452 gamess_base.amd gamess_base.amd64-m64-gcc42-nn [.]
forms_
10.77%496796 gamess_base.amd gamess_base.amd64-m64-gcc42-nn [.]
twotff_
7.58%377894 gamess_base.amd gamess_base.amd64-m64-gcc42-nn [.]
dirfck_
7.57%375587 gamess_peak.amd gamess_peak.amd64-m64-gcc42-nn [.]
dirfck_
7.01%328685 gamess_peak.amd gamess_peak.amd64-m64-gcc42-nn [.]
twotff_
4.98%243101 gamess_base.amd gamess_base.amd64-m64-gcc42-nn [.]
xyzint_
4.03%197815 gamess_peak.amd gamess_peak.amd64-m64-gcc42-nn [.]
xyzint_
with the already noticed loop where there's appearantly not enough iterations
warranting the vectorization and the cost model check comes in the way.
xyzint_ looks simiar.
Note that
DO 30 MK=1,NOC
DO 30 ML=1,MK
MKL = MKL+1
XPQKL(MPQ,MKL) = XPQKL(MPQ,MKL) +
* VAL1*(CO(MS,MK)*CO(MR,ML)+CO(MS,ML)*CO(MR,MK))
XPQKL(MRS,MKL) = XPQKL(MRS,MKL) +
* VAL3*(CO(MQ,MK)*CO(MP,ML)+CO(MQ,ML)*CO(MP,MK))
30 CONTINUE
shows the inner loop will first iterate once, then twice, then ... that
makes hoisting the cost model check not possible and also it makes the
alias check not invariant in the outer loop. That would mean if we'd
code-generate the iteration cost-model then loop splitting might get
the idea of splitting the outer loop ... (but loop splitting runs before
vectorization of course).
So in this very case if we analyze the scalar evolution of the niter
of the loop we want to vectorize we get back {0, +, 1}_5 -- that's
certainly something we could factor in when computing the vectorization
cost. It would increase the prologue/epilogue cost but it wouldn't
make vectorization never profitable (we know nothing about the upper bound
of the number of iterations).
[Bug rtl-optimization/87468] [9 Regression] ice "wrong amount of branch edges after conditional jump in bb"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87468 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||law at gcc dot gnu.org, ||marxin at gcc dot gnu.org Known to work||8.2.0 Known to fail||9.0 --- Comment #3 from Martin Liška --- Started with r264491.
[Bug c/85870] [6/7/8/9 Regression][LTO1] ICE in linemap_line_start, at libcpp/line-map.c:794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870 Martin Liška changed: What|Removed |Added Keywords|needs-reduction | CC||dmalcolm at gcc dot gnu.org --- Comment #10 from Martin Liška --- Obviously fails for the huge constructor in test_2.i: SOURCE_LINE (map, r) == 14 while to_line == 1048590 Note that line 14 is first element of the constructor. So maybe David can debug that? The test-case can't be reduced, one needs so huge initialization.
[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #10 from Tobias Burnus --- In my understanding, the problem is the following (of r254427): Unconditionally generate a vtable for any module derived type, as long as the standard is F2003 or later and it is not a vtype or a PDT template. The idea is: Any TYPE can be (later) uses in a polymorphic context, hence, one might need both the v(irtual )table and the default constructor and copy procedure. C++ has the same problem, but solves it differently. C++ by default doesn't create the vtable objects. (Which makes especially sense given that the class/struct is usually defined in a header.) But when used, it creates them in every .o which uses them. To avoid linker problems, those are created as "V"/"W", i.e. as weak objects. Thus, the gfortran solution could be likewise: Don't emit the vtab, def_init and copy code when compiling a module (unless used in the module) - and defer the creation to the later usage. The question is when does one need to create them? One possibility would be to create them in each translation unit which passes a TYPE to a CLASS(*)/CLASS() and when allocating it or associating it with a (nonpolymorphic) pointer target. I think that would work.
Re: [PATCHv2] Handle not explicitly zero terminated strings in merge sections
On 10/03/18 18:31, Jeff Law wrote:
>> - && (len = int_size_in_bytes (TREE_TYPE (decl))) > 0
>> - && TREE_STRING_LENGTH (decl) >= len)
>> + && (len = int_size_in_bytes (TREE_TYPE (decl))) >= 0
>> + && TREE_STRING_LENGTH (decl) == len)
> Not sure why you want to test for >= 0 here. > 0 seems sufficient,
> though I guess there's no harm in the = 0 case.
>
Aehm, cough...
Sorry Jeff, I need to change that back. It turns out that
completely empty strings don't work right, because of this
check in output_constant:
output_constant (tree exp, unsigned HOST_WIDE_INT size, unsigned int align,
bool reverse, bool merge_strings)
{
enum tree_code code;
unsigned HOST_WIDE_INT thissize;
rtx cst;
if (size == 0 || flag_syntax_only)
return size;
So while my intention was to add a null-termination for all strings, including
empty ones,
this does not work for empty strings, which was diagnosed by the solaris
assembler/linker.
However since those empty strings do not use any space, there is no improvement
by merging them in the first place.
Rainer bootstrapped the attached patch successfully.
Is it OK for trunk?
Thanks
Bernd.
2018-10-09 Bernd Edlinger
* varasm.c (mergeable_string_section): Don't try to move zero-length
strings to the merge section.
Index: gcc/varasm.c
===
--- gcc/varasm.c (revision 264887)
+++ gcc/varasm.c (working copy)
@@ -804,7 +804,7 @@ mergeable_string_section (tree decl ATTRIBUTE_UNUS
&& TREE_CODE (decl) == STRING_CST
&& TREE_CODE (TREE_TYPE (decl)) == ARRAY_TYPE
&& align <= 256
- && (len = int_size_in_bytes (TREE_TYPE (decl))) >= 0
+ && (len = int_size_in_bytes (TREE_TYPE (decl))) > 0
&& TREE_STRING_LENGTH (decl) == len)
{
scalar_int_mode mode;
RE: [PATCH][GCC][mid-end] Add a hook to support telling the mid-end when to probe the stack [patch (2/6)]
Hi Richard, > -Original Message- > From: Richard Biener > Sent: Tuesday, October 9, 2018 08:28 > To: Tamar Christina > Cc: Jeff Law ; gcc-patches@gcc.gnu.org; nd > ; i...@airs.com > Subject: RE: [PATCH][GCC][mid-end] Add a hook to support telling the mid- > end when to probe the stack [patch (2/6)] > > On Tue, 9 Oct 2018, Tamar Christina wrote: > > > Hi All, > > > > I'm looking for permission to backport this patch to the GCC-8 branch > > to fix PR86486. > > > > OK for backport? > > This doesn't seem to fix a regression and it's been on trunk only for a few > days. I probably should have asked for the backport on patch 0/8 instead of individually. But the reason for asking for the backport is that on GCC-8 the current implementation is insufficient for AArch64. The only protection a user would get from turning on stack-clash protection would be from the mid-end alloca code. static allocations and SVE code would get zero protection. The changes, including the mid-end changes don't affect any other target. The mid-end change is gated by a target hook that only aarch64 defines. I'm happy to let it sit on trunk a bit longer for more testing if that's what's required or to test against more targets. The current patch set was tested trunk on x86_64 and AArch64 by comparing a) builds with stack-clash off (with patches vs w/o patches) and b) builds with stack-clash on (with patches vs w/o patches). For AArch64 the glibc testsuite was also ran (with patches vs w/o patches) with stack-clash on. The patches apply almost cleanly on GCC-8, modulo some small conflicts like line numbers in configure file and removal of some minor features not available in GCC-8. So far the GCC-8 version I have only done a bootstrap and regression with stack-clash on by default on AArch64. I am planning more testing on AArch64 and x86_64 but wanted to check on the backport before doing the exhaustive testing. I believe a backport of only the target specific bits may also be sufficient to give protection, but have not worked through this scenario yet. It's not the preferred option but one that I'd be happy to investigate if it's the only one available. Regards, Tamar > > Richard. > > > Thanks, > > Tamar > > > > > -Original Message- > > > From: Jeff Law > > > Sent: Wednesday, July 11, 2018 19:53 > > > To: Tamar Christina ; > > > gcc-patches@gcc.gnu.org > > > Cc: nd ; rguent...@suse.de; i...@airs.com > > > Subject: Re: [PATCH][GCC][mid-end] Add a hook to support telling the > > > mid- end when to probe the stack [patch (2/6)] > > > > > > On 07/11/2018 05:21 AM, Tamar Christina wrote: > > > > Hi All, > > > > > > > > This patch adds a hook to tell the mid-end about the probing > > > > requirements of the target. On AArch64 we allow a specific range > > > > for which no probing needs to be done. This same range is also > > > > the amount that will have to be probed up when a probe is needed > > > > after dropping the > > > stack. > > > > > > > > Defining this probe comes with the extra requirement that the > > > > outgoing arguments size of any function that uses alloca and stack > > > > clash be at the very least 8 bytes. With this invariant we can > > > > skip doing the zero checks for alloca and save some code. > > > > > > > > A simplified version of the AArch64 stack frame is: > > > > > > > >+---+ > > > >| | > > > >| | > > > >| | > > > >+---+ > > > >|LR | > > > >+---+ > > > >|FP | > > > >+---+ > > > >|dynamic allocations| -\ probe range hook effects these > > > >+---+ --\ and ensures that outgoing stack > > > >|padding| -- args is always > 8 when alloca. > > > >+---+ ---/ Which means it's always safe to > > > > probe > > > >|outgoing stack args|-/ at SP > > > >+---+ > > > > > > > > > > > > This allows us to generate better code than without the hook > > > > without affecting other targets. > > > > > > > > With this patch I am also removing the > > > > stack_clash_protection_final_dynamic_probe > > > > hook which was added specifically for AArch64 but that is no longer > needed. > > > > > > > > Bootstrapped Regtested on aarch64-none-linux-gnu, > > > > x86_64-pc-linux-gnu > > > and no issues. > > > > Both targets were tested with stack clash on and off by default. > > > > > > > > Ok for trunk? > > > > > > > > Thanks, > > > > Tamar > > > > > > > > gcc/ > > > > 2018-07-11 Tamar Christina > > > > > > > > PR target/86486 > > > > * explow.c (anti_adjust_stack_and_probe_stack_clash): Support > > > custom > > > > probe ranges. > > > > * target.def (stack_clash_protection_alloca_probe_range): New. > > > >
[PATCH] Fix setting of hotness in non-LTO mode (PR gcov-profile/77698).
Hi.
In non-LTO mode, we should not set hotness according to computed histogram
in ipa-profile. Following patch does that and fixes the test-case isolated
from PR.
Patch survives regression tests on x86_64-linux-gnu.
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2018-10-09 Martin Liska
PR gcov-profile/77698
* ipa-profile.c (ipa_profile): Adjust hotness threshold
only in LTO mode.
gcc/testsuite/ChangeLog:
2018-10-09 Martin Liska
PR gcov-profile/77698
* gcc.dg/tree-prof/pr77698.c: New test.
---
gcc/ipa-profile.c| 5 ++---
gcc/testsuite/gcc.dg/tree-prof/pr77698.c | 23 +++
2 files changed, 25 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/tree-prof/pr77698.c
diff --git a/gcc/ipa-profile.c b/gcc/ipa-profile.c
index c74f4a4a41d..7065af59ba9 100644
--- a/gcc/ipa-profile.c
+++ b/gcc/ipa-profile.c
@@ -533,11 +533,10 @@ ipa_profile (void)
cumulated_size * 100.0 / overall_size);
}
- if (threshold > get_hot_bb_threshold ()
- || in_lto_p)
+ if (in_lto_p)
{
if (dump_file)
- fprintf (dump_file, "Threshold updated.\n");
+ fprintf (dump_file, "Setting hotness threshold in LTO mode.\n");
set_hot_bb_threshold (threshold);
}
}
diff --git a/gcc/testsuite/gcc.dg/tree-prof/pr77698.c b/gcc/testsuite/gcc.dg/tree-prof/pr77698.c
new file mode 100644
index 000..201bfc7ee20
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-prof/pr77698.c
@@ -0,0 +1,23 @@
+/* { dg-options "-O2 -fno-tree-vectorize -funroll-loops --param max-unroll-times=4 -fno-inline -fdump-rtl-alignments" } */
+
+volatile long int g;
+volatile long int j = 0;
+
+void foo(long int *a, long int *b, long int n)
+{
+ long int i;
+
+ for (i = 0; i < n; i++)
+a[j] = *b;
+}
+
+long int a, b;
+int main()
+{
+ a = 1; b = 2;
+ foo(, , 100);
+ g = a+b;
+ return 0;
+}
+
+/* { dg-final-use-not-autofdo { scan-rtl-dump-times "internal loop alignment added" 1 "alignments"} } */
[Bug c++/85114] [6/7 Regression] -fstack-check causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85114 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|WAITING |NEW Known to work||8.2.0, 9.0 Summary|-fstack-check causes|[6/7 Regression] |internal compiler error |-fstack-check causes ICE Known to fail||6.4.0, 7.3.0 --- Comment #8 from Martin Liška --- (In reply to Eric Botcazou from comment #7) > > Btw. works fine on Linux. > > Maybe with -fstack-check=generic? Yes, that causes ICE also on Linux. Fixed on trunk since r251650. I'll try to come up with a reduced test-case.
[Bug c/85870] [6/7/8/9 Regression][LTO1] ICE in linemap_line_start, at libcpp/line-map.c:794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870 --- Comment #9 from Martin Liška --- Now confirmed!
