[Bug tree-optimization/85814] [8/9 Regression] ICE Segmentation fault during GIMPLE pass: strlen -O3 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85814 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Known to work||7.3.1 Keywords||ice-on-valid-code, ||needs-bisection, ||needs-reduction Last reconfirmed||2018-05-17 Ever confirmed|0 |1 Summary|ICE Segmentation fault |[8/9 Regression] ICE |during GIMPLE pass: strlen |Segmentation fault during |-O3 and above |GIMPLE pass: strlen -O3 and ||above Target Milestone|--- |8.2 Known to fail||8.1.0 --- Comment #1 from Richard Biener --- I can reproduce this on the GCC 8 branch but not on trunk.
[Bug middle-end/85599] Prevent short-circuiting of logical expressions for non-pure functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599 --- Comment #24 from janus at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #22) > the semantics of TRUTH_ANDIF_EXPR is always to short circuit. > If you want a non short circuit you need to use TRUTH_AND_EXPR I haven't looked at the actual code yet, but pr57160 comment 1 sounds like we already use TRUTH_AND_EXPR: > GCC (the middle end) has TRUTH_AND_EXPR (matching Fortran's .AND.) and > TRUTH_ANDIF_EXPR (matching C's &&) - besides the IAND/& which is > BIT_AND_EXPR. > > Currently, the code generation directly translates all .AND. into > TRUTH_AND_EXPR. If that's indeed the case, and TRUTH_AND_EXPR actually results in short-circuiting, then I'm not sure I understand the difference to TRUTH_ANDIF_EXPR. Probably BIT_AND_EXPR can be used to fully prevent short-circuiting?
[Bug ada/85760] Using generic function to initialize a type created by a generic package crashes GNAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85760 Eric Botcazou changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #7 from Eric Botcazou --- Upgrade to GCC 8.
[Bug middle-end/85811] Invalid optimization with fmax, fabs and nan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85811 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-17 CC||rguenth at gcc dot gnu.org Component|rtl-optimization|middle-end Ever confirmed|0 |1 --- Comment #7 from Richard Biener --- (In reply to Marc Glisse from comment #6) > What does tree_expr_nonnegative_p call non-negative? A natural definition > would exclude NaN, but for REAL_CST we just return ! REAL_VALUE_NEGATIVE. Is there sth like -NaN?! Anyway, the bug is clearly in tree_expr_nonnegative_p and siblings. Btw, tree_binary_nonzero_warnv_p looks similarly suspicious. I guess first of all diff --git a/gcc/fold-const.c b/gcc/fold-const.c index faa184a2bbd..cb3de26f9f1 100644 --- a/gcc/fold-const.c +++ b/gcc/fold-const.c @@ -12949,7 +12949,8 @@ tree_single_nonnegative_warnv_p (tree t, bool *strict_overflow_p, int depth) return tree_int_cst_sgn (t) >= 0; case REAL_CST: - return ! REAL_VALUE_NEGATIVE (TREE_REAL_CST (t)); + return (! REAL_VALUE_ISNAN (TREE_REAL_CST (t)) + && ! REAL_VALUE_NEGATIVE (TREE_REAL_CST (t))); case FIXED_CST: return ! FIXED_VALUE_NEGATIVE (TREE_FIXED_CST (t)); but then how do we want to deal with MAX_EXPR (and MIN_EXPR which after the above could see an optimization for min (NaN, x)?). We'd have to special case real-type MAX_EXPR (what about real complex/vector? tree_single_nonnegative_warnv_p doesn't handle complex/vector constants but at least we should be correct in the uplevel treatment).
[Bug middle-end/85599] Prevent short-circuiting of logical expressions for non-pure functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599 --- Comment #25 from Thomas Koenig --- (In reply to janus from comment #23) > (In reply to Thomas Koenig from comment #21) > > If we make guarantees that the standard does not, we will be > > creating our own language > > I certainly don't want to create my own language. I'm trying to use the > freedom that the Fortran standard (unfortunately) gives in this area in a > reasonable way. > > > > (and people will get problems moving > > code to another compiler). > > We do have problems with compiler-dependent behavior already. The behavior > I'm proposing is consistent with what ifort, PGI and flang do. But that is something not guaranteed by the standard... > > > Warn, yes. This is the kind of thing that -Wsurprising is for, > > so people will get something with -Wall. (I volunteer for that). > > What do you want to warn about? And how? A front end pass (what else did you expect? :-) If an impure function is found (recursively) in the operands of an .AND. expression, issue a gfc_warning(OPT_Wsurprising, "Impure function %qs at %L may not be evaluated", ...) So, if (flag .and. f(x) > 0.) would also be warned about. > > > Optimize, yes. This could also be integrated with the warning. > > Optimize, yes, but not at the price of changing results. Not against what the standard guarantees. > > Change the language, no. > > Agreed. But that is what you are proposing - we would make a guarantee that the standard does not make.
[Bug c/85810] gcc incorrectly handles declarations inside parameter lists of function declarators.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85810 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #4 from Richard Biener --- moved.
[Bug tree-optimization/63185] Improve DSE with branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185 --- Comment #7 from Marc Glisse --- This PR is messy. To sum up, comment #0 was recently fixed, comment #5 is not (not noticing that the writes in the loop are dead), and comment #6 asks for increasing the alignment of VLAs the same way we sometimes increase the alignment of arrays to help vectorization.
[Bug lto/85801] LTO linking fails to reconcile symbol from common an data sections (-fPIE -Wl,--as-needed -flto): unresolvable R_ARM_REL32 relocation against symbol `progname'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-17 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #11 from Richard Biener --- (In reply to H.J. Lu from comment #10) > For LDPR_PREVAILING_DEF_IRONLY_EXP, if the IR definition is common, > compiler can't assume that the IR definition will prevail during the > final link. This is another COMMON symbol issue like > > https://sourceware.org/bugzilla/show_bug.cgi?id=23079 So the following might help (and shows bad abstraction of resolution_to_local_definition_p which depends on symbol type). Similar fixes would be needed for decl_binds_to_current_def_p (somehow split out code computing defined_locally and resolved_locally based on resolution from the former function). In other places the cgraph code seems to honor the fact that a common might be prevailed. Honza? diff --git a/gcc/varasm.c b/gcc/varasm.c index 85296b4a2ec..1021237389e 100644 --- a/gcc/varasm.c +++ b/gcc/varasm.c @@ -7075,7 +7075,9 @@ default_binds_local_p_3 (const_tree exp, bool shlib, bool weak_dominate, defined_locally = true; if (node->can_be_discarded_p ()) ; - else if (resolution_to_local_definition_p (node->resolution)) + else if (resolution_to_local_definition_p (node->resolution) + && (defined_locally + || node->resolution != LDPR_PREVAILING_DEF_IRONLY_EXP)) defined_locally = resolved_locally = true; else if (resolution_local_p (node->resolution)) resolved_locally = true;
[Bug fortran/85816] New: nested spread fails with "Integer overflow in xmallocarray"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85816 Bug ID: 85816 Summary: nested spread fails with "Integer overflow in xmallocarray" Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: m.diehl at mpie dot de Target Milestone: --- I'm having trouble with nested spread statements on GCC 8.1.0 (Linux 4.16.8-1-ARCH). The same code runs on GCC 7.3.0 (Linux 4.4.0-98-generic). A seemingly unnecessary set of brackets cures the following error: Operating system error: Cannot allocate memory Integer overflow in xmallocarray when running the following code program test implicit none real(8), dimension(3,3) :: tensor = 4.0 integer, dimension(3) :: grid= 16 write(6,*) spread(spread(tensor,3,grid(1)),4,grid(2)) ! ok write(6,*) spread((spread(spread(tensor,3,grid(1)),4,grid(2))),5,grid(3)) ! ok (note the brackets) write(6,*) spread(spread(spread(tensor,3,grid(1)),4,grid(2)),5,grid(3)) ! not ok end program
[Bug c++/85815] New: incorrect "invalid use of incomplete type" in a lambda on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85815
Bug ID: 85815
Summary: incorrect "invalid use of incomplete type" in a lambda
on valid code
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: v at vsamko dot com
Target Milestone: ---
This valid code:
template
class A {
static A* INSTANCE;
void foobar();
void moo() {}
};
template
A* A::INSTANCE = nullptr;
template
void A::foobar() {
auto x = []() {
INSTANCE->moo();
};
}
(compiled with -Wall)
Gives error:
: In lambda function:
:14:17: error: invalid use of incomplete type 'class A' [-Werror]
INSTANCE->moo();
This compiles fine with Clang and GCC 6, but fails with the error above with
GCC 7 and 8.
[Bug tree-optimization/63185] Improve DSE with branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #8 from Richard Biener ---
comment#5 runs into the fact that we cannot reliably compute kills for
loop-variant stores and thus we give up completely:
if (gimple_code (temp) == GIMPLE_PHI)
{
/* If we visit this PHI by following a backedge then we have to
make sure ref->ref only refers to SSA names that are invariant
with respect to the loop represented by this PHI node. */
if (dominated_by_p (CDI_DOMINATORS, gimple_bb (stmt),
gimple_bb (temp))
&& !for_each_index (ref->ref ? &ref->ref : &ref->base,
check_name, gimple_bb (temp)))
return DSE_STORE_LIVE;
but what we could do is somehow massage the ref to not get false
positive stmt_kills_ref_p or false negative ref_maybe_used_by_stmt_p
results. That could for example involve stripping all components
with variable names in them (and then also disabling byte-tracking).
For varying bases we still need to give up completely.
A backward data-flow algorithm might have an easier time dealing with this
case.
As for the value-numbering issue we currently do not use number of iteration
analysis / range-info to constrain the ao_ref max_size/offset. That's probably
a useful thing to add and might already help. In this case it doesn't
because the range is one too large (head controlled loop). And VRP doesn't
run after CH when FRE/PRE still runs afterwards. And value-numbering visiting
memset doesn't handle pointer destinations (that's easy to fix).
[Bug middle-end/85811] Invalid optimization with fmax, fabs and nan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85811 --- Comment #8 from Andreas Schwab --- > Is there sth like -NaN?! signbit can tell you.
[Bug tree-optimization/63185] Improve DSE with branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #9 from Richard Biener ---
So the following incomplete patch solves the value-numbering issue in FRE2.
diff --git a/gcc/tree-dfa.c b/gcc/tree-dfa.c
index a121b880bb0..745d60cbda5 100644
--- a/gcc/tree-dfa.c
+++ b/gcc/tree-dfa.c
@@ -529,6 +529,31 @@ get_ref_base_and_extent (tree exp, poly_int64_pod
*poffset,
/* Remember that we have seen an array ref with a variable
index. */
seen_variable_array_ref = true;
+
+ wide_int min, max;
+ if (TREE_CODE (index) == SSA_NAME
+ && integer_zerop (array_ref_low_bound (exp))
+ && (unit_size = array_ref_element_size (exp),
+ TREE_CODE (unit_size) == INTEGER_CST)
+ && get_range_info (index, &min, &max) == VR_RANGE
+ && wi::gts_p (max, 0))
+ {
+ poly_offset_int rmaxsize;
+ rmaxsize = offset_int::from (max, UNSIGNED) * wi::to_offset
(unit_size);
+ if (known_size_p (maxsize))
+ {
+ if (known_lt (rmaxsize, maxsize))
+ {
+ maxsize = rmaxsize;
+ seen_variable_array_ref = false;
+ }
+ }
+ else
+ {
+ maxsize = rmaxsize;
+ seen_variable_array_ref = false;
+ }
+ }
}
}
break;
diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index 1463c1d4116..dad4e4fecdf 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -1960,19 +1960,46 @@ vn_reference_lookup_3 (ao_ref *ref, tree vuse, void
*vr_,
&& gimple_call_builtin_p (def_stmt, BUILT_IN_MEMSET)
&& integer_zerop (gimple_call_arg (def_stmt, 1))
&& poly_int_tree_p (gimple_call_arg (def_stmt, 2))
- && TREE_CODE (gimple_call_arg (def_stmt, 0)) == ADDR_EXPR)
+ && (TREE_CODE (gimple_call_arg (def_stmt, 0)) == ADDR_EXPR
+ || TREE_CODE (gimple_call_arg (def_stmt, 0)) == SSA_NAME))
{
- tree ref2 = TREE_OPERAND (gimple_call_arg (def_stmt, 0), 0);
tree base2;
poly_int64 offset2, size2, maxsize2;
bool reverse;
- base2 = get_ref_base_and_extent (ref2, &offset2, &size2, &maxsize2,
- &reverse);
+ tree ref2 = gimple_call_arg (def_stmt, 0);
+ if (TREE_CODE (ref2) == SSA_NAME)
+ {
+ ref2 = SSA_VAL (ref2);
+ if (TREE_CODE (ref2) == SSA_NAME
+ && (TREE_CODE (base) != MEM_REF
+ || TREE_OPERAND (base, 0) != ref2))
+ {
+ gimple *def_stmt = SSA_NAME_DEF_STMT (ref2);
+ if (gimple_assign_single_p (def_stmt)
+ && gimple_assign_rhs_code (def_stmt) == ADDR_EXPR)
+ ref2 = gimple_assign_rhs1 (def_stmt);
+ }
+ }
+ if (TREE_CODE (ref2) == ADDR_EXPR)
+ {
+ ref2 = TREE_OPERAND (ref2, 0);
+ base2 = get_ref_base_and_extent (ref2, &offset2, &size2, &maxsize2,
+ &reverse);
+ if (!known_size_p (maxsize2)
+ || !operand_equal_p (base, base2, 0))
+ return (void *)-1;
+ }
+ else
+ {
+ if (TREE_CODE (base) != MEM_REF
+ || TREE_OPERAND (base, 0) != ref2
+ || !integer_zerop (TREE_OPERAND (base, 1)))
+ return (void *)-1;
+ offset2 = 0;
+ }
tree len = gimple_call_arg (def_stmt, 2);
- if (known_size_p (maxsize2)
- && operand_equal_p (base, base2, 0)
- && known_subrange_p (offset, maxsize, offset2,
- wi::to_poly_offset (len) << LOG2_BITS_PER_UNIT))
+ if (known_subrange_p (offset, maxsize, offset2,
+ wi::to_poly_offset (len) << LOG2_BITS_PER_UNIT))
{
tree val = build_zero_cst (vr->type);
return vn_reference_lookup_or_insert_for_pieces
[Bug tree-optimization/85814] [8/9 Regression] ICE Segmentation fault during GIMPLE pass: strlen -O3 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85814 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- I'm reducing that..
[Bug middle-end/85811] Invalid optimization with fmax, fabs and nan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85811 --- Comment #9 from rguenther at suse dot de --- On Thu, 17 May 2018, sch...@linux-m68k.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85811 > > --- Comment #8 from Andreas Schwab --- > > Is there sth like -NaN?! > > signbit can tell you. True. I guess that also asks for the guarantee on the operand for tree_single_nonnegative_warnv_p returning true. Does it guarantee that OP >= 0 compares as true? Or merely !(OP < 0)? So does it make sense for the function to return true for +NaN or should we err on the side of caution and not do that?
[Bug tree-optimization/85814] [8/9 Regression] ICE Segmentation fault during GIMPLE pass: strlen -O3 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85814
Martin Liška changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #3 from Martin Liška ---
Reduced test-case:
int a;
void b(c, d, e, f, g, h) char *c;
int d;
int e;
int f;
int g;
int h;
{
int i;
c++;
c++;
c++;
c++;
i = 0;
for (; i < 10; i++)
a = *c++ = 2;
}
[Bug tree-optimization/85814] [8/9 Regression] ICE Segmentation fault during GIMPLE pass: strlen -O3 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85814 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||jakub at gcc dot gnu.org, ||msebor at gcc dot gnu.org, ||rdsandiford at googlemail dot com --- Comment #4 from Martin Liška --- Started with r249880.
[Bug libstdc++/85812] make_exception_ptr can leak the allocated exception if construction throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85812 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-17 Ever confirmed|0 |1
[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85813 --- Comment #1 from Jonathan Wakely --- As you pointed out in PR 85812 the constructor of the exception can throw. That can happen even if the current translation unit is not built with exceptions, if the constructor is defined in a different translation unit. Since make_exception_ptr is noexcept, we simply avoid the possibility of termination by returning an empty exception_ptr.
[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85813 --- Comment #2 from Jonathan Wakely --- ... because if that constructor throws and the current translation unit is built without exceptions, we can't catch it.
[Bug c++/85713] [9 Regression] ICE in dependent_type_p, at cp/pt.c:24582 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85713 --- Comment #8 from paolo at gcc dot gnu.org --- Author: paolo Date: Thu May 17 09:17:56 2018 New Revision: 260308 URL: https://gcc.gnu.org/viewcvs?rev=260308&root=gcc&view=rev Log: 2018-05-17 Paolo Carlini PR c++/85713 * g++.dg/cpp1y/lambda-generic-85713-2.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-85713-2.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/69905] Digit separators break literal operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69905
--- Comment #8 from Jonathan Wakely ---
The testcase in comment 2 (the only one in the bug that's actually correct!)
works now, fixed by r258157 for Bug 84671.
The problem in comment 7 still exists, the corrected testcase is:
#include
int main() {
using namespace std::chrono_literals;
auto time = operator""s(0x8000'''''ULL);
static_assert(std::is_same(), "");
}
[Bug c++/85815] [7/8/9 Regression] incorrect "invalid use of incomplete type" in a lambda on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85815 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Known to work||6.4.0 Keywords||diagnostic, rejects-valid Last reconfirmed||2018-05-17 Ever confirmed|0 |1 Summary|incorrect "invalid use of |[7/8/9 Regression] |incomplete type" in a |incorrect "invalid use of |lambda on valid code|incomplete type" in a ||lambda on valid code Target Milestone|--- |7.4 --- Comment #1 from Richard Biener --- Confirmed.
[Bug middle-end/85599] Prevent short-circuiting of logical expressions for non-pure functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599 --- Comment #26 from janus at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #25) > > We do have problems with compiler-dependent behavior already. The behavior > > I'm proposing is consistent with what ifort, PGI and flang do. > > But that is something not guaranteed by the standard... Does not make too much difference in the end, does it? You still have code that gives different results with different compilers, which is always a bad thing. That's exactly why I think it was a bad decision for the standard to leave this decision to the compiler. > > > Optimize, yes. This could also be integrated with the warning. > > > > Optimize, yes, but not at the price of changing results. > > Not against what the standard guarantees. Does. Not. Matter. It is still an optimization that changes the end result, which is generally a bad thing IMHO. Even if some standards document says "it's not illegal", I would say "it's still a bad idea"! > > > Change the language, no. > > > > Agreed. > > But that is what you are proposing - we would make a guarantee that > the standard does not make. Disagree. We wouldn't make a guarantee, we would just choose one of two possible implementations that are allowed by the standard. That's not "changing the language".
[Bug target/85323] SSE/AVX/AVX512 shift by 0 not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85323 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Thu May 17 09:54:36 2018 New Revision: 260311 URL: https://gcc.gnu.org/viewcvs?rev=260311&root=gcc&view=rev Log: PR target/85323 * config/i386/i386.c: Include tree-vector-builder.h. (ix86_vector_shift_count): New function. (ix86_fold_builtin): Fold shift builtins by scalar count. (ix86_gimple_fold_builtin): Likewise. * gcc.target/i386/pr85323-1.c: New test. * gcc.target/i386/pr85323-2.c: New test. * gcc.target/i386/pr85323-3.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr85323-1.c trunk/gcc/testsuite/gcc.target/i386/pr85323-2.c trunk/gcc/testsuite/gcc.target/i386/pr85323-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/85323] SSE/AVX/AVX512 shift by 0 not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85323 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Thu May 17 10:01:33 2018 New Revision: 260312 URL: https://gcc.gnu.org/viewcvs?rev=260312&root=gcc&view=rev Log: PR target/85323 * config/i386/i386.c (ix86_fold_builtin): Fold shift builtins by vector. (ix86_gimple_fold_builtin): Likewise. * gcc.target/i386/pr85323-4.c: New test. * gcc.target/i386/pr85323-5.c: New test. * gcc.target/i386/pr85323-6.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr85323-4.c trunk/gcc/testsuite/gcc.target/i386/pr85323-5.c trunk/gcc/testsuite/gcc.target/i386/pr85323-6.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/84671] [6/7 Regression] Chrono literals don't accept apostrophe as separator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84671 Jonathan Wakely changed: What|Removed |Added CC||alisdairm at me dot com --- Comment #9 from Jonathan Wakely --- *** Bug 69905 has been marked as a duplicate of this bug. ***
[Bug target/85323] SSE/AVX/AVX512 shift by 0 not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85323 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Thu May 17 10:07:12 2018 New Revision: 260313 URL: https://gcc.gnu.org/viewcvs?rev=260313&root=gcc&view=rev Log: PR target/85323 * config/i386/i386.c (ix86_fold_builtin): Handle masked shifts even if the mask is not all ones. * gcc.target/i386/pr85323-7.c: New test. * gcc.target/i386/pr85323-8.c: New test. * gcc.target/i386/pr85323-9.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr85323-7.c trunk/gcc/testsuite/gcc.target/i386/pr85323-8.c trunk/gcc/testsuite/gcc.target/i386/pr85323-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug c++/69905] Digit separators break literal operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69905
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #9 from Jonathan Wakely ---
(In reply to andreas.molzer from comment #7)
> Leaving out the overload for operator""s(long double) will silently break
We provide that overload though. What do you mean?
> valid code. Consider:
>
> #include
> int main() {
> using std::chrono_literals;
> auto time = operator""s(0x8000'''''ULL);
> }
>
> According to standard, this should select the overload with unsigned long
> long argument, which does not exist.
No, according to the standard this is ill-formed because the value doesn't fit
in an unsigned long long (assuming 64 bits). GCC accepts it unless you use
-pedantic-errors, but this isn't valid code.
> It will instead silently perform a
> numeric conversion to long double, resulting in loss of accuracy on targets
> where gcc does not use extended 80-bit double. Any other integer arguments,
> which should lead to overload resolution failure, will also be double
> durations albeit with less immediately catastrophic results.
Again, this doesn't silently break valid code, because what you're doing should
be ill-formed according to the standard. So not valid code.
> However, that doesn't mean the long term effects are no issue. Consider
> that the type of time.count() also unexpectedly resolves as long double. Or
> even worse that assigning decltype(time)::max() to unsigned long long is
> undefined behaviour.
>
> It might be more fitting to open the missing declarations as a separately
> tracked bug, improving visibility of the standard issue as well.
Feel free to open a new bug (but this is not the place to report problems in
the standard, see https://cplusplus.github.io/LWG/lwg-active.html#submit_issue
for that).
I'm going to close this one as a dup of Bug 84671 because I don't think there's
any compiler bug here. The original problem was due to the library not handling
digit separators in its UDL operators, which is fixed.
*** This bug has been marked as a duplicate of bug 84671 ***
[Bug ipa/85817] New: [9 Regression] ICE in expand_call at gcc/calls.c:4291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85817
Bug ID: 85817
Summary: [9 Regression] ICE in expand_call at gcc/calls.c:4291
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org, prathamesh3492 at gcc dot gnu.org
Target Milestone: ---
Starting from r260250 I see ICE in GIMP being built with -O3 and -flto.
Unfortunately it happens in ltrans, thus it's hard to reduce a reproducer. So:
$ ./lto1 -quiet -dumpdir .libs/ -dumpbase gimp-2.9.ltrans3 -mtune=generic
-march=x86-64 -mtune=generic -march=x86-64 -auxbase-strip
gimp-2.9.ltrans3.ltrans.o -O3 -O3 -O3 -Werror=missing-prototypes -Wtype-limits
-version -fno-openacc -fno-common -fdiagnostics-show-option -fopenmp -fltrans
/home/marxin/BIG/buildbot/slave/source/gimp/app/gimp-2.9.ltrans3.o -o
gimp-2.9.ltrans3.s
GNU GIMPLE (GCC) version 9.0.0 20180515 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180323 [gcc-7-branch revision
258812], GMP version 6.1.2, MPFR version 4.0.1-p6, MPC version 1.1.0, isl
version isl-0.19-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 9.0.0 20180515 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180323 [gcc-7-branch revision
258812], GMP version 6.1.2, MPFR version 4.0.1-p6, MPC version 1.1.0, isl
version isl-0.19-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
during RTL pass: expand
gimpwindow.c: In function ‘gimp_window_key_press_event’:
gimpwindow.c:200:9: internal compiler error: Segmentation fault
0xf336c9 crash_signal
../../gcc/toplev.c:325
0x8d2290 expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.c:4287
0xa954be expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:11011
0xa8734c expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc/expr.c:8235
0x8e4c27 expand_expr
../../gcc/expr.h:280
0x8ede19 expand_call_stmt
../../gcc/cfgexpand.c:2690
0x8f1661 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3644
0x8f1dbb expand_gimple_stmt
../../gcc/cfgexpand.c:3810
0x8fab6e expand_gimple_basic_block
../../gcc/cfgexpand.c:5839
0x8fc7f9 execute
../../gcc/cfgexpand.c:6445
(gdb) p valreg
$2 = (rtx) 0x0
(gdb) p debug_tree(exp)
>
side-effects nothrow
fn
unsigned DI
size
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1
structural-equality context >
constant
arg:0
addressable used nothrow public external function-specific-target
function-specific-opt QI lebl-dialog.c:774:1 align:8 warn_if_not_align:0
context
(mem:QI (symbol_ref:DI ("gimp_lebl_dialog") [flags 0x43]
) [0 S1 A8])>>
gimpwindow.c:200:9 start: gimpwindow.c:200:9 finish: gimpwindow.c:200:9>
Optimized dump looks as follows:
;; Function gimp_window_key_press_event (gimp_window_key_press_event,
funcdef_no=194, decl_uid=6164, cgraph_uid=264, symbol_order=54507)
gimp_window_key_press_event (struct GtkWidget * widget, struct GdkEventKey *
event)
{
struct GtkWidgetClass * widget_class;
static guint32 val = 0;
gboolean __r;
GType __t;
gboolean __r;
GType __t;
gboolean __r;
GType __t;
static const char __func__[28] = <<< error >>>;
gboolean handled;
gboolean enable_mnemonics;
GdkModifierType accel_mods;
struct GtkWidget * focus;
struct GtkWindow * window;
struct GimpWindow * gimp_window;
long unsigned int _1;
long unsigned int _2;
struct GTypeClass * _3;
long unsigned int _4;
struct GtkWidget * _9;
_10;
unsigned int _11;
unsigned int _12;
unsigned int _13;
unsigned int _14;
unsigned int _15;
unsigned int _16;
unsigned int _17;
struct GimpWindowPrivate * _19;
struct GtkWidget * _20;
unsigned int _23;
unsigned int _24;
_25;
unsigned int _26;
_27;
unsigned int _28;
unsigned int _29;
unsigned int _30;
_31;
unsigned int _32;
long unsigned int _33;
gboolean (*) (struct GtkWidget *, struct GdkEventKey *) _34;
_35;
unsigned int _36;
int _41;
_187;
unsigned int prephitmp_189;
unsigned int pretmp_191;
struct GtkSettings * _195;
int _197;
unsigned int pretmp_199;
struct GtkSettings * _205;
int _207;
[local count: 1073741825]:
_1 = gimp_window_get_type ();
gimp_window_54 = g_type_check_instance_cast (widget_52(D), _1);
_2 = gtk_window_get_type ();
window_56 = g_type_check_instance_cast (widget_52(D), _2);
focus_58 = gtk_window_get_focus (window_56);
if (focus_58 != 0B)
goto ; [70.00%]
else
goto ; [30.00%]
[local count: 751
[Bug libstdc++/85812] [7/8/9 Regression] make_exception_ptr can leak the allocated exception if construction throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85812
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Known to work||6.4.0
Target Milestone|--- |7.4
Summary|make_exception_ptr can leak |[7/8/9 Regression]
|the allocated exception if |make_exception_ptr can leak
|construction throws |the allocated exception if
||construction throws
Known to fail||7.3.0, 8.1.0, 9.0
--- Comment #1 from Jonathan Wakely ---
Testcase:
#include
struct E {
E() = default;
E(const E&) { throw 1; }
};
int main()
{
std::make_exception_ptr(E{});
}
=
==23465==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 129 byte(s) in 1 object(s) allocated from:
#0 0x7f0ae56eb2d0 in __interceptor_malloc
/home/jwakely/src/gcc/gcc-7/libsanitizer/asan/asan_malloc_linux.cc:62
#1 0x7f0ae531f8cf in __cxa_allocate_exception
/home/jwakely/src/gcc/gcc-7/libstdc++-v3/libsupc++/eh_alloc.cc:272
#2 0x400d5f in main /tmp/ex.cc:10
#3 0x7f0ae499af29 in __libc_start_main (/lib64/libc.so.6+0x20f29)
SUMMARY: AddressSanitizer: 129 byte(s) leaked in 1 allocation(s).
This started with 7.1 due to r239664 for Bug 68297
[Bug ipa/85817] [9 Regression] ICE in expand_call at gcc/calls.c:4291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85817
--- Comment #1 from prathamesh3492 at gcc dot gnu.org ---
Created attachment 44142
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44142&action=edit
Untested fix
Oops, sorry about that.
I put the condition
if (integer_zerop (retval))
continue;
at the wrong place -;)
Can also be reproduced with:
_Bool f()
{
return 0;
}
In that the pure-const dump shows the function marked as malloc -:(
Could you check if the attached patch fixes the GIMP issue ?
Thanks,
Prathamesh
[Bug preprocessor/77810] provide format_inform_at_substring to go with format_warning_at_substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77810 Eric Gallager changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-17 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=77690, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=77696 Ever confirmed|0 |1 --- Comment #5 from Eric Gallager --- Confirmed since a bug that this blocks is confirmed.
[Bug ipa/85817] [9 Regression] ICE in expand_call at gcc/calls.c:4291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85817
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-05-17
Ever confirmed|0 |1
--- Comment #2 from Martin Liška ---
(In reply to prathamesh3492 from comment #1)
> Created attachment 44142 [details]
> Untested fix
>
> Oops, sorry about that.
It easily happens.
> I put the condition
> if (integer_zerop (retval))
> continue;
> at the wrong place -;)
>
> Can also be reproduced with:
> _Bool f()
> {
> return 0;
> }
> In that the pure-const dump shows the function marked as malloc -:(
> Could you check if the attached patch fixes the GIMP issue ?
Yes, it helps ;)
>
> Thanks,
> Prathamesh
[Bug tree-optimization/85793] [8/9 Regression][AARCH64] ICE in verify_gimple during GIMPLE pass vect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85793 --- Comment #3 from bin cheng --- Author: amker Date: Thu May 17 11:25:43 2018 New Revision: 260317 URL: https://gcc.gnu.org/viewcvs?rev=260317&root=gcc&view=rev Log: PR tree-optimization/85793 * tree-vect-stmts.c (vectorizable_load): Handle 1 element-wise load for VMAT_ELEMENTWISE. gcc/testsuite * gcc.dg/vect/pr85793.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr85793.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug ada/85760] Using generic function to initialize a type created by a generic package crashes GNAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85760 --- Comment #8 from Jere --- OH! I thought you meant here. I wasn't sure this was the same bug internally. They have different results in the two different versions of GNAT. The AdaCore GNAT Community put out a crash report while the FSF GNAT only returned quietly with no compilation results. If they acted exactly the same, I would have only reported to AdaCore as I am guessing AdaCore's fixes would eventually end up here (this is only a guess on my part though). However, since it acted differently in FSF GNAT I didn't know if AdaCore fixed it in GNAT Community if it would fix the same issue or if this happend to be a different bug triggered by the same code. I've seen multiple times in the past where a bug was fixed in a earlier version of GNAT GPL/Community but not in a later version of FSF GNAT, which probably means they weren't actually the same bug internally. Also there is no guarantee they'll even look at my report as it was for the community edition (this is not a knock against them, they have their own priorities that they must manage first). I was just trying to be nice to help them find bugs as well. I wasn't meaning to cause trouble, just help contribute to making GNAT the best it can be in all versions. Keep in mind it is difficult on my end to know what is going on internally. I don't always receive responses from AdaCore when I submit bugs (again, I'm not expecting them to when they have bigger priorities). When they have responded, they have not indicated they will push those fixes to FSF GNAT (I am guessing that they do eventually, but it is only a guess on my part) and it isn't fair for me to probe them further. I have no clue on my end if I am duplicating the triage work or not, especially in the case where the bug acts different in different versions. So my apologies on the trouble. I was not intending to cause any. I hope you will forgive me.
[Bug tree-optimization/85804] [8/9 Regression][AArch64] Mis-compilation of loop with strided array access and xor reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85804 bin cheng changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-17 CC||amker at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from bin cheng --- Confirmed. I will have a look
[Bug middle-end/85599] Prevent short-circuiting of logical expressions for non-pure functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599 --- Comment #27 from Thomas Koenig --- [Replying to myself now] > A front end pass (what else did you expect? :-) > > If an impure function is found (recursively) in the operands of an .AND. > expression, issue a > > gfc_warning(OPT_Wsurprising, "Impure function %qs at %L may not be > evaluated", ...) > > So, > > if (flag .and. f(x) > 0.) > > would also be warned about. I think I will start working on that warning; this should lead to users being made aware of a potential problem in their code. I am, of course, open to suggestions about the text of the warning.
[Bug libstdc++/85818] New: [8/9 Regression] undefined reference to `std::experimental::filesystem::v1::__cxx11::path::preferred_separator'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85818
Bug ID: 85818
Summary: [8/9 Regression] undefined reference to
`std::experimental::filesystem::v1::__cxx11::path::pre
ferred_separator'
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Keywords: link-failure
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
This fails to link when compiled as C++11 or C++14 with GCC 8 or 9:
#include
int main()
{
auto& sep = std::experimental::filesystem::path::preferred_separator;
}
/tmp/ccxrMmnw.o: In function `main':
/tmp/ps.cc:5: undefined reference to
`std::experimental::filesystem::v1::__cxx11::path::preferred_separator'
collect2: error: ld returned 1 exit status
The variable is defined in src/filesystem/path.cc:
constexpr path::value_type path::preferred_separator;
But that file is compiled with -std=gnu++17 and so the variable is implicitly
inline, and because it isn't used in that file its definition isn't emitted in
path.o
[Bug libstdc++/85818] [8/9 Regression] undefined reference to `std::experimental::filesystem::v1::__cxx11::path::preferred_separator'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85818 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-05-17 Known to work||6.4.0, 7.3.0 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |8.2 Ever confirmed|0 |1 Known to fail||8.1.0, 9.0
[Bug ipa/85655] [8/9 Regression] ICE with -flto and -O2 during IPA pass: cp lto1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85655 --- Comment #9 from Martin Jambor --- Author: jamborm Date: Thu May 17 12:18:06 2018 New Revision: 260319 URL: https://gcc.gnu.org/viewcvs?rev=260319&root=gcc&view=rev Log: Check is_single_const in intersect_with_plats 2018-05-17 Martin Jambor Backport from mainline 2018-05-11 Martin Jambor PR ipa/85655 * ipa-cp.c (intersect_with_plats): Check that the lattice contains single const. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/ipa-cp.c
[Bug ipa/85655] [8/9 Regression] ICE with -flto and -O2 during IPA pass: cp lto1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85655 --- Comment #10 from Martin Jambor --- Author: jamborm Date: Thu May 17 12:23:34 2018 New Revision: 260320 URL: https://gcc.gnu.org/viewcvs?rev=260320&root=gcc&view=rev Log: Check is_single_const in intersect_with_plats 2018-05-17 Martin Jambor Backport from mainline 2018-05-11 Martin Jambor PR ipa/85655 * ipa-cp.c (intersect_with_plats): Check that the lattice contains single const. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/ipa-cp.c
[Bug ipa/85655] [8/9 Regression] ICE with -flto and -O2 during IPA pass: cp lto1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85655 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Martin Jambor --- Fixed.
[Bug fortran/85599] Prevent short-circuiting of logical expressions for non-pure functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599 Dominique d'Humieres changed: What|Removed |Added Keywords|wrong-code | Priority|P3 |P5 Component|middle-end |fortran --- Comment #28 from Dominique d'Humieres --- > > This PR is now about a missed optimization in the middle-end. > > Well, that was absolutely not my intention when I opened this PR, > and it still isn't. Quite the opposite: I don't think gfortran should apply > more optimizations, but less. I'm changing the title and keyword again > to reflect that. Then I strongly opposed any change to the gfortran default behavior. Why should we take a chance to break valid codes to allow invalid or at best questionable ones? See Steve Lionel comment at https://groups.google.com/forum/#!topic/comp.lang.fortran/fXP1c0u57So: "All in all, functions that have side-effects are to be avoided." > If an impure function is found (recursively) in the operands of an .AND. > expression, issue a > > gfc_warning(OPT_Wsurprising, "Impure function %qs at %L may not be > evaluated", ...) > > So, > > if (flag .and. f(x) > 0.) > > would also be warned about. Why recursively? If this PR is going this way, pr57160 should be closed as a duplicate.
[Bug ada/85760] Using generic function to initialize a type created by a generic package crashes GNAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85760 --- Comment #9 from Eric Botcazou --- > OH! I thought you meant here. I wasn't sure this was the same bug > internally. They have different results in the two different versions of > GNAT. The AdaCore GNAT Community put out a crash report while the FSF GNAT > only returned quietly with no compilation results. Here's what I get: eric@polaris:~/build/gcc/native> ~/install/gcc-7-branch/bin/gcc -c main.adb +===GNAT BUG DETECTED==+ | 7.3.1 20180407 [gcc-7-branch revision 259208] (x86_64-suse-linux)| | Storage_Error stack overflow or erroneous memory access | | Error detected at main.adb:11:4 | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | eric@polaris:~/build/gcc/native> ~/install/gcc-8-branch/bin/gcc -c main.adb eric@polaris:~/build/gcc/native> > I've seen multiple times in the past where a bug was fixed in a earlier > version of GNAT GPL/Community but not in a later version of FSF GNAT, which > probably means they weren't actually the same bug internally. The chance that the same code triggers 2 different bugs in the compiler is virtually zero; what you experienced is only a discrepancy in release cycles. > Also there is no guarantee they'll even look at my report as it was for the > community edition (this is not a knock against them, they have their own > priorities that they must manage first). I was just trying to be nice to > help them find bugs as well. I wasn't meaning to cause trouble, just help > contribute to making GNAT the best it can be in all versions. There is a single GNAT codebase so there is no need to duplicate bug reports for all the different variants, they will eventually be resynced at some point. > So my apologies on the trouble. I was not intending to cause any. I hope > you will forgive me. Not sure if there is anything to forgive given your explanation.
[Bug middle-end/85620] Missing ENDBR after swapcontext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85620 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from H.J. Lu --- It has been fixed in glibc.
[Bug middle-end/85620] Missing ENDBR after swapcontext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85620 H.J. Lu changed: What|Removed |Added Resolution|FIXED |WONTFIX
[Bug target/81652] [meta-bug] -fcf-protection=full bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 Bug 81652 depends on bug 85620, which changed state. Bug 85620 Summary: Missing ENDBR after swapcontext https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85620 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/85599] Prevent short-circuiting of logical expressions for non-pure functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599 --- Comment #29 from janus at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #27) > > If an impure function is found (recursively) in the operands of an .AND. > > expression, issue a > > > > gfc_warning(OPT_Wsurprising, "Impure function %qs at %L may not be > > evaluated", ...) > > > > So, > > > > if (flag .and. f(x) > 0.) > > > > would also be warned about. > > I think I will start working on that warning; this should lead to > users being made aware of a potential problem in their code. That's not my favorite way of fixing it, but it's certainly an improvement upon the current state of things, so I'm fine with it. The warning text basically sounds good to me, although you could possibly replace 'may' by 'might'. I'm not a native speaker, but I think that is clearer and sounds less like "... is not allowed to be evaluated". In addition to .and., a treatment of .or. is needed as well.
[Bug target/85819] New: conversion from __v[48]su to __v[48]sf should use FMA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85819
Bug ID: 85819
Summary: conversion from __v[48]su to __v[48]sf should use FMA
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Testcase (cf. https://godbolt.org/g/UoU3zj):
using T = float;
using To [[gnu::vector_size(32)]] = T;
using From [[gnu::vector_size(32)]] = unsigned;
#define A2(I) (T)a[I], (T)a[1+I]
#define A4(I) A2(I), A2(2+I)
#define A8(I) A4(I), A4(4+I)
To f(From a) {
return To{A8(0)};
}
This compiles to:
vpand .LC0(%rip), %ymm0, %ymm1
vpsrld $16, %ymm0, %ymm0
vcvtdq2ps %ymm0, %ymm0
vcvtdq2ps %ymm1, %ymm1
vmulps .LC1(%rip), %ymm0, %ymm0
vaddps %ymm0, %ymm1, %ymm0
ret
The last vmulps and vaddps can be contracted to vfmadd132ps .LC1(%rip), %ymm1,
%ymm0.
The same is true for vector_size(16).
[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85813
--- Comment #3 from Mathias Stearn ---
My assumption was that if E(...) throws and it can't be caught, it should be
treated as any other case when an -fno-exceptions TU calls a throwing function.
In this case that would mean calling terminate() due to the noexcept, which
seems better than returning a null exception_ptr.
However, while testing the behavior of mixing -fno-exceptions TUs with normal
ones, I realized there may be a bigger problem due to ODR violations. In
particular, if you link these TUs without optimizations, one of the asserts
will trip depending on the link order:
// g++ -fno-exceptions -c
#include
#include
void no_exceptions() {
assert(!std::make_exception_ptr(1));
}
// g++ -fexceptions
#include
#include
void no_exceptions();
int main() {
assert(std::make_exception_ptr(1));
no_exceptions();
}
Is that just accepted, implying the the whole program must be compiled with
either -fexceptions or -fno-exeptions, rather than allowing mix-and-match? If
so, I guess this whole point is moot.
[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85783 Martin Sebor changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX --- Comment #12 from Martin Sebor --- That's right, bug 82063 tracks the inability to turn off the warning. This report is about the false positive (only). Hopefully, that will go away once we fix 85795.
[Bug libstdc++/85812] [7/8/9 Regression] make_exception_ptr can leak the allocated exception if construction throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85812 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Thu May 17 15:03:29 2018 New Revision: 260323 URL: https://gcc.gnu.org/viewcvs?rev=260323&root=gcc&view=rev Log: PR libstdc++/85812 fix memory leak in std::make_exception_ptr PR libstdc++/85812 * libsupc++/cxxabi_init_exception.h (__cxa_free_exception): Declare. * libsupc++/exception_ptr.h (make_exception_ptr) [__cpp_exceptions]: Refactor to separate non-throwing and throwing implementations. [__cpp_rtti && !_GLIBCXX_HAVE_CDTOR_CALLABI]: Deallocate the memory if constructing the object throws. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/cxxabi_init_exception.h trunk/libstdc++-v3/libsupc++/exception_ptr.h
[Bug tree-optimization/85814] [8/9 Regression] ICE Segmentation fault during GIMPLE pass: strlen -O3 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85814 --- Comment #5 from Vittorio Zecca --- I confirm I get the ICE on trunk 260152 and on a sanitized version I also get ../../gcc/gcc/tree-ssa-strlen.c:721:11: runtime error: member access within null pointer of type 'struct strinfo' Thank you for the very useful reduction, Martin.
[Bug c++/85763] Feature request: Add a suggestion when compilation fails dues to ambiguous templated friend function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85763 --- Comment #2 from Josh Marshall --- Created attachment 44143 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44143&action=edit Example file I got to making an example, but it seems that this is no longer a problem. I'm going to close this one out as invalid.
[Bug c++/85763] Feature request: Add a suggestion when compilation fails dues to ambiguous templated friend function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85763 Josh Marshall changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug fortran/66694] Failure in function returning an allocated CHARACTER array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66694 --- Comment #2 from Dominique d'Humieres --- This PR seems fixed by the patch at https://gcc.gnu.org/ml/fortran/2018-05/msg00046.html, likely a duplicate of pr82923. On darwin the executable hangs due to pr30617.
[Bug fortran/82814] ICE from submodule character function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82814 --- Comment #6 from Paul Thomas --- Author: pault Date: Thu May 17 15:17:43 2018 New Revision: 260324 URL: https://gcc.gnu.org/viewcvs?rev=260324&root=gcc&view=rev Log: 2017-05-17 Paul Thomas PR fortran/82814 * gfortran.dg/submodule_31.f08: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/submodule_31.f08 Modified: branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/85599] Prevent short-circuiting of logical expressions for non-pure functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599 Dominique d'Humieres changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #30 from Dominique d'Humieres --- *** Bug 57160 has been marked as a duplicate of this bug. ***
[Bug fortran/57160] short-circuit IF only with -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57160 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Dominique d'Humieres --- Duplicate of pr85599. *** This bug has been marked as a duplicate of bug 85599 ***
[Bug fortran/82814] ICE from submodule character function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82814 --- Comment #7 from Paul Thomas --- Author: pault Date: Thu May 17 15:31:42 2018 New Revision: 260325 URL: https://gcc.gnu.org/viewcvs?rev=260325&root=gcc&view=rev Log: 2017-05-17 Paul Thomas PR fortran/82814 * gfortran.dg/submodule_31.f08: New test. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/submodule_31.f08 Modified: branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug fortran/82814] ICE from submodule character function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82814 Paul Thomas changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #8 from Paul Thomas --- The PR was already fixed on 6- and 7-branches in the course of fixing another bug. All that was needed was the testcase. Thanks for the report. Paul
[Bug libstdc++/85818] [8/9 Regression] undefined reference to `std::experimental::filesystem::v1::__cxx11::path::preferred_separator'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85818 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Thu May 17 15:36:25 2018 New Revision: 260326 URL: https://gcc.gnu.org/viewcvs?rev=260326&root=gcc&view=rev Log: PR libstdc++/85818 ensure path::preferred_separator is defined Because path.cc is compiled with -std=gnu++17 the static constexpr data member is implicitly 'inline' and so no definition gets emitted unless it gets used in that translation unit. Other translation units built as C++11 or C++14 still require a namespace-scope definition of the variable, so mark the definition as used. PR libstdc++/85818 * src/filesystem/path.cc (path::preferred_separator): Add used attribute. * testsuite/experimental/filesystem/path/preferred_separator.cc: New. Added: trunk/libstdc++-v3/testsuite/experimental/filesystem/path/preferred_separator.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/filesystem/path.cc
[Bug fortran/82617] Internal compiler error in expand_expr_real_1 when compiling the attached file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82617 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 CC||pault at gcc dot gnu.org Component|middle-end |fortran --- Comment #4 from Dominique d'Humieres --- AFAICT this seems fixed by the patch at https://gcc.gnu.org/ml/fortran/2018-05/msg00046.html, likely a duplicate of pr82923.
[Bug fortran/85816] [8/9 Regression] nested spread fails with "Integer overflow in xmallocarray"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85816 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||7.3.0 Keywords||wrong-code Last reconfirmed||2018-05-17 CC||pault at gcc dot gnu.org Ever confirmed|0 |1 Summary|nested spread fails with|[8/9 Regression] nested |"Integer overflow in|spread fails with "Integer |xmallocarray" |overflow in xmallocarray" Target Milestone|--- |8.2 Known to fail||8.1.0, 9.0 --- Comment #1 from Dominique d'Humieres --- > Operating system error: Cannot allocate memory > Integer overflow in xmallocarray Confirmed at run time. Caused by revision r257065.
[Bug libstdc++/85812] [7/8 Regression] make_exception_ptr can leak the allocated exception if construction throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85812 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Thu May 17 16:10:20 2018 New Revision: 260327 URL: https://gcc.gnu.org/viewcvs?rev=260327&root=gcc&view=rev Log: PR libstdc++/85812 fix memory leak in std::make_exception_ptr PR libstdc++/85812 * libsupc++/cxxabi_init_exception.h (__cxa_free_exception): Declare. * libsupc++/exception_ptr.h (make_exception_ptr) [__cpp_exceptions]: Refactor to separate non-throwing and throwing implementations. [__cpp_rtti && !_GLIBCXX_HAVE_CDTOR_CALLABI]: Deallocate the memory if constructing the object throws. Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/libsupc++/cxxabi_init_exception.h branches/gcc-8-branch/libstdc++-v3/libsupc++/exception_ptr.h
[Bug libstdc++/85818] [8/9 Regression] undefined reference to `std::experimental::filesystem::v1::__cxx11::path::preferred_separator'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85818 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Thu May 17 16:10:26 2018 New Revision: 260328 URL: https://gcc.gnu.org/viewcvs?rev=260328&root=gcc&view=rev Log: PR libstdc++/85818 ensure path::preferred_separator is defined Because path.cc is compiled with -std=gnu++17 the static constexpr data member is implicitly 'inline' and so no definition gets emitted unless it gets used in that translation unit. Other translation units built as C++11 or C++14 still require a namespace-scope definition of the variable, so mark the definition as used. PR libstdc++/85818 * src/filesystem/path.cc (path::preferred_separator): Add used attribute. * testsuite/experimental/filesystem/path/preferred_separator.cc: New. Added: branches/gcc-8-branch/libstdc++-v3/testsuite/experimental/filesystem/path/preferred_separator.cc Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/src/filesystem/path.cc
[Bug tree-optimization/85820] New: [9 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85820 Bug ID: 85820 Summary: [9 Regression] internal compiler error: Segmentation fault Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: prathamesh3492 at gcc dot gnu.org Target Milestone: --- On x86-64, r260250 caused: gfortran -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin -DSPEC_CPU_LINUX -DSPEC_CPU_CASE_FLAG -DSPEC_CPU_LOGICAL_STRICT -frecord-marker=4 wrf_num_bytes_between.o pack_utils.o module_driver_constants.fppized.o module_domain.fppized.o module_integrate.fppized.o module_timing.fppized.o module_configure.fppized.o module_tiles.fppized.o module_machine.fppized.o module_nesting.fppized.o module_wrf_error.fppized.o module_state_description.fppized.o module_sm.fppized.o module_io.fppized.o module_dm_stubs.fppized.o module_quilt_outbuf_ops.fppized.o module_io_quilt.fppized.o module_bc.fppized.o module_io_wrf.fppized.o module_date_time.fppized.o module_io_domain.fppized.o module_bc_time_utilities.fppized.o module_model_constants.fppized.o module_soil_pre.fppized.o module_bl_mrf.fppized.o module_sf_myjsfc.fppized.o module_bl_myjpbl.fppized.o module_bl_ysu.fppized.o module_cu_bmj.fppized.o module_mp_kessler.fppized.o module_mp_ncloud5.fppized.o module_ra_sw.fppized.o module_sf_sfclay.fppized.o module_cu_kf.fppized.o module_cu_kfeta.fppized.o module_mp_lin.fppized.o module_mp_wsm3.fppized.o module_mp_wsm5.fppized.o module_mp_wsm6.fppized.o module_surface_driver.fppized.o module_cu_gd.fppized.o module_sf_sfcdiags.fppized.o module_ra_gsfcsw.fppized.o module_sf_slab.fppized.o module_sf_noahlsm.fppized.o module_sf_ruclsm.fppized.o module_mp_ncloud3.fppized.o module_mp_etanew.fppized.o module_ra_rrtm.fppized.o module_ra_gfdleta.fppized.o module_physics_init.fppized.o module_physics_addtendc.fppized.o module_solvedebug_em.fppized.o module_bc_em.fppized.o module_advect_em.fppized.o module_diffusion_em.fppized.o module_small_step_em.fppized.o module_big_step_utilities_em.fppized.o module_em.fppized.o module_init_utilities.fppized.o module_optional_si_input.fppized.o ESMF_Alarm.fppized.o ESMF_Base.fppized.o ESMF_BaseTime.fppized.o ESMF_Calendar.fppized.o ESMF_Clock.fppized.o ESMF_Fraction.fppized.o ESMF_Mod.fppized.o ESMF_Time.fppized.o ESMF_TimeInterval.fppized.o Meat.fppized.o wrf_shutdown.fppized.o collect_on_comm.o mediation_integrate.fppized.o mediation_feedback_domain.fppized.o mediation_force_domain.fppized.o mediation_interp_domain.fppized.o mediation_wrfmain.fppized.o wrf_auxhist1in.fppized.o wrf_auxhist1out.fppized.o wrf_auxhist2in.fppized.o wrf_auxhist2out.fppized.o wrf_auxhist3in.fppized.o wrf_auxhist3out.fppized.o wrf_auxhist4in.fppized.o wrf_auxhist4out.fppized.o wrf_auxhist5in.fppized.o wrf_auxhist5out.fppized.o wrf_auxinput1in.fppized.o wrf_auxinput1out.fppized.o wrf_auxinput2in.fppized.o wrf_auxinput2out.fppized.o wrf_auxinput3in.fppized.o wrf_auxinput3out.fppized.o wrf_auxinput4in.fppized.o wrf_auxinput4out.fppized.o wrf_auxinput5in.fppized.o wrf_auxinput5out.fppized.o wrf_bdyin.fppized.o wrf_bdyout.fppized.o wrf_histin.fppized.o wrf_histout.fppized.o wrf_inputin.fppized.o wrf_inputout.fppized.o wrf_restartin.fppized.o wrf_restartout.fppized.o couple_or_uncouple_em.fppized.o interp_domain_em.fppized.o interp_fcn.fppized.o nest_init_utils.fppized.o set_timekeeping.fppized.o sint.fppized.o solve_interface.fppized.o start_domain.fppized.o module_pbl_driver.fppized.o module_radiation_driver.fppized.o module_cumulus_driver.fppized.o module_microphysics_driver.fppized.o solve_em.fppized.o start_em.fppized.o internal_header_util.fppized.o io_int.fppized.o init_modules_em.fppized.o init_modules.fppized.o wrf_io.o field_routines.o wrf.fppized.o netcdf/attr.o netcdf/dim.o netcdf/error.o netcdf/fort-attio.o netcdf/fort-control.o netcdf/fort-dim.o netcdf/fort-genatt.o netcdf/fort-geninq.o netcdf/fort-genvar.o netcdf/fort-lib.o netcdf/fort-misc.o netcdf/fort-v2compat.o netcdf/fort-var1io.o netcdf/fort-varaio.o netcdf/fort-vario.o netcdf/fort-varmio.o netcdf/fort-varsio.o netcdf/libvers.o netcdf/nc.o netcdf/ncx.o netcdf/posixio.o netcdf/putget.o netcdf/string.o netcdf/v1hpg.o netcdf/v2i.o netcdf/var.o netcdf/typeSizes.o netcdf/netcdf.o -o wrf ... during RTL pass: expand internal_header_util.fppized.f90: In function 'int_get_ti_header_char.constprop': internal_header_util.fppized.f90:372:1: internal compiler error: Segmentation fault DataHandle, dummyData, DummyCount, code ) ^ 0xbb1a4f crash_signal ../../src-trunk/gcc/toplev.c:325 0x7a679b expand_call(tree_node*, rtx_def*, int) ../../src-trunk/gcc/calls.c:4287 0x8b6c7b expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_
[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698 --- Comment #9 from Pat Haugen --- Author: pthaugen Date: Thu May 17 16:19:16 2018 New Revision: 260329 URL: https://gcc.gnu.org/viewcvs?rev=260329&root=gcc&view=rev Log: PR target/85698 * config/rs6000/rs6000.c (rs6000_output_move_128bit): Check dest operand. * gcc.target/powerpc/pr85698.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr85698.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698 Pat Haugen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Pat Haugen --- Fixed.
[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85813
--- Comment #4 from Jonathan Wakely ---
(In reply to Mathias Stearn from comment #3)
> My assumption was that if E(...) throws and it can't be caught, it should be
> treated as any other case when an -fno-exceptions TU calls a throwing
> function. In this case that would mean calling terminate() due to the
> noexcept, which seems better than returning a null exception_ptr.
Simply returning an empty exception_ptr is what happened before the PR 64241
change, so what we do now retains that behaviour. That might be the main reason
for it.
It would be possible to use the new throw-less implementation for the
-fno-exceptions case. It would be fine for types with a non-throwing move, at
least:
--- a/libstdc++-v3/libsupc++/exception_ptr.h
+++ b/libstdc++-v3/libsupc++/exception_ptr.h
@@ -185,7 +185,7 @@ namespace std
__exception_ptr::__dest_thunk<_Ex>);
try
{
- ::new (__e) _Ex(__ex);
+ ::new (__e) _Ex(std::forward<_Ex>(__ex));
return exception_ptr(__e);
}
catch(...)
@@ -203,7 +203,19 @@ namespace std
return current_exception();
}
#else // no RTTI and no exceptions
+#if __cplusplus >= 201103L
+ if _GLIBCXX17_CONSTEXPR (std::is_nothrow_move_constructible<_Ex>::value)
+ {
+ void* __e = __cxxabiv1::__cxa_allocate_exception(sizeof(_Ex));
+ (void) __cxxabiv1::__cxa_init_primary_exception(
+ __e, const_cast(&typeid(__ex)),
+ __exception_ptr::__dest_thunk<_Ex>);
+ ::new (__e) _Ex(std::forward<_Ex>(__ex));
+ return exception_ptr(__e);
+ }
+#else
return exception_ptr();
+#endif
#endif
}
> Is that just accepted, implying the the whole program must be compiled with
> either -fexceptions or -fno-exeptions, rather than allowing mix-and-match?
> If so, I guess this whole point is moot.
Mix-and-match works if the function gets inlined.
But if you mix -fexceptions and -fno-exceptions then you do have to accept that
the resulting ODR violations might give surprising or undesirable results.
[Bug tree-optimization/85820] [9 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85820 --- Comment #1 from prathamesh3492 at gcc dot gnu.org --- This is most likely dup of PR85817. Could you check if the fix in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85817#c1 works ? Thanks, Prathamesh
[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85813 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > (In reply to Mathias Stearn from comment #3) > > My assumption was that if E(...) throws and it can't be caught, it should be > > treated as any other case when an -fno-exceptions TU calls a throwing > > function. In this case that would mean calling terminate() due to the > > noexcept, which seems better than returning a null exception_ptr. > > Simply returning an empty exception_ptr is what happened before the PR 64241 > change, so what we do now retains that behaviour. That might be the main > reason for it. Oops, wrong PR number, I meant PR 68297. Before the PR 64241 change we just returned undefined garbage!
[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85813 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-17 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #6 from Jonathan Wakely --- Let's confirm this as a valid enhancement request anyway.
[Bug c++/85763] Feature request: Add a suggestion when compilation fails dues to ambiguous templated friend function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85763 --- Comment #3 from Jonathan Wakely --- OK thanks for following up.
[Bug libstdc++/85821] New: Chrono literal operators do not follow the standard declarataions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85821
Bug ID: 85821
Summary: Chrono literal operators do not follow the standard
declarataions
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: andreas.molzer at gmx dot de
Target Milestone: ---
The literal operators provided by std::literals::chrono_literals are missing
their overloads for unsigned long long arguments. They instead provide a
declaration for long double and a non-standard declaration with template
argument list. This silently breaks valid code:
#include
int main() {
using namespace std::chrono_literals;
auto time = operator""s(1ull);
}
Name resolution will only find the single matching overload and convert the
argument to long double. This will result in a duration with unspecified
representation, in libstdc++ case a long double. The standard would instead
require the result to be std::chrono::seconds with representation of an
unspecified integral type with a minimum number of bits.
This can have various additional effects, including decltype(time)::max()
returning an invalid result, so that the normally perfectly valid
std::chrono::seconds::rep max = decltype(time)::max()
will result in undefined behaviour due to the long double maximum value not
fitting inside the unsigned long long.
The following code should be rejected because overload resolution should not be
able to determine a best match:
#include
int main() {
using namespace std::chrono_literals;
auto time = operator""s(0); // int, no priority for conversion to ull or
ld
}
[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85813 --- Comment #7 from Mathias Stearn --- > Simply returning an empty exception_ptr is what happened before the PR 64241 > change, so what we do now retains that behaviour. That might be the main > reason for it. Silently dropping errors always skeeves me out. I'm not sure if anyone is well served by the current behavior. If it were up to me (and I know it isn't) I'd make that case call std::terminate() or similar rather than returning the "no error" value. That seems consistent with the behavior of the __throw* functions, but it is a breaking change. Or even better, since gcc seems fine throwing through functions marked noexcept in -fno-exceptions TUs, maybe in the (very rare) case where copying/moving an exception throws inside an -fno-exceptions TU, just let it bubble out. > ::new (__e) _Ex(std::forward<_Ex>(__ex)); Should that be std::move(__ex)? I don't know why, but make_exception_ptr takes the exception by value rather than forwarding ref. I guess forward<_Ex> is fine either way, and will stay correct if that defect gets fixed. It just seemed odd to forward a value so I thought I'd mention it. > Mix-and-match works if the function gets inlined. Do you think this case warrants a [[gnu::always_inline]]? Given the sensitive nature of error handling, it seems pretty bad if a correct usage of make_exception_ptr() could be silently transformed to return the "no error" value just by linking in a bad library. Even if that library never dynamically executes make_exception_ptr(). I know I'd hate to be called in to debug that issue... I'm going to go make sure no code we link with uses -fno-exceptions!
[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85813 --- Comment #8 from Jonathan Wakely --- (In reply to Mathias Stearn from comment #7) > > Simply returning an empty exception_ptr is what happened before the PR 64241 > > change, so what we do now retains that behaviour. That might be the main > > reason for it. > > Silently dropping errors always skeeves me out. I'm not sure if anyone is > well served by the current behavior. If it were up to me (and I know it > isn't) I'd make that case call std::terminate() or similar rather than > returning the "no error" value. That seems consistent with the behavior of > the __throw* functions, but it is a breaking change. Or even better, since > gcc seems fine throwing through functions marked noexcept in -fno-exceptions > TUs, maybe in the (very rare) case where copying/moving an exception throws > inside an -fno-exceptions TU, just let it bubble out. > > > ::new (__e) _Ex(std::forward<_Ex>(__ex)); > > Should that be std::move(__ex)? That would move from an lvalue if called as: E e; std::make_exception_ptr(e); I don't know if that's valid (I sent an email to the LWG reflector about that a few minutes ago). > I don't know why, but make_exception_ptr > takes the exception by value rather than forwarding ref. Probably so it decays (which "throw e;" will do anyway). > I guess > forward<_Ex> is fine either way, and will stay correct if that defect gets > fixed. It just seemed odd to forward a value so I thought I'd mention it. > > > Mix-and-match works if the function gets inlined. > > Do you think this case warrants a [[gnu::always_inline]]? Given the Without thinking about it too deeply, no I don't think it should have that. It could have negative consequences on the optimization of other code around the call to make_exception_ptr (which might be more important, non-error handling code, that should be inlined in preference to the error-handling path). > sensitive nature of error handling, it seems pretty bad if a correct usage > of make_exception_ptr() could be silently transformed to return the "no > error" value just by linking in a bad library. Even if that library never > dynamically executes make_exception_ptr(). I know I'd hate to be called in > to debug that issue... > > I'm going to go make sure no code we link with uses -fno-exceptions! Rather than always_inline a better option might be to give it a different mangled name when exceptions are disabled (or just not declare it at all, but it might be too late for that as it would be a breaking change). That would ensure the return-null version never gets chosen by the linker to replace the real version.
[Bug libstdc++/85821] Chrono literal operators do not follow the standard declarataions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85821 --- Comment #1 from Jonathan Wakely --- The simple answer is of course "don't do that". Writing 1s works fine, or if you want to be explicit, std::chrono::seconds(1).
[Bug libstdc++/85818] [8/9 Regression] undefined reference to `std::experimental::filesystem::v1::__cxx11::path::preferred_separator'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85818 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- Fixed for 8.2
[Bug libstdc++/85812] [7/8 Regression] make_exception_ptr can leak the allocated exception if construction throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85812 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for 7.4 and 8.2
[Bug libstdc++/85812] [7/8 Regression] make_exception_ptr can leak the allocated exception if construction throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85812 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Thu May 17 17:26:44 2018 New Revision: 260331 URL: https://gcc.gnu.org/viewcvs?rev=260331&root=gcc&view=rev Log: PR libstdc++/85812 fix memory leak in std::make_exception_ptr PR libstdc++/85812 * libsupc++/cxxabi_init_exception.h (__cxa_free_exception): Declare. * libsupc++/exception_ptr.h (make_exception_ptr) [__cpp_exceptions]: Refactor to separate non-throwing and throwing implementations. [__cpp_rtti && !_GLIBCXX_HAVE_CDTOR_CALLABI]: Deallocate the memory if constructing the object throws. Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/libsupc++/cxxabi_init_exception.h branches/gcc-7-branch/libstdc++-v3/libsupc++/exception_ptr.h
[Bug middle-end/41475] common variables cannot be expected to be aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41475 Andrey Tarasevich changed: What|Removed |Added CC||atarasevich at comcast dot net --- Comment #10 from Andrey Tarasevich --- (In reply to Andrew Pinski from comment #8) > This code is undefined I think (and really it is not valid C90/C99 code). You are absolutely right - this code is not valid from the point of view of formal standard C language. It is illegal to provide multiple definitions of external objects with the same name. However, this is a popular extension in C implementations with Unix heritage. So, this entry is about the intended non-standard behavior of GCC compiler/linker.
[Bug tree-optimization/78969] bogus snprintf truncation warning due to missing range info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78969
Martin Sebor changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #12 from Martin Sebor ---
Thanks for the test case. Here's a slightly reduced version of it:
$ cat pr78969.c && gcc -O2 -S -Wall pr78969.c
void f (int, ...);
char d[4];
void g (unsigned i)
{
if (i >= 1000 && i < 1)
__builtin_snprintf (d, 4, "%3d", i / 10); // bogus -Wformat-truncation
else
f (i / 10 % 10);
}
pr78969.c: In function ‘g’:
pr78969.c:8:32: warning: ‘%3d’ directive output may be truncated writing
between 3 and 9 bytes into a region of size 4 [-Wformat-truncation=]
__builtin_snprintf (d, 4, "%3d", i / 10); // bogus -Wformat-truncation
^~~
pr78969.c:8:31: note: directive argument in the range [0, 429496729]
__builtin_snprintf (d, 4, "%3d", i / 10); // bogus -Wformat-truncation
^
pr78969.c:8:5: note: ‘__builtin_snprintf’ output between 4 and 10 bytes into a
destination of size 4
__builtin_snprintf (d, 4, "%3d", i / 10); // bogus -Wformat-truncation
^~~~
It does look like the false positive is due to the same underlying limitation
(the range not being reflected accurately outside the VRP pass). GCC 7 doesn't
warn but GCC 8 does. That's because in GCC 7 the result of the
get_range_info() function is VR_VARYING for the argument while in GCC 8 it
reports a VR_RANGE of [0, 429496729]. So ironically, the false positive is a
side-effect of the improvement in GCC 8's range tracking.
There is work underway to improve the accuracy of the range information even
further that should reduce the rate of these kinds of false positives.
That being said, a few comments:
1) The problem doesn't affect just -Wstringop-truncation but other warnings as
well, including -Wformat-overflow. The latter warning, especially, has proven
to be useful enough despite this limitation that removing either from -Wall
doesn't seem a like good solution.
2) The philosophy behind -Wstringop-truncation is based on the assumption that
snprintf() is being called because truncation is possible, and that most
programs aren't prepared to handle it correctly.
In the test case, since truncation isn't possible, calling snprintf() is
unnecessary (and sprintf() would be sufficient -- though calling sprintf with a
fixed-size buffer just big enough for the output would also cause a false
positive). Otherwise, if truncation were possible, the expectation is that the
caller should detect it by testing the return value from the function and
taking some action (e.g., by aborting).
Until the range improvements I mention above are made, I suggest to assume that
snprintf can truncate and handle the truncation somehow. In comparison to the
runtime cost of the snprintf call, the overhead of checking the return value
and aborting is negligible.
[Bug tree-optimization/85822] New: [8/9 Regression] Maybe wrong code in VRP since r249150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85822
Bug ID: 85822
Summary: [8/9 Regression] Maybe wrong code in VRP since r249150
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org, ygribov at gcc dot gnu.org
Target Milestone: ---
I've saw that in qtscript, isolated test-case looks as follows:
$ cat vrp.c
static const long int TagTypeNumber = 0xll;
long int x;
void foo(void)
{
x = TagTypeNumber + 1;
}
int main(int argc, char **argv)
{
if (argc > 0)
foo ();
if ((x & TagTypeNumber) == TagTypeNumber)
{
unsigned y = (unsigned)x;
__builtin_printf ("v: %u\n", y);
if (y != 1)
__builtin_abort ();
}
return 0;
}
$ gcc -O2 vrp.c && ./a.out
v: 0
Aborted (core dumped)
$
[Bug tree-optimization/85822] [8/9 Regression] Maybe wrong code in VRP since r249150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85822 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-17 Version|unknown |9.0 Ever confirmed|0 |1
[Bug tree-optimization/85820] [9 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85820 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from H.J. Lu --- (In reply to prathamesh3492 from comment #1) > This is most likely dup of PR85817. Could you check if the fix in > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85817#c1 works ? Yes, the patch works. Thanks. *** This bug has been marked as a duplicate of bug 85817 ***
[Bug ipa/85817] [9 Regression] ICE in expand_call at gcc/calls.c:4291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85817 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #3 from H.J. Lu --- *** Bug 85820 has been marked as a duplicate of this bug. ***
[Bug c++/85823] New: Boost.Tribool fails to compile: error: '(tribool::dummy::nonnull != 0)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85823
Bug ID: 85823
Summary: Boost.Tribool fails to compile: error:
'(tribool::dummy::nonnull != 0)' is not a constant
expression
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
Reduced from
https://github.com/boostorg/logic/pull/5#issuecomment-389965834
struct B {
struct dummy {
void nonnull() { }
};
using safe_bool = void (dummy::*)();
constexpr B() : value(false) {}
constexpr B(int) : value(true) {}
constexpr operator safe_bool() const
{
return value ? &dummy::nonnull : 0;
}
bool value;
};
constexpr B operator!(B x)
{
return x.value ? B() : B(1);
}
constexpr B tb_f{};
static_assert(!tb_f, "");
tribool.cc:25:15: error: non-constant condition for static assertion
static_assert(!tb_f, "");
^
tribool.cc:25:25: error: '(B::dummy::nonnull != 0)' is not a constant
expression
static_assert(!tb_f, "");
^
[Bug c++/85823] Boost.Tribool fails to compile: error: '(tribool::dummy::nonnull != 0)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85823 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-17 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Seems this never worked, thus not a regression.
[Bug lto/82229] GCC7's LTO underperforms compared to GCC6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82229 --- Comment #28 from krzysio.kurek at wp dot pl --- I mean the relative performance is worse but still Profiled GCC6 is faster than GCC 7 or GCC 8.
[Bug tree-optimization/85822] [8/9 Regression] Maybe wrong code in VRP since r249150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85822 --- Comment #1 from Marc Glisse --- _2 = x.0_1 & -281474976710656; if (_2 == -281474976710656) goto ; [20.24%] [...] x.0_11 = ASSERT_EXPR ; x.0_12 = ASSERT_EXPR ; x.0_13 = ASSERT_EXPR = -1>; y_7 = (unsigned intD.9) x.0_13; Those ASSERT_EXPR look strange, possibly the last 2 inequalities are inverted.
[Bug tree-optimization/85814] [8/9 Regression] ICE Segmentation fault during GIMPLE pass: strlen -O3 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85814 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||rsandifo at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #6 from rsandifo at gcc dot gnu.org --- Mine.
[Bug libstdc++/85824] New: regex constructor crashes under UTF-8 locale on Solaris-sparc when parsing a simple character class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85824
Bug ID: 85824
Summary: regex constructor crashes under UTF-8 locale on
Solaris-sparc when parsing a simple character class
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: wanyingloo at gmail dot com
Target Milestone: ---
$ cat test.cpp
#include
#include
int main (int argc, char *argv[]) {
setlocale(LC_ALL, "");
std::regex("[0-9]");
}
$ echo $LANG
en_US.UTF-8
$ g++ -std=c++11 test.cpp
$ ./a.out
terminate called after throwing an instance of 'std::length_error'
what(): basic_string::append
Abort (core dumped)
$ uname -a
SunOS t-solaris11sparc-02 5.11 11.3 sun4v sparc sun4v Solaris
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/tmp/wluo/othello/solaris-sparc-packages/bin/../libexec/gcc/sparc-sun-solaris2.10/4.9.2/lto-wrapper
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.9.2/configure --prefix=/usr
--with-local-prefix=/usr/local --enable-languages=c,c++ --disable-nls
--disable-lto --enable-clocale=generic
--with-stage1-ldflags='-L/data00/builds/trprince/platform-packages-build/idir/solaris-sparc/stage1-packages/lib
-static-libgcc -static-libstdc++ -laio -lmd'
--with-boot-ldflags='-L/data00/builds/trprince/platform-packages-build/idir/solaris-sparc/stage1-packages/lib
-static-libgcc -static-libstdc++ -laio -lmd' --disable-werror
--with-libiconv-prefix=/data00/builds/trprince/platform-packages-build/idir/solaris-sparc/stage1-packages
--with-gnu-ld --with-gnu-as --disable-multiarch --disable-bootstrap
Thread model: posix
gcc version 4.9.2 (GCC)
I can't reproduce it on Linux using the same GCC version. I did some
investigation and it seems to be because regex compiler doesn't account for
implementation-defined behavior of strxfrm(). I ran the following test on the
same Solaris SPARC machine.
$ cat more_test.cpp
#include
#include
#include
#include
int main (int argc, char *argv[]) {
setlocale(LC_ALL, "");
char a[] = { 0x80, '\0' };
printf("%lu\n", strxfrm(NULL, a, 0));
printf("%s\n", strerror(errno));
}
$ g++ -std=c++11 -w more_test.cpp
$ ./a.out
4294967295
Illegal byte sequence
In libstdc++-v3/include/bits/locale_classes.tcc, do_transform() is defined as
follows:
do_transform(const _CharT* __lo, const _CharT* __hi) const
{
...
size_t __res = _M_transform(__c, __p, __len);
...
__ret.append(__c, __res);
When _M_transform() calls strxfrm() and gets -1 when converting 0x80 under the
UTF-8 locale on Solaris SPARC, it simply assigns -1 to __res of type size_t
which creates a very large number. This causes __ret.append(__c, __res) to
crash. I think it would be nice if the code checks errno and issues a better
error message than the one above.
When I ran this test on a Linux machine with GCC 4.9.2, glibc's strxfrm()
converts 0x80 to 6 bytes. I tend to think Solaris SPARC's libc behavior makes
more sense here since 0x80 on its own isn't a valid UTF-8 code point even
though it's a valid UTF-8 code unit. I have no idea why glibc converts it to 6
bytes. In any event, how strxfrm() converts 0x80 under UTF-8 is
implementation-defined, and I'm not sure do_transform() accounts for that. At
the very least, it can be more defensive by checking errno, I think.
[Bug libstdc++/85824] regex constructor crashes under UTF-8 locale on Solaris-sparc when parsing a simple character class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85824 --- Comment #1 from Wanying Luo --- Here's GDB backtrace at the time of crash. #0 0xf56fe7a0 in __lwp_sigqueue () from /lib/libc.so.1 #1 0xf56a1e90 in raise () from /lib/libc.so.1 #2 0xf567a274 in abort () from /lib/libc.so.1 #3 0xff2f2d70 in __gnu_cxx::__verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95 #4 0xff2ef844 in __cxxabiv1::__terminate (handler=0xff2f2bac <__gnu_cxx::__verbose_terminate_handler()>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:47 #5 0xff2ef8e8 in std::terminate () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:57 #6 0xff2efc68 in __cxxabiv1::__cxa_rethrow () at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:125 #7 0xff29c974 in std::collate::do_transform (this=0xff34d9f8 <(anonymous namespace)::collate_c>, __lo=0x4fb3c "\200", __hi=0x4fb3d "") at /tmp/wluo/gcc-4.9.2/build/sparc-sun-solaris2.11/libstdc++-v3/include/bits/locale_classes.tcc:245 #8 0xff29c25c in std::collate::transform (this=0xff34d9f8 <(anonymous namespace)::collate_c>, __lo=0x4fb3c "\200", __hi=0x4fb3d "") at /tmp/wluo/gcc-4.9.2/build/sparc-sun-solaris2.11/libstdc++-v3/include/bits/locale_classes.h:662 #9 0x0002ead4 in std::string std::regex_traits::transform(char*, char*) const () #10 0x0002c634 in std::string std::regex_traits::transform_primary(char*, char*) const () #11 0x000275f8 in std::__detail::_BracketMatcher, false, false>::_M_apply(char, std::integral_constant) const () #12 0x00022bb4 in std::__detail::_BracketMatcher, false, false>::_M_make_cache(std::integral_constant) () #13 0x0001ed70 in std::__detail::_BracketMatcher, false, false>::_M_ready() () #14 0x0001f958 in void std::__detail::_Compiler >::_M_insert_bracket_matcher(bool) () #15 0x0001c630 in std::__detail::_Compiler >::_M_bracket_expression() () #16 0x000192e8 in std::__detail::_Compiler >::_M_atom() () #17 0x00017910 in std::__detail::_Compiler >::_M_term() () #18 0x00015868 in std::__detail::_Compiler >::_M_alternative() () #19 0x000141dc in std::__detail::_Compiler >::_M_disjunction() () #20 0x0001381c in std::__detail::_Compiler >::_Compiler(char const*, char const*, std::regex_traits const&, std::regex_constants::syntax_option_type) () #21 0x00013340 in std::shared_ptr > > std::__detail::__compile_nfa >(std::regex_traits::char_type const*, std::regex_traits::char_type const*, std::regex_traits const&, std::regex_constants::syntax_option_type) () #22 0x0001307c in std::basic_regex >::basic_regex(char const*, char const*, std::regex_constants::syntax_option_type) () #23 0x00012d84 in std::basic_regex >::basic_regex(char const*, std::regex_constants::syntax_option_type) () #24 0x000120d0 in main ()
[Bug libstdc++/85824] regex constructor crashes under UTF-8 locale on Solaris-sparc when parsing a simple character class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85824
--- Comment #2 from Wanying Luo ---
(In reply to Wanying Luo from comment #0)
> When I ran this test on a Linux machine with GCC 4.9.2, glibc's strxfrm()
> converts 0x80 to 6 bytes.
Pasting my test on Linux with the same version of GCC for completeness.
$ cat test.cpp
#include
#include
int main (int argc, char *argv[]) {
setlocale(LC_ALL, "");
std::regex("[0-9]");
}
$ echo $LANG
en_US.UTF-8
$ g++ -std=c++11 test.cpp
$ ./a.out
$ cat more_test.cpp
#include
#include
#include
#include
int main (int argc, char *argv[]) {
setlocale(LC_ALL, "");
char a[] = { 0x80, '\0' };
printf("%lu\n", strxfrm(NULL, a, 0));
printf("%s\n", strerror(errno));
}
$ g++ -std=c++11 -w more_test.cpp
$ ./a.out
6
Success
$ uname -a
Linux d-ubuntu12x64-11 3.2.0-126-generic #169-Ubuntu SMP Fri Mar 31 14:15:21
UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/wluo/othello/linux64-packages/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.2/configure --prefix=/usr
--with-local-prefix=/usr/local --enable-languages=c,c++,fortran --disable-nls
--disable-libcilkrts --disable-lto --enable-libstdcxx-time
--enable-clocale=generic
--with-stage1-ldflags='-L/slowfs/sighome/calebs/working/platform-packages-build/idir/linux64/stage1-packages/lib64
-L/slowfs/sighome/calebs/working/platform-packages-build/idir/linux64/stage1-packages/lib'
--with-boot-ldflags='-L/slowfs/sighome/calebs/working/platform-packages-build/idir/linux64/stage1-packages/lib64
-L/slowfs/sighome/calebs/working/platform-packages-build/idir/linux64/stage1-packages/lib'
--disable-werror --disable-multiarch --disable-bootstrap
Thread model: posix
gcc version 4.9.2 (GCC)
[Bug tree-optimization/85822] [8/9 Regression] Maybe wrong code in VRP since r249150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85822 Yuri Gribov changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #2 from Yuri Gribov --- Checking.
[Bug fortran/78797] It is time perhaps to implement -std=f2015
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78797 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #10 from janus at gcc dot gnu.org --- (In reply to Harald Anlauf from comment #8) > As -std=f2018 will be available in 8.0 and replaces -std=f2015, > shouldn't this bug be closed? Yes, gfortran 8 has -std=f2018. Closing.
[Bug c++/85823] Boost.Tribool fails to compile: error: '(tribool::dummy::nonnull != 0)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85823 --- Comment #2 from Andrew Pinski --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485
[Bug tree-optimization/85822] [8/9 Regression] Maybe wrong code in VRP since r249150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85822 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.2
