[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777 --- Comment #15 from Eric Gallager --- (In reply to Oleg Endo from comment #14) > (In reply to Eric Gallager from comment #13) > > > > > > I've tried that test case with the sh-lra branch and the problems seem to > > > be > > > gone. > > > > So is this FIXED yet then? > > LRA is not enabled by default on SH, so I'd say no, not fixed yet. Please > leave open. OK, please remember to come back to this if/when LRA is ever the default on SH then.
[Bug bootstrap/28472] -B$(build_tooldir)/bin/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28472 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #10 from Eric Gallager --- (In reply to Eric Gallager from comment #9) > Is this still an issue with newer versions of gcc? Putting in WAITING as per > https://gcc.gnu.org/bugs/management.html No reply; closing
[Bug rtl-optimization/87507] IRA unnecessarily uses non-volatile registers during register assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87507 --- Comment #7 from Peter Bergner --- Created attachment 44778 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44778=edit Proprosed patch FYI, this is what I'm testing.
[Bug c++/56951] Poor diagnostics for error: invalid abstract return type 'XXX'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56951 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||dodji at gcc dot gnu.org --- Comment #2 from Eric Gallager --- cc-ing diagnostics maintainers
[Bug rtl-optimization/87507] IRA unnecessarily uses non-volatile registers during register assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87507 --- Comment #6 from Peter Bergner --- (In reply to Peter Bergner from comment #2) > Seems to work fine on BE, so probably a LE only issue. So this is a generic problem, not related to LE. I can get this to fail on BE as well if I strategically remove some hard regs via using -ffixed-r6 -ffixed-r9 -ffixed-r11.
[Bug rtl-optimization/87507] IRA unnecessarily uses non-volatile registers during register assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87507
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2018-10-04
CC||law at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
Component|target |rtl-optimization
Ever confirmed|0 |1
--- Comment #5 from Peter Bergner ---
The other problem is that we don't add in the cost of saving and restoring
non-volatile registers in the prologue and epilogue if HONOR_REG_ALLOC_ORDER is
set (it is for rs6000):
if (!HONOR_REG_ALLOC_ORDER)
{
if ((saved_nregs = calculate_saved_nregs (hard_regno, mode)) != 0)
/* We need to save/restore the hard register in
epilogue/prologue. Therefore we increase the cost. */
{
rclass = REGNO_REG_CLASS (hard_regno);
add_cost = ((ira_memory_move_cost[mode][rclass][0]
+ ira_memory_move_cost[mode][rclass][1])
* saved_nregs / hard_regno_nregs (hard_regno,
mode) - 1);
cost += add_cost;
full_cost += add_cost;
}
}
The code in Comment 4 is what gives reg pair r7,r8 a cost of 1000 and since we
don't charge non-volatiles for prologue/epilogue save restore, reg pair r30,r31
gets a cost of zero, so assign_hard_reg picks r30,r31 and we get the
unnecessary non-volatile reg usage we're seeing.
It seems to me that we should always incorporate the save/restore cost into
non-volatiles. However, even if we enable the code above for targets that set
HONOR_REG_ALLOC_ORDER, there is still a bug in that the additional cost it
computes above, because it doesn't take into consideration the basic block
frequency assigned to the prologue and epilogue blocks. The additional cost
above really should be multiplied by the prologue/epilogue frequency.
The above analysis means this is no longer target bug, but a bug in the cost
computation in IRA, therefore I am resetting the Component and adding Vlad and
Jeff to the CC for their awareness.
I have a patch to fix the above that I am testing.
[Bug libstdc++/87493] chrono::system_clock unusable with std::tm due to misaligned precisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87493 Vinícius dos Santos Oliveira changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Vinícius dos Santos Oliveira --- >Recall that, from POSIX, `tm.tm_year` is supposed to be a number counted from >1900. Oh, I made this mistake. `std::chrono::system_clock` precision is probably enough. Thanks. Closing.
[Bug libstdc++/63776] [C++11] Regex collate matching not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63776
--- Comment #13 from Jonathan Wakely ---
Oops, paste fail. The second one should be:
#include
#include
int main()
{
std::locale::global(std::locale("en_US.UTF-8"));
std::wstring s = L"joão méroço";
std::wregex r{L"[[:alpha:]]{4} [[:alpha:]]{6}"};
assert( regex_match(s, r) );
}
[Bug libstdc++/63776] [C++11] Regex collate matching not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63776 --- Comment #12 from Tim Shen --- I'm not sure anymore about the meaning of pinging back end (my bad), but > But this is (assuming wchar_t uses a unicode encoding): The two pieces of code looks identical to me. :)
[Bug fortran/56789] Handling of contiguous dummy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789
--- Comment #16 from paul.richard.thomas at gmail dot com ---
Hi Thomas,
I think that the copy in/copy out might be rather easy to arrange.
Give me a couple of days.
Paul
On Wed, 3 Oct 2018 at 22:01, tkoenig at gcc dot gnu.org
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789
>
> --- Comment #14 from Thomas Koenig ---
> This would reject the obvious non-contiguous cases.
>
> Index: interface.c
> ===
> --- interface.c (Revision 264540)
> +++ interface.c (Arbeitskopie)
> @@ -3297,6 +3297,14 @@ compare_actual_formal (gfc_actual_arglist **ap, gf
> return false;
> }
>
> + if (f->sym->attr.contiguous
> + && !gfc_is_simply_contiguous (a->expr, false, true))
> + {
> + gfc_error ("Non-contiguous argument actual argument passed to "
> +"contiguous dummy argument %qs at %L", f->sym->name,
> +>expr->where);
> + }
> +
>/* Find the last array_ref. */
>actual_arr_ref = NULL;
>if (a->expr->ref)
> Index: trans-array.c
> ===
> --- trans-array.c (Revision 264540)
> +++ trans-array.c (Arbeitskopie)
> @@ -7862,8 +7862,7 @@ gfc_conv_array_parameter (gfc_se * se, gfc_expr *
>gfc_prepend_expr_to_block (>post, tmp);
> }
>
> - if (g77 || (fsym && fsym->attr.contiguous
> - && !gfc_is_simply_contiguous (expr, false, true)))
> + if (g77)
> {
>tree origptr = NULL_TREE;
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
[Bug fortran/56789] Handling of contiguous dummy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789 --- Comment #15 from Thomas Koenig --- Of course, there should be a "return false;" in there as well.
[Bug fortran/56789] Handling of contiguous dummy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789
--- Comment #14 from Thomas Koenig ---
This would reject the obvious non-contiguous cases.
Index: interface.c
===
--- interface.c (Revision 264540)
+++ interface.c (Arbeitskopie)
@@ -3297,6 +3297,14 @@ compare_actual_formal (gfc_actual_arglist **ap, gf
return false;
}
+ if (f->sym->attr.contiguous
+ && !gfc_is_simply_contiguous (a->expr, false, true))
+ {
+ gfc_error ("Non-contiguous argument actual argument passed to "
+"contiguous dummy argument %qs at %L", f->sym->name,
+>expr->where);
+ }
+
/* Find the last array_ref. */
actual_arr_ref = NULL;
if (a->expr->ref)
Index: trans-array.c
===
--- trans-array.c (Revision 264540)
+++ trans-array.c (Arbeitskopie)
@@ -7862,8 +7862,7 @@ gfc_conv_array_parameter (gfc_se * se, gfc_expr *
gfc_prepend_expr_to_block (>post, tmp);
}
- if (g77 || (fsym && fsym->attr.contiguous
- && !gfc_is_simply_contiguous (expr, false, true)))
+ if (g77)
{
tree origptr = NULL_TREE;
[Bug tree-optimization/84013] wrong __restrict clique with inline asm operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84013 --- Comment #5 from Katsunori Kumatani --- Hi, any news of this for GCC 9? I'm guessing it requires a bit more changes, hopefully not forgotten though. Currently I'm using a custom patched GCC 8 for it (and to test plugin behavior with it) but it's not ideal.
[Bug middle-end/61409] [6 regression] -Wmaybe-uninitialized false-positive with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61409 --- Comment #31 from Jeffrey A. Law --- No, it's marked as a regression against gcc-6. One of two things needs to happen for this to be closed. 1. Aldy's work would have to be backported to gcc-6. or 2. gcc-6 goes out of support I don't think this bug warrants backporting patches to gcc-6. So the path forward is via #2. gcc-6 will go out of support when gcc-9 releases, which will most likely happen in the sprint 2019.
[Bug c++/87494] hidden visibility constexpr variables left unevaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87494 --- Comment #2 from Andrew Pinski --- I don't think this is techincally a bug. It might be a missed optimization but not a bug. You still need a definition even for constexpr if used outside of a constexpr usage IIRC.
[Bug c++/85963] [8/9 Regression] false positive "set but not used" warning [-Wunused-but-set-variable]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85963 Andrew Pinski changed: What|Removed |Added CC||chtz at informatik dot uni-bremen. ||de --- Comment #7 from Andrew Pinski --- *** Bug 87503 has been marked as a duplicate of this bug. ***
[Bug c++/87503] Spurious -Wunused-but-set-variable warning in template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87503 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 85963. NOTE 8.2.0 is the bug fix release of the 8. 8.1.1 is only in developmental and never was a released sources. *** This bug has been marked as a duplicate of bug 85963 ***
[Bug libstdc++/55713] std::tuple incorrectly is convertible to "ElementType" when it is an empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55713 --- Comment #5 from Jonathan Wakely --- Now that we have [[no_unique_address]] I'll make our std::tuple use it (I think I have a partial implementation in a local branch, that I couldn't compile when I started work on it). I don't plan to work on it until stage 3 though, as this is a bug and so fixing it is valid for stage 3.
[Bug target/87507] IRA unnecessarily uses non-volatile registers during register assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87507
--- Comment #4 from Peter Bergner ---
So this seems to be coming from ira-costs.c:ira_tune_allocno_costs()
/* Some targets allow pseudos to be allocated to unaligned sequences
of hard registers. However, selecting an unaligned sequence can
unnecessarily restrict later allocations. So increase the cost of
unaligned hard regs to encourage the use of aligned hard regs. */
{
const int nregs = ira_reg_class_max_nregs[aclass][ALLOCNO_MODE (a)];
if (nregs > 1)
{
ira_allocate_and_set_costs
(_HARD_REG_COSTS (a), aclass, ALLOCNO_CLASS_COST (a));
reg_costs = ALLOCNO_HARD_REG_COSTS (a);
for (j = n - 1; j >= 0; j--)
{
regno = ira_non_ordered_class_hard_regs[aclass][j];
if ((regno % nregs) != 0)
{
int index = ira_class_hard_reg_index[aclass][regno];
ira_assert (index != -1);
reg_costs[index] += ALLOCNO_FREQ (a);
}
}
}
}
...which pessimizes odd/even register pairs (like r7,r8) over even/odd register
pairs (like r30,r31), but I think odd/even volatile pairs should still be
cheaper than even/odd non-volatile pairs. So maybe something like:
COST(even/odd volatile) < COST(odd/even volatile) < COST(even/odd
non-volatile) < COST(odd/even non-volatile)
??
[Bug fortran/56789] Handling of contiguous dummy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789 Thomas Koenig changed: What|Removed |Added Keywords||diagnostic Summary|Wrong code with contiguous |Handling of contiguous |dummy argument |dummy arguments --- Comment #13 from Thomas Koenig --- So, this is a diagnostic issue after all. For the time being, it seems that we could just not do the pack/unpack and issue an error for the test case. We can handle the F2018 stuff later (whatever it turns out to be).
[Bug target/87508] unrecognized command line option '-mfloat-gprs=double'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87508 --- Comment #2 from Zachary Wilcox --- Thank you sir. I should have checked the changes.
[Bug target/87508] unrecognized command line option '-mfloat-gprs=double'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87508 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- SPE support has been removed from the standard powerpc-eabi target. If you want/need SPE support, you need to use the powerpc-eabispe target instead. See https://gcc.gnu.org/gcc-8/changes.html
[Bug target/87508] New: unrecognized command line option '-mfloat-gprs=double'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87508 Bug ID: 87508 Summary: unrecognized command line option '-mfloat-gprs=double' Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zwilcox at sandia dot gov Target Milestone: --- The following -mfloat-gprs=double gives an error saying it is an unrecognized command. ./powerpc-eabi-gcc -mfloat-gprs=double powerpc-sandia_8_1_3-eabi-gcc: error: unrecognized command line option '-mfloat-gprs=double'; did you mean '-ffloat-store'? powerpc-sandia_8_1_3-eabi-gcc: fatal error: no input files compilation terminated. Even though it is still listed in the documentation: https://gcc.gnu.org/onlinedocs/gcc/PowerPC-SPE-Options.html It is not listed --target-help even though other PowerPC SPE Options are. I've tried in both GCC 8.2 and 8.1. It does work in GCC 7.x, 5.x and 4.x.
[Bug target/87507] IRA unnecessarily uses non-volatile registers during register assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87507 --- Comment #3 from Peter Bergner --- So the register pair r7,r8 is free to assign to TImode pseudo 126 in assign_hard_reg(), but its cost is 1000, while the cost of r30,r31 somehow looks to be zero, so we choose it instead!?!? Not sure how r30,r31 incorrectly got a cost of zero.
[Bug target/86592] [9 regression] gcc.target/powerpc/p8-vec-xl-xst-v2.c fails starting with r261510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86592 Bill Schmidt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Bill Schmidt --- We have it marked fixed in our internal tracker, so yeah, fixed.
[Bug libstdc++/55713] std::tuple incorrectly is convertible to "ElementType" when it is an empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55713 Bug 55713 depends on bug 63579, which changed state. Bug 63579 Summary: New attribute for empty member optimization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63579 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/63579] New attribute for empty member optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63579 Marc Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at redhat dot com Target Milestone|--- |9.0 --- Comment #5 from Marc Glisse --- Fixed in r264813 .
[Bug c++/87506] [7/8/9 Regression] ICE with inherited constexpr constructor with const argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87506 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-03 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |7.4 Summary|ICE with inherited |[7/8/9 Regression] ICE with |constexpr constructor with |inherited constexpr |const argument |constructor with const ||argument Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- commit cbc3b89fda8752ee376db4d75f1fda708becc6a0 Author: nathan Date: Mon Nov 20 14:39:00 2017 + [PR c++/82878] pass-by-invisiref in lambda https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01115.html PR c++/82878 PR c++/78495 * call.c (build_call_a): Don't set CALL_FROM_THUNK_P for inherited ctor. * cp-gimplify.c (cp_genericize_r): Restore THUNK dereference inhibibition check removed in previous c++/78495 change. PR c++/82878 * g++.dg/cpp0x/pr82878.C: New. * g++.dg/cpp1z/inh-ctor38.C: Check moves too. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@254958 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug target/87507] IRA unnecessarily uses non-volatile registers during register assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87507 Peter Bergner changed: What|Removed |Added Target||powerpc64le-linux --- Comment #2 from Peter Bergner --- Seems to work fine on BE, so probably a LE only issue.
[Bug target/87507] IRA unnecessarily uses non-volatile registers during register assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87507 Peter Bergner changed: What|Removed |Added CC||dje at gcc dot gnu.org, ||segher at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #1 from Peter Bergner --- I'll take a look at what the problem is.
[Bug target/87507] New: IRA unnecessarily uses non-volatile registers during register assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87507
Bug ID: 87507
Summary: IRA unnecessarily uses non-volatile registers during
register assignment
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
Current trunk and GCC 7 (haven't tested anything else) unnecessarily use
non-volatile regs forcing unneeded save/restore code, along with unnecessary
reg moves. Using a different 128-bit type (ie, long double, etc.) for the
struct field types, I see the code I would expect to see.
I'm guessing this is a target issue (insn constraints?), so setting the
Component to that for now.
bergner@pike:~$ cat bug.c
typedef struct
{
__int128_t i0;
__int128_t i1;
} i2_t;
void
foo (long cond, i2_t *dst, __int128_t src)
{
if (cond)
{
dst->i0 = src;
dst->i1 = src;
}
}
bergner@pike:~$ .../xgcc -B... -O2 -S bug.c
bergner@pike:~$ cat bug2.s
.file "bug.c"
.abiversion 2
.section".text"
.align 2
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
cmpdi 7,3,0
beqlr 7
std 30,-16(1)
std 31,-8(1)
.cfi_offset 30, -16
.cfi_offset 31, -8
mr 30,6
mr 31,5
addi 9,4,16
mr 10,30
mr 11,31
std 31,0(4)
std 30,8(4)
std 11,0(9)
std 10,8(9)
ld 30,-16(1)
ld 31,-8(1)
.cfi_restore 31
.cfi_restore 30
blr
.long 0
.byte 0,0,0,0,0,2,0,0
.cfi_endproc
.LFE0:
.size foo,.-foo
.ident "GCC: (GNU) 9.0.0 20181002 (experimental) [trunk revision
264800]"
.section.note.GNU-stack,"",@progbits
[Bug c++/87506] New: ICE with inherited constexpr constructor with const argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87506
Bug ID: 87506
Summary: ICE with inherited constexpr constructor with const
argument
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.a.moran at gmail dot com
Target Milestone: ---
Created attachment 44777
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44777=edit
A reproduction of the issue described
I've attached what I believe is a minimal reproduction. It can be built with
> gcc --std=c++14 -c ice_repro.cpp
* It reproduces with g++ 8.2.0 (I've confirmed it does not occur with 7.3.0)
* It reproduces with a --std= of c++11, c++14, c++17, c++1z and c++2a
* It uses constexpr, so it fails for uninterested reasons below C++11
* No other command-line flags are needed
* And I've not found any that cause the failure not to reproduce.
* I found this on a Linux box (Ubuntu 14.04.1), but the gcc was built from
source and no headers are included in the reproduction.
The failure mode is an internal compiler error (full error message at the
bottom). Changing any of the following will cause the failure not to happen:
* If you drop the constexpr from B::B(A)
* If you change "constexpr B(const A) {}" to "constexpr B(A) {}"
* If you use a built-in type like int as the tag argument instead of the
struct A
* If you change the argument to B::B(A) to be any reference category
The full error message is:
> ice_repro.cpp: In function ‘void func()’:
> ice_repro.cpp:8:24: in ‘constexpr’ expansion of ‘obj.C::C((A{}, A()))’
> ice_repro.cpp:8:24: internal compiler error: in adjust_temp_type, at
> cp/constexpr.c:1255
> void func() { C obj(A{}); }
> ^
> 0x58c00e adjust_temp_type
> ../../gcc-8.2.0/gcc/cp/constexpr.c:1255
> 0x5ee55b cxx_bind_parameters_in_call
> ../../gcc-8.2.0/gcc/cp/constexpr.c:1330
> 0x5ee55b cxx_eval_call_expression
> ../../gcc-8.2.0/gcc/cp/constexpr.c:1602
> 0x5f08c4 cxx_eval_constant_expression
> ../../gcc-8.2.0/gcc/cp/constexpr.c:4211
> 0x5ef958 cxx_eval_constant_expression
> ../../gcc-8.2.0/gcc/cp/constexpr.c:4337
> 0x5ef958 cxx_eval_constant_expression
> ../../gcc-8.2.0/gcc/cp/constexpr.c:4337
> 0x5f01d5 cxx_eval_constant_expression
> ../../gcc-8.2.0/gcc/cp/constexpr.c:4689
> 0x5eef24 cxx_eval_call_expression
> ../../gcc-8.2.0/gcc/cp/constexpr.c:1709
> 0x5f08c4 cxx_eval_constant_expression
> ../../gcc-8.2.0/gcc/cp/constexpr.c:4211
> 0x5f39c9 cxx_eval_outermost_constant_expr
> ../../gcc-8.2.0/gcc/cp/constexpr.c:4861
> 0x5f5ad8 maybe_constant_init_1
> ../../gcc-8.2.0/gcc/cp/constexpr.c:5187
> 0x64105c expand_default_init
> ../../gcc-8.2.0/gcc/cp/init.c:1918
> 0x64105c expand_aggr_init_1
> ../../gcc-8.2.0/gcc/cp/init.c:2021
> 0x64143b build_aggr_init(tree_node*, tree_node*, int, int)
> ../../gcc-8.2.0/gcc/cp/init.c:1761
> 0x60fb07 build_aggr_init_full_exprs
> ../../gcc-8.2.0/gcc/cp/decl.c:6283
> 0x60fb07 check_initializer
> ../../gcc-8.2.0/gcc/cp/decl.c:6432
> 0x61e62b cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
> ../../gcc-8.2.0/gcc/cp/decl.c:7145
> 0x697710 cp_parser_init_declarator
> ../../gcc-8.2.0/gcc/cp/parser.c:19749
> 0x69e488 cp_parser_simple_declaration
> ../../gcc-8.2.0/gcc/cp/parser.c:13052
> 0x69f218 cp_parser_block_declaration
> ../../gcc-8.2.0/gcc/cp/parser.c:12871
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See
[Bug tree-optimization/87490] [9 Regression] ICE in expand_builtin_strnlen at gcc/builtins.c:3164
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87490 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #4 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00197.html
[Bug tree-optimization/87415] [9 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87415 --- Comment #5 from Aldy Hernandez --- Author: aldyh Date: Wed Oct 3 17:36:29 2018 New Revision: 264817 URL: https://gcc.gnu.org/viewcvs?rev=264817=gcc=rev Log: PR tree-optimization/87415 * tree-vrp.c (set_value_range_with_overflow): Special case one bit precision fields. Added: trunk/gcc/testsuite/gcc.dg/pr87415.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/87415] [9 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87415 --- Comment #4 from Aldy Hernandez --- Fixed in trunk.
[Bug libgcc/85334] Shadow stack isn't unwound properly through signal handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85334 H.J. Lu changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Target Milestone|8.0 |8.3 --- Comment #8 from H.J. Lu --- Fixed for GCC 9 and GCC 8.3
[Bug target/81652] [meta-bug] -fcf-protection=full bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 Bug 81652 depends on bug 85334, which changed state. Bug 85334 Summary: Shadow stack isn't unwound properly through signal handler https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85334 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug libgcc/85334] Shadow stack isn't unwound properly through signal handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85334 --- Comment #7 from hjl at gcc dot gnu.org --- Author: hjl Date: Wed Oct 3 16:55:06 2018 New Revision: 264814 URL: https://gcc.gnu.org/viewcvs?rev=264814=gcc=rev Log: i386: Remove _Unwind_Frames_Increment CET kernel has been changed to place a restore token on shadow stack for signal handler to enhance security. It is usually transparent to user programs since kernel will pop the restore token when signal handler returns. But when an exception is thrown from a signal handler, now we need to remove _Unwind_Frames_Increment to pop the the restore token from shadow stack. Otherwise, we get FAIL: g++.dg/torture/pr85334.C -O0 execution test FAIL: g++.dg/torture/pr85334.C -O1 execution test FAIL: g++.dg/torture/pr85334.C -O2 execution test FAIL: g++.dg/torture/pr85334.C -O3 -g execution test FAIL: g++.dg/torture/pr85334.C -Os execution test FAIL: g++.dg/torture/pr85334.C -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test Backport from mainline 2018-07-27 H.J. Lu PR libgcc/85334 * config/i386/shadow-stack-unwind.h (_Unwind_Frames_Increment): Removed. Modified: branches/gcc-8-branch/libgcc/ChangeLog branches/gcc-8-branch/libgcc/config/i386/shadow-stack-unwind.h
[Bug lto/87434] LTO corrupts code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87434 kelvin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from kelvin at gcc dot gnu.org --- I have confirmed that the cause of this problem was an error in my draft patch. Thanks for comments that helped motivate me to look deeper.
[Bug tree-optimization/87505] Vectorizer generates a lot of code for a small loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87505 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- This is because 'i' is int while 'base' is size_t. Loop init expression 'int i = base' truncates base to 32 bits, and loop condition first converts i to size_t and then compares in that unsigned type. It's not exactly obvious how many iterations this loop has :) Using the proper type for 'i' results in reasonable code. Perhaps in principle niter analysis could handle this anyway?
[Bug tree-optimization/87505] New: Vectorizer generates a lot of code for a small loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87505
Bug ID: 87505
Summary: Vectorizer generates a lot of code for a small loop
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
test.cpp
#include
int bar(int* v, std::size_t base) {
int sum = 0;
for (int i = base; i < base + 4; ++i) {
sum += v[i];
}
return sum;
}
$ gcc-8.2 -std=c++17 -O3 -DNDEBUG test.cpp
bar(int*, unsigned long):
movslq %esi, %rcx
leaq4(%rsi), %r8
movl%esi, %edx
cmpq%r8, %rcx
jnb .L7
leaq3(%rsi), %rax
movq%r8, %r9
subq%rcx, %rax
subq%rcx, %r9
cmpq$3, %rax
jbe .L8
movq%r9, %rdx
leaq(%rdi,%rcx,4), %rax
pxor%xmm0, %xmm0
shrq$2, %rdx
salq$4, %rdx
addq%rax, %rdx
.L5:
movdqu (%rax), %xmm2
addq$16, %rax
paddd %xmm2, %xmm0
cmpq%rdx, %rax
jne .L5
movdqa %xmm0, %xmm1
movq%r9, %r10
psrldq $8, %xmm1
andq$-4, %r10
paddd %xmm1, %xmm0
addq%r10, %rcx
leal(%rsi,%r10), %edx
movdqa %xmm0, %xmm1
psrldq $4, %xmm1
paddd %xmm1, %xmm0
movd%xmm0, %eax
cmpq%r10, %r9
je .L10
.L3:
addl(%rdi,%rcx,4), %eax
leal1(%rdx), %ecx
movslq %ecx, %rcx
cmpq%r8, %rcx
jnb .L1
addl(%rdi,%rcx,4), %eax
leal2(%rdx), %ecx
movslq %ecx, %rcx
cmpq%rcx, %r8
jbe .L1
addl$3, %edx
addl(%rdi,%rcx,4), %eax
movslq %edx, %rdx
cmpq%rdx, %r8
jbe .L1
addl(%rdi,%rdx,4), %eax
ret
.L7:
xorl%eax, %eax
.L1:
ret
.L10:
ret
.L8:
xorl%eax, %eax
jmp .L3
[Bug c++/87504] New: inconsistent diagnostic style between C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87504
Bug ID: 87504
Summary: inconsistent diagnostic style between C and C++
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
I noticed an improvement in the diagnostic GCC issues for the following test
case (where I made a typo in the first argument to strlnen: a[v0]).
$ cat c.c && gcc -O2 -S -fdump-tree-optimized=/dev/stdout c.c
const char a[] = "12345";
int v0 = 0;
int f (unsigned n)
{
if (n < 6)
n = 6;
return __builtin_strnlen (a[v0], n);
}
c.c: In function ‘f’:
c.c:10:30: error: invalid operands to binary & (have ‘const char *’ and ‘int’)
10 | return __builtin_strnlen (a[v0], n);
| ~^~
| | |
| | char
| const char *
But when testing the same code with G++ I also noticed the message is slightly
different:
c.c: In function ‘int f(unsigned int)’:
c.c:10:30: error: invalid operands of types ‘const char [6]’ and ‘const char’
to binary ‘operator&’
10 | return __builtin_strnlen (a[v0], n);
| ~^~
It would be nice to converge on the same format and phrasing of the diagnostic
between the two languages.
FWIW, although I like how the C message distinguishes the operands from the
operator using different colors rendering each of the operands in its own color
seems somewhat distracting (it raises the question: do the colors suggest some
subtlety of the error that's not captured in the text?) I also find the C++
phrasing more readable than the C style with the "(have ‘const char *’ and
‘int’)".
[Bug c++/87503] New: Spurious -Wunused-but-set-variable warning in template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87503
Bug ID: 87503
Summary: Spurious -Wunused-but-set-variable warning in template
function
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chtz at informatik dot uni-bremen.de
Target Milestone: ---
Using g++ 8.1.0 and compiling the following minimal example with -Wall
template
Index bar(Index rows, Index cols) {
const bool left = flag;
Index x = left ? rows : cols;
return x;
}
int main() {
return bar(1,2);
}
I'm getting this:
warning: variable ‘left’ set but not used [-Wunused-but-set-variable]
This works fine with g++-7.3 (or earlier) and seems to be fixed in 8.2.0 (I
don't have easy access to 8.1.1. If it has been fixed there already, apologies
for the noise)
Maybe related issue: Bug 85827
[Bug c++/87502] New: Poor code generation for std::string("c-style string")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
Bug ID: 87502
Summary: Poor code generation for std::string("c-style string")
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 44776
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44776=edit
Preprocessed source code
It appears that gcc is creating quite poor code when "c-style strings"
are used to construct std::string objects. Ideally, the result ought
to be just a few move instructions for small strings.
Host: Linux x86_64 4.4.140-62-default (OpenSuSE)
Test code:
---
#include
extern void foo (const std::string &);
void
bar ()
{
foo ("abc");
foo (std::string("abc"));
}
---
# /usr/local/products/gcc/8.2.0/bin/g++ -std=gnu++1z -S -m32 -O3 ttt.C
# grep 'call.*construct' ttt.s
call
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag.constprop.18
call
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag.constprop.18
Here gcc generates complete calls to the generic string construction
even though the strings are constructed from small, known strings.
"-std=gnu++1z" is important; "-m32" and "-O3" (as opposed to "-m64" and
"-O2") are not.
# /usr/local/products/gcc/8.2.0/bin/g++ -S -m32 -O3 ttt.C
# grep 'call.*construct' ttt.s
# (nada)
No calls -- good. In this case gcc generates this fragment:
_Z3barv:
.LFB1084:
.cfi_startproc
.cfi_personality 0,__gxx_personality_v0
.cfi_lsda 0,.LLSDA1084
pushl %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl$25185, %edx
movl%esp, %ebp
.cfi_def_cfa_register 5
pushl %edi
pushl %esi
.cfi_offset 7, -12
.cfi_offset 6, -16
leal-48(%ebp), %esi
pushl %ebx
.cfi_offset 3, -20
leal-40(%ebp), %ebx
subl$56, %esp
movl%ebx, -48(%ebp)
pushl %esi
movw%dx, -40(%ebp)
movb$99, -38(%ebp)
movl$3, -44(%ebp)
movb$0, -37(%ebp)
.LEHB6:
.cfi_escape 0x2e,0x10
call_Z3fooRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
[...]
This is better than a call, but not great:
1. The string is moved into position in three chunks (25185, 99, 0).
This probably comes from inlined memcpy of 3 bytes, but the source
is zero-terminated so rounding the memcpy size up to 4 would have
been better.
2. It's unclear why 25185 is passed through a register.
[Bug bootstrap/87498] Inconsistent behaviour for passing -DNO_ASM and host=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87498 --- Comment #1 from Miro Kropacek --- > For x86_64's gmp, host is passed as "none-pc-linux-gnu", thus disabling > assembly and passing -DNO_ASM to CFLAGS from gmp's configure (making the > toplevel AM_CFLAGS useless). I must correct myself here - the fact gmp's CFLAGS contain -DNO_ASM means nothing here as CFLAGS is overriden by AM_CFLAGS. So the question / issue remains why AM_CFLAGS always pass -DNO_ASM but in m68k case do not use "none" as the host.
[Bug target/87156] [9 Regression] ICE building libstdc++ for mips64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87156 --- Comment #5 from Thomas Preud'homme --- (In reply to Paul Hua from comment #4) > (In reply to Jan Hubicka from comment #3) > > Does the attached patch fix the bootstrap? > > Index: cgraphclones.c > > === > > --- cgraphclones.c (revision 264180) > > +++ cgraphclones.c (working copy) > > @@ -967,6 +967,8 @@ cgraph_node::create_version_clone_with_b > >SET_DECL_ASSEMBLER_NAME (new_decl, DECL_NAME (new_decl)); > >SET_DECL_RTL (new_decl, NULL); > > > > + DECL_VIRTUAL_P (new_decl) = 0; > > + > >/* When the old decl was a con-/destructor make sure the clone isn't. */ > >DECL_STATIC_CONSTRUCTOR (new_decl) = 0; > >DECL_STATIC_DESTRUCTOR (new_decl) = 0; > > Yes, fixed. Thanks. Likewise for me on gcc23.
[Bug fortran/70149] [F08] Character pointer initialization causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149 --- Comment #10 from paul.richard.thomas at gmail dot com --- Thanks Andreas, I am clearly not casting the initializer correctly. I'll try to figure out what is correct tomorrow. Best regards Paul On Wed, 3 Oct 2018 at 13:39, sch...@linux-m68k.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149 > > --- Comment #9 from Andreas Schwab --- > This generates wrong code on powerpc64, either the initializer or the size of > _F.myptr_mod_MOD_number_string is wrong. > > .globl _F.myptr_mod_MOD_number_string > .align 3 > .type _F.myptr_mod_MOD_number_string, @object > .size _F.myptr_mod_MOD_number_string, 8 > _F.myptr_mod_MOD_number_string: > .long 16 > .zero 4 > ... > addis 9,2,_F.myptr_mod_MOD_number_string@toc@ha > addi 9,9,_F.myptr_mod_MOD_number_string@toc@l > ld 9,0(9) > extsw 9,9 > cmpwi 7,9,16 > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
[Bug libstdc++/87493] chrono::system_clock unusable with std::tm due to misaligned precisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87493 Aleksey Covacevice changed: What|Removed |Added CC||aleksey.covacevice at gmail dot co ||m --- Comment #3 from Aleksey Covacevice --- Vinícius: I couldn't reproduce the issue at hand. I've tested a number of `std::tm` combinations manually, and also checked through all `time_t` values from `INT_MIN` to `INT_MAX` without any failures. Could you provide a sample input for which the assertion fails? Recall that, from POSIX, `tm.tm_year` is supposed to be a number counted from 1900. Mistakenly inputting larger values will silently overflow things along the way.
[Bug c++/52477] Wrong initialization order? __attribute__((constructor)) vs static data access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52477 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #16 from Martin Liška --- Leaving for now..
[Bug gcov-profile/77698] Unrolled loop not considered hot after profiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77698 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Should be fixed since r264462, not planning to backport that.
[Bug target/86592] [9 regression] gcc.target/powerpc/p8-vec-xl-xst-v2.c fails starting with r261510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86592 --- Comment #4 from seurer at gcc dot gnu.org --- It looks like it is fixed.
[Bug c/87483] attribute alias accepted on a symbol definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87483 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-10-03 Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- I've got patch candidate.
[Bug c++/87494] hidden visibility constexpr variables left unevaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87494 Nathan Froyd changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-03 Ever confirmed|0 |1 --- Comment #1 from Nathan Froyd --- Giving gGkAtoms default visibility also works to make the bug go away.
[Bug lto/87501] New: lto1: error: Alias and target's section differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87501
Bug ID: 87501
Summary: lto1: error: Alias and target's section differs
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
It's also an older issue:
$ cat 1.ii
struct a {
virtual void f();
};
struct b : a {};
struct S : a, b {
void f() {}
};
main() { S c; }
$ cat 2.ii
struct S {
void f();
};
void S::f() {}
$ g++ -flto 1.ii 2.ii -fchecking
1.ii:5:8: warning: direct base ‘a’ inaccessible in ‘S’ due to ambiguity
struct S : a, b {
^
1.ii:8:6: warning: ISO C++ forbids declaration of ‘main’ with no type
[-Wreturn-type]
main() { S c; }
^
1.ii:5:8: warning: type ‘struct S’ violates the C++ One Definition Rule [-Wodr]
struct S : a, b {
^
2.ii:1:8: note: a type with different bases is defined in another translation
unit
struct S {
^
1.ii:6:8: warning: ‘f’ violates the C++ One Definition Rule [-Wodr]
void f() {}
^
2.ii:4:6: note: implicit this pointer type mismatch
void S::f() {}
^
2.ii:1:8: note: type ‘struct S’ itself violates the C++ One Definition Rule
struct S {
^
1.ii:5:8: note: the incompatible type is defined here
struct S : a, b {
^
2.ii:4:6: note: ‘f’ was previously declared here
void S::f() {}
^
2.ii:4:6: note: code may be misoptimized unless -fno-strict-aliasing is used
lto1: error: Alias and target's section differs
_ZN1S1fEv/26 (f) @0x7657c5c0
Type: function definition analyzed
Visibility: force_output externally_visible no_reorder prevailing_def_ironly
public
Address is taken.
References:
Referring: *.LTHUNK0/1 (alias)_ZTV1S/13 (addr)
Read from file: /tmp/ccaPfjxk.o
First run: 0
Function flags:
Called by:
Calls:
lto1: error: Alias and target's comdat groups differs
_ZN1S1fEv/26 (f) @0x7657c5c0
Type: function definition analyzed
Visibility: force_output externally_visible no_reorder prevailing_def_ironly
public
Address is taken.
References:
Referring: *.LTHUNK0/1 (alias)_ZTV1S/13 (addr)
Read from file: /tmp/ccaPfjxk.o
First run: 0
Function flags:
Called by:
Calls:
*.LTHUNK0/1 (*.LTHUNK0) @0x7657c170
Type: function definition analyzed alias
Visibility: comdat_group:_ZN1S1fEv section:.text._ZN1S1fEv (implicit_section)
artificial
Same comdat group as: _ZThn8_N1S1fEv/2
References: _ZN1S1fEv/26 (alias)
Referring:
Read from file: /tmp/ccF6bEVE.o
First run: 0
Function flags:
Called by: _ZThn8_N1S1fEv/2 (can throw external)
Calls:
(null):0: confused by earlier errors, bailing out
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: error:
lto-wrapper failed
collect2: error: ld returned 1 exit status
[Bug fortran/70149] [F08] Character pointer initialization causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149 --- Comment #9 from Andreas Schwab --- This generates wrong code on powerpc64, either the initializer or the size of _F.myptr_mod_MOD_number_string is wrong. .globl _F.myptr_mod_MOD_number_string .align 3 .type _F.myptr_mod_MOD_number_string, @object .size _F.myptr_mod_MOD_number_string, 8 _F.myptr_mod_MOD_number_string: .long 16 .zero 4 ... addis 9,2,_F.myptr_mod_MOD_number_string@toc@ha addi 9,9,_F.myptr_mod_MOD_number_string@toc@l ld 9,0(9) extsw 9,9 cmpwi 7,9,16
[Bug lto/87500] New: ICE in discriminator_for_local_entity, at cp/mangle.c:1967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87500
Bug ID: 87500
Summary: ICE in discriminator_for_local_entity, at
cp/mangle.c:1967
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, jakub at gcc dot gnu.org,
marxin at gcc dot gnu.org
Target Milestone: ---
It's old ICE:
$ cat ice.ii
template struct a {
void b() {
a c;
int d;
#pragma omp declare reduction(+ : a : 9)
#pragma omp parallel reduction(+ : c)
d++;
}
};
main() {
a c;
c.b();
}
$ g++ ice.ii -flto -fopenmp -c
ice.ii:10:6: warning: ISO C++ forbids declaration of ‘main’ with no type
[-Wreturn-type]
10 | main() {
| ^
during IPA pass: *free_lang_data
ice.ii: In instantiation of ‘void omp declare reduction operator+(a<
>&) [with = double]’:
ice.ii:5:9: required from here
ice.ii:5:9: internal compiler error: in discriminator_for_local_entity, at
cp/mangle.c:1967
5 | #pragma omp declare reduction(+ : a : 9)
| ^~~
0x909f04 discriminator_for_local_entity
/home/marxin/Programming/gcc/gcc/cp/mangle.c:1967
0x909f04 write_local_name
/home/marxin/Programming/gcc/gcc/cp/mangle.c:2065
0x909f04 write_name
/home/marxin/Programming/gcc/gcc/cp/mangle.c:964
0x909486 write_encoding
/home/marxin/Programming/gcc/gcc/cp/mangle.c:825
0x9134a4 mangle_decl_string
/home/marxin/Programming/gcc/gcc/cp/mangle.c:3795
0x9139c0 get_mangled_id
/home/marxin/Programming/gcc/gcc/cp/mangle.c:3817
0x9139c0 mangle_decl(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/mangle.c:3855
0x117722d decl_assembler_name(tree_node*)
/home/marxin/Programming/gcc/gcc/tree.c:691
0x11974fa assign_assembler_name_if_needed(tree_node*)
/home/marxin/Programming/gcc/gcc/tree.c:5791
0x1199410 free_lang_data_in_cgraph
/home/marxin/Programming/gcc/gcc/tree.c:5840
0x1199410 free_lang_data
/home/marxin/Programming/gcc/gcc/tree.c:5881
0x1199410 execute
/home/marxin/Programming/gcc/gcc/tree.c:5934
[Bug libstdc++/59439] std::locale uses atomic instructions on construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59439 --- Comment #14 from Jonathan Wakely --- The testcase now scales with the number of CPUs, instead of running effectively single-threaded. If the global locale is changed so std::locale() != std::locale::classic() then every thread contends for the reference count on the global locale again. That would be mitigated by PR 71430.
[Bug libstdc++/71430] Consider having different global std::locale object per thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71430 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-03 Ever confirmed|0 |1
[Bug lto/87499] New: error: invalid conversion in gimple call for a nested function with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87499 Bug ID: 87499 Summary: error: invalid conversion in gimple call for a nested function with lto Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Very old issue: $ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/nested-func-9.c -flto -fchecking /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/nested-func-9.c: In function ‘fn2’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/nested-func-9.c:20:3: error: invalid conversion in gimple call fn2 (void) ^ struct S struct S # .MEM_12 = VDEF <.MEM_11(D)> = fn (); [static-chain: CHAIN.7_4(D)] [return slot optimization] /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/nested-func-9.c:20: confused by earlier errors, bailing out lto-wrapper: fatal error: gcc returned 1 exit status compilation terminated. /usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status
[Bug bootstrap/87498] New: Inconsistent behaviour for passing -DNO_ASM and host=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87498 Bug ID: 87498 Summary: Inconsistent behaviour for passing -DNO_ASM and host=none Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: miro.kropacek at gmail dot com Target Milestone: --- While testing recent 7.3.0 on m68k I have noticed an inconsistency when it comes to enabling/disabling assemly routines for gmp. Commit 4b2246ef8ab1687ade4dfeaa82b1da3934e74213 introduces passing -DNO_ASM to avoid building in-tree version of GMP with assembly inlines (due to safety reasons). That's good. However what I don't understand is the behaviour happening during the canadian cross - in my case where build=x86_64 and host=target=m68k. For x86_64's gmp, host is passed as "none-pc-linux-gnu", thus disabling assembly and passing -DNO_ASM to CFLAGS from gmp's configure (making the toplevel AM_CFLAGS useless). For m68k's gmp, host is passed as "m68k-elf", thus not disabling assembly and passing -DNO_ASM from toplevel AM_CFLAGS. This leads to an inconsistent state because some asm routines (files) are still used in GMP however inlines are disabled due to NO_ASM. I assume that in the m68k case, some check determines that m68k-gcc cross compiler is outside the build tree (what is) and decides to pass true host id. What is fine with me but in that case AM_CFLAGS's -DNO_ASM shouldn't be passed along.
[Bug c++/87497] New: constexprs involving non-literal const variables are incorrectly accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87497
Bug ID: 87497
Summary: constexprs involving non-literal const variables are
incorrectly accepted
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
G++ accepts:
struct s { volatile int x; int y; };
constexpr int foo (const s ) { return s1.y; }
void g () { const s local_s = { 1, 2 }; constexpr int a = foo (local_s); }
even though "local_s" is only const, not constexpr (and couldn't be constexpr
due to having a non-literal type).
From Jonathan on IRC:
I think for foo(local_s) to be a constant expression, local_s needs to be a
constexpr variable, or a non-volatile const-qualified integer, or a reference
http://eel.is/c++draft/expr.const#8.7
[Bug target/87496] ICE in aggregate_value_p at gcc/function.c:2046
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87496 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Needs -mcpu=power7 (or power8, but not power9) -mno-popcntd -m64. Confirmed.
[Bug libstdc++/59439] std::locale uses atomic instructions on construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59439 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #13 from Jonathan Wakely --- Fixed for gcc 9.
[Bug libstdc++/59439] std::locale uses atomic instructions on construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59439
--- Comment #12 from Jonathan Wakely ---
Author: redi
Date: Wed Oct 3 11:27:40 2018
New Revision: 264811
URL: https://gcc.gnu.org/viewcvs?rev=264811=gcc=rev
Log:
PR libstdc++/59439 optimize uses of classic ("C") std::locale
The global locale::_Impl that represents the "C" locale is never
destroyed, so there is no need to keep track of reference count updates
for that object. This greatly reduce contention between threads that
refer to the classic locale. Since the global std::locale initially uses
the classic locale, this benefits the common case for any code using the
global locale, such as construction/destruction of iostream objects.
All these updates are done inside libstdc++.so so there's no need to
worry about users' objects having inlined old versions of the code which
still update the reference count for the classic locale.
PR libstdc++/59439
* src/c++98/locale.cc (locale::locale(const locale&)): Bypass
reference count updates for the classic locale.
(locale::~locale()): Likewise.
(locale::operator=(const locale&)): Likewise.
* src/c++98/locale_init.cc (locale::locale()): Likewise.
(locale::global(const locale&)): Likewise.
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++98/locale.cc
trunk/libstdc++-v3/src/c++98/locale_init.cc
[Bug other/87353] gcc man page formatting issue due to leading spaces in .texi contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87353 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jonathan Wakely --- Done
[Bug other/87353] gcc man page formatting issue due to leading spaces in .texi contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87353 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Wed Oct 3 10:58:43 2018 New Revision: 264809 URL: https://gcc.gnu.org/viewcvs?rev=264809=gcc=rev Log: PR other/87353 fix formatting and grammar in manual The changes to invoke.texi in r242433 left some unwanted spaces that texi2pod.pl interprets as verbatim formatting. There are also some grammatical errors due to the removal of references to GCJ, where the G++ driver is referred to in the plural. PR other/87353 * doc/invoke.texi (Link Options): Fix formatting and grammar. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/doc/invoke.texi
[Bug other/87353] gcc man page formatting issue due to leading spaces in .texi contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87353 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Wed Oct 3 10:58:49 2018 New Revision: 264810 URL: https://gcc.gnu.org/viewcvs?rev=264810=gcc=rev Log: PR other/87353 fix formatting and grammar in manual The changes to invoke.texi in r242433 left some unwanted spaces that texi2pod.pl interprets as verbatim formatting. There are also some grammatical errors due to the removal of references to GCJ, where the G++ driver is referred to in the plural. PR other/87353 * doc/invoke.texi (Link Options): Fix formatting and grammar. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/doc/invoke.texi
[Bug libstdc++/63776] [C++11] Regex collate matching not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63776
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #11 from Jonathan Wakely ---
(In reply to Tim Shen from comment #8)
> I don't think std::regex_match should care
> about decoding a char string to wchar_t string and call
> std::regex_match std::regex_traits>, leaving user defined RegexTraits potentially
> unused.
I agree.
> Instead, user can maually decode the utf-8 string (I'm sad we don't have a
> standard char iterator adaptor which converts a utf-8 char iterator to
> char32_t iterator) and call std::regex_match<..., wchar_t, ...>.
Agreed.
> These are my understanding, so it's surely possible that I may miss
> something.
>
> Thoughts?
Having looked through this again, I think you're right.
So this reduced test case is not expected to pass:
#include
#include
int main()
{
std::locale::global(std::locale("en_US.UTF-8"));
std::string s = "joão méroço";
std::regex r{"[[:alpha:]]{4} [[:alpha:]]{6}"};
assert( regex_match(s, r) );
}
But this is (assuming wchar_t uses a unicode encoding):
#include
#include
int main()
{
std::locale::global(std::locale("en_US.UTF-8"));
std::string s = "joão méroço";
std::regex r{"[[:alpha:]]{4} [[:alpha:]]{6}"};
assert( regex_match(s, r) );
}
[Bug rtl-optimization/87485] [9 Regression] Compile time hog w/ -O2 -fschedule-insns -fno-guess-branch-probability -fno-isolate-erroneous-paths-dereference -fno-omit-frame-pointer -fno-split-wide-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485 --- Comment #4 from Martin Liška --- Unfortunately can't reproduce even with your complete option list.
[Bug target/87496] New: ICE in aggregate_value_p at gcc/function.c:2046
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87496 Bug ID: 87496 Summary: ICE in aggregate_value_p at gcc/function.c:2046 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: segher at gcc dot gnu.org Target Milestone: --- Maybe similar to PR87133: $ gcc /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/pr41928.f90 -mno-popcntd ... internal compiler error: Segmentation fault 0xac9d2f crash_signal /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/toplev.c:325 0x76bc310f ??? /usr/src/debug/glibc-2.27-6.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x8724cb aggregate_value_p(tree_node const*, tree_node const*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/function.c:2046 0x72b2b4 emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type, machine_mode, int, std::pair*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/calls.c:4747 0x82d5a4 emit_library_call_value(rtx_def*, rtx_def*, libcall_type, machine_mode, rtx_def*, machine_mode) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/rtl.h:4185 0x82d5a4 convert_mode_scalar /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/expr.c:329 0x82d5a4 convert_move(rtx_def*, rtx_def*, int) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/expr.c:271 0x82e232 convert_modes(machine_mode, machine_mode, rtx_def*, int) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/expr.c:712 0x9f2277 expand_fix(rtx_def*, rtx_def*, int) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/optabs.c:4930 0x838b14 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/expr.c:8961 0x73c5c1 expand_gimple_stmt_1 /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/cfgexpand.c:3694 0x73c5c1 expand_gimple_stmt /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/cfgexpand.c:3755 0x73dfdf expand_gimple_basic_block /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/cfgexpand.c:5791 0x741f9e execute /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/cfgexpand.c:6396
[Bug fortran/56789] Wrong code with contiguous dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789 --- Comment #12 from Paul Thomas --- (In reply to Harald Anlauf from comment #11) > (In reply to paul.richard.tho...@gmail.com from comment #10) > > Even if that were allowed, the standard explicitly disallows the > > argument association in the testcase: See 5.3.7 of the F2008 standard. > > The wording has changed in F2018 DIS, 8.5.7, paragraph 1: > > The CONTIGUOUS attribute specifies that an assumed-shape array is contiguous, > that an array pointer can only be pointer associated with a contiguous > target, > or that an assumed-rank dummy data object is contiguous. > > > In my interpretation, the testcase is valid under F2018, but invalid in > F2008. Hmmm! The F2018 standard is almost obfusticating about argument association with contiguous dummies. I will wade through the pertinent sections tonight. Paul
[Bug fortran/87495] New: Warning: ‘fastcall’ attribute ignored [-Wattributes] for !GCC$ ATTRIBUTES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495 Bug ID: 87495 Summary: Warning: ‘fastcall’ attribute ignored [-Wattributes] for !GCC$ ATTRIBUTES Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Looks GCC ATTRIBUTES are broken: $ cat fortran-options.f90 program test interface subroutine sub1() end subroutine sub1 subroutine sub2() !GCC$ ATTRIBUTES CDECL :: sub2 end subroutine sub2 subroutine sub3() !GCC$ ATTRIBUTES STDCALL :: sub3 end subroutine sub3 subroutine sub4() !GCC$ ATTRIBUTES FASTCALL :: sub4 end subroutine sub4 end interface !gcc$ attributes cdecl :: cdecl !gcc$ attributes stdcall :: stdcall procedure(), pointer :: ptr procedure(), pointer :: cdecl procedure(), pointer :: stdcall procedure(), pointer :: fastcall !gcc$ attributes fastcall :: fastcall ! Valid: ptr => sub1 cdecl => sub2 stdcall => sub3 fastcall => sub4 end program $ gfortran fortran-options.f90 -c fortran-options.f90:26:0: cdecl => sub2 Warning: ‘cdecl’ attribute ignored [-Wattributes] fortran-options.f90:26:0: Warning: ‘cdecl’ attribute ignored [-Wattributes] fortran-options.f90:27:0: stdcall => sub3 Warning: ‘stdcall’ attribute ignored [-Wattributes] fortran-options.f90:27:0: Warning: ‘stdcall’ attribute ignored [-Wattributes] fortran-options.f90:28:0: fastcall => sub4 Warning: ‘fastcall’ attribute ignored [-Wattributes] fortran-options.f90:28:0: Warning: ‘fastcall’ attribute ignored [-Wattributes] It's for GCC 7.1.0+. Very old versions (4.8.0+) also suffer. In between 5.1.0 and 6.4.0 I see ICE that was fixed in r246203.
[Bug c++/87478] [DR 1980] Hidden member function falsely takes part in qualified name lookup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87478 Jonathan Wakely changed: What|Removed |Added Status|NEW |SUSPENDED Summary|Hidden member function |[DR 1980] Hidden member |falsely takes part in |function falsely takes part |qualified name lookup |in qualified name lookup --- Comment #3 from Jonathan Wakely --- Yes, it's that issue again, thanks.
[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005 Jonathan Wakely changed: What|Removed |Added Assignee|bkoz at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #21 from Jonathan Wakely --- (In reply to Eric Gallager from comment #19) > (In reply to Jonathan Wakely from comment #18) > > I still want to close this. > > With what resolution? FIXED? WORKSFORME? FIXED, I think, as we do the right thing now. But there's no rush, I'd rather wait and get HP's input.
[Bug libstdc++/87493] chrono::system_clock unusable with std::tm due to misaligned precisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87493 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-10-03 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- This is not a valid bug report, please provide a proper testcase and the other information requested at https://gcc.gnu.org/bugs/ As documented at the following pages, those functions are potentially lossy if the precisions aren't the same (which isn't a problem for POSIX because std::time_t measures seconds anyway): https://en.cppreference.com/w/cpp/chrono/system_clock/to_time_t https://en.cppreference.com/w/cpp/chrono/system_clock/from_time_t
[Bug gcov-profile/86109] gcov reports lines in lambdas as not executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86109 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.0 Resolution|--- |FIXED Summary|[8/9 Regression] gcov |gcov reports lines in |reports lines in lambdas as |lambdas as not executable |not executable | Known to fail|9.0 | --- Comment #6 from Martin Liška --- Fixed on all active branches.
[Bug c++/87494] New: hidden visibility constexpr variables left unevaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87494
Bug ID: 87494
Summary: hidden visibility constexpr variables left unevaluated
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: froydnj at gcc dot gnu.org
Target Milestone: ---
The following testcase, reduced from Firefox:
#pragma GCC visibility push(hidden)
typedef int size_t;
class A;
class B {
A *m_fn1() const;
bool mBaseVal;
};
class A {};
class nsStaticAtom : public A {};
namespace mozilla {
namespace detail {
struct GkAtoms {
enum { F, T, AtomsCount };
nsStaticAtom mAtoms[AtomsCount];
} extern gGkAtoms;
}
}
class nsGkAtoms {
public:
static constexpr nsStaticAtom *_false =
::detail::gGkAtoms.mAtoms[size_t(mozilla::detail::GkAtoms::F)];
static constexpr nsStaticAtom *_true =
::detail::gGkAtoms.mAtoms[size_t(mozilla::detail::GkAtoms::T)];
};
A *B::m_fn1() const { return mBaseVal ? nsGkAtoms::_true : nsGkAtoms::_false; }
when compiled with x86-64 GCC version 8.2, gives:
cmpb$0, (%rdi)
movq_ZN9nsGkAtoms6_falseE(%rip), %rax
je .L1
movq_ZN9nsGkAtoms5_trueE(%rip), %rax
.L1:
ret
which leads to link failures, because neither symbol is defined.
Removing the #pragma gives correct output:
cmpb$0, (%rdi)
movq_ZN7mozilla6detail8gGkAtomsE@GOTPCREL(%rip), %rax
jne .L3
ret
.L3:
addq$1, %rax
ret
Very curiously, so does changing B::m_fn1() to:
A *B::m_fn1() const { return mBaseVal ? (nsStaticAtom*)nsGkAtoms::_true :
nsGkAtoms::_false; }
which gives slightly different, but still correct, assembly:
leaq1+_ZN7mozilla6detail8gGkAtomsE(%rip), %rax
cmpb$0, (%rdi)
leaq-1(%rax), %rdx
cmove %rdx, %rax
ret
[Bug c++/71140] [concepts] ill-formed nested-requirement lacking a semicolon not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71140 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-10-03 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- Mine.
[Bug gcov-profile/86109] [8/9 Regression] gcov reports lines in lambdas as not executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86109 --- Comment #5 from Martin Liška --- Author: marxin Date: Wed Oct 3 09:24:38 2018 New Revision: 264807 URL: https://gcc.gnu.org/viewcvs?rev=264807=gcc=rev Log: Backport r264806 2018-10-03 Martin Liska Backport from mainline 2018-10-03 Martin Liska PR gcov-profile/86109 * coverage.c (coverage_begin_function): Do not mark lambdas as artificial. * tree-core.h (struct GTY): Remove tm_clone_flag and introduce new lambda_function. * tree.h (DECL_LAMBDA_FUNCTION): New macro. 2018-10-03 Martin Liska Backport from mainline 2018-10-03 Martin Liska PR gcov-profile/86109 * parser.c (cp_parser_lambda_declarator_opt): Set DECL_LAMBDA_FUNCTION for lambdas. 2018-10-03 Martin Liska Backport from mainline 2018-10-03 Martin Liska PR gcov-profile/86109 * g++.dg/gcov/pr86109.C: New test. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/gcov/pr86109.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/coverage.c branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/parser.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-core.h branches/gcc-8-branch/gcc/tree.h
[Bug rtl-optimization/86087] ICE in rtl_verify_fallthru, at cfgrtl.c:2911 (error: verify_flow_info: Incorrect fallthru 8->9; error: wrong insn in the fallthru edge)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86087 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Segher Boessenkool --- Okay, let's close it then.
[Bug c++/87406] Implement -Wconstant-conversion and -Wbitfield-constant-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87406 --- Comment #4 from Martin Liška --- (In reply to Eric Gallager from comment #3) > Is clang's -Wbitfield-constant-conversion anything like the > -Wbitfield-conversion flag requested in bug 39170? It's similar, but if I see correctly the LLVM warning is only about constants: https://godbolt.org/z/srLT8m
[Bug rtl-optimization/87485] [9 Regression] Compile time hog w/ -O2 -fschedule-insns -fno-guess-branch-probability -fno-isolate-erroneous-paths-dereference -fno-omit-frame-pointer -fno-split-wide-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485 --- Comment #3 from Arseny Solokha --- % x86_64-pc-linux-gnu-gcc-9.0.0-alpha20180930 -O2 -fschedule-insns -fno-guess-branch-probability -fno-isolate-erroneous-paths-dereference -fno-omit-frame-pointer -fno-split-wide-types -fno-tree-ccp -fno-tree-sra -w -c wo2ahro9.c --verbose Using built-in specs. COLLECT_GCC=x86_64-pc-linux-gnu-gcc-9.0.0-alpha20180930 Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180930/work/gcc-9-20180930/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/9.0.0-alpha20180930 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.0.0-alpha20180930/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.0.0-alpha20180930 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.0.0-alpha20180930/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.0.0-alpha20180930/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.0.0-alpha20180930/include/g++-v9 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/9.0.0-alpha20180930/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --disable-nls --enable-checking=yes --disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --with-multilib-list=m64 --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap --disable-vtable-verify --disable-libvtv --disable-libquadmath --enable-lto --with-isl --disable-isl-version-check --disable-libsanitizer --enable-default-pie --enable-default-ssp Thread model: posix gcc version 9.0.0-alpha20180930 20180930 (experimental) (GCC) COLLECT_GCC_OPTIONS='-O2' '-fschedule-insns' '-fno-guess-branch-probability' '-fno-isolate-erroneous-paths-dereference' '-fno-omit-frame-pointer' '-fno-split-wide-types' '-fno-tree-ccp' '-fno-tree-sra' '-w' '-c' '-v' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-pc-linux-gnu/9.0.0-alpha20180930/cc1 -quiet -v wo2ahro9.c -quiet -dumpbase wo2ahro9.c -mtune=generic -march=x86-64 -auxbase wo2ahro9 -O2 -w -version -fschedule-insns -fno-guess-branch-probability -fno-isolate-erroneous-paths-dereference -fno-omit-frame-pointer -fno-split-wide-types -fno-tree-ccp -fno-tree-sra -o /tmp/ccMuyRPu.s GNU C17 (GCC) version 9.0.0-alpha20180930 20180930 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 9.0.0-alpha20180930 20180930 (experimental), GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/9.0.0-alpha20180930/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-pc-linux-gnu/9.0.0-alpha20180930/include /usr/lib/gcc/x86_64-pc-linux-gnu/9.0.0-alpha20180930/include-fixed /usr/include End of search list. GNU C17 (GCC) version 9.0.0-alpha20180930 20180930 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 9.0.0-alpha20180930 20180930 (experimental), GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 7ddb5283a960f24fa6ae96c9b977a55b
[Bug c/87482] Clarify behaviour of resolvers with parameters in for __attribute__((ifunc))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87482 --- Comment #4 from Peter Smith --- Thanks very much for the clarification.
[Bug c++/70037] [concepts] comdat group error and an ICE with a conceptified tuple implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70037 --- Comment #3 from Paolo Carlini --- So, is this fixed as duplicate of PR69515?
[Bug rtl-optimization/87485] [9 Regression] Compile time hog w/ -O2 -fschedule-insns -fno-guess-branch-probability -fno-isolate-erroneous-paths-dereference -fno-omit-frame-pointer -fno-split-wide-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-10-03 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Can't confirm, can you please paste content of --verbose option?
[Bug gcov-profile/86109] [8/9 Regression] gcov reports lines in lambdas as not executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86109 Martin Liška changed: What|Removed |Added Known to work||8.2.1 Known to fail|8.1.0 | --- Comment #4 from Martin Liška --- Fixed on trunk so far.
[Bug rtl-optimization/86087] ICE in rtl_verify_fallthru, at cfgrtl.c:2911 (error: verify_flow_info: Incorrect fallthru 8->9; error: wrong insn in the fallthru edge)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86087 --- Comment #2 from Arseny Solokha --- Indeed, I cannot reproduce it w/ gcc-9.0.0-alpha20180930 (r264727).
[Bug gcov-profile/86109] [8/9 Regression] gcov reports lines in lambdas as not executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86109 --- Comment #3 from Martin Liška --- Author: marxin Date: Wed Oct 3 08:30:10 2018 New Revision: 264806 URL: https://gcc.gnu.org/viewcvs?rev=264806=gcc=rev Log: Properly mark lambdas in GCOV (PR gcov-profile/86109). 2018-10-03 Martin Liska PR gcov-profile/86109 * coverage.c (coverage_begin_function): Do not mark lambdas as artificial. * tree-core.h (struct GTY): Remove tm_clone_flag and introduce new lambda_function. * tree.h (DECL_LAMBDA_FUNCTION): New macro. 2018-10-03 Martin Liska PR gcov-profile/86109 * parser.c (cp_parser_lambda_declarator_opt): Set DECL_LAMBDA_FUNCTION for lambdas. 2018-10-03 Martin Liska PR gcov-profile/86109 * g++.dg/gcov/pr86109.C: New test. Added: trunk/gcc/testsuite/g++.dg/gcov/pr86109.C Modified: trunk/gcc/ChangeLog trunk/gcc/coverage.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-core.h trunk/gcc/tree.h
[Bug ipa/87491] [9 Regression] ipa_fn_summary missing for node during inlining/dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87491 Martin Liška changed: What|Removed |Added Known to work||8.2.0 Version|unknown |9.0 Target Milestone|--- |9.0 Summary|ipa_fn_summary missing for |[9 Regression] |node during |ipa_fn_summary missing for |inlining/dumping|node during ||inlining/dumping Known to fail||9.0
[Bug target/87330] ICE in scan_rtx_reg, at regrename.c:1097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87330 --- Comment #5 from sameerad at gcc dot gnu.org --- The original regrename pass is renaming the register x19 to x25, however, the expr_list which holds the dead register information is not updated accordingly. Hence, there is a conflict of register names when same information is accessed again by tag collision pass. The fix is under testing.
[Bug rtl-optimization/86087] ICE in rtl_verify_fallthru, at cfgrtl.c:2911 (error: verify_flow_info: Incorrect fallthru 8->9; error: wrong insn in the fallthru edge)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86087 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #1 from Segher Boessenkool --- I cannot reproduce this easily (it requires graphite).
[Bug ipa/87491] ipa_fn_summary missing for node during inlining/dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87491 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-10-03 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed and mine.
[Bug target/86731] [8/9 Regression] Miscompiles vec_sl at -O3 with -fwrapv on ppc64el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86731 --- Comment #4 from Segher Boessenkool --- Is this fixed now?
[Bug target/86592] [9 regression] gcc.target/powerpc/p8-vec-xl-xst-v2.c fails starting with r261510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86592 --- Comment #3 from Segher Boessenkool --- Is this fixed now?
[Bug rtl-optimization/86928] ICE in compute_live, at sel-sched.c:3097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86928 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-03 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Confirmed. Needs -m32.
[Bug testsuite/86766] new test case c-c++-common/spec-barrier-1.c introduced in r263168 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86766 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||segher at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Segher Boessenkool --- This was fixed, I think on 2018-08-01 already.
