[Bug c++/85545] [8/9 Regression] ICE with static_cast of pointer-to-member-function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85545 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/85529] [7/8/9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85529 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Fri Apr 27 07:09:51 2018 New Revision: 259696 URL: https://gcc.gnu.org/viewcvs?rev=259696&root=gcc&view=rev Log: PR tree-optimization/85529 * tree-ssa-reassoc.c (optimize_range_tests_var_bound): Add FIRST_BB argument. Don't call get_nonzero_bits if opcode is ERROR_MARK_NODE, rhs2 def stmt's bb is dominated by first_bb and it isn't an obvious zero extension or masking of the MSB bit. (optimize_range_tests): Add FIRST_BB argument, pass it through to optimize_range_tests_var_bound. (maybe_optimize_range_tests, reassociate_bb): Adjust optimize_range_tests callers. * gcc.c-torture/execute/pr85529-1.c: New test. * gcc.c-torture/execute/pr85529-2.c: New test. * gcc.dg/pr85529.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr85529-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr85529-2.c trunk/gcc/testsuite/gcc.dg/pr85529.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug tree-optimization/85529] [7/8/9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85529 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Fri Apr 27 07:11:44 2018 New Revision: 259697 URL: https://gcc.gnu.org/viewcvs?rev=259697&root=gcc&view=rev Log: PR tree-optimization/85529 * tree-ssa-reassoc.c (optimize_range_tests_var_bound): Add FIRST_BB argument. Don't call get_nonzero_bits if opcode is ERROR_MARK_NODE, rhs2 def stmt's bb is dominated by first_bb and it isn't an obvious zero extension or masking of the MSB bit. (optimize_range_tests): Add FIRST_BB argument, pass it through to optimize_range_tests_var_bound. (maybe_optimize_range_tests, reassociate_bb): Adjust optimize_range_tests callers. * gcc.c-torture/execute/pr85529-1.c: New test. * gcc.c-torture/execute/pr85529-2.c: New test. * gcc.dg/pr85529.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/execute/pr85529-1.c branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/execute/pr85529-2.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr85529.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-reassoc.c
[Bug inline-asm/85546] GCC assumes volatile asm block returns same value in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85546 --- Comment #2 from Richard Biener --- I think this is a misconception of what a volatile asm is. Volatile says there may be additional side-effects the asm performs - it does _not_ mean the output depends on more than the inputs. Note I can't reproduce your findings but your instructions for reproduction are somewhat incomplete.
[Bug ada/85540] gcc/ada/init.c:1282: suspicious expression ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85540 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-27 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- The code is obsolete anyway.
[Bug ada/85540] gcc/ada/init.c:1282: suspicious expression ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85540 --- Comment #2 from Eric Botcazou --- Author: ebotcazou Date: Fri Apr 27 08:05:44 2018 New Revision: 259698 URL: https://gcc.gnu.org/viewcvs?rev=259698&root=gcc&view=rev Log: PR ada/85540 * init.c (__gnat_handle_vms_condition): Add missing parentheses. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/init.c
[Bug ada/85540] gcc/ada/init.c:1282: suspicious expression ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85540 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #3 from Eric Botcazou --- Fixed on mainline.
[Bug fortran/85547] Run-time error: character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85547 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-27 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- Confirmed.
[Bug c++/85548] New: Zero-initialization of padding bits of an aggregate class (class A) member of a non-aggregate class (class B) is not performed when B is value-initialized.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85548
Bug ID: 85548
Summary: Zero-initialization of padding bits of an aggregate
class (class A) member of a non-aggregate class (class
B) is not performed when B is value-initialized.
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jenda.tusil at gmail dot com
Target Milestone: ---
Consider classes A and B:
```
struct A {
char c1;
int i1;
char c2;
int i2;
};
struct B {
virtual void foo(){}
A a;
};
```
The class `A` is an aggregate, `B` is not.
Now consider this declaration:
```
B b{};
```
When an instance of `B` is list-initialized with an empty list, it should be
value-initialized, because `B` is not an aggregate, and because it has a
default-constructor (the implicitly-generated `B::B()`). In this case,
value-initialization means zero-initialization, because `B` is a class-type
without deleted or user-provided default-constructor. Therefore the non-static
member `B::a` is zero-initialized, as well as the padding bits of `B` (there
are none on x86-64). The zero-initialization of 'b.a' means zero-initialization
of `c1`, `i1`, `c2`, `i2`, and of all the padding. However, GCC 6 and GCC 7
does not perform the zero-initialization of the padding (clang 5 and clang 6
does).
A full program:
```
extern "C" void abort();
#define assert(x) if(!(x)) abort();
struct A {
char c1;
int i1;
char c2;
int i2;
};
struct B {
virtual void foo(){}
A a;
};
int main() {
B my_b{};
assert(my_b.a.c1 == 0); // the members are zero-initialized
int const alig_size_1 = int(((char *)&my_b.a.i1 - &my_b.a.c1) -
sizeof(my_b.a.c1));
// This does not have to hold, but holds for x86-64
assert(alig_size_1 > 0);
for (int i = 0; i < alig_size_1; i++) {
assert(*(&my_b.a.c1 + 1 + i) == 0); // fails
}
// The same for the padding between A::c2 and A::i2
int const alig_size_2 = int(((char *)&my_b.a.i2 - &my_b.a.c2) -
sizeof(my_b.a.c2));
assert(alig_size_2 > 0);
for (int i = 0; i < alig_size_2; i++) {
assert(*(&my_b.a.c2 + 1 + i) == 0);
}
}
```
Also, when optimizing with -O1, GCC 7.3 gives the following warnings:
```
warning: '*((void*)& my_b +9)' is used uninitialized in this function
assert(*(&my_b.a.c1 + 1 + i) == 0);
^
warning: '*((void*)& my_b +10)' may be used uninitialized in this function
warning: '*((void*)& my_b +11)' may be used uninitialized in this function
warning: '*((void*)& my_b +17)' may be used uninitialized in this function
assert(*(&my_b.a.c2 + 1 + i) == 0);
^
warning: '*((void*)& my_b +18)' may be used uninitialized in this function
warning: '*((void*)& my_b +19)' may be used uninitialized in this function
```
[Bug target/85512] [8/9 Regression] gcc generating non-existing sshr with immh == 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85512 --- Comment #11 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Fri Apr 27 08:48:49 2018 New Revision: 259699 URL: https://gcc.gnu.org/viewcvs?rev=259699&root=gcc&view=rev Log: [AArch64] PR target/85512: Tighten SIMD right shift immediate constraints pt2 PR target/85512 * config/aarch64/constraints.md (Usg): Limit to 31. (Usj): Limit to 63. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/constraints.md
[Bug target/85538] kortest for 32 and 64 bit masks incorrectly uses k0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85538
--- Comment #3 from Matthias Kretz ---
Some more observations:
1. The instruction sequence:
kmovq %k1,-0x8(%rsp)
vmovq -0x8(%rsp),%xmm1
vmovq %xmm1,%rax
kmovq %rax,%k0
should be a simple `kmovq %k1,%k0` instead.
2. Adding `asm("");` before the compare intrinsic makes the problem go away.
3. Using inline asm in place of the kortest intrinsic shows the same preference
for using the k0 register. Test case:
void bad(__m512i x, __m512i y) {
auto k = _mm512_cmp_epi8_mask(x, y, _MM_CMPINT_EQ);
asm("kmovq %0,%%rax" :: "k"(k));
}
4. The following test cases still unnecessarily prefers k0, but does it with a
nicer `kmovq %k1,%0`:
auto almost_good(__m512i x, __m512i y) {
auto k = _mm512_cmp_epi8_mask(x, y, _MM_CMPINT_EQ);
asm("kmovq %0, %0" : "+k"(k));
return k;
}
(cf. https://godbolt.org/g/hZTga4 for 2, 3 and 4)
[Bug target/82518] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518 --- Comment #59 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Fri Apr 27 08:56:02 2018 New Revision: 259700 URL: https://gcc.gnu.org/viewcvs?rev=259700&root=gcc&view=rev Log: [arm] PR target/82518: Return false in ARRAY_MODE_SUPPORTED_P for BYTES_BIG_ENDIAN followup PR target/82518 * lib/target-supports.exp (check_effective_target_vect_load_lanes): Use check_effective_target_arm_little_endian. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp
[Bug libgcc/85532] New: crtend.o built without --enable-initfini-array has bad .eh_frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85532 Bug ID: 85532 Summary: crtend.o built without --enable-initfini-array has bad .eh_frame Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Target Milestone: --- Seen on a cross from x86_64-linux to powerpc64le-linux. If gcc is configured without --enable-initfini-array, the tests for linker initfini support are not run because those tests are native only. HAVE_INITFINI_ARRAY_SUPPORT is thus zero in auto-host.h, and crtend.o has bogus .eh_frame data past the zero terminator. GNU ld complains about this: error in gcc/crtend.o(.eh_frame); no .eh_frame_hdr table will be created The problem has been worked around on various targets by adding -fno-asynchronous-unwind-tables to CRTSTUFF_T_CFLAGS. See also pr31868 and pr80037. Building crtend.o (and crtendS.o) with -fno-asynchronous-unwind-tables is necessary for a native --disable-initfini-array build too. --- Comment #1 from Alan Modra --- Author: amodra Date: Fri Apr 27 09:06:39 2018 New Revision: 259702 URL: https://gcc.gnu.org/viewcvs?rev=259702&root=gcc&view=rev Log: PR85532, crtend.o built without --enable-initfini-array has bad .eh_frame PR libgcc/85532 * config/rs6000/t-crtstuff (CRTSTUFF_T_CFLAGS): Add -fno-asynchronous-unwind-tables. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/rs6000/t-crtstuff
[Bug libgcc/85532] crtend.o built without --enable-initfini-array has bad .eh_frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85532 --- Comment #2 from Alan Modra --- Author: amodra Date: Fri Apr 27 09:17:49 2018 New Revision: 259703 URL: https://gcc.gnu.org/viewcvs?rev=259703&root=gcc&view=rev Log: PR85532, crtend.o built without --enable-initfini-array has bad .eh_frame PR libgcc/85532 * config/rs6000/t-crtstuff (CRTSTUFF_T_CFLAGS): Add -fno-asynchronous-unwind-tables. Modified: branches/gcc-8-branch/libgcc/ChangeLog branches/gcc-8-branch/libgcc/config/rs6000/t-crtstuff
[Bug libgcc/85532] crtend.o built without --enable-initfini-array has bad .eh_frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85532 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-27 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Ever confirmed|0 |1
[Bug ipa/85549] New: [8/9 Regression] Infinite loop in ilmbase package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85549 Bug ID: 85549 Summary: [8/9 Regression] Infinite loop in ilmbase package Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: jamborm at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Starting from r259319, I see that ilbmbase.ii is miscompiled. #1637 0x0042e6aa in void (anonymous namespace)::visit >(int&, int, int, std::vector >&, std::vector, std::allocator > >&) [clone .constprop.47] () at ../Iex/IexBaseExc.h:154 ---Type to continue, or q to quit--- #1638 0x0042e6aa in void (anonymous namespace)::visit >(int&, int, int, std::vector >&, std::vector, std::allocator > >&) [clone .constprop.47] () at ../Iex/IexBaseExc.h:154 #1639 0x0042e6aa in void (anonymous namespace)::visit >(int&, int, int, std::vector >&, std::vector, std::allocator > >&) [clone .constprop.47] () at ../Iex/IexBaseExc.h:154 #1640 0x0042e6aa in void (anonymous namespace)::visit >(int&, int, int, std::vector >&, std::vector, std::allocator > >&) [clone .constprop.47] () at ../Iex/IexBaseExc.h:154 #1641 0x0042e6aa in void (anonymous namespace)::visit >(int&, int, int, std::vector >&, std::vector, std::allocator > >&) [clone .constprop.47] () at ../Iex/IexBaseExc.h:154 #1642 0x0042e808 in testBox() () at ../Iex/IexBaseExc.h:154 #1643 0x00403664 in main (argc=, argv=) at main.cpp:67 I'll try to reduce the test-case. Can you Martin please take a look at 3 IPA CP clones that all created here?
[Bug ipa/85549] [8/9 Regression] Infinite loop in ilmbase package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85549 --- Comment #1 from Martin Liška --- Created attachment 44028 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44028&action=edit Small self-contained test-case
[Bug ipa/85549] [8/9 Regression] Infinite loop in ilmbase package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85549 Martin Liška changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 Version|unknown |8.0.1
[Bug ipa/85549] [8/9 Regression] Infinite loop in ilmbase package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85549 Martin Liška changed: What|Removed |Added Attachment #44028|0 |1 is obsolete|| --- Comment #2 from Martin Liška --- Created attachment 44029 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44029&action=edit Even smaller test-case
[Bug ipa/85549] [8/9 Regression] Infinite loop in ilmbase package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85549 Martin Jambor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-27 Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Jambor --- Mine
[Bug inline-asm/85546] GCC assumes volatile asm block returns same value in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85546 Alexander Monakov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||amonakov at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Alexander Monakov --- I'm not sure Richard is correct about the definition of volatile asms: similar to reads of volatile objects, volatile asms can produce different output on each invocation (iow they are not pure/const). In any case the inline asm in io() is missing clobbers for rcx, r11 and memory, which makes the bug invalid.
[Bug debug/85550] New: [7/8/9 Regression] -fdebug-types-section broken with DW_OP_addr in DW_AT_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85550
Bug ID: 85550
Summary: [7/8/9 Regression] -fdebug-types-section broken with
DW_OP_addr in DW_AT_location
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
struct A {
int bar () const { return 0; }
};
template
struct B {
};
B<&A::bar> b;
int
main ()
{
}
fails to link with -O2 -g -fdebug-types-section starting with r240578.
Without -fdebug-types-section we handle removal of the location attribute or
replacement with something else through resolve_addr, but that can't be really
called when the type units are already split, they are checksummed, so we can't
really modify them.
Wonder what are all the cases where type units need to have DW_AT_location
attribute and what we can do for them, could we e.g. use unconditionally
DW_OP_GNU_variable_value in that case instead of DW_OP_addr? Though, not
really sure if type units can refer to such DIEs.
[Bug debug/85550] [7/8/9 Regression] -fdebug-types-section broken with DW_OP_addr in DW_AT_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85550 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-27 CC||ccoutant at gmail dot com, ||jason at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1
[Bug debug/85550] [7/8/9 Regression] -fdebug-types-section broken with DW_OP_addr in DW_AT_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85550 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |7.4
[Bug debug/85550] [7/8/9 Regression] -fdebug-types-section broken with DW_OP_addr in DW_AT_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85550 --- Comment #1 from Richard Biener --- Huh, I never expected types to have "locations" ;) I don't think we can use DW_OP_GNU_variable_value because the refered to DIE would be in another section. We could simply avoid splitting out those types, right? Those with DW_OP_addr, that is. I've always wanted a way to have locations in symbolical form thus in this case sth like DW_OP_GNU_expr_value and that refering to a string like "A::foo". That works even for the optimized out case then.
[Bug ipa/85549] [8/9 Regression] Infinite loop in ilmbase package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85549 Richard Biener changed: What|Removed |Added Known to work||7.3.1 Target Milestone|--- |8.0
[Bug debug/85550] [7/8/9 Regression] -fdebug-types-section broken with DW_OP_addr in DW_AT_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85550 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug libgcc/85532] crtend.o built without --enable-initfini-array has bad .eh_frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85532 Richard Biener changed: What|Removed |Added Target||powerpc64le-linux Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug c++/85548] Zero-initialization of padding bits of an aggregate class (class A) member of a non-aggregate class (class B) is not performed when B is value-initialized.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85548 --- Comment #1 from Richard Biener --- Why do you think padding should be initialized in any way?
[Bug rtl-optimization/85551] New: No strength reduction of modulo and integer vision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85551 Bug ID: 85551 Summary: No strength reduction of modulo and integer vision Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: linux at carewolf dot com Target Milestone: --- Created attachment 44030 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44030&action=edit strmod.cpp Many simple loops using modulo naively can be optimized too not perform the expensive module/division every iterations, but GCC does not perform this strength reduction. I have attached a motivating example including two iterations of optimizations. An easy safe one (though it might interfere with vectorization if the arch has vectorized integer divisions), and a more agressive one that is much faster in some cases but not always.
[Bug rtl-optimization/85551] No strength reduction of modulo and integer vision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85551 --- Comment #1 from Allan Jensen --- I also stumbled on this old motivating article when I tried googling the concept: http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TM-600.pdf
[Bug rtl-optimization/85551] No strength reduction of modulo and integer vision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85551
--- Comment #2 from Allan Jensen ---
Hmm.. I appear to have made unsafe assumptions in the mod_opt cases.
The first safe optimization version would then be:
void mod_opt(int *a, int count, int stride, unsigned width)
{
int pos_opt = 0;
for (int i = 0; i < count; ++i) {
if (pos_opt < 0 || pos_opt >= width)
pos_opt = pos_opt % width;
a[i] = pos_opt;
pos_opt += stride;
}
}
To be able to completely get rid of modulo, you need to know or check for the
size of stride compared to width.
[Bug ipa/85549] [8/9 Regression] Infinite loop in ilmbase package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85549
--- Comment #4 from Martin Jambor ---
This is another stupid omission, I forgot that for by-reference aggregate
values, one has to check the agg_preserved of the jump function.
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 1b8f335fd32..4f28a55b862 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -4372,7 +4372,9 @@ find_aggregate_values_for_callers_subset (struct
cgraph_node *node,
{
struct ipa_jump_func *jfunc
= ipa_get_ith_jump_func (IPA_EDGE_REF (cs), i);
- if (self_recursive_pass_through_p (cs, jfunc, i))
+ if (self_recursive_pass_through_p (cs, jfunc, i)
+ && (!plats->aggs_by_ref
+ || ipa_get_jf_pass_through_agg_preserved (jfunc)))
continue;
inter = intersect_aggregates_with_edge (cs, i, inter);
[Bug ipa/85549] [8/9 Regression] Infinite loop in ilmbase package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85549
--- Comment #5 from Martin Liška ---
(In reply to Martin Jambor from comment #4)
> This is another stupid omission, I forgot that for by-reference aggregate
> values, one has to check the agg_preserved of the jump function.
>
> diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
> index 1b8f335fd32..4f28a55b862 100644
> --- a/gcc/ipa-cp.c
> +++ b/gcc/ipa-cp.c
> @@ -4372,7 +4372,9 @@ find_aggregate_values_for_callers_subset (struct
> cgraph_node *node,
> {
> struct ipa_jump_func *jfunc
> = ipa_get_ith_jump_func (IPA_EDGE_REF (cs), i);
> - if (self_recursive_pass_through_p (cs, jfunc, i))
> + if (self_recursive_pass_through_p (cs, jfunc, i)
> + && (!plats->aggs_by_ref
> + || ipa_get_jf_pass_through_agg_preserved (jfunc)))
> continue;
> inter = intersect_aggregates_with_edge (cs, i, inter);
I can confirm the patch fixes test-suite of the package.
[Bug c++/85548] Zero-initialization of padding bits of an aggregate class (class A) member of a non-aggregate class (class B) is not performed when B is value-initialized.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85548 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-27 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- Because the standard says so: - if T is a (possibly cv-qualified) non-union class type, its padding bits (6.7) are initialized to zero bits and each non-static data member, each non-virtual base class subobject, and, if the object is not a base class subobject, each virtual base class subobject is zero-initialized;
[Bug middle-end/55185] Error generated on extern inline function which isn't called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55185 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-27 Ever confirmed|0 |1
[Bug middle-end/85450] ICE: invalid types in nop conversion during GIMPLE pass: ompexp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85450 --- Comment #10 from Andreas Schwab --- This also breaks building libgcc with -mabi=ilp32, and the patch in #c8 fixes that.
[Bug tree-optimization/84362] [7/8/9 Regression] Auto-vectorization regression when accessing member variable through getter/accessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84362 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-27 Component|c++ |tree-optimization Version|unknown |8.0 Summary|Auto-vectorization |[7/8/9 Regression] |regression when accessing |Auto-vectorization |member variable through |regression when accessing |getter/accessor |member variable through ||getter/accessor Ever confirmed|0 |1 --- Comment #1 from Marc Glisse --- Before lim2, we have - _8 = MEM[(unsigned int *)&v + 4000B]; + _8 = v._size; and lim2 only manages to put v._size to SSA form in the second case.
[Bug middle-end/85450] ICE: invalid types in nop conversion during GIMPLE pass: ompexp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85450 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #11 from ktkachov at gcc dot gnu.org --- The commit r259711 should have fixed the aarch64 ICEs
[Bug c++/85545] [8 Regression] ICE with static_cast of pointer-to-member-function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85545 --- Comment #4 from Jason Merrill --- Author: jason Date: Fri Apr 27 15:00:53 2018 New Revision: 259712 URL: https://gcc.gnu.org/viewcvs?rev=259712&root=gcc&view=rev Log: PR c++/85545 - ICE with noexcept PMF conversion. * cvt.c (cp_fold_convert): Pass PMF CONSTRUCTORs to build_ptrmemfunc. * typeck.c (build_ptrmemfunc): Don't build a NOP_EXPR for zero adjustment. (build_ptrmemfunc_access_expr): Special-case CONSTRUCTORs. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cvt.c trunk/gcc/cp/typeck.c
[Bug c++/85552] New: Adding curly braces to the declaration of a std::unique_ptr to a forward declared class breaks compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85552 Bug ID: 85552 Summary: Adding curly braces to the declaration of a std::unique_ptr to a forward declared class breaks compilation Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: parker.coates at gmail dot com Target Milestone: --- Created attachment 44031 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44031&action=edit Minimal test case The attached sample fails to compile on GCC, despite working on Clang and MSVC. https://godbolt.org/g/D9bHBN To my non-expert eyes, this appears to be a bug, as there is no reason this code should need to generate a destructor.
[Bug c++/85545] [8 Regression] ICE with static_cast of pointer-to-member-function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85545 --- Comment #5 from Jason Merrill --- Author: jason Date: Fri Apr 27 15:06:14 2018 New Revision: 259713 URL: https://gcc.gnu.org/viewcvs?rev=259713&root=gcc&view=rev Log: PR c++/85545 - ICE with noexcept PMF conversion. * cvt.c (cp_fold_convert): Pass PMF CONSTRUCTORs to build_ptrmemfunc. * typeck.c (build_ptrmemfunc): Don't build a NOP_EXPR for zero adjustment. (build_ptrmemfunc_access_expr): Special-case CONSTRUCTORs. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/noexcept-type20.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/cvt.c branches/gcc-8-branch/gcc/cp/typeck.c
[Bug objc/53345] some OPT_Wformat is enabled by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53345 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=67479 --- Comment #4 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #2) > A relatively simple fix is a new option OPT_Wformat_pedantic that is enabled > by default. That's bug 67479
[Bug c/43797] __attribute__((deprecated("message"))) produces unexpected messages in some cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43797 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=79078 --- Comment #5 from Eric Gallager --- Possibly related to bug 79078
[Bug ipa/85549] [8/9 Regression] Infinite loop in ilmbase package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85549 --- Comment #6 from Martin Jambor --- I have posted the fix to the mailing list: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01236.html
[Bug c++/85552] Adding curly braces to the declaration of a std::unique_ptr to a forward declared class breaks compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85552 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-27 Ever confirmed|0 |1
[Bug c++/85552] Adding curly braces to the declaration of a std::unique_ptr to a forward declared class breaks compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85552
--- Comment #1 from Jonathan Wakely ---
Any default member initializer has the same problem, not just a
braced-init-list, i.e. all of these cause an error:
class DoesntCompile
{
std::unique_ptr s{};
std::unique_ptr s = std::unique_ptr();
std::unique_ptr t = nullptr;
};
[class.mem]p9 says a default member initializer should not cause the
constructor to be defined:
A brace-or-equal-initializer for a non-static
data member specifies a default member initializer for the member, and shall
not directly or indirectly cause
the implicit definition of a defaulted default constructor for the enclosing
class or the exception specification
of that constructor.
[class.ctor]p7 says the constructor is defined when odr-used:
A default constructor that is defaulted and not defined as deleted is
implicitly defined when it is odr-used (6.2)
to create an object of its class type (6.6.2), when it is needed for constant
evaluation (8.6), or when it is
explicitly defaulted after its first declaration.
So we shouldn't need the DoesntCompile constructor here, and so shouldn't need
to instantiate the destructor of std::unique_ptr.
[Bug c++/85552] Adding curly braces to the declaration of a std::unique_ptr to a forward declared class breaks compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85552
--- Comment #2 from Jonathan Wakely ---
GCC and EDG both reject this reduced version but Clang accepts it:
template
struct uptr {
uptr() { }
~uptr() { static_assert(sizeof(T), "complete type"); }
};
class S;
class Compiles
{
uptr s;
};
class DoesntCompile
{
~DoesntCompile();
DoesntCompile();
uptr s{};
};
int main()
{
return 0;
}
But if we remove the uptr() default constructor only EDG rejects it. If we use
a non-default constructor all three compilers reject it:
template
struct uptr {
uptr(void*) { }
~uptr() { static_assert(sizeof(T), "complete type"); }
};
class S;
class Compiles
{
uptr s;
};
class DoesntCompile
{
~DoesntCompile();
DoesntCompile();
uptr s = nullptr;
};
int main()
{
return 0;
}
[Bug other/35511] release scripts added release note to zlib/ChangeLog, not zlib/ChangeLog.gcj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35511 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Eric Gallager --- (In reply to Eric Gallager from comment #2) > (In reply to Eric Gallager from comment #1) > > (In reply to Debian GCC Maintainers from comment #0) > > > the release scripts added the release note for 4.3.0 to zlib/ChangeLog > > > (upstream), not zlib/ChangeLog.gcj > > > > IMO zlib/ChangeLog.gcj should be renamed since gcj has been removed from > > gcc. > > Putting this in WAITING for someone else's opinion Closing due to no replies in 3 months.
[Bug c/23087] Misleading warning, "... differ in signedness"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087 Eric Gallager changed: What|Removed |Added Keywords||diagnostic, documentation --- Comment #19 from Eric Gallager --- (In reply to Keith Thompson from comment #17) > > I'll also note the documentation of the "-fsigned-char" option: > > Let the type 'char' be signed, like 'signed char'. > > It's difficult to tell uses that plain char is not signed when gcc's > own documentation says it is. > I guess this is a documentation issue, too, then
Database of NetApp end users list
Hello there, I would like to know if you are interested in acquiring NetApp Users List. Information fields: Names, Title, Email, Phone, Company Name, Company URL, Company physical address, SIC Code, Industry, Company Size (Revenue and Employee). If you are interested, let me know your targeted geography so that I will get back to you with the counts and more information. Regards, Diane Marketing Executive If you are not interested in receiving further emails, please answer back with "overlook" in the title.
[Bug c++/70808] Spurious -Wzero-as-null-pointer-constant for nullptr_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70808
--- Comment #10 from Jonathan Wakely ---
This causes a regression for:
using T = decltype(nullptr);
const constexpr T foo{};
np.cc:2:23: error: ‘(const T)nullptr’ is not a constant expression
const constexpr T foo{};
^
[Bug c++/84691] [6/7/8/9 Regression] internal compiler error: in poplevel_class, at cp/name-lookup.c:4430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84691 --- Comment #4 from paolo at gcc dot gnu.org --- Author: paolo Date: Fri Apr 27 16:56:55 2018 New Revision: 259716 URL: https://gcc.gnu.org/viewcvs?rev=259716&root=gcc&view=rev Log: /cp 2018-04-27 Paolo Carlini PR c++/84691 * decl.c (grokdeclarator): Clear friendp upon definition in local class definition error. /testsuite 2018-04-27 Paolo Carlini PR c++/84691 * g++.dg/cpp0x/friend3.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/friend3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/84691] [6/7/8 Regression] internal compiler error: in poplevel_class, at cp/name-lookup.c:4430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84691 Paolo Carlini changed: What|Removed |Added Summary|[6/7/8/9 Regression]|[6/7/8 Regression] internal |internal compiler error: in |compiler error: in |poplevel_class, at |poplevel_class, at |cp/name-lookup.c:4430 |cp/name-lookup.c:4430 --- Comment #5 from Paolo Carlini --- Fixed in trunk so far.
[Bug c++/85545] [8 Regression] ICE with static_cast of pointer-to-member-function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85545 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed.
[Bug c++/70808] Spurious -Wzero-as-null-pointer-constant for nullptr_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70808 --- Comment #11 from Jonathan Wakely --- That's now PR 85553
[Bug c++/85553] New: [8/9 Regression] cannot list-initialize a variable of type std::nullptr_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85553
Bug ID: 85553
Summary: [8/9 Regression] cannot list-initialize a variable of
type std::nullptr_t
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: paolo at gcc dot gnu.org
Target Milestone: ---
THe fix for PR 70808 (r259303) causes this valid code to be rejected:
using T = decltype(nullptr);
const constexpr T foo{};
np.cc:2:23: error: '(const T)nullptr' is not a constant expression
const constexpr T foo{};
^
Reverting r259303 fixes it.
[Bug c++/85553] [8/9 Regression] cannot list-initialize a variable of type std::nullptr_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85553 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-27 CC||jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/85553] [8/9 Regression] cannot list-initialize a variable of type std::nullptr_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85553 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |8.0 --- Comment #1 from Jakub Jelinek --- So shouldn't we then do instead: --- gcc/cp/init.c.jj2018-04-27 19:11:56.613549524 +0200 +++ gcc/cp/init.c 2018-04-27 19:20:50.102839130 +0200 @@ -180,8 +180,10 @@ build_zero_init_1 (tree type, tree nelts items with static storage duration that are not otherwise initialized are initialized to zero. */ ; - else if (TYPE_PTR_OR_PTRMEM_P (type) || NULLPTR_TYPE_P (type)) + else if (TYPE_PTR_OR_PTRMEM_P (type)) init = fold (convert (type, nullptr_node)); + else if (NULLPTR_TYPE_P (type)) +init = build_int_cst (type, 0); else if (SCALAR_TYPE_P (type)) init = fold (convert (type, integer_zero_node)); else if (RECORD_OR_UNION_CODE_P (TREE_CODE (type))) Then we don't warn on cpp0x/Wzero-as-null-pointer-constant-3.C and accept the value initialization in constexpr.
[Bug c++/85553] [8/9 Regression] cannot list-initialize a variable of type std::nullptr_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85553 --- Comment #2 from Paolo Carlini --- Thanks Jakub for looking into this. For sure, the whole fold and convert machinery should not be necessary for something this simple, but, to be honest, isn't immediately obvious to me why it does the wrong thing in this case.
[Bug c++/85553] [8/9 Regression] cannot list-initialize a variable of type std::nullptr_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85553 --- Comment #3 from Jakub Jelinek --- (In reply to Paolo Carlini from comment #2) > Thanks Jakub for looking into this. For sure, the whole fold and convert > machinery should not be necessary for something this simple, but, to be > honest, isn't immediately obvious to me why it does the wrong thing in this > case. Because it isn't folded into INTEGER_CST, but NOP_EXPR with the decltype(nullptr) type wrapping zero INTEGER_CST and constexpr.c doesn't consider that a valid reduced constant expression.
[Bug c++/85553] [8/9 Regression] cannot list-initialize a variable of type std::nullptr_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85553 --- Comment #4 from Paolo Carlini --- I see. Then, my humble opinion (we got Jason in CC, anyway) is that if we are still hoping to have this fixed in 8.1.0 we should just go ahead with something rather straightforward like your tweak, otherwise we should probably investigate the constexpr.c behavior a little more, because I don't really see why going from integer_zero_node to NULLPTR_TYPE_P is "better" than going from nullptr_node to NULLPTR_TYPE_P, if you see what I mean.
[Bug go/85429] Several gotools tests FAIL with Solaris as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85429 --- Comment #3 from ian at gcc dot gnu.org --- Author: ian Date: Fri Apr 27 18:01:00 2018 New Revision: 259719 URL: https://gcc.gnu.org/viewcvs?rev=259719&root=gcc&view=rev Log: PR go/85429 cmd/go: add Solaris assembler syntax for gccgo buildid file The Solaris assembler uses a different syntax for section directives. This is https://golang.org/cl/109140 ported over to gccgo. Reviewed-on: https://go-review.googlesource.com/109141 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/go/cmd/go/internal/work/buildid.go
[Bug go/85429] Several gotools tests FAIL with Solaris as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85429 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ian Lance Taylor --- Should be fixed on tip, requested permission to backport to GCC 8 branch.
[Bug c++/85554] New: GCC does not instantiate template function when only used as a function type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85554
Bug ID: 85554
Summary: GCC does not instantiate template function when only
used as a function type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: me at adhokshajmishraonline dot in
Target Milestone: ---
Proof of concept:
=
template
auto make_value(){
return T{};
}
template
auto call(F func){
return func();
}
int main(){
auto result = call(make_value);
return 0;
}
Compiling with G++
==
╭─ adhokshajmishra@andromeda in /tmp
╰─➤ g++ --version
g++ (GCC) 7.3.1 20180406
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
╭─ adhokshajmishra@andromeda in /tmp
╰─➤ g++ test.cpp -o test -std=c++17
test.cpp: In function ‘int main()’:
test.cpp:12:42: error: no matching function for call to ‘call()’
auto result = call(make_value);
^
test.cpp:7:6: note: candidate: template auto call(F)
auto call(F func){
^~~~
test.cpp:7:6: note: template argument deduction/substitution failed:
test.cpp:12:42: note: couldn't deduce template parameter ‘F’
auto result = call(make_value);
^
Compiling with Clang: no error
As per [http://eel.is/c++draft/temp#inst-4.sentence-1], GCC seems to be wrong
here.
[Bug c++/85515] Bogus suggestions from "GCC's leaky abstractions"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85515 --- Comment #5 from David Malcolm --- Author: dmalcolm Date: Fri Apr 27 18:39:18 2018 New Revision: 259720 URL: https://gcc.gnu.org/viewcvs?rev=259720&root=gcc&view=rev Log: Don't offer suggestions for compiler-generated variables (PR c++/85515) gcc/cp/ChangeLog: PR c++/85515 * name-lookup.c (consider_binding_level): Skip compiler-generated variables. * search.c (lookup_field_fuzzy_info::fuzzy_lookup_field): Flatten nested if statements into a series of rejection tests. Reject lambda-ignored entities as suggestions. gcc/testsuite/ChangeLog: PR c++/85515 * g++.dg/pr85515-1.C: New test. * g++.dg/pr85515-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr85515-1.C trunk/gcc/testsuite/g++.dg/pr85515-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/cp/search.c trunk/gcc/testsuite/ChangeLog
[Bug go/85429] Several gotools tests FAIL with Solaris as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85429 --- Comment #5 from ian at gcc dot gnu.org --- Author: ian Date: Fri Apr 27 18:44:28 2018 New Revision: 259721 URL: https://gcc.gnu.org/viewcvs?rev=259721&root=gcc&view=rev Log: PR go/85429 cmd/go: add Solaris assembler syntax for gccgo buildid file The Solaris assembler uses a different syntax for section directives. This is https://golang.org/cl/109140 ported over to gccgo. Reviewed-on: https://go-review.googlesource.com/109141 Modified: branches/gcc-8-branch/libgo/go/cmd/go/internal/work/buildid.go
[Bug libgcc/84292] __sync_add_and_fetch returns the old value instead of the new value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84292 --- Comment #5 from Andreas Tobler --- Author: andreast Date: Fri Apr 27 19:14:05 2018 New Revision: 259722 URL: https://gcc.gnu.org/viewcvs?rev=259722&root=gcc&view=rev Log: 2018-04-27 Andreas Tobler Maryse Levavasseur PR libgcc/84292 * config/arm/freebsd-atomic.c (SYNC_OP_AND_FETCH_N): Fix the op_and_fetch to return the right result. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/arm/freebsd-atomic.c
[Bug target/85492] riscv64: endless loop when throwing an exception from a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85492 --- Comment #3 from Jim Wilson --- I figured out that I wasn't fully rebuilding and relinking all libraries while trying to debug this with printf, and that sent me down the wrong path. Trying this again, correctly, I see that we have a loop in unwind, because the return address for _start is pointing at _start. This works by accident when static linking, because crt1.o is included before crtbegin.o, crtbegin.o registers FDEs starting from a label it adds to the eh_frame section, and hence the FDE for _start in crt1.o gets lost. When unwinding, we see that there is no FDE for _start, and it isn't an exception frame, so that terminates unwinding. When dynamic linking, we use PT_GNU_EH_FRAME which uses eh_frame section addresses and hence finds every FDE, including the one for _start, so we try to unwind through _start, get a return address pointing at _start, and go into an infinite loop. This requires a glibc patch to fix. Just setting the return address in _start to 0 works.
[Bug target/85492] riscv64: endless loop when throwing an exception from a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85492 --- Comment #4 from Jim Wilson --- Created attachment 44032 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44032&action=edit proposed glibc patch to fix the problem
[Bug c++/85553] [8/9 Regression] cannot list-initialize a variable of type std::nullptr_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85553 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Fri Apr 27 20:29:12 2018 New Revision: 259728 URL: https://gcc.gnu.org/viewcvs?rev=259728&root=gcc&view=rev Log: PR c++/85553 * init.c (build_zero_init_1): For zero initialization of NULLPTR_TYPE_P type use build_int_cst directly. * g++.dg/cpp0x/Wzero-as-null-pointer-constant-3.C: Add dg-bogus directive. * g++.dg/cpp0x/constexpr-85553.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-85553.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/Wzero-as-null-pointer-constant-3.C
[Bug target/85492] riscv64: endless loop when throwing an exception from a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85492 --- Comment #5 from palmer at gcc dot gnu.org --- Thanks Jim. This looks good to me, are you comfortable submitting glibc patches? If so then I'll commit it, otherwise I can send it out myself.
[Bug c++/85553] [8/9 Regression] cannot list-initialize a variable of type std::nullptr_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85553 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Fri Apr 27 20:30:56 2018 New Revision: 259729 URL: https://gcc.gnu.org/viewcvs?rev=259729&root=gcc&view=rev Log: PR c++/85553 * init.c (build_zero_init_1): For zero initialization of NULLPTR_TYPE_P type use build_int_cst directly. * g++.dg/cpp0x/Wzero-as-null-pointer-constant-3.C: Add dg-bogus directive. * g++.dg/cpp0x/constexpr-85553.C: New test. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-85553.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/init.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/Wzero-as-null-pointer-constant-3.C
[Bug ipa/85549] [8/9 Regression] Infinite loop in ilmbase package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85549 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Fri Apr 27 20:32:18 2018 New Revision: 259730 URL: https://gcc.gnu.org/viewcvs?rev=259730&root=gcc&view=rev Log: PR ipa/85549 * ipa-cp.c (find_aggregate_values_for_callers_subset): Make sure the jump function allows for passing through aggregate values. * g++.dg/ipa/pr85549.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr85549.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c trunk/gcc/testsuite/ChangeLog
[Bug c++/85553] [8/9 Regression] cannot list-initialize a variable of type std::nullptr_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85553 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug ipa/85549] [8/9 Regression] Infinite loop in ilmbase package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85549 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Fri Apr 27 20:32:53 2018 New Revision: 259731 URL: https://gcc.gnu.org/viewcvs?rev=259731&root=gcc&view=rev Log: PR ipa/85549 * ipa-cp.c (find_aggregate_values_for_callers_subset): Make sure the jump function allows for passing through aggregate values. * g++.dg/ipa/pr85549.C: New test. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/ipa/pr85549.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/ipa-cp.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug ipa/85549] [8/9 Regression] Infinite loop in ilmbase package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85549 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed by Martin's patch.
[Bug target/85492] riscv64: endless loop when throwing an exception from a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85492 --- Comment #6 from Jim Wilson --- I suggest you handle the glibc patch. Note that you can probably also fix this by adding unwind direcives to _start to say that the return address is in x0. This would avoid the minor code size increase, but takes a little more effort to figure out how to add the right unwind directives to assembly code to make this work. I haven't tried that.
[Bug c++/85554] GCC does not instantiate template function when only used as a function type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85554 --- Comment #1 from Andrew Pinski --- I think this is a dup of bug 64194.
[Bug testsuite/85527] [openacc] atomic_capture-1.{c,f90} undefined behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85527 --- Comment #1 from Tom de Vries --- Author: vries Date: Fri Apr 27 22:11:12 2018 New Revision: 259733 URL: https://gcc.gnu.org/viewcvs?rev=259733&root=gcc&view=rev Log: [openacc, testsuite] Fix undefined behaviour in atomic_capture-1.f90 2018-04-28 Tom de Vries PR testsuite/85527 * testsuite/libgomp.oacc-fortran/atomic_capture-1.f90 (main): Store atomic capture results obtained in parallel loop to an array, instead of to a scalar. Modified: trunk/libgomp/ChangeLog trunk/libgomp/testsuite/libgomp.oacc-fortran/atomic_capture-1.f90
[Bug c++/85554] GCC does not instantiate template function when only used as a function type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85554 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- Yes this is definitely PR 64194 *** This bug has been marked as a duplicate of bug 64194 ***
[Bug c++/64194] [C++14] for function template with auto return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64194 Jonathan Wakely changed: What|Removed |Added CC||me at adhokshajmishraonline dot in --- Comment #9 from Jonathan Wakely --- *** Bug 85554 has been marked as a duplicate of this bug. ***
[Bug fortran/85138] [8/9 regression] ICE with generic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138 kargl at gcc dot gnu.org changed: What|Removed |Added CC||mail at pietrodelugas dot it --- Comment #10 from kargl at gcc dot gnu.org --- *** Bug 85526 has been marked as a duplicate of this bug. ***
[Bug fortran/85526] [6/7/8/9 regression] ICE when calling a (pure) function from inside another pure function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85526 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from kargl at gcc dot gnu.org --- This is actually a duplicate of PR 85138. Comment #6 should be added to that PR. *** This bug has been marked as a duplicate of bug 85138 ***
[Bug fortran/85138] [8/9 regression] ICE with generic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138
--- Comment #11 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #10)
> *** Bug 85526 has been marked as a duplicate of this bug. ***
Comment #6 in the duplicate provides additional information.
Reprodcued here.
Well, I understand the problem a bit now. In decl.c (lines 3229
to 3248), we have
/* If gfortran ends up here, then the len may be reducible to a
constant. Try to do that here. If it does not reduce, simply
assign len to the charlen. */
if (len && len->expr_type != EXPR_CONSTANT)
{
gfc_expr *e;
e = gfc_copy_expr (len);
gfc_reduce_init_expr (e);
if (e->expr_type == EXPR_CONSTANT)
{
gfc_replace_expr (len, e);
if (mpz_cmp_si (len->value.integer, 0) < 0)
mpz_set_ui (len->value.integer, 0);
}
else
{
gfc_free_expr (e);
}
cl->length = len;
}
'gfc_reduce_init_expr (e)' is causing the symbol checkFmt,
which has not previously been seen, to be committed to the
current namespace before the symbol has been resolved. So,
checkFmt() doesn't have a proper type and gfortran cannot
set it when she finally parses the function. During the
translation, checkFmt is implicitly typed, which can be
gleaned from
0x6ce630 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc8/gcc/fortran/trans-expr.c:7918
0x6d0967 gfc_conv_expr_val(gfc_se*, gfc_expr*)<-- from stepping in gdb
../../gcc8/gcc/fortran/trans-expr.c:7975
0x6fed87 gfc_trans_if_1
../../gcc8/gcc/fortran/trans-stmt.c:1427
0x70715a gfc_trans_if(gfc_code*)
What needs to be done is that symbols in the gfc_current_ns
must be save before the call to 'gfc_reduce_init_expr (e)'.
If reduction fails, then the old symbols need to be
restored in the gfc_current_ns and any new symbols added
by 'gfc_reduce_init_expr (e)' need to be removed.
Unfortunately, I don't know how to do this.
ITALY SALAD BOWL
This is our website for the 34oz plastic bowls: please click it and see, https://cwrsl.en.alibaba.com/product/60634767456-802693463/34oz_Beauty_rose_shape_crystal_plastic_packing_lid_dessert_bowl_for_take_away.html?spm=a2700.icbuShop.prewdfa4cf.4.4f5865c4Bw0Aix Warm Regards， Jim
