[Bug c++/85689] if constexpr compiles false branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85689 W E Brown changed: What|Removed |Added CC||webrown.cpp at gmail dot com --- Comment #1 from W E Brown --- I believe the test program demonstrates that g++ is behaving correctly in processing static_assert in the context of a constexpr if. The demonstrated behavior is part of the design of the constexpr if facility as proposed for and adopted into C++17. Please see wg21.link/p0292, which in section "Not proposed" exhibits an example very similar to the submitted test program, pronouncing it "ill-formed". I respectfully recommend this issue be closed as INVALID, as it seems to be based on a misunderstanding.
[Bug target/84923] [8/9 regression] gcc.dg/attr-weakref-1.c failed on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84923 --- Comment #7 from Vladimir Mezentsev --- About comment #3 and #4. I cannot reproduce a problem. Is it a cross compilation on x86 for aarch64 ? What need to do to reproduce the problem ?
[Bug c++/85646] [7/8/9 Regression] Incorrect lambda visibility with -fvisibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85646 --- Comment #4 from Jason Merrill --- Author: jason Date: Tue May 8 03:13:09 2018 New Revision: 260022 URL: https://gcc.gnu.org/viewcvs?rev=260022&root=gcc&view=rev Log: PR c++/85646 - lambda visibility. * decl2.c (determine_visibility): Don't mess with template arguments from the containing scope. (vague_linkage_p): Check DECL_ABSTRACT_P before looking at a 'tor thunk. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/ext/visibility/lambda1.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/decl2.c
[Bug middle-end/85619] Inconsistent descriptions for new warning options in GCC 8.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85619 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- Let me take care of this.
[Bug middle-end/85619] Inconsistent descriptions for new warning options in GCC 8.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85619 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-08 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed. The "included in -Wall" or "included in -Wextra" bit would ideally be generated to avoid having to remember to mention it explicitly in the documentation of every option.
[Bug c/85623] strncmp() warns about attribute 'nonstring' incorrectly in -Wstringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85623 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- This should be easily fixable for the simple cases involving string constants. It may not be so simple for the non-constant ones.
[Bug c/85623] strncmp() warns about attribute 'nonstring' incorrectly in -Wstringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85623
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-05-08
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
Confirmed with the simpler test case below. GCC transforms the strncmp() call
to strcmp() because it can see that the bound is larger than the length of one
of the arguments but the warning doesn't consider this case (i.e., it triggers
even when the strcmp call cannot read past the end of the non-string array.
$ cat b.c && gcc -O2 -S -Wall b.c
extern __attribute__((nonstring)) char a[4];
int f (const char *s)
{
return __builtin_strcmp (a, "12");
}
b.c: In function ‘f’:
b.c:5:10: warning: ‘__builtin_strcmp’ argument 1 declared attribute ‘nonstring’
[-Wstringop-overflow=]
return __builtin_strcmp (a, "12");
^~
b.c:1:40: note: argument ‘a’ declared here
extern __attribute__((nonstring)) char a[4];
^
[Bug middle-end/85643] attribute nonstring fails to squash -Wstringop-truncation warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85643 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- Let me work on this.
[Bug middle-end/85643] attribute nonstring fails to squash -Wstringop-truncation warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85643 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-08 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed. In both f3() and f4() the destination at a non-zero offset is represented as a MEM_REF(ADDR_EXPR(VAR_DECL(data)), offset) that the warning isn't prepared to deal with the same way as when the offset is zero.
[Bug middle-end/85650] Additional warnings when -fsanitize=undefined is used with -Wstringop-truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- I'll work on this for GCC 9.
[Bug middle-end/85650] Additional warnings when -fsanitize=undefined is used with -Wstringop-truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-08 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- I actually view the warning in attachment 44067 as a feature (though one that just coincidentally happens to be enabled by the UBSan instrumentation) and its absence as a feature request. The warning in attachment 44068 is the opposite: the UBSan instrumentation gets in the way of the warning seeing the assignment as a suppression mechanism. The instrumentation in this case is pointless and can be removed with no loss of efficacy -- see bug 79265.
[Bug c/84890] Overly verbose notes for missing headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84890 --- Comment #9 from Martin Sebor --- (In reply to Martin Sebor from comment #8) To clarify: it's not correct to directly include the header in a GCC source file. Instead, one is expected to define the INCLUDE_STRING macro before including gcc/system.h.
[Bug middle-end/85652] -Wformat-overflow warning silenced by -fpic/-fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85652
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||msebor at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #2 from Martin Sebor ---
As explained in comment #1, with -fpic extern functions are not considered
candidates for inlining because they can be superimposed. Without -fpic GCC
sees that the inlined function can return a string that's as long as 55
characters but with the option a superimposed implementation could be
guaranteed to return a shorter string. The same effect can be seen with other
middle-end warnings, including for example -Warray-bounds with the following
modified test case:
struct b
{
const char *h(int) const;
char c[4][56];
};
const char *b::h(int d) const
{
return c[d]; // no -Warray-bounds with -fpic
}
void f() {
b a;
__builtin_puts (a.h (99));
}
[Bug c++/85691] New: Faulty Class Member Default Initialization - No Warning or Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85691
Bug ID: 85691
Summary: Faulty Class Member Default Initialization - No
Warning or Error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger at rankedgaming dot com
Target Milestone: ---
/// Bug Report
struct test
{
int x = data;
int data;
test(int o) : data(o) { }
};
/// Potentially Related Issue
struct test2
{
int x;
int data;
test2(int o) : data(o), x(data) { }
};
/*
- Details -
There should be a warning/error for test and test2.
In test the default initialization of x relies on data, which is initialized
after x.
In test2 the constructor initialization list is out of order. Same result as
for test.
- Note -
clang displays a warning for both these cases, but neither gcc nor msvc do
*/
[Bug fortran/85687] ICE in gfc_sym_identifier, at fortran/trans-decl.c:351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85687
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 260016)
+++ gcc/fortran/check.c (working copy)
@@ -3894,8 +3894,11 @@ gfc_check_rank (gfc_expr *a)
? a->value.function.esym->result->attr.pointer
: a->symtree->n.sym->result->attr.pointer;
- if (a->expr_type == EXPR_OP || a->expr_type == EXPR_NULL
- || a->expr_type == EXPR_COMPCALL|| a->expr_type == EXPR_PPC
+ if (a->expr_type == EXPR_OP
+ || a->expr_type == EXPR_NULL
+ || a->expr_type == EXPR_COMPCALL
+ || a->expr_type == EXPR_PPC
+ || a->ts.type == BT_PROCEDURE
|| !is_variable)
{
gfc_error ("The argument of the RANK intrinsic at %L must be a data "
[Bug c++/85646] [7/8/9 Regression] Incorrect lambda visibility with -fvisibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85646 --- Comment #3 from Jason Merrill --- Author: jason Date: Mon May 7 23:50:16 2018 New Revision: 260017 URL: https://gcc.gnu.org/viewcvs?rev=260017&root=gcc&view=rev Log: PR c++/85646 - lambda visibility. * decl2.c (determine_visibility): Don't mess with template arguments from the containing scope. (vague_linkage_p): Check DECL_ABSTRACT_P before looking at a 'tor thunk. Added: trunk/gcc/testsuite/g++.dg/ext/visibility/lambda1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c
[Bug c++/85690] New: missing suggested header for std-qualified names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85690 Bug ID: 85690 Summary: missing suggested header for std-qualified names Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- For the test case below, GCC suggests to include for the unqualified reference to ptrdiff_t but it doesn't offer a similar suggestion for the reference to std::size_t. It should suggest the header to include for both. In addition, since the kind of C headers need not define symbols in the global namespace (and not implementations do define them there), for unqualified references to such symbols GCC should suggest the traditional header, and the kind only for std-qualified references. $ cat b.c && gcc -O3 -S -Wall -Wextra -Wpedantic -xc++ b.c void f (ptrdiff_t); void g (std::size_t); b.c:1:18: error: variable or field ‘f’ declared void void f (ptrdiff_t); ^ b.c:1:9: error: ‘ptrdiff_t’ was not declared in this scope void f (ptrdiff_t); ^ b.c:1:9: note: ‘ptrdiff_t’ is defined in header ‘’; did you forget to ‘#include ’? +#include void f (ptrdiff_t); ^ b.c:3:20: error: variable or field ‘g’ declared void void g (std::size_t); ^ b.c:3:14: error: ‘size_t’ is not a member of ‘std’ void g (std::size_t); ^~
[Bug jit/66812] jit code-generation example that unexpectedly required -fno-strict-aliasing to work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66812 Eric Gallager changed: What|Removed |Added Keywords||patch CC||egallager at gcc dot gnu.org --- Comment #11 from Eric Gallager --- (In reply to David Malcolm from comment #10) > Candidate patch posted as: > https://gcc.gnu.org/ml/jit/2015-q3/msg00060.html adding "patch" keyword
[Bug c/84890] Overly verbose notes for missing headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84890 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #8 from Martin Sebor --- I would also find phrasing these notes in the form of suggestions (hints) preferable to asking questions. #including the header also may not be the only solution (the definition of INT_MAX can be brought in by including in addition to ), or even the right one (it isn't for GCC) so rather than referring to a required header it might be better to simply state that the symbol is declared (or defined in the case of macros) in the corresponding standard header. error: ‘INT_MAX’ undeclared (first use in this function) note: macro ‘INT_MAX’ is defined in
[Bug jit/66811] RFE: have jit dumps be compileable as C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66811 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-07 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Eric Gallager --- Confirming as an enhancement
[Bug jit/66627] [meta-bug] Tracker bug for jit bugs affecting ravi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66627 Bug 66627 depends on bug 66783, which changed state. Bug 66783 Summary: No error-checking for creating structs containing opaque structs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66783 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug jit/66783] No error-checking for creating structs containing opaque structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66783 Eric Gallager changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Eric Gallager --- (In reply to David Malcolm from comment #5) > Keeping this open until it's committed to the gcc-5-branch gcc-5-branch is closed so this bug can be closed, too.
[Bug jit/66594] jitted code should use -mtune=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-07 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #7 from Eric Gallager --- Confirming as an enhancement
[Bug tree-optimization/85651] Invalid -Warray-bounds warning with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85651 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug tree-optimization/85651] Invalid -Warray-bounds warning with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85651
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-05-07
CC||msebor at gcc dot gnu.org
Component|c++ |tree-optimization
Ever confirmed|0 |1
--- Comment #2 from Martin Sebor ---
Confirmed. The warning is issued from gimple-ssa-warn-restrict.c for the
following expression:
_68 = &logBuilder + _69;
The offset _69 is in the anti-range ~[-9223372036854775800,
-9223372036854775800] which the warning pass interprets as/transforms into
[-9223372036854775799, -9223372036854775801] (this is the range referenced by
the diagnostic). The builtin_memref::offset_out_of_bounds() function detects
this kind of range and has special code to deal with it but only for references
of ARRAY_TYPE. In the test case, logBuilder is RECORD_TYPE so the special
handling isn't performed. The following lightly tested change adds this
handling for structs as well to avoid the spurious warning.
Index: gcc/gimple-ssa-warn-restrict.c
===
--- gcc/gimple-ssa-warn-restrict.c (revision 260013)
+++ gcc/gimple-ssa-warn-restrict.c (working copy)
@@ -475,7 +475,10 @@ builtin_memref::offset_out_of_bounds (int strict,
/* A temporary, possibly adjusted, copy of the offset range. */
offset_int offrng[2] = { offrange[0], offrange[1] };
- if (DECL_P (base) && TREE_CODE (TREE_TYPE (base)) == ARRAY_TYPE)
+ tree_code basecode = TREE_CODE (TREE_TYPE (base));
+ if (DECL_P (base)
+ && (basecode == ARRAY_TYPE
+ || basecode == RECORD_TYPE))
{
/* Check for offset in an anti-range with a negative lower bound.
For such a range, consider only the non-negative subrange. */
[Bug target/85593] [6,7,8,9 Regression] GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593 --- Comment #7 from Austin Morton --- I will certainly give writing a patch a try - but I will disclaim up front that because there is a viable workaround for the issue I was having (patch below [1]), this issue is "resolved" as far as my employer is concerned. Nevertheless, I will attempt to tackle this on a weekend out of curiosity (never had a reason to dig around in compiler guts before). [1] https://marc.info/?l=linux-bluetooth&m=152535913710490&w=2
[Bug fortran/85687] ICE in gfc_sym_identifier, at fortran/trans-decl.c:351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85687 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (9.0). Note that -std=f2018 is accepted on 8.1 and 9.0 only.
[Bug fortran/85686] [8/9 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85686 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||7.3.0 Keywords||ice-on-valid-code Last reconfirmed||2018-05-07 CC||pault at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |8.2 Known to fail||8.1.0, 9.0 --- Comment #1 from Dominique d'Humieres --- Likely revision r257781 (pr84115).
[Bug target/85665] Multiple typos in diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85665 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez --- Hi Roland, my guess is that these texts are deep within target-specific code, where target maintainers normally do not consult with other maintainers (diagnostic or otherwise) before committing changes to target-specific code and most of those maintainers are not native speakers. Since those messages are very specific, they are rarely seen by users. Given the amount of bugs in GCC, people tend to focus their efforts in other things. Most of these would require a one line change in the code and you can do such changes without any legal papers or approval by maintainers if you have write after approval status. Hence, it may be worth applying for such status, then applying the changes yourself: https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps The first time, it may require a bit of effort to setup subversion/git and you may need to submit a patch to get write after approval, but it should be trivial from there onwards.
[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-07 CC||pinskia at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- .
[Bug middle-end/78947] sub-optimal code for (bool)(int ? int : int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78947 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Severity|normal |enhancement
[Bug middle-end/85559] [meta-bug] Improve conditional move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85559 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-07 CC||pinskia at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- .
[Bug jit/66627] [meta-bug] Tracker bug for jit bugs affecting ravi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66627 David Malcolm changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from David Malcolm --- Looks like Ravi deleted the libgccjit backend: https://github.com/dibyendumajumdar/ravi/issues/142 Closing this one out.
[Bug c++/85680] Missed optimization for value-init of variable-sized allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85680 --- Comment #3 from Mathias Stearn --- MSVC and ICC both also handle this poorly: https://godbolt.org/g/i4wMYa https://developercommunity.visualstudio.com/content/problem/246786/poor-codegen-for-value-init-followed-by-explicit-i.html
[Bug target/58801] 4.7.2 alpha-dec-vms fails to link java front end due to language independent incpath.c:target_c_incpath referencing lanuage dependent vms.c:vms_c_register_includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58801 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Eric Gallager --- (In reply to Jay from comment #0) > This is likely fixed in versions. > Recording here for either posterity, or to fix in 4.7.newer, or for > people searching the bug database, though anyone trying this target > will probably have any problems and know how to figure this out. > > > Oh, drat, there is 4.7.3. I can check it. All gcc 4 branches are closed, and java has been removed. Closing.
[Bug target/85683] [8/9 Regression] GCC 8 stopped using RMW (Read Modify Write) instructions on x86[_64]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85683
--- Comment #4 from Jakub Jelinek ---
This seems to work.
--- gcc/config/i386/i386.md.jj 2018-05-02 23:55:44.0 +0200
+++ gcc/config/i386/i386.md 2018-05-07 22:27:18.848705146 +0200
@@ -19285,6 +19285,40 @@
const0_rtx);
})
+;; Likewise for cmpelim optimized pattern.
+(define_peephole2
+ [(set (match_operand:SWI 0 "register_operand")
+ (match_operand:SWI 1 "memory_operand"))
+ (parallel [(set (reg FLAGS_REG)
+ (compare (match_operator:SWI 3 "plusminuslogic_operator"
+ [(match_dup 0)
+ (match_operand:SWI 2 "")])
+ (const_int 0)))
+ (set (match_dup 0) (match_dup 3))])
+ (set (match_dup 1) (match_dup 0))]
+ "(TARGET_READ_MODIFY_WRITE || optimize_insn_for_size_p ())
+ && peep2_reg_dead_p (3, operands[0])
+ && !reg_overlap_mentioned_p (operands[0], operands[1])
+ && !reg_overlap_mentioned_p (operands[0], operands[2])
+ && (mode != QImode
+ || immediate_operand (operands[2], QImode)
+ || any_QIreg_operand (operands[2], QImode))
+ && ix86_match_ccmode (peep2_next_insn (1),
+(GET_CODE (operands[3]) == PLUS
+ || GET_CODE (operands[3]) == MINUS)
+? CCGOCmode : CCNOmode)"
+ [(parallel [(set (match_dup 4) (match_dup 6))
+ (set (match_dup 1) (match_dup 5))])]
+{
+ operands[4] = SET_DEST (XVECEXP (PATTERN (peep2_next_insn (1)), 0, 0));
+ operands[5]
+= gen_rtx_fmt_ee (GET_CODE (operands[3]), GET_MODE (operands[3]),
+ copy_rtx (operands[1]), operands[2]);
+ operands[6]
+= gen_rtx_COMPARE (GET_MODE (operands[4]), copy_rtx (operands[5]),
+ const0_rtx);
+})
+
;; Likewise for instances where we have a lea pattern.
(define_peephole2
[(set (match_operand:SWI 0 "register_operand")
[Bug fortran/85675] parameters from other modules in openmp default(none) not specified in enclosing 'parallel'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85675 --- Comment #2 from Harald Anlauf --- Running under the debugger (separate file 2 only): Breakpoint 1, gfc_omp_predetermined_sharing (decl=0xb7c100fc) at ../../trunk/gcc/fortran/trans-openmp.c:152 152 if (VAR_P (decl) && TREE_READONLY (decl) && TREE_STATIC (decl)) (gdb) p decl->base.readonly_flag $10 = 1 (gdb) p decl->base.static_flag $11 = 0 Running on the whole file: (gdb) p decl->base.static_flag $16 = 1
[Bug middle-end/54664] expand_gimple_cond warning for predictably small BRANCH_COST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54664 Eric Gallager changed: What|Removed |Added Keywords||build CC||egallager at gcc dot gnu.org Known to fail|4.10.0 |5.0 --- Comment #2 from Eric Gallager --- (In reply to Hans-Peter Nilsson from comment #1) > Also seen for 4.9.1 and 4.10.0 i.e. trunk r212879. 4.10.0 became 5.0
[Bug fortran/85685] [7/8/9 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85685 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||6.4.0 Keywords||ice-on-valid-code Last reconfirmed||2018-05-07 CC||vehre at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |7.4 Known to fail||7.3.0, 8.1.0, 9.0 --- Comment #1 from Dominique d'Humieres --- The assert has been introduced by revision r243021.
[Bug target/55143] vms-c.o:(.toc+0x0): undefined reference to `c_default_pointer_mode' (building cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55143 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from Eric Gallager --- (In reply to Bernhard Reutner-Fischer from comment #5) > Fixed on the trunk for 5.0. > > Eventual backport including beef-up of the impl is left to the port > maintainers. No previous branches are open for backports so this is fixed for all open branches.
[Bug target/47093] [meta-bug]: broken configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47093 Bug 47093 depends on bug 55143, which changed state. Bug 55143 Summary: vms-c.o:(.toc+0x0): undefined reference to `c_default_pointer_mode' (building cc1plus) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55143 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/47093] [meta-bug]: broken configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47093 Bug 47093 depends on bug 48904, which changed state. Bug 48904 Summary: x86_64-knetbsd-gnu fails to build https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48904 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/48904] x86_64-knetbsd-gnu fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48904 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Eric Gallager --- (In reply to Bernhard Reutner-Fischer from comment #5) > Fixed on the trunk. If trunk was 6 at the time, then this bug is fixed overall, since no older branches are still open.
[Bug other/25914] strsignal.c:558: warning: comparison between signed and unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25914 --- Comment #7 from dave.anglin at bell dot net --- On 2018-05-07 4:05 PM, egallager at gcc dot gnu.org wrote: > Did this proposal ever happen? Yes: http://pubs.opengroup.org/onlinepubs/9699919799/functions/psignal.html
[Bug target/47098] i686-openbsd3.0: OBSD_LIB_SPEC missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47098 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Eric Gallager --- (In reply to Bernhard Reutner-Fischer from comment #4) > Fixed on the trunk. If trunk was 6 at the time, then this bug is fixed overall, since no older branches are still open.
[Bug fortran/85675] parameters from other modules in openmp default(none) not specified in enclosing 'parallel'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85675 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #1 from Harald Anlauf --- The module file c.mod is the same when compiling the units separately or in one file. Probably some internal information is not dumped to the module file or not properly restored when reading the module.
[Bug target/47093] [meta-bug]: broken configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47093 Bug 47093 depends on bug 47098, which changed state. Bug 47098 Summary: i686-openbsd3.0: OBSD_LIB_SPEC missing https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47098 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug bootstrap/44756] [meta-bug] --enable-werror-always issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44756 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Alias||enable-werror-always --- Comment #10 from Eric Gallager --- alias enable-werror-always
[Bug target/49656] internal compiler error on Mac OS 10.7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49656 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from Eric Gallager --- (In reply to andreas from comment #3) > I just compiled GCC 4.6.1 again without clang after I found out how to do > that. > > By defining > CC = /usr/bin/gcc-4.2 > CPP = /usr/bin/cpp-4.2 > CXX = /usr/bin/g++-4.2 > LD = /usr/bin/gcc-4.2 > before the configure step the Apple GCC is used for compilation. > > If you don't do that, clang will be used on Mac OS with XCode >4 and this > leads to this "internal compiler error". > So, it doesn't seem to be a GCC issue. OK, so closing then.
[Bug target/37759] powerpc option -mabi=no-spe still generates SPE instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37759 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- Is this still relevant now that powerpc and powerpcspe have been split into separate targets?
[Bug other/25914] strsignal.c:558: warning: comparison between signed and unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25914 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to John David Anglin from comment #5) > The libiberty version is documented as unsigned and has been this > way for many years. The Open Group has a strawman proposal which may > be submitted to the Austin Group for addition to POSIX in its next > release. It uses a signed int. Did this proposal ever happen?
[Bug bootstrap/32815] crtstuff.c,warning, will always evaluate as 'true'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32815 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #7 from Eric Gallager --- (In reply to littlestar from comment #5) > (In reply to comment #3) > > > It's known that -O2 contain "-fstrict-aliasing" which has bugs since gcc > > > 3.X. > > Huh? > > from 4.2.1 status report. > PR 32182 -fstrict-aliasing ... > PR 32327 Incorrect stack sharing... > PR 32328 -fstrict-aliasing ... > > ... These are all closed now.
[Bug c++/85689] New: if constexpr compiles false branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85689
Bug ID: 85689
Summary: if constexpr compiles false branch
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msharov at users dot sourceforge.net
Target Milestone: ---
int main (void)
{
if constexpr (false)
static_assert (false, "this should not be compiled");
return 0;
}
g++ 8.1 fails compiling the branch with the static_assert even though if
constexpr condition is false. May be the same as #85149, but still present in
g++ 8.1.0 on Arch.
[Bug target/85683] [8/9 Regression] GCC 8 stopped using RMW (Read Modify Write) instructions on x86[_64]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85683 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I'll handle this.
[Bug c++/85688] Unhelpful fix-it hint for __float128 when using -mno-float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85688
--- Comment #1 from Jonathan Wakely ---
If this is accepted as a bug then I'll create a similar one for the C front
end:
gcc -c -x c - -mno-float128 <<< 'void f() { __float128 f = 0.0; }'
: In function ‘f’:
:1:12: error: unknown type name ‘__float128’; did you mean ‘_Float128’?
[Bug c++/85688] New: Unhelpful fix-it hint for __float128 when using -mno-float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85688
Bug ID: 85688
Summary: Unhelpful fix-it hint for __float128 when using
-mno-float128
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
g++ -c -x c++ - -mno-float128 <<< 'void f() { __float128 f = 0.0; }'
: In function ‘void f()’:
:1:12: error: ‘__float128’ was not declared in this scope
:1:12: note: suggested alternative: ‘__ieee128’
It might be better to say that __float128 support has been disabled by the
-mno-float128 option, or is not supported for this target and set of options.
[Bug target/85683] [8/9 Regression] GCC 8 stopped using RMW (Read Modify Write) instructions on x86[_64]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85683 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |8.2 Summary|[8 Regression] GCC 8|[8/9 Regression] GCC 8 |stopped using RMW (Read |stopped using RMW (Read |Modify Write) instructions |Modify Write) instructions |on x86[_64] |on x86[_64] --- Comment #2 from Jakub Jelinek --- Started with r247992.
[Bug target/85593] [6,7,8,9 Regression] GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Known to work||4.6.4 Summary|[5,6,7,8 Regression] GCC on |[6,7,8,9 Regression] GCC on |ARM allocates R3 for local |ARM allocates R3 for local |variable when calling naked |variable when calling naked |function with O2|function with O2 |optimizations enabled |optimizations enabled Known to fail||5.4.1 --- Comment #6 from Eric Gallager --- gcc 5 branch is closed; retitling
[Bug c/82922] Request: add -Wstrict-prototypes to -Wextra as K&R style is obsolescent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82922 Eric Gallager changed: What|Removed |Added CC||david at westcontrol dot com --- Comment #5 from Eric Gallager --- *** Bug 85676 has been marked as a duplicate of this bug. ***
[Bug c/85676] Obsolete function declarations should have warnings by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85676 Eric Gallager changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Eric Gallager --- Dup of bug 82922 *** This bug has been marked as a duplicate of bug 82922 ***
[Bug libstdc++/85672] [9 Regression] error: redefinition of 'constexpr long double std::abs(long double)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85672 --- Comment #10 from Jonathan Wakely --- Created attachment 44083 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44083&action=edit Restore previous behaviour of #undef _GLIBCXX_USE_FLOAT128 based on configure checks. This still follows the same approach of custom logic instead of autogenerated macros, but restores the old behaviour when support is absent during configuration.
[Bug c++/85618] [8/9 Regression] Zero initialized non constant stack array causes internal compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85618 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/85618] [8/9 Regression] Zero initialized non constant stack array causes internal compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85618 --- Comment #4 from Jason Merrill --- Author: jason Date: Mon May 7 19:34:59 2018 New Revision: 260013 URL: https://gcc.gnu.org/viewcvs?rev=260013&root=gcc&view=rev Log: PR c++/85618 - ICE with initialized VLA. * tree.c (vla_type_p): New. * typeck2.c (store_init_value, split_nonconstant_init_1): Check it rather than array_of_runtime_bound_p. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/ext/vla20.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/cp-tree.h branches/gcc-8-branch/gcc/cp/tree.c branches/gcc-8-branch/gcc/cp/typeck2.c
[Bug tree-optimization/71769] Invalid warning from -Wunsafe-loop-optimizations for a finite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71769 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #7 from Eric Gallager --- (In reply to amker from comment #6) > (In reply to nightstrike from comment #5) > > Could you backport to the branches? > > Well, that's release manager's call. Richard? Guess not...
[Bug c++/85618] [8/9 Regression] Zero initialized non constant stack array causes internal compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85618 --- Comment #3 from Jason Merrill --- Author: jason Date: Mon May 7 19:22:35 2018 New Revision: 260012 URL: https://gcc.gnu.org/viewcvs?rev=260012&root=gcc&view=rev Log: PR c++/85618 - ICE with initialized VLA. * tree.c (vla_type_p): New. * typeck2.c (store_init_value, split_nonconstant_init_1): Check it rather than array_of_runtime_bound_p. Added: trunk/gcc/testsuite/g++.dg/ext/vla20.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/tree.c trunk/gcc/cp/typeck2.c
[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80506 --- Comment #12 from emsr at gcc dot gnu.org --- Yes, all other stuff is rolled back except for this patch.
[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80506 --- Comment #11 from emsr at gcc dot gnu.org --- Yes, I had an ugly morning with svn. Hopefully the bits are rolled back. That chunk is 83140. Ed.
[Bug libstdc++/85672] [9 Regression] error: redefinition of 'constexpr long double std::abs(long double)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85672 --- Comment #9 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #8) > The new logic [...] comes before the automatically added parts. And obviously you can't #undef something that hasn't been defined yet.
[Bug libstdc++/85672] [9 Regression] error: redefinition of 'constexpr long double std::abs(long double)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85672 Jonathan Wakely changed: What|Removed |Added Keywords||build Known to work||8.1.0 Target Milestone|--- |9.0 Known to fail||9.0
[Bug libstdc++/85672] [9 Regression] error: redefinition of 'constexpr long double std::abs(long double)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85672 --- Comment #8 from Jonathan Wakely --- (In reply to Marc Glisse from comment #7) > Yes, or maybe don't generate #define _GLIBCXX_USE_FLOAT128 0 but instead /* > #undef _GLIBCXX_USE_FLOAT128 */ as we used to do and as the rest of the > c++config.h file does. All of those are auto-generated. The custom logic for the float128 macro isn't auto-generated. > Actually, I am not sure why r259813 needed to change > so many things... Because changing /* #undef _GLIBCXX_USE_FLOAT128 */ to a #define was done by autoconf, and that gets automatically added at the end of the c++config file after any manual alterations. The new logic that does: #if defined(__FLOAT128__) || defined(__SIZEOF_FLOAT128__) #undef _GLIBCXX_USE_FLOAT128 #endif comes before the automatically added parts. My autotools-fu is too weak to come up with anything better but I'd be very happy if you can suggest something cleaner.
[Bug target/85323] SSE/AVX/AVX512 shift by 0 not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85323 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 44082 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44082&action=edit gcc9-pr85323.patch Untested WIP patch. Still need to add testsuite coverage for the case when both first and second arguments are constant.
[Bug c++/85680] Missed optimization for value-init of variable-sized allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85680 --- Comment #2 from Mathias Stearn --- FYI, I don't think this is a signed/unsigned thing since it also repros with unsigned long https://godbolt.org/g/LTmrpi My initial repo actually used size_t, but I (incorrectly) changed it to long rather than unsigned long based on past experience that compiler authors prefer repros that don't have any #includes and the (IMO) sad fact that size_t still isn't actually part of the language.
[Bug libstdc++/85671] Lack of `std::move()` inside `operator/` for `std::filesystem::path`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85671 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #4 from Jonathan Wakely --- (In reply to Liu Hao from comment #2) > There is no difference in implementation as long as NRVO is in effect. There is a difference. Using move(path(__lhs) /= __rhs) has one copy construction and one non-elided move construction. What I've committed to trunk has a copy construction and an elided move construction.
[Bug fortran/85687] New: ICE in gfc_sym_identifier, at fortran/trans-decl.c:351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85687 Bug ID: 85687 Summary: ICE in gfc_sym_identifier, at fortran/trans-decl.c:351 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Feeding F2018 intrinsic function RANK with an illegal argument (t is not a constant or variable) is silently accepted with -std=f2018, but gives an ICE with -std=f2008 or older. $ cat z1.f90 program p type t end type print *, rank(t) end $ cat z2.f90 program p type t integer :: n end type print *, rank(t) end $ gfortran-9-20180506 -c z1.f90 -std=f2018 $ $ gfortran-9-20180506 -c z1.f90 -std=f2008 z1.f90:2:0: type t internal compiler error: Segmentation fault 0xb9e99f crash_signal ../../gcc/toplev.c:325 0x766aa0 gfc_sym_identifier ../../gcc/fortran/trans-decl.c:351 0x767993 build_function_decl ../../gcc/fortran/trans-decl.c:2274 0x76eca3 gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1695 0x781e7f gfc_conv_variable ../../gcc/fortran/trans-expr.c:2554 0x77eb62 gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:7930 0x7853be gfc_conv_expr_reference(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8030 0x77a8c0 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.c:5273 0x77e5fc gfc_conv_function_expr ../../gcc/fortran/trans-expr.c:6812 0x77eb42 gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:7922 0x785268 gfc_conv_expr_reference(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8057 0x7a5396 gfc_trans_transfer(gfc_code*) ../../gcc/fortran/trans-io.c:2585 0x74ae97 trans_code ../../gcc/fortran/trans.c:2044 0x7a2e47 build_dt ../../gcc/fortran/trans-io.c:2027 0x74aeb7 trans_code ../../gcc/fortran/trans.c:2016 0x772499 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6507 0x7015e0 translate_all_program_units ../../gcc/fortran/parse.c:6121 0x7015e0 gfc_parse_file() ../../gcc/fortran/parse.c:6324 0x74832f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/85686] New: [8/9 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85686 Bug ID: 85686 Summary: [8/9 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed around 20180218, affects versions 8/9 : $ cat z1.f90 subroutine s(x) character(*) :: x(:) associate (y => 'a'//x) print *, y end associate end $ gfortran-7 -c z1.f90 $ $ gfortran-9-20180506 -c z1.f90 z1.f90:4:0: print *, y internal compiler error: Segmentation fault 0xb9e99f crash_signal ../../gcc/toplev.c:325 0x75333b gfc_conv_scalarized_array_ref ../../gcc/fortran/trans-array.c:3385 0x754049 gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*) ../../gcc/fortran/trans-array.c:3540 0x781e3d gfc_conv_variable ../../gcc/fortran/trans-expr.c:2737 0x77eb62 gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:7930 0x7826c9 gfc_conv_string_length(gfc_charlen*, gfc_expr*, stmtblock_t*) ../../gcc/fortran/trans-expr.c:2242 0x74ef56 get_array_charlen ../../gcc/fortran/trans-array.c:6890 0x74efb4 get_array_charlen ../../gcc/fortran/trans-array.c:6833 0x75cde6 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-array.c:7190 0x7b158f trans_associate_var ../../gcc/fortran/trans-stmt.c:1703 0x7b8721 gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.c:2065 0x74afa7 trans_code ../../gcc/fortran/trans.c:1924 0x772499 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6507 0x7015e0 translate_all_program_units ../../gcc/fortran/parse.c:6121 0x7015e0 gfc_parse_file() ../../gcc/fortran/parse.c:6324 0x74832f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/85685] New: [7/8/9 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85685 Bug ID: 85685 Summary: [7/8/9 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions 7/8/9, if source contains an unused class variable. Compiles without that line "... unused". $ cat z1.f90 program p type t integer, pointer :: z end type class(t), allocatable :: unused contains subroutine s(x) type(t) :: x[*] if ( associated(x%z) ) deallocate(x%z) end end $ gfortran-6 -c z1.f90 -fcoarray=lib $ $ gfortran-9-20180506 -c z1.f90 -fcoarray=single $ gfortran-9-20180506 -c z1.f90 -fcoarray=lib z1.f90:9:0: if ( associated(x%z) ) deallocate(x%z) internal compiler error: in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598 0x74e610 gfc_deallocate_scalar_with_status(tree_node*, tree_node*, tree_node*, bool, gfc_expr*, gfc_typespec, bool) ../../gcc/fortran/trans.c:1598 0x7bc806 gfc_trans_deallocate(gfc_code*) ../../gcc/fortran/trans-stmt.c:6943 0x74af27 trans_code ../../gcc/fortran/trans.c:2000 0x7b03f3 gfc_trans_if_1 ../../gcc/fortran/trans-stmt.c:1433 0x7b81da gfc_trans_if(gfc_code*) ../../gcc/fortran/trans-stmt.c:1464 0x74b017 trans_code ../../gcc/fortran/trans.c:1916 0x772499 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6507 0x772317 gfc_generate_contained_functions ../../gcc/fortran/trans-decl.c:5519 0x772317 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6436 0x7015e0 translate_all_program_units ../../gcc/fortran/parse.c:6121 0x7015e0 gfc_parse_file() ../../gcc/fortran/parse.c:6324 0x74832f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80506 --- Comment #10 from Jonathan Wakely --- (In reply to emsr from comment #5) > Author: emsr > Date: Mon May 7 15:55:11 2018 > New Revision: 260001 > > URL: https://gcc.gnu.org/viewcvs?rev=260001&root=gcc&view=rev > Log: > 2018-05-07 Edward Smith-Rowland <3dw...@verizon.net> > > Moar PR libstdc++/80506 > * include/bits/random.tcc (gamma_distribution::__generate_impl()): > Fix magic number used in loop condition. > > > Removed: > > trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/ > 02_assoc_legendre/check_value.cc > Modified: > trunk/libstdc++-v3/ChangeLog > trunk/libstdc++-v3/include/tr1/legendre_function.tcc > > trunk/libstdc++-v3/testsuite/special_functions/02_assoc_legendre/check_value. > cc This commit seems to be something unrelated, was it committed by mistake?
[Bug libstdc++/85671] Lack of `std::move()` inside `operator/` for `std::filesystem::path`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85671 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Mon May 7 17:26:28 2018 New Revision: 260009 URL: https://gcc.gnu.org/viewcvs?rev=260009&root=gcc&view=rev Log: PR libstdc++/85671 allow copy elision in path concatenation By performing the /= operation on a named local variable instead of a temporary the copy made for the return value can be elided. PR libstdc++/85671 * include/bits/fs_path.h (operator/): Permit copy elision. * include/experimental/bits/fs_path.h (operator/): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/fs_path.h trunk/libstdc++-v3/include/experimental/bits/fs_path.h
[Bug c++/85680] Missed optimization for value-init of variable-sized allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85680 --- Comment #1 from Marc Glisse --- Quite impressive how we do the test in multiple ways, which are not quite equivalent because of the wrapping semantics of unsigned. Maybe if we asserted that the argument of operator new must be less than the size of the address space / 2 after the call... Probably easier to tweak the C++ FE so it generates more consistent comparisons (this would only remove 1 test). [local count: 118111601]: n.0_11 = (sizetype) n_10(D); _14 = operator new [] (n.0_11); _1 = n.0_11 + 18446744073709551615; _15 = (long int) _1; if (_15 < 0) goto ; [11.00%] else goto ; [89.00%] [local count: 118111600]: if (n_10(D) <= 0) goto ; [11.00%] else goto ; [89.00%] [local count: 105119325]: _31 = n.0_11 + 18446744073709551614; _26 = (long int) _31; _22 = _26 >= -1 ? n.0_11 : 1; __builtin_memset (_14, 0, _22); goto ; [11.00%] [local count: 105119324]: __builtin_memset (_14, 255, n.0_11); [local count: 118111600]: return _14;
[Bug bootstrap/85681] r259995 breaks bootstrap on x86_64-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from kargl at gcc dot gnu.org --- (In reply to Luis Machado from comment #4) > Reverted the offending changes for now. Reverting your patch fixes bootstrap, so closing. Thanks for quick response.
[Bug bootstrap/85681] r259995 breaks bootstrap on x86_64-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681 --- Comment #7 from Steve Kargl --- On Mon, May 07, 2018 at 05:01:59PM +, luis.machado at linaro dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681 > > --- Comment #6 from Luis Machado --- > Would you please confirm the bootstrap is back to normal and declare it > resolved? I don't have permission to change its state. > With r259995 reverted, gcc completes bootstrap. Is this the info you want?
[Bug bootstrap/85681] r259995 breaks bootstrap on x86_64-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681 --- Comment #6 from Luis Machado --- Would you please confirm the bootstrap is back to normal and declare it resolved? I don't have permission to change its state.
[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80506 --- Comment #9 from emsr at gcc dot gnu.org --- Author: emsr Date: Mon May 7 16:59:08 2018 New Revision: 260008 URL: https://gcc.gnu.org/viewcvs?rev=260008&root=gcc&view=rev Log: 2018-05-07 Edward Smith-Rowland <3dw...@verizon.net> Moar PR libstdc++/80506 * include/bits/random.tcc (gamma_distribution::__generate_impl()): Fix magic number used in loop condition. Actually put the file in. Don't know what my problem is today... Modified: trunk/libstdc++-v3/include/bits/random.tcc
[Bug target/85616] ARM target using -O2 may cause unaligned access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85616 --- Comment #4 from Denis Roux --- I agree that the given example code is breaking the C strict aliasing rule. However, I do not believe that the issue I'm reporting is related to aliasing. Further more, adding -fno-strict-aliasing option do not alter the output. The issue I'm having with the optimized code is that it got optimized from 2 store instructions that do not have alignment restriction into 1 multi-store instruction the does have alignment restriction. I would have expected that the optimization would have occurred only if the alignment was guaranteed to be respected.
[Bug target/85683] [8 Regression] GCC 8 stopped using RMW (Read Modify Write) instructions on x86[_64]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85683
Alexander Monakov changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-05-07
CC||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexander Monakov ---
Smaller testcase:
void f(void);
void g(int *p)
{
if (!--*p)
f();
}
On gcc-7.3 this is optimized by the peephole2 pass so it doesn't really help
with register pressure (combine pass seems more suitable for that); don't know
why the peephole doesn't trigger on gcc-8.
[Bug c++/85646] [7/8/9 Regression] Incorrect lambda visibility with -fvisibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85646 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/85684] New: output of instrinsic _xgetbv is wrongly overwritten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85684
Bug ID: 85684
Summary: output of instrinsic _xgetbv is wrongly overwritten
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gregory.hainaut at gmail dot com
Target Milestone: ---
Hello,
GCC8.0 adds the long long _xgetbv(unsigned int), however the output isn't taken
into account. xgetbv should return values in rdx:rax (edx:eax in 32 bits).
The following code snippet
#include
#include
int main()
{
if ((_xgetbv(0) & 6) == 6)
printf("Yes\n");
else
printf("No\n");
return 0;
}
will compile as (g++ -mavx2), xgetbv in O0 build
...
xgetbv
movq %rsi, %rax
andl $6, %eax
cmpq $6, %rax
sete %al
testb %al, %al
je .L2
...
Note: the full code is optimized in -O1 as only 2 instructions !
main:
movl $0, %ecx
xgetbv
Best regards
[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80506 --- Comment #8 from emsr at gcc dot gnu.org --- Author: emsr Date: Mon May 7 16:23:29 2018 New Revision: 260006 URL: https://gcc.gnu.org/viewcvs?rev=260006&root=gcc&view=rev Log: 2018-05-07 Edward Smith-Rowland <3dw...@verizon.net> Jonathan Wakely Backport from mainline 2018-05-07 Edward Smith-Rowland <3dw...@verizon.net> PR libstdc++/80506 * include/bits/random.tcc (gamma_distribution::operator()): Fix magic number used in loop condition. (gamma_distribution::__generate_impl()): Ditto. Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/include/bits/random.tcc
[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80506 --- Comment #7 from emsr at gcc dot gnu.org --- Author: emsr Date: Mon May 7 16:19:34 2018 New Revision: 260005 URL: https://gcc.gnu.org/viewcvs?rev=260005&root=gcc&view=rev Log: 2018-05-07 Edward Smith-Rowland <3dw...@verizon.net> Backport from mainline 2018-05-07 Edward Smith-Rowland <3dw...@verizon.net> Moar PR libstdc++/80506 * include/bits/random.tcc (gamma_distribution::__generate_impl()): Fix magic number used in loop condition. Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/include/bits/random.tcc
[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80506 --- Comment #6 from emsr at gcc dot gnu.org --- Author: emsr Date: Mon May 7 16:17:32 2018 New Revision: 260004 URL: https://gcc.gnu.org/viewcvs?rev=260004&root=gcc&view=rev Log: 2018-05-07 Edward Smith-Rowland <3dw...@verizon.net> Moar PR libstdc++/80506 * include/bits/random.tcc (gamma_distribution::__generate_impl()): Fix magic number used in loop condition. Modified: trunk/libstdc++-v3/ChangeLog
[Bug c++/85618] [8/9 Regression] Zero initialized non constant stack array causes internal compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85618 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/85683] New: [8 Regression] GCC 8 stopped using RMW (Read Modify Write) instructions on x86[_64]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85683
Bug ID: 85683
Summary: [8 Regression] GCC 8 stopped using RMW (Read Modify
Write) instructions on x86[_64]
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dmitry at zend dot com
Target Milestone: ---
GCC 8 stopped generation of RMW instructions and uses 3 instructions instead of
one. Although, this shouldn't affect executed uops, this increases code size
(pressure to instruction decoder and instruction cache) and requires an extra
register (that may cause extra spills and related degradations).
=== test_rmw.c ===
typedef struct _refcounted {
unsigned int refcount;
} refcounted;
typedef struct _value {
refcounted *val;
} value;
extern void value_dtor_func(refcounted *val);
void ptr_dtor(value *ptr)
{
refcounted *ref = ptr->val;
--ref->refcount;
if (ref->refcount == 0) {
value_dtor_func(ref);
}
}
===
$ gcc -O2 -S test_rmw.c
$ cat test_rmw.s
movq(%rdi), %rdi
movl(%rdi), %eax
subl$1, %eax
movl%eax, (%rdi)
je .L4
ret
.L4:
jmp value_dtor_func
[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80506 --- Comment #5 from emsr at gcc dot gnu.org --- Author: emsr Date: Mon May 7 15:55:11 2018 New Revision: 260001 URL: https://gcc.gnu.org/viewcvs?rev=260001&root=gcc&view=rev Log: 2018-05-07 Edward Smith-Rowland <3dw...@verizon.net> Moar PR libstdc++/80506 * include/bits/random.tcc (gamma_distribution::__generate_impl()): Fix magic number used in loop condition. Removed: trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/02_assoc_legendre/check_value.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/tr1/legendre_function.tcc trunk/libstdc++-v3/testsuite/special_functions/02_assoc_legendre/check_value.cc
[Bug middle-end/85682] Regression: gcc.dg/tree-ssa/prefetch-5.c at r259995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85682 --- Comment #1 from Luis Machado --- Will do. I've temporarily reverted the prefetcher changes since it caused x86 bootstrap issues. I'll investigate this alongside it.
[Bug bootstrap/85681] r259995 breaks bootstrap on x86_64-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681 --- Comment #5 from luisgpm at gcc dot gnu.org --- Author: luisgpm Date: Mon May 7 15:47:14 2018 New Revision: 26 URL: https://gcc.gnu.org/viewcvs?rev=26&root=gcc&view=rev Log: 2018-05-07 Luis Machado PR bootstrap/85681 Revert: 2018-05-07 Luis Machado * config/aarch64/aarch64-protos.h (cpu_prefetch_tune) : New const bool field. * config/aarch64/aarch64.c (generic_prefetch_tune): Update to include prefetch_dynamic_strides. (exynosm1_prefetch_tune): Likewise. (thunderxt88_prefetch_tune): Likewise. (thunderx_prefetch_tune): Likewise. (thunderx2t99_prefetch_tune): Likewise. (qdf24xx_prefetch_tune): Likewise. Set prefetch_dynamic_strides to false. (aarch64_override_options_internal): Update to set PARAM_PREFETCH_DYNAMIC_STRIDES. * doc/invoke.texi (prefetch-dynamic-strides): Document new option. * params.def (PARAM_PREFETCH_DYNAMIC_STRIDES): New. * params.h (PARAM_PREFETCH_DYNAMIC_STRIDES): Define. * tree-ssa-loop-prefetch.c (should_issue_prefetch_p): Account for prefetch-dynamic-strides setting. 2018-05-07 Luis Machado * config/aarch64/aarch64-protos.h (cpu_prefetch_tune) : New const int field. * config/aarch64/aarch64.c (generic_prefetch_tune): Update to include minimum_stride field. (exynosm1_prefetch_tune): Likewise. (thunderxt88_prefetch_tune): Likewise. (thunderx_prefetch_tune): Likewise. (thunderx2t99_prefetch_tune): Likewise. (qdf24xx_prefetch_tune): Likewise. Set minimum_stride to 2048. (aarch64_override_options_internal): Update to set PARAM_PREFETCH_MINIMUM_STRIDE. * doc/invoke.texi (prefetch-minimum-stride): Document new option. * params.def (PARAM_PREFETCH_MINIMUM_STRIDE): New. * params.h (PARAM_PREFETCH_MINIMUM_STRIDE): Define. * tree-ssa-loop-prefetch.c (should_issue_prefetch_p): Return false if stride is constant and is below the minimum stride threshold. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-protos.h trunk/gcc/config/aarch64/aarch64.c trunk/gcc/doc/invoke.texi trunk/gcc/params.def trunk/gcc/params.h trunk/gcc/tree-ssa-loop-prefetch.c
[Bug bootstrap/85681] r259995 breaks bootstrap on x86_64-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681 --- Comment #4 from Luis Machado --- Reverted the offending changes for now.
[Bug middle-end/85682] New: Regression: gcc.dg/tree-ssa/prefetch-5.c at r259995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85682 Bug ID: 85682 Summary: Regression: gcc.dg/tree-ssa/prefetch-5.c at r259995 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: luis.machado at linaro dot org Reporter: jgreenhalgh at gcc dot gnu.org CC: hjl.tools at gmail dot com, law at redhat dot com, luis.machado at linaro dot org Target Milestone: --- Target: x86-64-none-linux-gnu Hi, our bisect robot spotted failures in gcc.dg/tree-ssa/prefetch-9.c gcc.dg/tree-ssa/prefetch-8.c gcc.dg/tree-ssa/prefetch-7.c gcc.dg/tree-ssa/prefetch-6.c gcc.dg/tree-ssa/prefetch-3.c gcc.target/i386/opt-1.c gcc.target/i386/opt-2.c gcc.dg/tree-ssa/loop-28.c gcc.dg/tree-ssa/prefetch-5.c after revision r259995 on x86-64-none-linux-gnu. Would you mind taking a look?
[Bug bootstrap/85681] r259995 breaks bootstrap on x86_64-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681 --- Comment #3 from Luis Machado --- There are a couple fixups needed in there. The second error you ran into was already caught by gcc in the first comment.
[Bug bootstrap/85681] r259995 breaks bootstrap on x86_64-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #0)
> ../../gcc/gcc/tree-ssa-loop-prefetch.c: In function 'bool
> should_issue_prefetch_p(mem_ref*)':
> ../../gcc/gcc/tree-ssa-loop-prefetch.c:1010:54: error: comparison of integer
> expressions of different signedness: 'long unsigned int' and 'int'
> [-Werror=sign-compare]
>&& absu_hwi (int_cst_value (ref->group->step)) <
> PREFETCH_MINIMUM_STRIDE)
> ../../gcc/gcc/tree-ssa-loop-prefetch.c:1014:4: error: format '%d' expects
> argument of type 'int', but argument 5 has type 'long int' [-Werror=format=]
> "Step for reference %u:%u (%d) is less than the mininum "
> ^
> "required stride of %d\n",
> ~
> ref->group->uid, ref->uid, int_cst_value (ref->group->step),
>
> cc1plus: all warnings being treated as errors
> gmake[3]: *** [Makefile:1110: tree-ssa-loop-prefetch.o] Error 1
> gmake[3]: Leaving directory '/safe/sgk/gcc/obj/gcc'
> gmake[2]: *** [Makefile:4662: all-stage2-gcc] Error 2
> gmake[2]: Leaving directory '/safe/sgk/gcc/obj'
The obvious patch
Index: gcc/tree-ssa-loop-prefetch.c
===
--- gcc/tree-ssa-loop-prefetch.c(revision 25)
+++ gcc/tree-ssa-loop-prefetch.c(working copy)
@@ -1011,7 +1011,7 @@ should_issue_prefetch_p (struct mem_ref *ref)
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file,
-"Step for reference %u:%u (%d) is less than the mininum "
+"Step for reference %u:%u (%ld) is less than the mininum "
"required stride of %d\n",
ref->group->uid, ref->uid, int_cst_value (ref->group->step),
PREFETCH_MINIMUM_STRIDE);
allows bootstrap to get to
-MMD -MP -MF ./.deps/tree-ssa-loop-prefetch.TPo
../../gcc/gcc/tree-ssa-loop-prefetch.c
../../gcc/gcc/tree-ssa-loop-prefetch.c: In function 'bool
should_issue_prefetch_p(mem_ref*)':
../../gcc/gcc/tree-ssa-loop-prefetch.c:1010:54: error: comparison of integer
expressions of different signedness: 'long unsigned int' and 'int'
[-Werror=sign-compare]
&& absu_hwi (int_cst_value (ref->group->step)) <
PREFETCH_MINIMUM_STRIDE)
cc1plus: all warnings being treated as errors
gmake[3]: *** [Makefile:1110: tree-ssa-loop-prefetch.o] Error 1
gmake[3]: Leaving directory '/safe/sgk/gcc/obj/gcc'
gmake[2]: *** [Makefile:4662: all-stage2-gcc] Error 2
gmake[2]: Leaving directory '/safe/sgk/gcc/obj'
Please backout your patch.
[Bug bootstrap/85681] r259995 breaks bootstrap on x86_64-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681 --- Comment #1 from Luis Machado --- Working on it.
