[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-05-20
Ever confirmed|0 |1
--- Comment #14 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #13)
> Looks that this doesn't work when the operand 1 is equal to the operand 2
> which is the case for the above insns 92, 93 and 83. The peephole
> removed with the fix in PR65153 transformed these insns prior to
> the above peephole so to avoid the problem. The patch below fixes
> this case. It looks there are similar peephole patterns,though.
> Oleg, if you get the spare time, could you look into these peepholes?
>
> --
> diff --git a/config/sh/sh.md b/config/sh/sh.md
> index 27f0074..5bc3401 100644
> --- a/config/sh/sh.md
> +++ b/config/sh/sh.md
> @@ -14750,6 +14750,7 @@ label:
>"TARGET_SH1
> && peep2_reg_dead_p (3, operands[0])
> && !reg_overlap_mentioned_p (operands[0], operands[3])
> + && !reg_overlap_mentioned_p (operands[1], operands[2])
> && (REGNO (operands[0]) == REGNO (operands[4])
> || REGNO (operands[0]) == REGNO (operands[5]))
> && (REGNO (operands[2]) == REGNO (operands[4])
Sorry for the long chain of trouble and pain.
Adding the !reg_overlap_mentioned_p (operands[1], operands[2]) condition should
fix the problem. However, the peephole is actually meant to transform
(insn 92 14 15 3 (set (reg:SI 1 r1 [orig:171 D.2078 ] [171])
(reg:SI 2 r2 [172])) 252 {movsi_ie}
(expr_list:REG_DEAD (reg:SI 2 r2 [172])
(nil)))
(insn 93 16 83 3 (set (reg:SI 2 r2)
(const_int 66602 [0x1042a])) 252 {movsi_ie}
(nil))
(insn 83 93 18 3 (set (reg:SI 147 t)
(eq:SI (and:SI (reg:SI 1 r1 [orig:171 D.2078 ] [171])
(reg:SI 2 r2))
(const_int 0 [0]))) 1 {tstsi_t}
(expr_list:REG_DEAD (reg:SI 2 r2)
(expr_list:REG_DEAD (reg:SI 1 r1 [orig:171 D.2078 ] [171])
(nil
into
(insn 93 16 83 3 (set (reg:SI 2 r1)
(const_int 66602 [0x1042a])) 252 {movsi_ie}
(nil))
(insn 83 93 18 3 (set (reg:SI 147 t)
(eq:SI (and:SI (reg:SI 1 r1 [orig:171 D.2078 ] [171])
(reg:SI 2 r2))
(const_int 0 [0]))) 1 {tstsi_t}
(expr_list:REG_DEAD (reg:SI 2 r2)
(expr_list:REG_DEAD (reg:SI 1 r1 [orig:171 D.2078 ] [171])
(nil
I think the check operands[1] / operands[2] check should go into the
preparation statement. operands[0] is dying after this peephole, so I guess
this should work:
{
if (reg_overlap_mentioned_p (operands[1], operands[2]))
std::swap (operands[0], operands[2])
sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[3]));
emit_insn (gen_tstsi_t (operands[2],
gen_rtx_REG (SImode, (REGNO (operands[1]);
}
I guess that the following peephole (sh.md line 14733) will also have a similar
problem.
[Bug c++/66211] [5/6 Regression] Rvalue conversion in ternary operator causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66211 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-20 CC||jakub at gcc dot gnu.org Target Milestone|--- |5.2 Summary|Rvalue conversion in|[5/6 Regression] Rvalue |ternary operator causes |conversion in ternary |internal compiler error |operator causes internal ||compiler error Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r217279.
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #13 from rguenther at suse dot de --- On Wed, 20 May 2015, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||jakub at gcc dot gnu.org > > --- Comment #12 from Jakub Jelinek --- > hashval_t should be unsigned int? Is it some other type on your host, or is > CHAR_BIT bigger than 8, or do you have 64-bit unsigned int? Yeah, it looks odd. All hosts should have uint64_t nowadays, so even before honzas patch we _always_ should have gone the mul_mod path. Can you attach pre-processed source with the revision you bisected reverted? (pre-processed source of genmatch.c, that is?) Might be that bconfig.h/system.h combo for your host makes the difference somehow.
[Bug tree-optimization/65961] [6 Regression] ice in vect_is_simple_use_1 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65961 --- Comment #6 from Richard Biener --- It might be mitigated for the testcase in question but the underlying problem didn't get fixed.
[Bug c++/66211] [5/6 Regression] Rvalue conversion in ternary operator causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66211 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- I will have a look.
[Bug gcov-profile/66209] Out of memory when compiling with --coverage and optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66209 Richard Biener changed: What|Removed |Added Blocks||64928 --- Comment #1 from Richard Biener --- Maybe related to PR64928 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 [Bug 64928] [4.8/4.9/5/6 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs
[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #15 from Oleg Endo ---
(In reply to Oleg Endo from comment #14)
>
> I think the check operands[1] / operands[2] check should go into the
> preparation statement. operands[0] is dying after this peephole, so I guess
> this should work:
>
I have confirmed that the following fixes the test case in attachment 35572:
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 223416)
+++ gcc/config/sh/sh.md (working copy)
@@ -14721,6 +14721,9 @@
|| REGNO (operands[2]) == REGNO (operands[5]))"
[(const_int 0)]
{
+ if (reg_overlap_mentioned_p (operands[1], operands[2]))
+std::swap (operands[0], operands[2]);
+
sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[3]));
emit_insn (gen_tstsi_t (operands[2],
gen_rtx_REG (SImode, (REGNO (operands[1]);
However, I think that the emit_move_insn could also be a source of hidden
problems. For instance, if the captured insn
(set (match_operand:SI 2 "arith_reg_dest")
(match_operand:SI 3))
is not a move insn, but some computation like (set (reg) (plus:SI ... )). I'm
not sure what emit_move_insn is going to do in this case. Maybe a better way
would be to copy/re-emit the captured original insn in a different way.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #25 from Richard Biener ---
(In reply to Chung-Kil Hur from comment #24)
> (In reply to schwab from comment #23)
> > "gil.hur at sf dot snu.ac.kr" writes:
> >
> > > Since "hello" is not printed, I think the if-statement is the same as
> > > no-op.
> > > Thus, removing the if-statement should not change the behavior of the
> > > program
> > > according to ISO C11.
> >
> > Unless you are invoking undefined behaviour.
> >
> > Andreas.
>
> ==
> #include
>
> int main() {
> int x = 0;
> uintptr_t xp = (uintptr_t) &x;
> uintptr_t i, j;
>
> for (i = 0; i < xp; i++) { }
> j = i;
>
> *(int*)((xp+i)-j) = 15;
>
> printf("%d\n", x);
> }
> =
>
> This prints "15".
> And I do not think there is any UB.
> Please correct me if I am wrong.
>
> Then, I add the if-statement.
>
> ==
> #include
>
> int main() {
> int x = 0;
> uintptr_t xp = (uintptr_t) &x;
> uintptr_t i, j;
>
> for (i = 0; i < xp; i++) { }
> j = i;
>
> /** begin ***/
> if (j != xp) {
> printf("hello\n");
> j = xp;
> }
> /** end */
>
> *(int*)((xp+i)-j) = 15;
>
> printf("%d\n", x);
> }
> =
>
> This prints "0" without printing "hello".
>
> Thus, this raises no UB unless "j != xp" raises UB.
>
> If you think "j != xp" raises UB, please explain why and give some reference.
>
> Otherwise, I think it is a bug of GCC.
The C standard only guarantees that you can convert a pointer to uintptr_t and
back, it doesn't guarantee that you can convert a modified uintptr_t back to
a pointer that is valid.
Thus, doing (int *)((xp + i) - j) is invoking undefined behavior.
That you see an effect of this undefined behavior just with the added if
is because that if confuses early GCC optimizations which would have
cancelled i - j to zero, retaining (int *)xp. Instead it enables later
optimization to see that xp - j cancels and thus it is left with (int *)i.
This is because you are essentially computing (xp + xp) - xp == xp but
dependent on what two pieces get cancelled the pointer is based on
either xp (ok) or on i (not ok - that is related to xp only via an
implicit equivalency).
The net result is that I can't see how to "detect" this kind of situation
in points-to analysis in a way that does not pessimize all pointer-to-integer /
integer-to-pointer conversions. In theory it would be possible to add a
flag similar to -fno-strict-aliasing to do this pessimization (but there
is already -fno-tree-pta which avoids the issue as well).
So in the end my conclusion is that either the testcase invokes undefined
behavior or the C standard has a defect. Thus the bug is WONTFIX unless
somebody can come up with a way to handle these kind of equivalences
in the points-to algorithm in GCC in a way not pessimizing everything.
One might consider an incomplete approach like that in comment #6 but
I am not convinced about this hack (and one would need to evaluate its
effects on code generation).
[Bug c++/66211] [5/6 Regression] Rvalue conversion in ternary operator causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66211 --- Comment #3 from Richard Biener --- So we fold (and did fold before) 1 > 0 ? x : y to (float) x (thus an rvalue). Then later we call ocp_convert on that requesting a conversion to int which does 810 converted = fold_if_not_in_template (convert_to_integer (type, e)); where convert_to_integer ends up just doing 910 return build1 (FIX_TRUNC_EXPR, type, expr); and fold then applying the simplification /* If we are converting an integer to a floating-point that can represent it exactly and back to an integer, we can skip the floating-point conversion. */ (if (inside_int && inter_float && final_int && (unsigned) significand_size (TYPE_MODE (inter_type)) >= inside_prec - !inside_unsignedp) (convert @0)) and (for cvt (convert view_convert float fix_trunc) (simplify (cvt @0) (if ((GIMPLE && useless_type_conversion_p (type, TREE_TYPE (@0))) || (GENERIC && type == TREE_TYPE (@0))) @0))) where wrapping the result as (non_lvalue @0) fixes the regression. The bug is of course the C++ frontend folding stuff too early (and too aggressive) here. But for GCC 5 the above might be a good-enough workaround (eventually we can conditionalize building non_lvalue exprs to non-C-frontends).
[Bug libstdc++/60936] [4.9/5/6 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 Markus Eisenmann changed: What|Removed |Added CC||meisenmann.lba@fh-salzburg. ||ac.at --- Comment #12 from Markus Eisenmann --- Created attachment 35573 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35573&action=edit Using __throw_out_of_range (instead of __throw_out_of_range_fmt), if configured with --disable-libstdcxx-verbose My patch (file gcc-4.9-pr60936.patch) is a fix/work-around as suggested by Jonathan in Comment 4. Calling __throw_out_of_range_fmt is replaced by the (simpler) function __throw_out_of_range(), if the gcc-build is configured with the option --disable-libstdcxx-verbose. Note: I have used the previous call to __throw_out_of_range as used in GCC-release 4.8.4. Maybe the patch has to be applied with the option -p1 (or change the patch-file), because the path begins with 'gcc-4.9.2/' ... Following source-files will be changed (by this patch): [gcc-4.9.2/] libstdc++-v3/include/bits/basic_string.h [gcc-4.9.2/] libstdc++-v3/include/bits/functexcept.h [gcc-4.9.2/] libstdc++-v3/include/bits/stl_bvector.h [gcc-4.9.2/] libstdc++-v3/include/bits/stl_deque.h [gcc-4.9.2/] libstdc++-v3/include/bits/stl_vector.h [gcc-4.9.2/] libstdc++-v3/include/debug/array [gcc-4.9.2/] libstdc++-v3/include/experimental/string_view [gcc-4.9.2/] libstdc++-v3/include/ext/vstring.h [gcc-4.9.2/] libstdc++-v3/include/profile/array [gcc-4.9.2/] libstdc++-v3/include/std/array [gcc-4.9.2/] libstdc++-v3/include/std/bitset [gcc-4.9.2/] libstdc++-v3/src/c++11/functexcept.cc [gcc-4.9.2/] libstdc++-v3/testsuite/util/exception/safety.h Best regards, Markus
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 --- Comment #10 from Gerhard Steinmetz --- Perhaps it's better to make one factor larger. Maybe the following will help. $ cat zz1.f90 program p real :: z(2) z = 10 + [real :: 1, 2] print *, z end # you may check your patch $ cat zz2.f90 program p real :: z(2) z = 10. + [real :: 1, 2] print *, z end # you may check your patch --- $ cat zz3.f90 program p real :: z(2) z = [real :: 1, 2] + 10 print *, z end $ gfortran zz3.f90 $ a.out 1. 2. # expected: 11. 12. $ cat zz4.f90 program p real :: z(2) z = [real :: 1, 2] + 10. print *, z end $ gfortran zz4.f90 $ a.out 1. 2. # expected: 11. 12. --- Or to use an other basic operation : $ cat zz5.f90 program p real :: z(2) z = -10 * [real :: 1, 2] print *, z end # you may check your patch $ cat zz6.f90 program p real :: z(2) z = -10. * [real :: 1, 2] print *, z end # you may check your patch
[Bug target/62231] [4.8/4.9 regression] Exception handling broken on powerpc-e500v2-linux-gnuspe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62231 --- Comment #16 from Andri Yngvason --- Sorry, Joseph, I wasn't sure if this issue was fixed or not since the status is "NEW". I'll report a new issue.
[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #16 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #15) Thanks for a quick look! > However, I think that the emit_move_insn could also be a source of hidden > problems. For instance, if the captured insn Also arguments of emit_move_insn must have the same integer modes. if (reg_overlap_mentioned_p (operands[1], operands[2])) std::swap (operands[0], operands[2]); sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[3])); might ICE if operands[0] and operands[2] have different modes and swap happens, though I'm not sure whether such insns are real or not.
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #14 from Douglas Mencken --- sizeof(hashval_t) = 4, CHAR_BIT = 8 Just checked it manually. Built with patch subset, genmatch problem is here again. It isn't related to changes in hash_table_mod1 & hash_table_mod2. What's left? abort() replaced by gcc_checking_assert()?
[Bug libgcc/66212] New: Exception handling broken on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66212
Bug ID: 66212
Summary: Exception handling broken on powerpc
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: andri.yngvason at marel dot com
Target Milestone: ---
All exceptions cause the running process to be aborted.
The following program is aborted when trying to unwind the stack:
#include
#include
#include
using std::cout;
using std::endl;
void foobar()
{
cout << "..." << endl;
throw std::runtime_error("Whoohoo");
cout << "Wtf?" << endl;
}
int main(int, char**)
{
cout << "Throwing standard exception..." << endl;
try {
foobar();
} catch(std::exception& e) {
cout << "Caught: " << e.what() << endl;
}
cout << "Done!" << endl;
return 0;
}
Backtrace:
#0 0x0fbff76c in raise () from /lib/libc.so.6
#1 0x0fc010cc in abort () from /lib/libc.so.6
#2 0x0fd5fc1c in uw_init_context_1 () from /lib/glibc2.21/libgcc_s.so.1
#3 0x0fd60408 in _Unwind_RaiseException () from /lib/glibc2.21/libgcc_s.so.1
#4 0x0fed10ac in __cxa_throw () at
../../../../gcc-5.1.0/libstdc++-v3/libsupc++/eh_throw.cc:82
#5 0x1c28 in foobar() ()
#6 0x1cac in main ()
$ powerpc-marel-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=powerpc-marel-linux-gnu-g++
COLLECT_LTO_WRAPPER=/opt/plutotoolchain/libexec/gcc/powerpc-marel-linux-gnu/5.1.0/lto-wrapper
Target: powerpc-marel-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=/opt/plutotoolchain
--target=powerpc-marel-linux-gnu --enable-languages=c,c++
--enable-threads=posix --enable-shared --disable-multilib --enable-__cxa_atexit
--disable-sjlj-exceptions --disable-nls --enable-symvers=gnu --enable-c99
--enable-long-long --enable-profile --with-tune=e300c3 --disable-altivec
Thread model: posix
gcc version 5.1.0 (GCC)
I tried to compile libgcc with debug symbols so that I could see which
assertion fails, but my attempts had no effect. I'd be happy to learn how to
get those debug symbols in there.
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #15 from Douglas Mencken ---
I'm going to surround calls to gcc_[checking_]assert (in gcc/hash-table.*) with
#ifdef ENABLE_CHECKING {--disable-checking is in my config already}. Let's see
where it lands.
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #16 from Andreas Schwab --- > After, <= 32 triggers assert (--> failure). This is backwards. The failure case is sizeof (hashval_t) * CHAR_BIT > 32.
[Bug c/66213] New: unsigned char value range can be greater than sizeof unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66213
Bug ID: 66213
Summary: unsigned char value range can be greater than sizeof
unsigned char
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: z.hege...@t-systems.com
Target Milestone: ---
Unsigned char can be greater than 1 byte (== sizeof(unsigned char))
Example:
#include
int main() {
unsigned char a=200, b=80;
int z = a+b;
printf("z=: %d\n", z);
return 0;
}
When data type char or signed char is used in the example above a char overflow
occurs (as expected) but if unsigned char is used the return value can be
greater than 1 byte (or sizeof(unsigned char))
Reason:
Breakpoint 8, 0x004011f6 in main () at char.c:8
(gdb) i r
eax0x50 80
edx0xc8 200
Breakpoint 10, 0x00401215 in main () at char.c:10
0x0040121a 10 z = c+d;
(gdb) ni
(gdb) i r
eax0x50 80
edx0xffc8 -56
Where "c" and "d" are signed chars.
When unsigned char is used gcc uses movzx instead of movsx and probably the
sign bit is overwritten.
[Bug c/66213] unsigned char value range can be greater than sizeof unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66213 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Marek Polacek --- I don't know where you think is a bug. The usual arithmetic conversion are performed on that addition so it is done on ints.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 --- Comment #26 from Chung-Kil Hur --- Thanks for the detailed explanations. > The C standard only guarantees that you can convert a pointer to uintptr_t > and back, it doesn't guarantee that you can convert a modified uintptr_t > back to > a pointer that is valid. > > Thus, doing (int *)((xp + i) - j) is invoking undefined behavior. > I didn't know about this rule. I thought this cast is valid because "(xp+i)-j" is even "safely-derived". Could you give a reference for that rule in the standard? Thanks!
[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #17 from John Paul Adrian Glaubitz --- Thanks a lot guys for working on this! I'm really glad you're doing this :).
[Bug middle-end/66214] New: [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214 Bug ID: 66214 Summary: [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250 Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: hubicka at gcc dot gnu.org Target Milestone: --- Created attachment 35574 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35574&action=edit Test case (input13.ii): Compile with g++ -std=c++11 -g The bug reminds me of 66103, but is one is without LTO. Compiling the attached code snipped with "g++ -std=c++11 -g" give the following ICE. Without "-g", it doesn't crash: input13.ii:53:34: required from here input13.ii:44:74: error: TYPE_CANONICAL is not compatible template < typename _Tp, typename _Alloc = std::allocator < _Tp > >class vector:protected _Vector_base < _Tp, [...] input13.ii:44:74: internal compiler error: verify_type failed 0xf3e280 verify_type(tree_node const*) ../../gcc/tree.c:13257 0x96dc04 gen_type_die_with_usage ../../gcc/dwarf2out.c:20250 0x96e2a3 gen_type_die_with_usage ../../gcc/dwarf2out.c:20337 0x97f21c gen_type_die ../../gcc/dwarf2out.c:20434 0x97f21c gen_formal_types_die ../../gcc/dwarf2out.c:18027
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214 Tobias Burnus changed: What|Removed |Added Known to work||5.1.0 Target Milestone|--- |6.0 Known to fail||6.0 --- Comment #1 from Tobias Burnus --- (In reply to Tobias Burnus from comment #0) > The bug reminds me of bug 66103, but is one is without LTO.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 --- Comment #27 from Chung-Kil Hur --- (In reply to Chung-Kil Hur from comment #26) > Thanks for the detailed explanations. > > > The C standard only guarantees that you can convert a pointer to uintptr_t > > and back, it doesn't guarantee that you can convert a modified uintptr_t > > back to > > a pointer that is valid. > > > > Thus, doing (int *)((xp + i) - j) is invoking undefined behavior. > > > > I didn't know about this rule. > I thought this cast is valid because "(xp+i)-j" is even "safely-derived". > > Could you give a reference for that rule in the standard? > > Thanks! It seems that the following rule might be the one. = 7.20.1.4 Integer types capable of holding object pointers The following type designates a signed integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer: intptr_t The following type designates an unsigned integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer: uintptr_t These types are optional. = Right. This does not say that we are allowed to cast a modified integer back to a pointer. What I remember might be from the C++ standard, where "safely derived" integers are allowed to be cast back to pointers. Umm. This might also be implementation-defined. Anyway, thanks very much for taking your time to respond to my questions!! Best, Gil
[Bug libgcc/66212] Exception handling broken on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66212 --- Comment #1 from Andri Yngvason --- I've now compiled the same toolchain for i686 and I have the same issue there, so I assume that I'm doing something wrong. It's hard to pin down what I'm doing wrong though. Everything seems to be linked correctly: # ldd stdexcept linux-gate.so.1 (0xb77ad000) libstdc++.so.6 => /lib/libstdc++.so.6 (0xb7633000) libm.so.6 => /lib/libm.so.6 (0xb75ea000) libgcc_s.so.1 => /lib/glibc2.21/libgcc_s.so.1 (0xb75ce000) libc.so.6 => /lib/libc.so.6 (0xb742) /lib/ld-linux.so.2 (0xb77ae000) # ls -l /lib/libstdc++.so.6 /lib/libm.so.6 /lib/libc.so.6 /lib/glibc2.21/libgcc_s.so.1 /lib/ld-linux.so.2 -rw-r--r--1 root root397872 May 20 10:11 /lib/glibc2.21/libgcc_s.so.1 lrwxrwxrwx1 root root10 May 20 10:57 /lib/ld-linux.so.2 -> ld-2.21.so lrwxrwxrwx1 root root12 May 20 10:57 /lib/libc.so.6 -> libc-2.21.so lrwxrwxrwx1 root root12 May 20 10:57 /lib/libm.so.6 -> libm-2.21.so lrwxrwxrwx1 root root19 May 20 10:57 /lib/libstdc++.so.6 -> libstdc++.so.6.0.21 I'll try 4.9...
[Bug c/66213] unsigned char value range can be greater than sizeof unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66213 --- Comment #2 from zh__ --- Yep, sorry. My bad.
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #17 from rguenther at suse dot de --- On Wed, 20 May 2015, dougmencken at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 > > --- Comment #14 from Douglas Mencken --- > sizeof(hashval_t) = 4, CHAR_BIT = 8 > > Just checked it manually. Built with patch subset, genmatch problem is here > again. It isn't related to changes in hash_table_mod1 & hash_table_mod2. > > What's left? abort() replaced by gcc_checking_assert()? Well, it shouldn't segfault in this case either (well - maybe we replace gcc_checking_assert () with gcc_unreachable () with --disable-checking). Indeed we do. That would explain seeing a segfault instead of an assertion failure (so yes, try without --disable-checking)
[Bug libstdc++/60936] [4.9/5/6 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #13 from Jonathan Wakely --- Created attachment 35575 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35575&action=edit Lightweight __throw_out_of_range_fmt for non-verbose builds This is what I had in mind.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 --- Comment #28 from rguenther at suse dot de --- On Wed, 20 May 2015, gil.hur at sf dot snu.ac.kr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 > > --- Comment #27 from Chung-Kil Hur --- > (In reply to Chung-Kil Hur from comment #26) > > Thanks for the detailed explanations. > > > > > The C standard only guarantees that you can convert a pointer to uintptr_t > > > and back, it doesn't guarantee that you can convert a modified uintptr_t > > > back to > > > a pointer that is valid. > > > > > > Thus, doing (int *)((xp + i) - j) is invoking undefined behavior. > > > > > > > I didn't know about this rule. > > I thought this cast is valid because "(xp+i)-j" is even "safely-derived". > > > > Could you give a reference for that rule in the standard? > > > > Thanks! > > It seems that the following rule might be the one. > > = > 7.20.1.4 Integer types capable of holding object pointers > > The following type designates a signed integer type with the property that any > valid pointer to void can be converted to this type, then converted back to > pointer to void, and the result will compare equal to the original pointer: > intptr_t > > The following type designates an unsigned integer type with the property that > any valid pointer to void can be converted to this type, then converted back > to > pointer to void, and the result will compare equal to the original pointer: > uintptr_t > These types are optional. > = Yes, that's the one I remember. > Right. This does not say that we are allowed to cast a modified integer back > to > a pointer. > > What I remember might be from the C++ standard, where "safely derived" > integers > are allowed to be cast back to pointers. > Umm. This might also be implementation-defined. Yeah, what is "safely derived" is the question here (you might not break the dependency chain in any (non-)obvious way).
[Bug libstdc++/38265] STL treats explicit constructors as converting constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #15 from Jonathan Wakely --- (In reply to Geoff Romer from comment #14) > But see [sequence.reqmts]/p3: "i and j denote iterators satisfying input > iterator requirements and refer to elements implicitly convertible to > value_type". So this is not "intended to work" per se; a conforming library > could disallow it. However, the notes on LWG 536 say "Some support, not > universal, for respecting the explicit qualifier", so it looks like the > standard intentionally permits this as a conforming extension. Which makes the original testcase invalid, so it's a bug in the user's code, not a bug in libstdc++ to accept it. > In principle, I think "perfect initialization" is what's called for here: > the range ctor should be explicit if and only if it uses an explicit > constructor for value_type. I don't think that would be a good idea. I don't think it follows that X(int) being explicit should mean deque(int*, int*) should be explicit. By that logic shared_ptr(unique_ptr&&) should be explicit, because unique_ptr(T*) is explicit. int* is not int, and deque is not X.
[Bug target/66215] New: [4.8/4.9/5/6 Regression] Wrong after label NOP emission for -mhotpatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
Bug ID: 66215
Summary: [4.8/4.9/5/6 Regression] Wrong after label NOP
emission for -mhotpatch
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Target: 390-linux
Hi.
Starting from r221381 GCC does not place nops right after function label.
Unfortunately, the problematic patch was also backported to gcc4-[89] and
gcc-5.
$ cat /tmp/s390.c
static int foo()
{
return 0;
}
int main(int argc, char **argv)
{
return foo();
}
$ ./xgcc -B. /tmp/s390.c -mhotpatch=2,3 -o o0.s -S -fno-inline
$ cat o0.s | head ..
.text
.align 8
.type foo, @function
nopr%r7 # pre-label NOPs for hotpatch (2 halfwords)
nopr%r7
# alignment for hotpatch
.align 8
foo:
# post-label NOPs for hotpatch (3 halfwords)
.LFB0:
stm %r11,%r14,44(%r15)
.LCFI0:
lr %r11,%r15
.LCFI1:
nop 0
nopr%r7
lhi %r1,0
lr %r2,%r1
l %r4,56(%r11)
lm %r11,%r14,44(%r11)
.LCFI2:
br %r4
Problem is that patched compiler relies that NOTE_INSN_FUNCTION_BEG is at the
beginning of function.
/* Inject nops for hotpatching. */
+ for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
+ {
+ if (NOTE_P (insn) && NOTE_KIND (insn) == NOTE_INSN_FUNCTION_BEG)
+ break;
+ }
Problem is that if you use -O2, 256r.sched2 reorders insns after
pro_and_epilogue, where NOTE_INSN_FUNCTION_BEG is placed at the beginning.
On the other hand, if you try -O0, -O1, as the pass is not executed, emission
of NOTE_INSN_FUNCTION_BEG is not reordered.
$ cat s390.c.242r.pro_and_epilogue
foo
(note 1 0 5 NOTE_INSN_DELETED)
(note 5 1 18 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn/f 18 5 19 2 (set (mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 56 [0x38])) [1 S4 A8])
(reg:SI 14 %r14)) /tmp/s390.c:7 -1
(nil))
(insn 19 18 20 2 (set (reg:SI 5 %r5)
(unspec_volatile [
(const_int 0 [0])
] UNSPECV_MAIN_POOL)) /tmp/s390.c:7 -1
(nil))
(note 20 19 17 2 NOTE_INSN_PROLOGUE_END)
(insn 17 20 4 2 (set (reg:SI 5 %r5)
(unspec_volatile [
(const_int 0 [0])
] UNSPECV_MAIN_POOL)) 675 {main_pool}
(nil))
(note 4 17 8 2 NOTE_INSN_FUNCTION_BEG)
(insn 8 4 24 2 (set (reg:SI 1 %r1)
(mem/u/c:SI (unspec:SI [
(symbol_ref/u:SI ("*.LC0") [flags 0x2])
(reg:SI 5 %r5)
] UNSPEC_LTREF) [2 S4 A32])) /tmp/s390.c:8 68 {*movsi_esa}
(expr_list:REG_EQUAL (symbol_ref:SI ("foo") [flags 0x3] )
(nil)))
(note 24 8 23 2 NOTE_INSN_EPILOGUE_BEG)
(insn/f 23 24 9 2 (set (reg:SI 14 %r14)
(mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 56 [0x38])) [1 S4 A8])) /tmp/s390.c:9 -1
(expr_list:REG_CFA_DEF_CFA (plus:SI (reg/f:SI 15 %r15)
(const_int 96 [0x60]))
(expr_list:REG_CFA_RESTORE (reg:SI 14 %r14)
(nil
(call_insn/u/j 9 23 10 2 (set (reg:SI 2 %r2)
(call (mem:QI (reg:SI 1 %r1) [0 foo S1 A8])
(const_int 0 [0]))) /tmp/s390.c:8 631 {*sibcall_value_br}
(expr_list:REG_CALL_DECL (symbol_ref:SI ("foo") [flags 0x3]
)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(nil))
(barrier 10 9 16)
(note 16 10 0 NOTE_INSN_DELETED)
$ cat s390.c.256r.sched2
(note 1 0 3 NOTE_INSN_DELETED)
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 3 15 2 NOTE_INSN_FUNCTION_BEG)
(insn/f 15 2 16 2 (set (mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 56 [0x38])) [1 S4 A8])
(reg:SI 14 %r14)) /tmp/s390.c:2 68 {*movsi_esa}
(expr_list:REG_DEAD (reg:SI 14 %r14)
(nil)))
(insn 16 15 17 2 (set (reg:SI 5 %r5)
(unspec_volatile [
(const_int 0 [0])
] UNSPECV_MAIN_POOL)) /tmp/s390.c:2 675 {main_pool}
(expr_list:REG_UNUSED (reg:SI 5 %r5)
(nil)))
(note 17 16 14 2 NOTE_INSN_PROLOGUE_END)
(insn 14 17 25 2 (set (reg:SI 5 %r5)
(unspec_volatile [
(const_int 0 [0])
] UNSPECV_MAIN_POOL)) 675 {main_pool}
(expr_list:REG_UNUSED (reg:SI 5 %r5)
(nil)))
(note 25 14 21 2 NOTE_INSN_EPILOGUE_BEG)
(insn 21 25 9 2 (set (reg:SI 4 %r4)
(mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 56 [0x38])) [1 S4 A8])) /tmp/s390.c:4 68
{*movsi_esa}
(nil))
(insn 9 21 22 2 (set (reg/i:SI 2 %r2)
(const_int 0 [0])) /tmp/s390.c:4 68 {*movsi_esa}
(nil))
(insn/f 22 9 10 2 (set (reg:SI 14 %r14)
(mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 56 [0x38])) [1 S4 A8])) /tmp/s390.c:4 68
{*movsi_esa}
(e
[Bug target/66215] [4.8/4.9/5/6 Regression] Wrong after label NOP emission for -mhotpatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #1 from Martin Liška ---
Following testcase is wrongly compiled event with -O2 optimization level.
$ cat o2-test-case.c
static int a;
int t(int tt)
{
switch (tt)
{
case 1: return a;
}
return 0;
}
$ ./xgcc -B. -mhotpatch=2,3 -O2 -fno-inline -o /tmp/test.s -S o2-test-case.c
$ head -n20 /tmp/test.s
.file "o2-test-case.c"
.text
.align 8
.globl t
.type t, @function
nopr%r7 # pre-label NOPs for hotpatch (2 halfwords)
nopr%r7
# alignment for hotpatch
.align 8
t:
marxin@marxinbox:~/Programming/gcc2/objdir/gcc> head -n20 /tmp/test.s
.file "o2-test-case.c"
.text
.align 8
.globl t
.type t, @function
nopr%r7 # pre-label NOPs for hotpatch (2 halfwords)
nopr%r7
# alignment for hotpatch
.align 8
t:
# post-label NOPs for hotpatch (3 halfwords)
.LFB0:
st %r14,56(%r15)
nop 0
nopr%r7
.LCFI0:
l %r4,56(%r15)
lhi %r2,0
l %r14,56(%r15)
.LCFI1:
[Bug target/66215] [4.8/4.9/5/6 Regression] Wrong after label NOP emission for -mhotpatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #2 from Martin Liška ---
(In reply to Martin Liška from comment #1)
> Following testcase is wrongly compiled event with -O2 optimization level.
>
> $ cat o2-test-case.c
> static int a;
>
> int t(int tt)
> {
> switch (tt)
> {
> case 1: return a;
> }
>
> return 0;
> }
>
> $ ./xgcc -B. -mhotpatch=2,3 -O2 -fno-inline -o /tmp/test.s -S o2-test-case.c
> $ head -n20 /tmp/test.s
>
> .file "o2-test-case.c"
> .text
> .align 8
> .globl t
> .type t, @function
> nopr%r7 # pre-label NOPs for hotpatch (2 halfwords)
> nopr%r7
> # alignment for hotpatch
> .align 8
> t:
> marxin@marxinbox:~/Programming/gcc2/objdir/gcc> head -n20 /tmp/test.s
> .file "o2-test-case.c"
> .text
> .align 8
> .globl t
> .type t, @function
> nopr%r7 # pre-label NOPs for hotpatch (2 halfwords)
> nopr%r7
> # alignment for hotpatch
> .align 8
> t:
> # post-label NOPs for hotpatch (3 halfwords)
> .LFB0:
> st %r14,56(%r15)
> nop 0
> nopr%r7
> .LCFI0:
> l %r4,56(%r15)
> lhi %r2,0
> l %r14,56(%r15)
> .LCFI1:
Sorry, this testcase is invalid as I modified the compiler.
Martin
[Bug c++/66216] New: Defaulted Operators and contructors not working with aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66216
Bug ID: 66216
Summary: Defaulted Operators and contructors not working with
aligned attribute
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: npl at chello dot at
Target Milestone: ---
The code below will not compile, faulting with defaulted declaration 'xx' does
not match expected signature.
This behaviour is in any gcc version from 4.7 - 5
// g++ -std=c++11 -c testalign.cpp
class CMymy
{
unsigned char _a;
unsigned char _b;
public:
constexpr CMymy() : _a(), _b() {}
constexpr CMymy(const CMymy &) = default;
CMymy &operator=(const CMymy &) = default;
} __attribute__((aligned(2)));
[Bug target/66215] [4.8/4.9/5/6 Regression] Wrong after label NOP emission for -mhotpatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215 Andreas Krebbel changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-20 Ever confirmed|0 |1
[Bug target/29256] [4.8/4.9/5/6 regression] loop performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256 --- Comment #53 from Bill Schmidt --- I'm not a fan of a tree-level unroller. It's impossible to make good decisions about unroll factors that early. But your second approach sounds quite promising to me.
[Bug ada/66217] New: PowerPC rotate/shift/mask instructions not optimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66217 Bug ID: 66217 Summary: PowerPC rotate/shift/mask instructions not optimal Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: segher at gcc dot gnu.org Reporter: segher at gcc dot gnu.org Target Milestone: --- Target: powerpc*-*-* GCC does not generate optimal instruction sequences for rotate/shift/mask sequences; it pretty often makes quite bad code, even, esp. when it involves 64-bit instructions. One part of the problem is that the masks we allow are less general than what the hardware allows. Not a huge problem for the rlwinm instructions, but we shouldn't need "mask_operand_wrap" there either. Another big part of the problem is our rtx_cost function does not handle rotate-and-mask correctly; it recurses to get the cost of the mask, but then it looks at the mode of it, which is VOIDmode (it is a const_int), and things go south. It would be nice to not need that rtx_cost at all, certainly not for combine (which has access to full insns always), but that is a bigger project. Another problem is with the insert insns. They are not as general as they should be, as before. Also, we should be able to handle things like (a << 16) | (b >> 16), which is an insert insn followed by a "normal" rotate (or the other way around). This should also make the bswap patterns a little bit simpler.
[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144 chrbr at gcc dot gnu.org changed: What|Removed |Added Blocks||59884 CC||joey.ye at arm dot com --- Comment #2 from chrbr at gcc dot gnu.org --- *** Bug 59884 has been marked as a duplicate of this bug. *** Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59884 [Bug 59884] Unexpected warning pragma GCC target
[Bug target/59884] Unexpected warning pragma GCC target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59884 chrbr at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||chrbr at gcc dot gnu.org Depends on||52144 Resolution|--- |DUPLICATE --- Comment #4 from chrbr at gcc dot gnu.org --- #pragma GCC target relies on the target_attribute work *** This bug has been marked as a duplicate of bug 52144 *** Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144 [Bug 52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source
[Bug c++/66216] [6 Regression] Defaulted Operators and constructors not working with aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66216 Jonathan Wakely changed: What|Removed |Added Keywords||ice-on-valid-code, ||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-20 Summary|Defaulted Operators and |[6 Regression] Defaulted |contructors not working |Operators and constructors |with aligned attribute |not working with aligned ||attribute Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- And now it gives an ICE on trunk, so it's regressed from rejects-valid to ice-on-valid-code: a.cc:1:7: internal compiler error: canonical types differ for identical types const CMymy and const CMymy class CMymy ^ 0x103f comptypes(tree_node*, tree_node*, int) /home/jwakely/src/gcc/gcc/cp/typeck.c:1423 0x1033108b structural_comptypes /home/jwakely/src/gcc/gcc/cp/typeck.c:1357 0x103332e7 comptypes(tree_node*, tree_node*, int) /home/jwakely/src/gcc/gcc/cp/typeck.c:1415 0x1033675f compparms(tree_node const*, tree_node const*) /home/jwakely/src/gcc/gcc/cp/typeck.c:1534 0x10379fc7 defaulted_late_check(tree_node*) /home/jwakely/src/gcc/gcc/cp/method.c:1972 0x1029a5ff check_bases_and_members /home/jwakely/src/gcc/gcc/cp/class.c:5808 0x1029c4f3 finish_struct_1(tree_node*) /home/jwakely/src/gcc/gcc/cp/class.c:6582 0x1029ef53 finish_struct(tree_node*, tree_node*) /home/jwakely/src/gcc/gcc/cp/class.c:6888 0x102ebd73 cp_parser_class_specifier_1 /home/jwakely/src/gcc/gcc/cp/parser.c:19868 0x102ebd73 cp_parser_class_specifier /home/jwakely/src/gcc/gcc/cp/parser.c:20096 0x102ebd73 cp_parser_type_specifier /home/jwakely/src/gcc/gcc/cp/parser.c:14734 0x10305447 cp_parser_decl_specifier_seq /home/jwakely/src/gcc/gcc/cp/parser.c:11965 0x1031d9c7 cp_parser_simple_declaration /home/jwakely/src/gcc/gcc/cp/parser.c:11542 0x10315547 cp_parser_block_declaration /home/jwakely/src/gcc/gcc/cp/parser.c:11489 0x10322abf cp_parser_declaration /home/jwakely/src/gcc/gcc/cp/parser.c:11386 0x10320a5f cp_parser_declaration_seq_opt /home/jwakely/src/gcc/gcc/cp/parser.c:11272 0x10320e43 cp_parser_translation_unit /home/jwakely/src/gcc/gcc/cp/parser.c:4107 0x10320e43 c_parse_file() /home/jwakely/src/gcc/gcc/cp/parser.c:33213 0x104b160b c_common_parse_file() /home/jwakely/src/gcc/gcc/c-family/c-opts.c:1067
[Bug c++/66211] [5/6 Regression] Rvalue conversion in ternary operator causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66211 Richard Biener changed: What|Removed |Added CC||jason at redhat dot com Version|unknown |5.1.0 --- Comment #4 from Richard Biener --- Unfortunately this causes FAIL: gcc.dg/tree-ssa/foldcast-1.c scan-tree-dump-times original "return x;" 2 FAIL: gcc.dg/tree-ssa/pr31261.c scan-tree-dump-times original "return b & 7;" 1 FAIL: gfortran.dg/assumed_type_2.f90 -O0 scan-tree-dump-times original "sub_ scalar .(struct t1 .) array_class_t1_ptr._data.dat" 1 FAIL: gfortran.dg/assumed_type_2.f90 -O1 scan-tree-dump-times original "sub_ scalar .(struct t1 .) array_class_t1_ptr._data.dat" 1 FAIL: gfortran.dg/assumed_type_2.f90 -O2 scan-tree-dump-times original "sub_ scalar .(struct t1 .) array_class_t1_ptr._data.dat" 1 FAIL: gfortran.dg/assumed_type_2.f90 -O3 -fomit-frame-pointer scan-tree-dump -times original "sub_scalar .(struct t1 .) array_class_t1_ptr._data.dat" 1 FAIL: gfortran.dg/assumed_type_2.f90 -O3 -fomit-frame-pointer -funroll-all-loo ps -finline-functions scan-tree-dump-times original "sub_scalar .(struct t 1 .) array_class_t1_ptr._data.dat" 1 FAIL: gfortran.dg/assumed_type_2.f90 -O3 -fomit-frame-pointer -funroll-loops scan-tree-dump-times original "sub_scalar .(struct t1 .) array_class_t1 _ptr._data.dat" 1 FAIL: gfortran.dg/assumed_type_2.f90 -O3 -g scan-tree-dump-times original "s ub_scalar .(struct t1 .) array_class_t1_ptr._data.dat" 1 FAIL: gfortran.dg/assumed_type_2.f90 -Os scan-tree-dump-times original "sub_ scalar .(struct t1 .) array_class_t1_ptr._data.dat" 1 FAIL: gfortran.dg/c_f_pointer_tests_3.f90 -O scan-tree-dump-times original " fptr_array.data = cptr;" 1 FAIL: gfortran.dg/c_loc_test_22.f90 -O scan-tree-dump-times original "D.[0-9 ]+ = parm.[0-9]+.data;[^;]+ptr[1-4] = D.[0-9]+;" 4 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O0 scan-tree-dump-times original "fgsl _file.[0-9]+.gsl_file = c_ptr.[0-9]+;" 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O0 scan-tree-dump-times original "fgsl _file.[0-9]+.gsl_func = c_funptr.[0-9]+;" 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O1 scan-tree-dump-times original "fgsl _file.[0-9]+.gsl_file = c_ptr.[0-9]+;" 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O1 scan-tree-dump-times original "fgsl _file.[0-9]+.gsl_func = c_funptr.[0-9]+;" 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O2 scan-tree-dump-times original "fgsl _file.[0-9]+.gsl_file = c_ptr.[0-9]+;" 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O2 scan-tree-dump-times original "fgsl _file.[0-9]+.gsl_func = c_funptr.[0-9]+;" 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O3 -fomit-frame-pointer scan-tree-dump -times original "fgsl_file.[0-9]+.gsl_file = c_ptr.[0-9]+;" 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O3 -fomit-frame-pointer scan-tree-dump -times original "fgsl_file.[0-9]+.gsl_func = c_funptr.[0-9]+;" 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O3 -fomit-frame-pointer -funroll-all-loo ps -finline-functions scan-tree-dump-times original "fgsl_file.[0-9]+.gsl_file = c_ptr.[0-9]+;" 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O3 -fomit-frame-pointer -funroll-all-loo ps -finline-functions scan-tree-dump-times original "fgsl_file.[0-9]+.gsl_func = c_funptr.[0-9]+;" 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O3 -fomit-frame-pointer -funroll-loops scan-tree-dump-times original "fgsl_file.[0-9]+.gsl_file = c_ptr.[0-9]+;" 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O3 -fomit-frame-pointer -funroll-loops scan-tree-dump-times original "fgsl_file.[0-9]+.gsl_func = c_funptr.[0-9]+;" 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O3 -g scan-tree-dump-times original "f gsl_file.[0-9]+.gsl_file = c_ptr.[0-9]+;" 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O3 -g scan-tree-dump-times original "f gsl_file.[0-9]+.gsl_func = c_funptr.[0-9]+;" 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -Os scan-tree-dump-times original "fgsl _file.[0-9]+.gsl_file = c_ptr.[0-9]+;" 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -Os scan-tree-dump-times original "fgsl _file.[0-9]+.gsl_func = c_funptr.[0-9]+;" 1 FAIL: gfortran.dg/c_ptr_tests_15.f90 -O scan-tree-dump-times original "fgsl_ file.[0-9]+.gsl_file = c_ptr.[0-9]+;" 1 FAIL: gfortran.dg/c_ptr_tests_15.f90 -O scan-tree-dump-times original "fgsl_ file.[0-9]+.gsl_func = c_funptr.[0-9]+;" 1 FAIL: gfortran.dg/coarray_31.f90 -O scan-tree-dump original "a.y.d._data.dat a = D.[0-9]+.y.d._data.data;" FAIL: gfortran.dg/coarray_31.f90 -O scan-tree-dump original "a.y.x.data = D. [0-9]+.y.x.data;" FAIL: gfortran.dg/coarray_31.f90 -O scan-tree-dump original "a.y.z._data.dat a = D.[0-9]+.y.z._data.data;" FAIL: gfortran.dg/no_arg_check_2.f90 -O0 scan-tree-dump-times original "sub_ scalar .(struct t1 .) array_class_t1_ptr._data.dat" 1 F
[Bug c++/52742] Initializing an array using brace initializer and template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52742 Jonathan Wakely changed: What|Removed |Added Known to work||4.8.1 Known to fail||4.7.4, 4.8.0 --- Comment #3 from Jonathan Wakely --- This is fixed in 4.8.1
[Bug c++/66218] New: [c++-concepts] "inconsistent deduction for ‘auto’" with a partial-concept-id in a deduction constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66218
Bug ID: 66218
Summary: [c++-concepts] "inconsistent deduction for ‘auto’"
with a partial-concept-id in a deduction constraint
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 35576
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35576&action=edit
testcase.cpp
Compiling this correct program with r223444 of the c++-concepts branch:
#include
template
concept bool Same =
std::is_same::value;
template
concept bool C =
requires(T t) {
{ t } -> Same;
};
template
constexpr bool f() { return false; }
template
constexpr bool f() { return true; }
static_assert(f(), "");
static_assert(f(), "");
static_assert(f(), "");
int main() {}
produces errors:
bug2.cpp:19:22: error: inconsistent deduction for ‘auto’: ‘char’ and then ‘int’
static_assert(f(), "");
^
bug2.cpp:19:1: error: static assertion failed:
static_assert(f(), "");
^
bug2.cpp:20:25: error: inconsistent deduction for ‘auto’: ‘char’ and then
‘double’
static_assert(f(), "");
^
bug2.cpp:20:1: error: static assertion failed:
static_assert(f(), "");
^
It appears that the result of the first deduction is stored in memory instead
of being discarded.
[Bug c/66219] New: The gcc generated section start/stop pointers become undefined when option -flto is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66219
Bug ID: 66219
Summary: The gcc generated section start/stop pointers become
undefined when option -flto is used
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dscao999 at hotmail dot com
Target Milestone: ---
Created attachment 35577
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35577&action=edit
This tar contains all the information required for a bug
#include
__attribute__ ((__section__("MAP"))) long flags[] = {1, 2, 3, 4, 5, 6};
extern const long __start_MAP[];
extern const long __stop_MAP[];
int main(int argc, char *argv[])
{
const long *m;
m = __start_MAP;
while (m < __stop_MAP) {
printf("%d ", *m);
m++;
}
printf("\n");
return 0;
}
The magic pointers(__start_MAP, __stop_MAP) of sections will become undefined
if option -flto is used.
[Bug c++/66211] [5/6 Regression] Rvalue conversion in ternary operator causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66211 --- Comment #5 from Jakub Jelinek --- Perhaps just guard this particular match.pd pattern with GIMPLE guard for now (until the delayed C++ folding is committed)?
[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144 chrbr at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||chrbr at gcc dot gnu.org --- Comment #3 from chrbr at gcc dot gnu.org --- patch set posted : (2.1/6) https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01185.html (2.2/6) https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01198.html (4/6) https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01537.html (5.1/6) https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01539.html (5.2/6) https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01558.html (6 /6) https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01542.html
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-20 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Confirmed.
[Bug sanitizer/62216] UBSan can read past valid memory region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62216 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- https://llvm.org/bugs/show_bug.cgi?id=20721 is fixed now, closing this one as well.
[Bug c/66220] New: -Wmisleading-indentation false/inconsistent warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66220
Bug ID: 66220
Summary: -Wmisleading-indentation false/inconsistent warning
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Created attachment 35578
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35578&action=edit
Testcase to reproduce
The following indenting style generates a false warning:
int test1(int v)
{
int res = 28;
if (v == 2)
{
res = 27;
} else
{
res = 18;
}
return res;
}
test-indent.c: In function 'test1':
test-indent.c:13:5: warning: statement is indented as if it were guarded by...
[-Wmisleading-indentation]
return res;
^
test-indent.c:9:7: note: ...this 'else' clause, but it is not
} else
^
Even though I don't like this style, I don't think it's misleading.
If you change the 'else' to 'else if ()' the warning goes away, that's why
think it's at least inconsistent.
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 chrbr at gcc dot gnu.org changed: What|Removed |Added Depends on||52144 --- Comment #29 from chrbr at gcc dot gnu.org --- Extend the attribute_target thumb/arm support to -mfpu isas Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144 [Bug 52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source
[Bug c/66220] -Wmisleading-indentation false/inconsistent warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66220 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-20 CC||dmalcolm at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/65835] bootstrap failure: multiple invalid conversions from ‘const char*’ to ‘char*’ [-fpermissive] in winnt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65835 tprince at computer dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from tprince at computer dot org --- The problem appears to have been cleared in trunk by 2015-05-19
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 --- Comment #11 from asmwarrior --- Today, I did the same test as in comment 6 with a more recent gcc 5.1(http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/dongsheng-daily/5.x/gcc-5-win32_5.1.1-20150512.7z/download), but I still get the same bad result.
[Bug target/66215] [4.8/4.9/5/6 Regression] Wrong after label NOP emission for -mhotpatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- IMHO the nops should go immediately before the first real instruction in the function. The point of not emitting it earlier is so that the nops are already covered by debug and unwind info. So, we certainly should skip all NOTEs at the start of the function, and perhaps selected other insns (dunno if e.g. UNSPECV_MAIN_POOL insn emits any code or not). NOTE_INSN_FUNCTION_BEG is not a good place, as it can be preceeded by various prologue instructions, and the nops really have to go before all real instructions (that emit some bytes into the function text section).
[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 --- Comment #8 from Jonathan Wakely --- NetBSD 5 and DragonFly BSD fail the test too. I'm going to make libstdc++ assume pthread_once is not exception-aware unless specifically told otherwise for targets where we know it works, such as x86-linux and (hopefully) glibc > 2.21
[Bug middle-end/66221] New: [CHKP, 6 regression] lto1: error: type variant has different TYPE_ARG_TYPES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66221
Bug ID: 66221
Summary: [CHKP, 6 regression] lto1: error: type variant has
different TYPE_ARG_TYPES
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ienkovich at gcc dot gnu.org
Target Milestone: ---
Check added by r222991 reveals a problem with function types created for
instrumented functions.
>cat test1.c
int test1 (const char *p)
{
return (int)(*p);
}
>cat test2.c
int test1 (const char *);
int main (int argc, const char **argv)
{
return test1 (argv[0]);
}
>gcc test1.c test2.c -O0 -flto -fcheck-pointer-bounds -mmpx
lto1: error: type variant has different TYPE_ARG_TYPES
unit size
align 32 symtab 0 alias set -1 canonical type 0x7f7056843690 precision
32 min max
pointer_to_this >
QI
size constant 8>
unit size constant 1>
align 8 symtab 0 alias set 0 canonical type 0x7f7056a34bd0
arg-types
unsigned DI
size
unit size
align 64 symtab 0 alias set 0 canonical type 0x7f705685a7e0
pointer_to_this >
chain >>
pointer_to_this >
unit size
align 32 symtab 0 alias set -1 canonical type 0x7f7056843690 precision
32 min max
pointer_to_this >
QI
size constant 8>
unit size constant 1>
align 8 symtab 0 alias set 0 canonical type 0x7f7056a34c78
arg-types
unsigned DI
size
unit size
align 64 symtab 0 alias set 0 canonical type 0x7f705685a7e0
pointer_to_this >
chain
chain
lto1: internal compiler error: verify_type failed
0xf81484 verify_type(tree_node const*)
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/tree.c:12971
0x6c12c4 lto_fixup_state
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/lto/lto.c:2849
0x6c143b lto_fixup_decls
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/lto/lto.c:2881
0x6c1d2e read_cgraph_and_symbols
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/lto/lto.c:3102
0x6c29b3 lto_main()
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/lto/lto.c:3479
[Bug lto/66180] [6 Regression] many -Wodr false positives when building LLVM with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66180
--- Comment #8 from Markus Trippelsdorf ---
If I change foo1.cpp from comment5 to:
#include
namespace first{
class A {
int i;
};
}
using namespace first;
class G {
std::unique_ptr foo() const;
};
std::unique_ptr G::foo() const { return std::make_unique(); }
it works fine. So it looks like a bug after all, because an anonymous namespace
should be equivalent to:
namespace _compiler_generated_name {
...
}
using namespace _compiler_generated_name;
[Bug target/66215] [4.8/4.9/5/6 Regression] Wrong after label NOP emission for -mhotpatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215 --- Comment #4 from Andreas Krebbel --- (In reply to Jakub Jelinek from comment #3) > IMHO the nops should go immediately before the first real instruction in the > function. The point of not emitting it earlier is so that the nops are > already covered by debug and unwind info. > So, we certainly should skip all NOTEs at the start of the function, and > perhaps > selected other insns (dunno if e.g. UNSPECV_MAIN_POOL insn emits any code or > not). NOTE_INSN_FUNCTION_BEG is not a good place, as it can be preceeded by > various prologue instructions, and the nops really have to go before all > real instructions (that emit some bytes into the function text section). UNSPECV_MAIN_POOL does not itself emit code. However, it is used as an anchor to emit insns right after it so we should not skip it here I think. We will try with skipping all the NOTEs as you suggested and we definitely should run all the hotpatch testcases at different optimization levels. Thanks!
[Bug libstdc++/66078] 20_util/specialized_algorithms/uninitialized_copy/808590.cc fails with -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66078 --- Comment #2 from Jason Merrill --- Ping? I think this is now the only thing preventing me from throwing the switch to default C++14.
[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #9 from Rich Felker --- This is not portable usage of pthread_once. The longjmp based version is clearly wrong, per the resolution of http://austingroupbugs.net/view.php?id=863 and while POSIX has nothing to say about C++, the lack of any text forbidding the analogous C++ construct does not make a requirement to support it. FYI, this type of usage is not supported, and impossible to support, in musl's implementation of pthread_once (which does not interact with exceptions/unwinding, only with thread cancellation). There's a slim chance the C11 call_once function could be used, but I think the way it's specified also requires this kind of deadlock if you leave the init routine via any means but returning, and it's not widely supported yet anyway. I think the right solution is to use atomics directly to implement std::call_once and only fallback to pthread sync primitives in the contended case. As long as you don't pass arbitrary C++ callback functions provided by the caller to pthread_once, it should be safe to use any pthread functions.
[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- In glibc, clear_once_control should clear the pthread_once_t var on throw, wonder why it doesn't work on ppc*, seems like pthread_once.c is correctly compiled with -fexceptions. If musl doesn't want to support it, it is its own bad choice.
[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> Thanks, Martin. So maybe something like this:
>
> --- a/libstdc++-v3/include/std/mutex
> +++ b/libstdc++-v3/include/std/mutex
> @@ -726,7 +738,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>__set_once_functor_lock_ptr(&__functor_lock);
> #endif
>
> +#ifdef __powerpc__
> + int __e;
> + __try {
> + __e = __gthread_once(&__once._M_once, &__once_proxy);
> + } __catch(...) {
> + __once._M_once = once_flag{}._M_once;
N.B. This won't work because it races, and may not even compile (if e.g.
pthread_once_t has a const member)
[Bug middle-end/64928] [4.8/4.9/5/6 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 Nick Wellnhofer changed: What|Removed |Added CC||wellnhofer at aevum dot de --- Comment #19 from Nick Wellnhofer --- *** Bug 66209 has been marked as a duplicate of this bug. ***
[Bug gcov-profile/66209] Out of memory when compiling with --coverage and optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66209 Nick Wellnhofer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Nick Wellnhofer --- Yes, this seems to be the same issue. *** This bug has been marked as a duplicate of bug 64928 ***
[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 --- Comment #12 from Rich Felker --- Jakub, this is not the place to discuss the pros and cons of musl or other particular implementations; libstdc++ needs to support many which do not have the glibc-specific semantics you want. In particular there are plenty of BSDs the current code is broken on too. If you want to use pthread_once directly to implement std::call_once on glibc, that's your business, but there needs to be a portable implementation that works on other systems.
[Bug middle-end/64928] [4.8/4.9/5/6 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 Bug 64928 depends on bug 66209, which changed state. Bug 66209 Summary: Out of memory when compiling with --coverage and optimizations https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66209 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #38 from vehre at gcc dot gnu.org --- Author: vehre Date: Wed May 20 14:56:47 2015 New Revision: 223445 URL: https://gcc.gnu.org/viewcvs?rev=223445&root=gcc&view=rev Log: gcc/fortran/ChangeLog: 2015-05-19 Andre Vehreschild PR fortran/65548 * trans-stmt.c (gfc_trans_allocate): Always retrieve the descriptor or a reference to a source= expression for arrays and non-arrays, respectively. Use a temporary symbol and gfc_trans_assignment for all source= assignments to allocated objects besides for class and derived types. gcc/testsuite/ChangeLog: 2015-05-19 Andre Vehreschild PR fortran/65548 * gfortran.dg/allocate_with_source_5.f90: Extend test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90
[Bug ada/66217] PowerPC rotate/shift/mask instructions not optimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66217 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-20 CC||dje at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- Confirmed.
[Bug c++/39478] please improve recursive template instantiation diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39478 --- Comment #3 from Daniel Frey --- Just a reminder that the error message is basically still the same with GCC 4.9 and does not help to understand the cause of the error. Especially real-world cases are therefore extremely hard to understand! I realize that "recursion" might not be the most appropriate word to describe the problem, maybe "loop" or "cycle" would be more helpful. To explain the problem again: The type is incomplete as the error message says, but the real question is: Why can't the compiler complete it like it normally would? It certainly *tried* to, but it failed. This is not obvious from the error message. The loop/cycle that is caused by the attempt to complete the type is not shown in the error message. The Clang error message is slightly better as it at least contains a hint towards typename T::type dummy(); which, as T=bar is trying to access bar::type (which exists and is void), but therefore bar has to be a complete type. Note that the error obviously goes away when you use int dummy(); instead. I'd still like to see GCC to hint at the loop when trying to complete types where the completion of A requires a completed B and the completion of B requires a completed A.
[Bug c/66222] New: gcc error: invalid use of '__builtin_va_arg_pack ()' at -O2 and up & pass at noopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66222 Bug ID: 66222 Summary: gcc error: invalid use of '__builtin_va_arg_pack ()' at -O2 and up & pass at noopt Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mshzhb at gmail dot com Target Milestone: --- Created attachment 35579 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35579&action=edit source code ABSTRACT: [gcc] error: invalid use of '__builtin_va_arg_pack ()' at -O2 and up & pass at noopt DRIVER PASS: DRIVER FAIL:gcc 4.8.2 OPTIONS PASS: noopt OPTIONS FAIL: -O2 -O3 and up MACHINE DETAILS: (Optional: Specify machine name, OS and architecture) lep8244bv detail: Distributor ID: Ubuntu Description:Ubuntu 14.04.2 LTS Release:14.04 Codename: trusty Linux version 3.13.0-35-generic (buildd@fisher02) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #62-Ubuntu SMP Fri Aug 15 01:57:29 UTC 2014 Architecture: ppc64le Byte Order:Little Endian CPU(s):192 On-line CPU(s) list: 0-3,8-11,16-19,24-27,32-35,40-43,48-51,56-59,64-67,72-75,80-83,88-91,96-99,104-107,112-115,120-123,128-131,136-139,144-147,152-155,160-163,168-171,176-179,184-187 Off-line CPU(s) list: 4-7,12-15,20-23,28-31,36-39,44-47,52-55,60-63,68-71,76-79,84-87,92-95,100-103,108-111,116-119,124-127,132-135,140-143,148-151,156-159,164-167,172-175,180-183,188-191 Thread(s) per core:4 Core(s) per socket:6 Socket(s): 4 NUMA node(s): 4 Model: 8286-42A L1d cache: 64K L1i cache: 32K L2 cache: 512K L3 cache: 8192K NUMA node0 CPU(s): 0-3,8-11,16-19,24-27,32-35,40-43 NUMA node1 CPU(s): 48-51,56-59,64-67,72-75,80-83,88-91 NUMA node16 CPU(s):96-99,104-107,112-115,120-123,128-131,136-139 NUMA node17 CPU(s):144-147,152-155,160-163,168-171,176-179,184-187 PROBLEM DESCRIPTION: gcc error: invalid use of '__builtin_va_arg_pack ()' at -O2 and up but pass at noopt error information : In file included from /usr/include/stdio.h:937:0, from perlsdio.h:5, from iperlsys.h:203, from perl.h:325, from av.c:16: /usr/include/powerpc64le-linux-gnu/bits/stdio2.h: In function 'sprintf': /usr/include/powerpc64le-linux-gnu/bits/stdio2.h:33:3: error: invalid use of '__builtin_va_arg_pack ()' return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, ^ /usr/include/powerpc64le-linux-gnu/bits/stdio2.h: In function 'snprintf': /usr/include/powerpc64le-linux-gnu/bits/stdio2.h:64:3: error: invalid use of '__builtin_va_arg_pack ()' return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, ^ /usr/include/powerpc64le-linux-gnu/bits/stdio2.h: In function 'fprintf': /usr/include/powerpc64le-linux-gnu/bits/stdio2.h:97:3: error: invalid use of '__builtin_va_arg_pack ()' return __fprintf_chk (__stream, __USE_FORTIFY_LEVEL - 1, __fmt, ^ /usr/include/powerpc64le-linux-gnu/bits/stdio2.h: In function 'printf': /usr/include/powerpc64le-linux-gnu/bits/stdio2.h:104:3: error: invalid use of '__builtin_va_arg_pack ()' return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ()); ^ /usr/include/powerpc64le-linux-gnu/bits/stdio2.h: In function 'dprintf': /usr/include/powerpc64le-linux-gnu/bits/stdio2.h:141:3: error: invalid use of '__builtin_va_arg_pack ()' return __dprintf_chk (__fd, __USE_FORTIFY_LEVEL - 1, __fmt, ^ - STEPS TO REPRODUCE: (Reduce the code in the README.ksh file as much as possible) /usr/bin/gcc -m64 -D__64BIT__=1 -O3 -mcpu=power8 -fabi-version=4 -std=gnu99 -I_END_XOPTS -DSPEC_CPU2000 -DSPEC_CPU2000_LP64 -DSPEC_CPU2000_LINUX_PPC32 -DSPEC_CPU2000_NEED_BOOL -DHAS_FGETPOS -DHAS_FSETPOS -fno-strict-aliasing -c -o av.o av.c - TESTCASE SOURCE: (reduced where applicable): (this field is optional for SPEC defects) //av.c see attachment
[Bug c/66222] gcc error: invalid use of '__builtin_va_arg_pack ()' at -O2 and up & pass at noopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66222
--- Comment #1 from Tong Liu ---
//av.h
/*av.h
*
*Copyright (c) 1991-1999, Larry Wall
*
*You may distribute under the terms of either the GNU General Public
*License or the Artistic License, as specified in the README file.
*
*/
struct xpvav {
char* xav_array; /* pointer to first array element */
SSize_t xav_fill; /* Index of last element present */
SSize_t xav_max;/* Number of elements for which array has space
*/
IV xof_off;/* ptr is incremented by offset */
double xnv_nv; /* numeric value, if any */
MAGIC* xmg_magic; /* magic for scalar array */
HV* xmg_stash; /* class package */
SV**xav_alloc; /* pointer to malloced string */
SV* xav_arylen;
U8 xav_flags;
};
#define AVf_REAL 1 /* free old entries */
#define AVf_REIFY 2 /* can become real */
#define AVf_REUSED 4/* got undeffed--don't turn old memory into SVs now */
#define Nullav Null(AV*)
#define AvARRAY(av) ((SV**)((XPVAV*) SvANY(av))->xav_array)
#define AvALLOC(av) ((XPVAV*) SvANY(av))->xav_alloc
#define AvMAX(av) ((XPVAV*) SvANY(av))->xav_max
#define AvFILLp(av) ((XPVAV*) SvANY(av))->xav_fill
#define AvARYLEN(av)((XPVAV*) SvANY(av))->xav_arylen
#define AvFLAGS(av) ((XPVAV*) SvANY(av))->xav_flags
#define AvREAL(av) (AvFLAGS(av) & AVf_REAL)
#define AvREAL_on(av) (AvFLAGS(av) |= AVf_REAL)
#define AvREAL_off(av) (AvFLAGS(av) &= ~AVf_REAL)
#define AvREIFY(av) (AvFLAGS(av) & AVf_REIFY)
#define AvREIFY_on(av) (AvFLAGS(av) |= AVf_REIFY)
#define AvREIFY_off(av) (AvFLAGS(av) &= ~AVf_REIFY)
#define AvREUSED(av)(AvFLAGS(av) & AVf_REUSED)
#define AvREUSED_on(av) (AvFLAGS(av) |= AVf_REUSED)
#define AvREUSED_off(av) (AvFLAGS(av) &= ~AVf_REUSED)
#define AvREALISH(av) (AvFLAGS(av) & (AVf_REAL|AVf_REIFY))
#define AvFILL(av) ((SvRMAGICAL((SV *) (av))) \
? mg_size((SV *) av) : AvFILLp(av))
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #18 from Douglas Mencken --- > try without --disable-checking Okay, doing it now. Meanwhile. Why ``sizeof (hashval_t) * CHAR_BIT'' cannot be checked at configure time, not at buildtime nor runtime?
[Bug c++/66223] New: Diagnostic of pure virtual function call broken, including __cxa_pure_virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66223
Bug ID: 66223
Summary: Diagnostic of pure virtual function call broken,
including __cxa_pure_virtual
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.frey at gmx dot de
Target Milestone: ---
Consider this small and certainly broken program:
struct B {
B* self;
B() : self( this ) { self->f(); }
virtual void f() = 0;
};
struct D : B
{
void f() {}
};
int main()
{
D d;
}
The ctor of B calls (indirectly) the pure virtual function f(), but the vtbl is
still from B, not D (yet). Hence the program crashes. With GCC 4.9, I got:
> ./a.out
pure virtual method called
terminate called without an active exception
Aborted (core dumped)
>
Which is a good hint and I got a core dump. Fine so far. With GCC 5.1, I get
this:
> ./a.out
Segmentation fault (core dumped)
>
Which is certainly less helpful.
What is actually a lot worse is that even __cxa_pure_virtual is severly broken.
I used to have my own __cxa_pure_virtual method to provide more output
including a backtrace, something like this was my output for GCC 4.9:
> ./a.out
### EMERGENCY ###
pure virtual function called
### BACKTRACE ###
build/release/test/emergency/pure_virtual_XFAIL(coin::core::output::backtrace()+0x23)
[0x4034a3]
build/release/test/emergency/pure_virtual_XFAIL(__cxa_pure_virtual+0x47)
[0x4031f7]
build/release/test/emergency/pure_virtual_XFAIL() [0x402a09]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7ff9dd52dec5]
build/release/test/emergency/pure_virtual_XFAIL() [0x402b14]
### ABORTING ###
Aborted (core dumped)
>
After the backtrace was printed to stdout, a core dump was written. With GCC
5.1, all I get is:
> ./a.out
>
where at least the result code is not 0 (it's 128 if it helps). But no message
and no core dump.
Further experiments have shown that GCC 5.1 actually calls the terminate
handler (which I also registered via std::set_terminate). This handler prints a
backtrace and some other information when called on other errors, but for a
pure virtual call it seems to be unable to even call a simple write() to
stdout.
Please let me know if you need further help to debug and fix this problem. I
realize it's "just" a diagnostic in case of calling an unimplemented pure
virtual method which should not be done in the first place, but I think the
current situation is really hurting people when there is absolutely no message
and no core dump and the process just returns with a non-zero exit code.
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #19 from Jakub Jelinek --- (In reply to Douglas Mencken from comment #18) > > try without --disable-checking > Okay, doing it now. > > Meanwhile. Why ``sizeof (hashval_t) * CHAR_BIT'' cannot be checked at > configure time, not at buildtime nor runtime? Because it is closer to the code which it wants to guard. And, at least in optimized built, it should be a no-op - optimized away completely if the condition is true, because it can be evaluated at compile time.
[Bug c/66222] gcc error: invalid use of '__builtin_va_arg_pack ()' at -O2 and up & pass at noopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66222 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-05-20 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Please provide a preprocessed source file (ideally minimalized). av.c has #include "EXTERN.h" #include "perl.h" and we really don't have those headers.
[Bug c/66220] -Wmisleading-indentation false/inconsistent warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66220
--- Comment #2 from David Malcolm ---
Thanks.
I ran into a variant of this whilst testing -Wmisleading-indentation on the
linux kernel, where a preprocessor macro conditionalizes the "if/else"; here's
the test case I reduced it to:
/* This variant of K&R-style formatting (in the presence of conditional
compilation) shouldn't lead to a warning.
Based on false positive seen with r223098 when compiling
linux-4.0.3:arch/x86/crypto/aesni-intel_glue.c:aesni_init. */
void
fn_36 (void)
{
#if 1 /* e.g. some configuration variable. */
if (flagA) {
foo(0);
foo(1);
foo(2);
} else
#endif
{
foo(3);
foo(4);
foo(5);
}
foo(6); /* We shouldn't warn here. */
}
I have a fix for this, by requiring that the visual column of the guard
("else") be <= that of the stmts, which works for all of the testcases
(including the new ones I posted as
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01846.html ), apart from fn_15:
#define FOR_EACH(VAR, START, STOP) for ((VAR) = (START); (VAR) < (STOP);
(VAR++)) /* { dg-message "36: ...this 'for' clause, but it is not" } */
void fn_15 (void)
{
int i;
FOR_EACH (i, 0, 10) /* { dg-message "3: in expansion of macro" } */
foo (i);
bar (i, i); /* { dg-warning "statement is indented as if it were guarded
by..." } */
}
#undef FOR_EACH
which then fails to report the warning due to it using the location of the
"for" in the defn of macro FOR_EACH.
Fixing that will require some reworking on how we handle macro expansions.
[Bug c++/39478] please improve recursive template instantiation diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39478 --- Comment #4 from Manuel López-Ibáñez --- (In reply to Daniel Frey from comment #3) > instead. I'd still like to see GCC to hint at the loop when trying to > complete types where the completion of A requires a completed B and the > completion of B requires a completed A. Then, what output do you propose for the testcase above? I'm not even sure GCC knows there is cycle. It probably only knows that the type is not complete at a time where the standard says it should be complete, and it doesn't try to figure out why it is not.
[Bug c++/66223] Diagnostic of pure virtual function call broken, including __cxa_pure_virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66223 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-20 Ever confirmed|0 |1
[Bug c++/39478] please improve recursive template instantiation diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39478 --- Comment #5 from Daniel Frey --- I don't know if it is possible for GCC to know, but it feels like it should know. If one type needs to instantiate another type, this goes on until either everything worked or GCC stops to instantiate a sub-type because this is already part of the current "stack" of template instantiations. Maybe I lack the background to understand what else the compiler could do, but it seems to me that it must somehow detect where to stop and instead bail out with an incomplete type which is then triggering the current error message in the caller which does require the instantiation to be successful. An error message could therefore look like this IMHO: t.cc: In instantiation of 'foo >' t.cc:14: instantiated from here foo< bar< int > > x; ^ t.cc:14: error: cyclic instantiation dependency in 'foo >' t.cc:4: instantiating 'bar' required for 'foo >' typename T::type dummy(); ^ t.cc:11: instantiating 'foo >' required for 'bar', end of cycle foo< bar > p; ^
[Bug c/66220] -Wmisleading-indentation false/inconsistent warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66220 David Malcolm changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org --- Comment #3 from David Malcolm --- Patch posted as: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01858.html
[Bug target/66224] New: PowerPC _GLIBCXX_READ_MEM_BARRIER too weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66224 Bug ID: 66224 Summary: PowerPC _GLIBCXX_READ_MEM_BARRIER too weak Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org Target Milestone: --- _GLIBCXX_READ_MEM_BARRIER should be lwsync on PowerPC for acquire barrier (fence), not isync.
[Bug target/66224] PowerPC _GLIBCXX_READ_MEM_BARRIER too weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66224 David Edelsohn changed: What|Removed |Added Target||powerpc*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-20 CC||bergner at gcc dot gnu.org, ||munroesj at us dot ibm.com, ||seurer at us dot ibm.com, ||wschmidt at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- Confirmed.
[Bug libstdc++/66145] [5/6 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-20 Known to work||4.8.4, 4.9.2 Summary|std::ios_base::failure |[5/6 Regression] |objects thrown from |std::ios_base::failure |libstdc++.so use old ABI|objects thrown from ||libstdc++.so use old ABI Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Let's call this a regression, since the testcase used to catch the exception, but now doesn't with the default build settings.
[Bug libstdc++/66078] 20_util/specialized_algorithms/uninitialized_copy/808590.cc fails with -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66078 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Wed May 20 17:11:03 2015 New Revision: 223449 URL: https://gcc.gnu.org/viewcvs?rev=223449&root=gcc&view=rev Log: PR libstdc++/66078 * include/bits/stl_iterator.h (__make_move_if_noexcept_iterator): Add overload for pointers. * testsuite/20_util/specialized_algorithms/uninitialized_copy/ 808590.cc: Add -std=gnu++03 switch. * testsuite/20_util/specialized_algorithms/uninitialized_copy/ 808590-cxx11.cc: Copy of 808590.cc to test with -std=gnu++11. * testsuite/23_containers/vector/modifiers/push_back/ strong_guarantee.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/808590-cxx11.cc - copied, changed from r223442, trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/808590.cc trunk/libstdc++-v3/testsuite/23_containers/vector/modifiers/push_back/strong_guarantee.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_iterator.h trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/808590.cc
[Bug libstdc++/66078] 20_util/specialized_algorithms/uninitialized_copy/808590.cc fails with -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66078 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #4 from Jonathan Wakely --- Fixed on trunk.
[Bug target/65730] xtensa: ICE in libstdc++-v3/include/bits/atomic_base.h: In function ‘bool std::atomic_flag_test_and_set_explicit(std::__atomic_flag_base*, std::memory_order)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65730 --- Comment #2 from jcmvbkbc at gcc dot gnu.org --- Author: jcmvbkbc Date: Wed May 20 18:56:14 2015 New Revision: 223452 URL: https://gcc.gnu.org/viewcvs?rev=223452&root=gcc&view=rev Log: Fix PR target/65730 2015-05-20 Max Filippov gcc/ * config/xtensa/xtensa.c (init_alignment_context): Replace MULT by BITS_PER_UNIT with ASHIFT by exact_log2 (BITS_PER_UNIT). Modified: trunk/gcc/ChangeLog trunk/gcc/config/xtensa/xtensa.c
[Bug target/65730] xtensa: ICE in libstdc++-v3/include/bits/atomic_base.h: In function ‘bool std::atomic_flag_test_and_set_explicit(std::__atomic_flag_base*, std::memory_order)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65730 jcmvbkbc at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from jcmvbkbc at gcc dot gnu.org --- Fixed.
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #20 from Douglas Mencken --- I'm lost. “Vanilla” 5.1.0 configured without --disable-checking went thru stage2 w/o any issue...
[Bug libgcc/66225] New: libgcc/config/rs6000/morecore.S will not build on systems with an older assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66225 Bug ID: 66225 Summary: libgcc/config/rs6000/morecore.S will not build on systems with an older assembler Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: amodra at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- Host: powerpc64-unknown-linux-gnu Target: powerpc64-unknown-linux-gnu Build: powerpc64-unknown-linux-gnu I downloaded subversion id 223451 of GCC and tried to build it on my big endian power7 system running Sles 11r3, and it would not build due to the use of the .abiversion pseudo op that is not available in either the host assembler or in the Advance Toolchain 7.0 assembler.
[Bug libgcc/66225] libgcc/config/rs6000/morecore.S will not build on systems with an older assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66225 Michael Meissner changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-05-20 Ever confirmed|0 |1 Severity|normal |blocker
[Bug libgcc/66225] libgcc/config/rs6000/morecore.S will not build on systems with an older assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66225 --- Comment #1 from Michael Meissner --- Created attachment 35580 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35580&action=edit Proposed patch to fix the problem I just wrote this patch, and I'm starting a bootstrap build with it.
[Bug c++/66216] [6 Regression] Defaulted Operators and constructors not working with aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66216 --- Comment #2 from James Almer --- (In reply to Jonathan Wakely from comment #1) > And now it gives an ICE on trunk, so it's regressed from rejects-valid to > ice-on-valid-code: > > a.cc:1:7: internal compiler error: canonical types differ for identical > types const CMymy and const CMymy > class CMymy This may be a duplicate of pr65936 then, or related.
[Bug c/66226] New: Incorrect code generation ppc, later assignment causes calling argument corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66226
Bug ID: 66226
Summary: Incorrect code generation ppc, later assignment causes
calling argument corruption
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: steven.deller at ois dot com
Target Milestone: ---
Created attachment 35581
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35581&action=edit
Interim file
In the attached code, a simple assignment "rp = res" after the call to
getaddrinfo causes the arguments to getaddrinfo to be invalid, most likely the
hints argument, since making that argument NULL also allows the compiled code
to execute successfully.
An assignment following a call should not cause different behavior within the
call.
This only fails on the PowerPC compiler (I only have tested it on AIX). It
fails for versions 4.7.3, 4.8.3 and this reported 4.9.3 version.
The gcc compiler is the version supplied from AdaCore with the GNAT products.
I do not have access to the build information for the compiler.
Regards,
Steven Deller
410-757-6924
tga.c source:
#include
#include
#include
int main(int argc, char **argv) {
struct addrinfo *res;
struct addrinfo hints;
int rc;
struct addrinfo *rp;
hints.ai_family = AF_INET; /* IPv4 only */
hints.ai_socktype = SOCK_DGRAM;
hints.ai_flags = 0;
hints.ai_protocol = 0;
hints.ai_canonname = NULL;
hints.ai_addr = NULL;
hints.ai_next = NULL;
rc = getaddrinfo("aix7", NULL, &hints, &res); // if hints is "NULL",
runs fine
rp = res; // rc=11 with this in. Comment out and rc=0.
printf ("rc=%d\n", rc);
return 0;
}
output from "gcc -v -save-temps tga.c" compilation:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../libexec/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/lto-wrapper
Target: powerpc-ibm-aix7.1.0.0
Configured with: ../src/configure --enable-languages=ada,c --with-gnu-as
--with-gnu-ld --with-dwarf2 --disable-shared
--disable-build-poststage1-with-cxx --disable-libsanitizer --disable-libcilkrts
--with-bugurl=URL:mailto:rep...@adacore.com --disable-nls
--without-libiconv-prefix --disable-libmudflap --disable-libstdcxx-pch
--disable-libada --enable-checking=release --enable-multilib --disable-plugin
--with-mpfr=/sully.a/gnatmail/sandbox/gnat-7.3.1/ppc-aix-linux/mpfr/install
--with-gmp=/sully.a/gnatmail/sandbox/gnat-7.3.1/ppc-aix-linux/gmp/install
--with-mpc=/sully.a/gnatmail/sandbox/gnat-7.3.1/ppc-aix-linux/mpc/install
--with-build-time-tools=/sully.a/gnatmail/sandbox/gnat-7.3.1/ppc-aix/gcc/build/buildtools/bin
--prefix=/usr/local/gnat --target=powerpc-ibm-aix7.1.0.0
--host=powerpc-ibm-aix7.1.0.0 --build=i686-pc-linux-gnu
Thread model: aix
gcc version 4.9.3 20141101 for GNAT Pro 7.3.1 (20150118) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps'
/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../libexec/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/cc1
-E -quiet -v -iprefix
/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/
tga.c -fpch-preprocess -o tga.i
ignoring nonexistent directory
"/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/../../../../powerpc-ibm-aix7.1.0.0/include"
ignoring duplicate directory
"/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../lib/gcc/../../lib/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/include"
ignoring duplicate directory
"/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../lib/gcc/../../lib/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/include-fixed"
ignoring nonexistent directory
"/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../lib/gcc/../../lib/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/../../../../powerpc-ibm-aix7.1.0.0/include"
#include "..." search starts here:
#include <...> search starts here:
/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/include
/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/include-fixed
/usr/local/include
/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../lib/gcc/../../include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps'
/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../libexec/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/cc1
-fpreprocessed tga.i -quiet -dumpbase tga.c -auxbase tga -version -o tga.s
GNU C (GCC) version 4.9.3 20141101 for GNAT Pro 7.3.1 (20150118)
(powerpc-ibm-aix7.1.0.0)
compiled by GNU C version 4.9.3 20141101 for GNAT Pro 7.3.1 (20150118),
GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=32768
GNU C (GCC) version 4.9.3 20141101 for GNAT Pro 7.3.1 (20150118)
(powerpc-ib
[Bug fortran/66227] New: [OOP] EXTENDS_TYPE_OF n returns wrong result for polymorphic variable allocated to extended type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66227 Bug ID: 66227 Summary: [OOP] EXTENDS_TYPE_OF n returns wrong result for polymorphic variable allocated to extended type Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: patnel97269-gfortran at yahoo dot fr Target Milestone: --- Hi, The extends_type_of intrisic return the wrong value for the a polymorphic variable allocated to a daughter class. See small code below. Code tested on version 5.1.0 . implicit none type t1 integer :: a end type t1 type, extends(t1):: t11 integer :: b end type t11 type(t1) a1 type(t11) a11 class(t1), allocatable :: b1,bb1 class(t11), allocatable :: b11 allocate(t11::b1) print *, extends_type_of(b1,a11) ! T print *, extends_type_of(b1,a1) ! T deallocate(b1) allocate(b1,source=a11) print *, extends_type_of(b1,a11) ! T print *, extends_type_of(b1,a1) ! T allocate( b11,source=a11) print *, extends_type_of(b11,a11) ! T print *, extends_type_of(b11,a1) ! T allocate( bb1,source=a1) print *, extends_type_of(bb1,a11) ! F print *, extends_type_of(bb1,a1) ! T end
[Bug libgcc/66212] Exception handling broken on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66212 --- Comment #2 from Jim Wilson --- libgcc should be built with debug info by default, but the one in /lib is probably stripped. Try setting LD_LIBRARY_PATH to point at the gcc-5.1 libraries that you built, instead of using the default ones provided by the OS in /lib.
[Bug libgcc/66225] libgcc/config/rs6000/morecore.S will not build on systems with an older assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66225 --- Comment #2 from Michael Meissner --- The proposed patch allows the big endian powerpc build to build and install.
[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #18 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #16) > > Also arguments of emit_move_insn must have the same integer modes. > > if (reg_overlap_mentioned_p (operands[1], operands[2])) > std::swap (operands[0], operands[2]); > > sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[3])); > > might ICE if operands[0] and operands[2] have different modes and > swap happens, though I'm not sure whether such insns are real or not. Yes, that is true. However, because op0, op1, op2 are all "arith_reg_dest" the peephole will only match if those are GP regs. Each captured insn will only reference a single GP reg, because DImode moves should have been smashed into SImode moves before the peephole2 pass. Thus, I think it should be safe to just force the mode of op0 to SImode. I'll try it out.
[Bug target/66226] Incorrect code generation ppc, later assignment causes calling argument corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66226 Andrew Pinski changed: What|Removed |Added Component|c |target --- Comment #1 from Andrew Pinski --- This sounds more likegetaddrinfo is over writing past the variable hints.
[Bug lto/66228] New: Compiling simple program with -flto -O1 causes mad behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66228 Bug ID: 66228 Summary: Compiling simple program with -flto -O1 causes mad behaviour Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: t...@the-tk.com Target Milestone: --- Created attachment 35582 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35582&action=edit This is the wtf.i file left over from running gcc -v -save-temps -flto -O1 wtf.c This code, when compiled with -O1 and -flto and ran with no arguments passed prints: ./a.out: Incorrect number of arguments ./a.out: WTF? And exits returning 1. This behaviour is obviously incorrect. This has been tested on versions (various people): 4.8.4 4.9.2 20150304 5.1.0 20150505 5.1.1 20150519 The version I am personally using is 4.9.2 20150304. Here is the output of `gcc -v -save-temps -flto -O1 wtf.c': Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc/src/gcc-4.9-20150304/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --disable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 4.9.2 20150304 (prerelease) (GCC) COLLECT_GCC_OPTIONS='-B' '/usr/lib/hardening-wrapper/bin' '-fPIE' '-D' '_FORTIFY_SOURCE=2' '-pie' '-fstack-protector-strong' '-v' '-save-temps' '-flto' '-O1' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1 -E -quiet -v -D _FORTIFY_SOURCE=2 wtf.c -mtune=generic -march=x86-64 -fPIE -fstack-protector-strong -flto -O1 -fpch-preprocess -o wtf.i ignoring nonexistent directory "/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include /usr/local/include /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-B' '/usr/lib/hardening-wrapper/bin' '-fPIE' '-D' '_FORTIFY_SOURCE=2' '-pie' '-fstack-protector-strong' '-v' '-save-temps' '-flto' '-O1' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1 -fpreprocessed wtf.i -quiet -dumpbase wtf.c -mtune=generic -march=x86-64 -auxbase wtf -O1 -version -fPIE -fstack-protector-strong -flto -o wtf.s GNU C (GCC) version 4.9.2 20150304 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.9.2 20150304 (prerelease), GMP version 6.0.0, MPFR version 3.1.2-p11, MPC version 1.0.2 warning: MPC header version 1.0.2 differs from library version 1.0.3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.9.2 20150304 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.9.2 20150304 (prerelease), GMP version 6.0.0, MPFR version 3.1.2-p11, MPC version 1.0.2 warning: MPC header version 1.0.2 differs from library version 1.0.3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: de1e8c8938fc18eb6d7bf643b5ef22cd COLLECT_GCC_OPTIONS='-B' '/usr/lib/hardening-wrapper/bin' '-fPIE' '-D' '_FORTIFY_SOURCE=2' '-pie' '-fstack-protector-strong' '-v' '-save-temps' '-flto' '-O1' '-mtune=generic' '-march=x86-64' as -v --64 -o wtf.o wtf.s GNU assembler version 2.25.0 (x86_64-unknown-linux-gnu) using BFD version (GNU Binutils) 2.25.0 COMPILER_PATH=/usr/lib/hardening-wrapper/bin/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/ LIBRARY_PATH=/usr/lib/hardening-wrapper/bin/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-B' '/usr/lib/hardening-wrapper/bin' '-fPIE' '-D' '_FORTIFY_SOURCE=2' '-pie' '-fstack-protector-strong' '-v' '-save-temps' '-flto' '-O1' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/collect2 -plugin /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-w
[Bug lto/66229] New: LTO fails with -fauto-profile on mcf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66229
Bug ID: 66229
Summary: LTO fails with -fauto-profile on mcf
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: hubicka at gcc dot gnu.org
Reporter: spop at gcc dot gnu.org
CC: dehao at gcc dot gnu.org, hiraditya at msn dot com
Target Milestone: ---
lto1: internal compiler error: in compute_working_sets, at gcov-io.c:1006
0x790dad compute_working_sets(gcov_ctr_summary const*, gcov_working_set_info*)
../../gcc/gcov-io.c:1006
0xba0faa get_working_sets()
../../gcc/profile.c:264
0xaf0ac7 input_symtab()
../../gcc/lto-cgraph.c:1880
0x6c3da0 read_cgraph_and_symbols
../../gcc/lto/lto.c:3061
0x6c4be9 lto_main()
../../gcc/lto/lto.c:3479
MCF from SPEC 2006 on x86_64-linux and other programs would fail with LTO +
AutoFDO with the following flags:
COPTIMIZE = -Ofast -g3 -fno-strict-aliasing -flto
-fauto-profile=mcf_base.gcc43-64bit.gcov
This fails with both trunk gcc and with the 5.1 release.
Also fails with an empty profile.
We collected the profile with create_gcov from a linux perf data.
We ran gdb on lto1 and have seen that the crash happens in gcov reader of lto:
gcc/gcov-io.c:1006
/* Compute the working set information from the counter histogram in
the profile summary. This is an array of information corresponding to a
range of percentages of the total execution count (sum_all), and includes
the number of counters required to cover that working set percentage and
the minimum counter value in that working set. */
GCOV_LINKAGE void
compute_working_sets (const struct gcov_ctr_summary *summary,
gcov_working_set_t *gcov_working_sets)
{
[...]
/* Next, walk through the histogram in decending order of hotness
and compute the statistics for the working set summary array.
As histogram entries are accumulated, we check to see which
working set entries have had their expected cum_value reached
and fill them in, walking the working set entries in increasing
size of cum_value. */
ws_ix = 0; /* The current entry into the working set array. */
cum = 0; /* The current accumulated counter sum. */
count = 0; /* The current accumulated count of block counters. */
for (h_ix = GCOV_HISTOGRAM_SIZE - 1;
h_ix >= 0 && ws_ix < NUM_GCOV_WORKING_SETS; h_ix--)
{
histo_bucket = &summary->histogram[h_ix];
/* If we haven't reached the required cumulative counter value for
the current working set percentage, simply accumulate this histogram
entry into the running sums and continue to the next histogram
entry. */
if (cum + histo_bucket->cum_value < working_set_cum_values[ws_ix])
{
cum += histo_bucket->cum_value;
count += histo_bucket->num_counters;
continue;
}
[Here continue is always taken such that ws_ix never gets incremented.]
[...]
}
gcov_nonruntime_assert (ws_ix == NUM_GCOV_WORKING_SETS);
[And this would assert because ws_ix is still 0.]
