[Bug debug/92418] New: g++ does not produce the DW_AT_calling_convention attribute for types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92418
Bug ID: 92418
Summary: g++ does not produce the DW_AT_calling_convention
attribute for types
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: tankut.baris.aktemur at intel dot com
Target Milestone: ---
DWARF5 introduced the DW_AT_calling_convention attribute for *types*. Below is
the related section from the DWARF5 spec:
A structure type, union type or class type entry may have a
DW_AT_calling_convention attribute, whose value indicates whether a value
of the type is passed by reference or passed by value. The set of calling
convention codes for use with types is given in Table 5.5 following.
Table 5.5: Calling convention codes for types
DW_CC_normal
DW_CC_pass_by_value
DW_CC_pass_by_reference
GCC does not emit the DW_AT_calling_convention attribute for types. For
example, given the following C++ program, the DIE for the ByVal class could
include the 'DW_CC_pass_by_value' value in a DW_AT_calling_convention
attribute, whereas the type information for the ByRef class could include
'DW_CC_pass_by_reference'.
Tested with GCC 9.2.1.
~~~
class ByVal {
public:
ByVal () { x = 2; }
int x;
};
class ByRef {
public:
ByRef () { x = 2; }
ByRef (const ByRef &rhs) { x = 3; }
int x;
};
int
cbv1 (ByVal arg)
{
return arg.x;
}
int
cbv2 (ByRef arg)
{
return arg.x;
}
int
main ()
{
ByVal val;
ByRef ref;
return cbv1 (val) + cbv2 (ref);
}
~~~
[Bug fortran/91253] [9/10 Regression] gfortran.dg/continuation_6.f fails when using -pre_include as done with latest glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91253 --- Comment #2 from Tobias Burnus --- Author: burnus Date: Fri Nov 8 08:14:40 2019 New Revision: 277948 URL: https://gcc.gnu.org/viewcvs?rev=277948&root=gcc&view=rev Log: Fortran] PR91253 fix continuation-line handling with -pre_include PR fortran/91253 * scanner.c (skip_fixed_comments): Move comment lines to next if block. (gfc_next_char_literal): Fix continue_line setting. (get_file): Remove bogus ATTRIBUTE_UNUSED. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/scanner.c
[Bug c/92088] aggregates with VLAs and nested functions are broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92088 --- Comment #8 from rguenther at suse dot de --- On Thu, 7 Nov 2019, joseph at codesourcery dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92088 > > --- Comment #7 from joseph at codesourcery dot com dot com> --- > Yes, pointers to VLA are variably modified (but are OK in function > arguments even for extern functions, as VLAs there get treated as [*]). > > So maybe you should use C_TYPE_VARIABLE_SIZE as the test on the types of > the arguments (and the return value, or is it OK for that to be > variable-size?). OK, will check with C_TYPE_VARIABLE_SIZE. The cases with VLA return types I saw all used RSO which works fine, we wouldn't handle other cases OK. VLAs really are all the same as C++ classes with non-trivial CTORs (where the types are TREE_ADDRESSABLE) here. Which is also why we should pass VLAs by reference (and have the FE set up the non-trivial copy at the caller). So for more appropriate middle-end handling we maybe should set TREE_ADDRESSABLE on C_TYPE_VARIABLE_SIZE types? So as said, avoiding the inlining with the proposed patch is just a workaround for missing FE support for passing VLAs by value. I think the middle-end "knows" how to handle the complication of passing the argument by seeing WITH_SIZE_EXPR on it, likewise for stores from a return value where WITH_SIZE_EXPR should appear on the LHS. Guess I need to find a testcase to trigger this with inlining and no RSO but it looks like the gimplifier always forces RSO for VLA returns: else if (TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (*to_p))) != INTEGER_CST) /* Always use the target and thus RSO for variable-sized types. GIMPLE cannot deal with a variable-sized assignment embedded in a call statement. */ use_target = true; but the gimplifier cannot do the same for arguments (DECL_BY_REFERENCE). Using DECL_BY_REFERENCE in the FE requires adjustments to how it builds calls to VLA typed functions, I'm not set up to dig into that.
[Bug tree-optimization/92401] [10 Regression] ICE in fold_ternary_loc, at fold-const.c:11698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92401 --- Comment #4 from Jakub Jelinek --- Created attachment 47197 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47197&action=edit gcc10-pr92401.patch Full untested patch.
[Bug fortran/91253] [9/10 Regression] gfortran.dg/continuation_6.f fails when using -pre_include as done with latest glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91253 --- Comment #3 from Martin Liška --- Thank you Tobias for the fix.
[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #6 from Rainer Orth --- (In reply to Martin Liška from comment #5) > > > > I have to leave the office now but I am testing the attached fix on an > > x86_64 - I have lost connection to the i686 I was using (gcc45). > > I would recommend here to use your machine and set up a KVM where you can > install i686 openSUSE. It's likely much faster machine that we have in > compile farm ;) Why so complicated: you could just as well build a bi-arch x86_64 gcc and test both multilibs. That's what I'm doing on both Solaris/x86 and Linux/x86_64 all the time. Catches a large number of issues that don't show up on 64-bit.
[Bug target/92055] [avr] Support 64-bit double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92055 --- Comment #8 from Georg-Johann Lay --- Author: gjl Date: Fri Nov 8 08:49:07 2019 New Revision: 277954 URL: https://gcc.gnu.org/viewcvs?rev=277954&root=gcc&view=rev Log: PR target/92055 * config/avr/avr.opt (-mdouble=, -mlong-double=): Fix a missing '-' when displaying these options in the help screen. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.opt
[Bug middle-end/92410] Invalid access to df->insns[] in regstat_bb_compute_calls_crossed (caught by hwasan)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410
--- Comment #2 from Martin Liška ---
One can see it with the following patch:
diff --git a/gcc/regstat.c b/gcc/regstat.c
index 4da9b7cc523..c6cefb117d7 100644
--- a/gcc/regstat.c
+++ b/gcc/regstat.c
@@ -324,6 +324,7 @@ regstat_bb_compute_calls_crossed (unsigned int bb_index,
bitmap live)
FOR_BB_INSNS_REVERSE (bb, insn)
{
+ gcc_assert (INSN_UID (insn) < DF_INSN_SIZE ());
struct df_insn_info *insn_info = DF_INSN_INFO_GET (insn);
unsigned int regno;
and with the following test-case:
$ cat /tmp/ice.i
int v;
int a() {
;
return v;
}
$ ./xgcc -B. /tmp/ice.i -O2 -c -g
during RTL pass: sched2
/tmp/ice.i: In function ‘a’:
/tmp/ice.i:6:1: internal compiler error: in regstat_bb_compute_calls_crossed,
at regstat.c:327
6 | }
| ^
0x10519d1 regstat_bb_compute_calls_crossed
../../gcc/regstat.c:327
0x1051c0e regstat_compute_calls_crossed()
../../gcc/regstat.c:380
0x1d30bbd sched_init()
../../gcc/haifa-sched.c:7337
0x1d30c21 haifa_sched_init()
../../gcc/haifa-sched.c:7354
0x10acbac schedule_insns()
../../gcc/sched-rgn.c:3514
0x10ad507 rest_of_handle_sched2
../../gcc/sched-rgn.c:3746
0x10ad6ce execute
../../gcc/sched-rgn.c:3882
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug middle-end/92410] Invalid access to df->insns[] in regstat_bb_compute_calls_crossed (caught by hwasan)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410 Martin Liška changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org Known to fail||10.0, 7.4.0 --- Comment #3 from Martin Liška --- Confirmed also with r247015 (GCC 7 branch point). @Vladimir: Can you please take a look?
[Bug middle-end/92410] Invalid access to df->insns[] in regstat_bb_compute_calls_crossed (caught by hwasan)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410 --- Comment #4 from Martin Liška --- Can be reproduced with a aarch64 cross compiler on x86-64-linux-gnu.
[Bug c/92324] [10 Regression] ICE in expand_direct_optab_fn, at internal-fn.c:2890
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92324 --- Comment #4 from Richard Biener --- Author: rguenth Date: Fri Nov 8 09:01:41 2019 New Revision: 277955 URL: https://gcc.gnu.org/viewcvs?rev=277955&root=gcc&view=rev Log: 2019-11-08 Richard Biener PR tree-optimization/92324 * tree-vect-loop.c (vect_create_epilog_for_reduction): Use STMT_VINFO_REDUC_VECTYPE for all computations, inserting sign-conversions as necessary. (vectorizable_reduction): Reject conversions in the chain that are not sign-conversions, base analysis on a non-converting stmt and its operation sign. Set STMT_VINFO_REDUC_VECTYPE. * tree-vect-stmts.c (vect_stmt_relevant_p): Don't dump anything for debug stmts. * tree-vectorizer.h (_stmt_vec_info::reduc_vectype): New. (STMT_VINFO_REDUC_VECTYPE): Likewise. * gcc.dg/vect/pr92205.c: XFAIL. * gcc.dg/vect/pr92324-1.c: New testcase. * gcc.dg/vect/pr92324-2.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr92205.c trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vect-stmts.c trunk/gcc/tree-vectorizer.h
[Bug c/92324] [10 Regression] ICE in expand_direct_optab_fn, at internal-fn.c:2890
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92324 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug debug/92418] g++ does not produce the DW_AT_calling_convention attribute for types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92418 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-08 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug c/92324] [10 Regression] ICE in expand_direct_optab_fn, at internal-fn.c:2890
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92324 --- Comment #6 from Uroš Bizjak --- (In reply to Richard Biener from comment #4) > Author: rguenth > Date: Fri Nov 8 09:01:41 2019 > New Revision: 277955 > > URL: https://gcc.gnu.org/viewcvs?rev=277955&root=gcc&view=rev > Log: > 2019-11-08 Richard Biener > > PR tree-optimization/92324 > * tree-vect-loop.c (vect_create_epilog_for_reduction): Use > STMT_VINFO_REDUC_VECTYPE for all computations, inserting > sign-conversions as necessary. > (vectorizable_reduction): Reject conversions in the chain > that are not sign-conversions, base analysis on a non-converting > stmt and its operation sign. Set STMT_VINFO_REDUC_VECTYPE. > * tree-vect-stmts.c (vect_stmt_relevant_p): Don't dump anything > for debug stmts. > * tree-vectorizer.h (_stmt_vec_info::reduc_vectype): New. > (STMT_VINFO_REDUC_VECTYPE): Likewise. > > * gcc.dg/vect/pr92205.c: XFAIL. > * gcc.dg/vect/pr92324-1.c: New testcase. > * gcc.dg/vect/pr92324-2.c: Likewise. > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/testsuite/ChangeLog > trunk/gcc/testsuite/gcc.dg/vect/pr92205.c > trunk/gcc/tree-vect-loop.c > trunk/gcc/tree-vect-stmts.c > trunk/gcc/tree-vectorizer.h New testcases were not committed for some reason.
[Bug tree-optimization/92412] excessive errno aliasing assumption defeats optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92412
--- Comment #2 from Richard Biener ---
The DECL_EXTERNAL is what should make the difference but IIRC a errno.h
with a tentative definition would be conforming, no? And that woudln't
be DECL_EXTERNAL ...
TREE_READONLY should be handled more generally,
/* If the reference is based on a decl that is not aliased the call
cannot possibly clobber it. */
if (DECL_P (base)
&& !may_be_aliased (base)
/* But local non-readonly statics can be modified through recursion
or the call may implement a threading barrier which we must
treat as may-def. */
&& (TREE_READONLY (base)
|| !is_global_var (base)))
return false;
gives a hint (but doesn't apply here due to the var being address-taken).
I think we could split out
if (DECL_P (base)
&& TREE_READONLY (base))
return false;
? I know I'm usually overly cautionous with const vs non-const, but on
decls it should work. OTOH...
int var;
const int const_var __attribute__((alias("var")));
is likely a valid way to "document" that some parts cannot modify 'var'
but for
int foo()
{
int tem = const_var;
bar ();
return const_var;
}
we cannot elide the second load because bar() might modify it via a store
to 'var'.
Likewise interposing a const int def with a non-const int def is probably
OK.
Thus we'd need to ask the varpool if 'base' is prevailing, look at the
ultimate alias target and only take that vars const-ness into account...
(ick).
[Bug middle-end/92419] New: const variable aliases lead to folding non-const initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92419
Bug ID: 92419
Summary: const variable aliases lead to folding non-const
initializers
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
int var = 3;
extern const int const_var __attribute__((alias("var")));
void bar()
{
var = 5;
}
int foo()
{
int tem = const_var;
bar ();
return const_var;
}
int main()
{
if (foo() != 5)
__builtin_abort ();
return 0;
}
[Bug tree-optimization/92412] excessive errno aliasing assumption defeats optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92412 --- Comment #3 from Richard Biener --- PR92419 for that mess...
[Bug fortran/91253] [9/10 Regression] gfortran.dg/continuation_6.f fails when using -pre_include as done with latest glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91253 --- Comment #4 from Tobias Burnus --- Author: burnus Date: Fri Nov 8 09:25:40 2019 New Revision: 277957 URL: https://gcc.gnu.org/viewcvs?rev=277957&root=gcc&view=rev Log: Fortran] PR91253 fix continuation-line handling with -pre_include Backport from mainline 2019-11-08 Tobias Burnus
[Bug fortran/91253] [9/10 Regression] gfortran.dg/continuation_6.f fails when using -pre_include as done with latest glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91253 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Tobias Burnus --- (In reply to Martin Liška from comment #3) > Thank you Tobias for the fix. You are welcome – it also bothered me, when running the test suite. FIXED on the trunk and GCC 9.
[Bug middle-end/92419] const variable aliases lead to folding non-const initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92419 Richard Biener changed: What|Removed |Added Keywords||wrong-code CC||hubicka at gcc dot gnu.org Known to fail||10.0, 8.3.0, 9.2.0 --- Comment #1 from Richard Biener --- GCC 7+ abort at -O0 already, GCC 4.8.5 only with optimization. We fold the const_var read to 3 (oops). But the testcase also makes sure that the read wouldn't be CSEd over the call to bar(). With symbol interposition it would be valid to interpose const var with a non-const one as well, no? (IIRC that came up in another bug where we concluded we can ignore that) So the thing is to fix constant folding and guide alias analysis when we can safely assume a call doesn't modify a TREE_READONLY variable.
[Bug c/92324] [10 Regression] ICE in expand_direct_optab_fn, at internal-fn.c:2890
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92324 --- Comment #7 from Richard Biener --- Author: rguenth Date: Fri Nov 8 09:30:52 2019 New Revision: 277958 URL: https://gcc.gnu.org/viewcvs?rev=277958&root=gcc&view=rev Log: 2019-11-08 Richard Biener PR tree-optimization/92324 * tree-vect-loop.c (vect_create_epilog_for_reduction): Use STMT_VINFO_REDUC_VECTYPE for all computations, inserting sign-conversions as necessary. (vectorizable_reduction): Reject conversions in the chain that are not sign-conversions, base analysis on a non-converting stmt and its operation sign. Set STMT_VINFO_REDUC_VECTYPE. * tree-vect-stmts.c (vect_stmt_relevant_p): Don't dump anything for debug stmts. * tree-vectorizer.h (_stmt_vec_info::reduc_vectype): New. (STMT_VINFO_REDUC_VECTYPE): Likewise. * gcc.dg/vect/pr92205.c: XFAIL. * gcc.dg/vect/pr92324-1.c: New testcase. * gcc.dg/vect/pr92324-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/vect/pr92324-1.c trunk/gcc/testsuite/gcc.dg/vect/pr92324-2.c
[Bug tree-optimization/92420] New: [7/8/9/10 Regression] Vectorization miscompilation with negative strides since r238039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92420
Bug ID: 92420
Summary: [7/8/9/10 Regression] Vectorization miscompilation
with negative strides since r238039
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
The following testcase is miscompiled on x86_64-linux, e.g. with -O3 -mavx2 or
-O3 -mssse3 since r238039:
#define N 16
struct C { int r, i; };
struct C a[N], b[N], c[N], d[N], e[N];
__attribute__((noipa)) static void
foo (struct C *__restrict x, struct C *__restrict y, struct C *__restrict z,
int w)
{
int i;
for (int i = 0; i < w; i++)
{
z[i].r = x[i].r * y[-1 - i].r - x[i].i * y[-1 - i].i;
z[i].i = x[i].i * y[-1 - i].r + x[i].r * y[-1 - i].i;
}
}
__attribute__((noipa)) static void
bar (struct C *__restrict x, struct C *__restrict y, struct C *__restrict z,
int w)
{
int i;
for (int i = 0; i < w; i++)
{
z[i].r = x[i].r * y[i].r - x[i].i * y[i].i;
z[i].i = x[i].i * y[i].r + x[i].r * y[i].i;
}
}
int
main ()
{
int i;
for (i = 0; i < N; ++i)
{
a[i].r = N - i; a[i].i = i - N;
b[i].r = i - N; b[i].i = i + N;
c[i].r = -1 - i; c[i].i = 2 * N - 1 - i;
}
foo (a, b + N, d, N);
bar (a, c, e, N);
for (i = 0; i < N; ++i)
if (d[i].r != e[i].r || d[i].i != e[i].i)
__builtin_abort ();
return 0;
}
In bar which looks correct it is:
vect__6.87_69 = MEM[base: y_21(D), index: ivtmp.133_9, offset: 0B];
vect__6.88_70 = VEC_PERM_EXPR ;
vect__4.84_66 = MEM[base: x_20(D), index: ivtmp.133_9, offset: 0B];
vect__4.93_75 = VEC_PERM_EXPR ;
vect__6.97_79 = VEC_PERM_EXPR ;
vect__7.89_71 = vect__4.84_66 * vect__6.88_70;
vect__10.98_80 = vect__4.93_75 * vect__6.97_79;
vect__12.99_81 = vect__7.89_71 - vect__10.98_80;
vect__12.100_82 = vect__7.89_71 + vect__10.98_80;
_83 = VEC_PERM_EXPR ;
MEM[base: z_22(D), index: ivtmp.133_9, offset: 0B] = _83;
foo has the y pointer iterating with -8 step rather than 8, so I'd expect the x
related permutations
to stay and for y to start with y_21(D) - 32B and use { 7, 7, 5, 5, 3, 3, 1, 1
} and { 6, 6, 4, 4, 2, 2, 0, 0 }
permutations, but we actually emit instead:
_34 = (void *) ivtmp.64_69;
vect__9.16_80 = MEM[base: _34, offset: 0B];
vect__9.17_81 = VEC_PERM_EXPR ;
vect__4.13_76 = MEM[base: x_23(D), index: ivtmp.62_71, offset: 0B];
vect__4.22_86 = VEC_PERM_EXPR ;
vect__12.25_90 = MEM[base: _34, offset: 4B];
vect__12.26_91 = VEC_PERM_EXPR ;
vect__10.18_82 = vect__4.13_76 * vect__9.17_81;
vect__13.27_92 = vect__4.22_86 * vect__12.26_91;
vect__15.28_93 = vect__10.18_82 - vect__13.27_92;
vect__15.29_94 = vect__10.18_82 + vect__13.27_92;
_95 = VEC_PERM_EXPR ;
MEM[base: z_25(D), index: ivtmp.62_71, offset: 0B] = _95;
where ivtmp.64_69 starts at y_21(D) - 8 (!) and with step -32.
[Bug c++/92421] New: ice in inline_small_functions, at ipa-inline.c:2001
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92421 Bug ID: 92421 Summary: ice in inline_small_functions, at ipa-inline.c:2001 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 47198 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47198&action=edit gzipped C++ source code For the attached C++ code with recent gcc trunk and compiler flag -O3, does this: $ /home/dcb/gcc/results/bin/gcc -c -O3 /tmp/q.ii during IPA pass: inline chewing_large_table2_kyotodb.cpp:426:2: internal compiler error: in inline_small_functions, at ipa-inline.c:2001 0x8b15f7 inline_small_functions ../../trunk/gcc/ipa-inline.c:2001 0x8b15f7 ipa_inline ../../trunk/gcc/ipa-inline.c:2616 0x8b15f7 execute ../../trunk/gcc/ipa-inline.c:3024 I'll have my usual go at reducing the code and finding a revision range.
[Bug tree-optimization/92420] [7/8/9/10 Regression] Vectorization miscompilation with negative strides since r238039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92420 Jakub Jelinek changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-08 CC||rsandifo at gcc dot gnu.org Target Milestone|--- |7.5 Ever confirmed|0 |1
[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409 --- Comment #7 from Martin Jambor --- Ah sorry, looking at my bash history, yesterday I somehow lost the -m32 on my command line :-( Will try again.
[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409 --- Comment #8 from Richard Biener --- I think the fix is more like the following to make declare_return_variable notice the mismatch. That alone might not be enough but the fix should be there. I assume that we use a return slot only for non-registers because those are the only valid uses of VIEW_CONVERT_EXPRs on lvalues. Index: gcc/tree-inline.c === --- gcc/tree-inline.c (revision 277955) +++ gcc/tree-inline.c (working copy) @@ -3593,7 +3593,9 @@ declare_return_variable (copy_body_data vs. the call expression. */ if (modify_dest) caller_type = TREE_TYPE (modify_dest); - else + else if (return_slot) +caller_type = TREE_TYPE (return_slot); + else /* No LHS on the call. */ caller_type = TREE_TYPE (TREE_TYPE (callee)); /* We don't need to do anything for functions that don't return anything. */ @@ -3634,6 +3636,10 @@ declare_return_variable (copy_body_data && !DECL_GIMPLE_REG_P (result) && DECL_P (var)) DECL_GIMPLE_REG_P (var) = 0; + + if (!useless_type_conversion_p (callee_type, caller_type)) + var = build1 (VIEW_CONVERT_EXPR, callee_type, var); + use = NULL; goto done; }
[Bug c/92088] aggregates with VLAs and nested functions are broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92088 --- Comment #9 from Eric Botcazou --- > I don't think the inliner should work around this - this hasn't been > necessary for Ada which is a good sign here. Eric - how does GiGi handle > this > case? VLAs are always passed by reference in Ada.
[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409 Richard Biener changed: What|Removed |Added Assignee|jamborm at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |10.0
[Bug c/92088] aggregates with VLAs and nested functions are broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92088 --- Comment #10 from Eric Botcazou --- > VLAs are always passed by reference in Ada. And, more generally, any type with variable size is too.
[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409 Martin Jambor changed: What|Removed |Added Attachment #47195|0 |1 is obsolete|| --- Comment #9 from Martin Jambor --- Created attachment 47199 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47199&action=edit Fixed fix Uh, the conversion must be on the RHS, not the LHS. I'm testing this patch, it should be the right one now :-)
[Bug fortran/92422] New: Warning with character and optimisation flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92422 Bug ID: 92422 Summary: Warning with character and optimisation flags Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: moad212 at hotmail dot com Target Milestone: --- When I compile the Fortran test program: *** PROGRAM character_warning CHARACTER(len=16) :: word word = 'hi' WRITE(*,*) word END PROGRAM character_warning *** with 'gfortran -Warray-bounds -O2 character_warning.f90', I get a warning: *** character_warning.f90:5:0: 5 | word = 'hi' | Warning: array subscript 0 is outside array bounds of 'character(kind=1)[1:16]' [-Warray-bounds] character_warning.f90:3:0: 3 | CHARACTER(len=16) :: word | note: while referencing 'word' *** This only started to happened when I upgraded to gfortran9 from gfortran8. I don't understand why the warning is being thrown and would like to remove it so that my compilation is clean. The warning goes away if I lower the optimisation to -O1 or if I remove the -Warray-bounds flag (maybe obviously). I posted about this on stackoverflow here: https://stackoverflow.com/questions/58752319/array-bounds-warning-with-character-in-gfortran
[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409 --- Comment #10 from Richard Biener --- (In reply to Martin Jambor from comment #9) > Created attachment 47199 [details] > Fixed fix > > Uh, the conversion must be on the RHS, not the LHS. I'm testing this patch, > it should be the right one now :-) I'm testing the other patch which IMHO is better (more testing coverage would be nice though).
[Bug c++/92421] ice in inline_small_functions, at ipa-inline.c:2001
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92421 --- Comment #1 from David Binderman --- gcc trunk first seems to go wrong sometime between revision 277750 and 277800.
[Bug c++/92421] [10 Regression] ice in inline_small_functions, at ipa-inline.c:2001
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92421 Richard Biener changed: What|Removed |Added Keywords||needs-reduction CC||hubicka at gcc dot gnu.org Target Milestone|--- |10.0 Summary|ice in |[10 Regression] ice in |inline_small_functions, at |inline_small_functions, at |ipa-inline.c:2001 |ipa-inline.c:2001 --- Comment #2 from Richard Biener --- Those asserts again...
[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409 --- Comment #11 from Martin Jambor --- (In reply to Richard Biener from comment #8) > @@ -3634,6 +3636,10 @@ declare_return_variable (copy_body_data > && !DECL_GIMPLE_REG_P (result) > && DECL_P (var)) > DECL_GIMPLE_REG_P (var) = 0; > + > + if (!useless_type_conversion_p (callee_type, caller_type)) > + var = build1 (VIEW_CONVERT_EXPR, callee_type, var); > + >use = NULL; >goto done; > } OK, but please note that the callee_type and caller_type have different sizes here: (gdb) pt callee_type constant 32>... (gdb) pt caller_type constant 96>... ...so you are creating a size-mismatched V_C_E. Don't you want to use force_value_to_type instead?
[Bug middle-end/92419] const variable aliases lead to folding non-const initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92419
--- Comment #2 from Richard Biener ---
bool
varpool_node::ctor_useable_for_folding_p (void)
{
...
/* Alias of readonly variable is also readonly, since the variable is stored
in readonly memory. We also accept readonly aliases of non-readonly
locations assuming that user knows what he is asking for. */
if (!TREE_READONLY (decl) && !TREE_READONLY (real_node->decl))
return false;
so looks like this is done on purpose? Shouldn't we then diagnose
those aliases? I'd have done
if (!TREE_READONLY (real_node->decl))
return false;
since as the comment says whether the variable may be stored in readonly
memory or not is what matters. Was there a real reason to be this
forgiving for the testcase at hand? Just to avoid the "asymmetry"
with the non-const alias of a const var?
Better testcase w/o unused 'tem':
int var = 3;
extern const int const_var __attribute__((alias("var")));
void bar()
{
var = 5;
}
int foo()
{
int tem = const_var;
bar ();
return const_var - tem;
}
int main()
{
if (foo() != 2)
__builtin_abort ();
return 0;
}
[Bug middle-end/92384] [8/9/10 Regression] Empty class instances have different equal testing result among GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92384 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Fri Nov 8 10:52:50 2019 New Revision: 277962 URL: https://gcc.gnu.org/viewcvs?rev=277962&root=gcc&view=rev Log: PR c++/92384 * function.c (assign_parm_setup_block, assign_parm_setup_stack): Don't copy TYPE_EMPTY_P arguments from data->entry_parm to data->stack_parm slot. (assign_parms): For TREE_ADDRESSABLE parms with TYPE_EMPTY_P type force creation of a unique data.stack_parm slot. * g++.dg/torture/pr92384.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr92384.C Modified: trunk/gcc/ChangeLog trunk/gcc/function.c trunk/gcc/testsuite/ChangeLog
[Bug target/92038] Extremely inefficient x86_64 code for trivally copyable types passed in registers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92038 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Fri Nov 8 10:53:50 2019 New Revision: 277963 URL: https://gcc.gnu.org/viewcvs?rev=277963&root=gcc&view=rev Log: PR target/92038 * gimple-ssa-store-merging.c (find_constituent_stores): For return value only, return non-NULL if there is a single non-clobber constituent store even if there are constituent clobbers and return one of clobber constituent stores if all constituent stores are clobbers. (split_group): Handle clobbers. (imm_store_chain_info::output_merged_store): When computing bzero_first, look after all clobbers at the start. Don't count clobber stmts in orig_num_stmts, except if the first orig store is a clobber covering the whole area and split_stores cover the whole area, consider equal number of stmts ok. Punt if split_stores contains only ->orig stores and their number plus number of original clobbers is equal to original number of stmts. For ->orig, look past clobbers in the constituent stores. (imm_store_chain_info::output_merged_stores): Don't remove clobber stmts. (rhs_valid_for_store_merging_p): Don't return false for clobber stmt rhs. (store_valid_for_store_merging_p): Allow clobber stmts. (verify_clear_bit_region_be): Fix up a thinko in function comment. * g++.dg/opt/store-merging-1.C: New test. * g++.dg/opt/store-merging-2.C: New test. * g++.dg/opt/store-merging-3.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/store-merging-1.C trunk/gcc/testsuite/g++.dg/opt/store-merging-2.C trunk/gcc/testsuite/g++.dg/opt/store-merging-3.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-store-merging.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/92384] [8/9 Regression] Empty class instances have different equal testing result among GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92384 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] Empty |[8/9 Regression] Empty |class instances have|class instances have |different equal testing |different equal testing |result among GCC versions |result among GCC versions --- Comment #6 from Jakub Jelinek --- Should be fixed on the trunk, will wait a little bit before backporting it to release branches.
[Bug tree-optimization/92420] [7/8/9/10 Regression] Vectorization miscompilation with negative strides since r238039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92420 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #1 from rsandifo at gcc dot gnu.org --- Mine
[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409 --- Comment #12 from rguenther at suse dot de --- On Fri, 8 Nov 2019, jamborm at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409 > > --- Comment #11 from Martin Jambor --- > (In reply to Richard Biener from comment #8) > > @@ -3634,6 +3636,10 @@ declare_return_variable (copy_body_data > > && !DECL_GIMPLE_REG_P (result) > > && DECL_P (var)) > > DECL_GIMPLE_REG_P (var) = 0; > > + > > + if (!useless_type_conversion_p (callee_type, caller_type)) > > + var = build1 (VIEW_CONVERT_EXPR, callee_type, var); > > + > >use = NULL; > >goto done; > > } > > OK, but please note that the callee_type and caller_type have > different sizes here: > > (gdb) pt callee_type > size bitsizetype> constant 32>... > > (gdb) pt caller_type > size bitsizetype> constant 96>... > > ...so you are creating a size-mismatched V_C_E. Don't you want to use > force_value_to_type instead? No, I need an lvalue here. Note V_C_Es like this are OK-ish (Ada creates those as well). In the end we're moving the mismatch handling to RTL which eventually will simply push to a stack slot and do a bitfield read (or ICE ...).
[Bug testsuite/92391] gcc.dg/vect/bb-slp-40.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92391
--- Comment #4 from Joel Hutton ---
Hi Rainer
I set up an account with cfarm, and tested on gcc202, the test fails because on
SPARC, no constructor is generated, the for whatever reason (see below) making
the test not really applicable. I suggest making the test an xfail, so that if
at some point in the future SPARC generates a constructor here the test will
apply. The other option is to skip it for SPARC.
tree output on SPARC at the slp pass:
.
.
.
MEM[(char *)d_202 + 25B] = _136;
# .MEM_233 = VDEF <.MEM_232>
MEM[(char *)d_202 + 26B] = _140;
# .MEM_234 = VDEF <.MEM_233>
MEM[(char *)d_202 + 27B] = _144;
# .MEM_235 = VDEF <.MEM_234>
MEM[(char *)d_202 + 28B] = _148;
# .MEM_236 = VDEF <.MEM_235>
MEM[(char *)d_202 + 29B] = _152;
# .MEM_237 = VDEF <.MEM_236>
MEM[(char *)d_202 + 30B] = _156;
# .MEM_238 = VDEF <.MEM_237>
MEM[(char *)d_202 + 31B] = _160;
# PT = { D.1522 } (nonlocal, interposable)
d_239 = d_202 + 32;
[Bug testsuite/92415] new test case g++.dg/cpp2a/spaceship-scalar1-neg.C introduced in r277925 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92415 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I think r277934 should have fixed this already.
[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #12 from Richard Biener ---
Tackling from the tuning side, -mfma -mtune=znver2 miscompares,
-mtune=generic doesn't [checkme].
Using -mfma -mtune=generic
-mtune-ctrl=^fuse_alu_and_branch,^lcp_stall,use_incdec,^avoid_false_dep_for_bmi,^one_if_conv_insn,use_ffreep,^ext_80387_constants,sse_packed_single_insn_optimal,avoid_fma_chains,avoid_fma256_chains,256_unaligned_load_optimal,256_unaligned_store_optimal,^qimode_math
(all tunables to the znver2 variant) doesn't miscompare
on the gimple side IVOPTs and avoid_fma_chains makes a difference
-O2 -mfma -mtune=generic -fno-schedule-insns2 is OK
-O2 -mfma -mtune=znver2 -fno-schedule-insns2 -mtune-ctrl=^avoid_fma_chains
FAILs
-O2 -mfma -mtune=znver2 -fno-schedule-insns2 -mtune-ctrl=^avoid_fma_chains
-fno-ivopts is OK
-O2 -mfma -mtune=znver2 -fno-schedule-insns2 -fno-ivopts is OK
-O2 -mfma -mtune=znver2 -fno-ivopts is OK
Trying to bisect with IVOPTs debug-counter.
65:69 FAIL
65:66 OK
67:69 OK
*sigh*
more complex "ranges" for debug counters appreciated,
-fdbg-cnt=foo:{5-6,9,1-10} or some sorts of that (lists of ranges / values).
I'm definitely missing a all-but-N as well. ~6 and ~6-9 maybe. Guess
{} don't work very well due to shell limitations so maybe
simply foo:5-6:9:1-10,bar:... with changing semantics of previous handling.
Implementation-wise we'd have instead of high/low arrays
an array of pair > which we only look at
the last element of the vec (sort it backwards), popping it whenever
we reach it's max and checking against the current min. or some
other data structure mimicing this, that is, dbg_cnt () is still O(1)
just parsing the option might involve sorting.
[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #13 from Richard Biener ---
(In reply to Richard Biener from comment #12)
> more complex "ranges" for debug counters appreciated,
> -fdbg-cnt=foo:{5-6,9,1-10} or some sorts of that (lists of ranges / values).
> I'm definitely missing a all-but-N as well. ~6 and ~6-9 maybe. Guess
> {} don't work very well due to shell limitations so maybe
> simply foo:5-6:9:1-10,bar:... with changing semantics of previous handling.
> Implementation-wise we'd have instead of high/low arrays
> an array of pair > which we only look at
> the last element of the vec (sort it backwards), popping it whenever
> we reach it's max and checking against the current min. or some
> other data structure mimicing this, that is, dbg_cnt () is still O(1)
> just parsing the option might involve sorting.
If we store the "inverse" in the vector then an empty vector would be
the natural default value [0,+INF] included. So we could continue to
statically initialize it (or treat .exists () as special value as
opposed to empty).
[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #14 from Martin Liška ---
>
> more complex "ranges" for debug counters appreciated,
+1
> -fdbg-cnt=foo:{5-6,9,1-10} or some sorts of that (lists of ranges / values).
> I'm definitely missing a all-but-N as well. ~6 and ~6-9 maybe. Guess
> {} don't work very well due to shell limitations so maybe
> simply foo:5-6:9:1-10,bar:... with changing semantics of previous handling.
Note that the debug counter is mainly for us as developers, so I would not
care much about backward compatibility.
> Implementation-wise we'd have instead of high/low arrays
> an array of pair > which we only look at
> the last element of the vec (sort it backwards), popping it whenever
> we reach it's max and checking against the current min. or some
> other data structure mimicing this, that is, dbg_cnt () is still O(1)
> just parsing the option might involve sorting.
Yes, one simple improvement can be:
foo:5-6:9:10-100:1000 where we can enforce that ranges are in increasing
order and not overlapping. Or we can sort the ranges and then dbg_cnt will
be O(1) with the popping technique.
I can work on that after we discuss the extended format.
[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #15 from rguenther at suse dot de ---
On Fri, 8 Nov 2019, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
>
> --- Comment #14 from Martin Liška ---
> >
> > more complex "ranges" for debug counters appreciated,
>
> +1
>
> > -fdbg-cnt=foo:{5-6,9,1-10} or some sorts of that (lists of ranges / values).
> > I'm definitely missing a all-but-N as well. ~6 and ~6-9 maybe. Guess
> > {} don't work very well due to shell limitations so maybe
> > simply foo:5-6:9:1-10,bar:... with changing semantics of previous handling.
>
> Note that the debug counter is mainly for us as developers, so I would not
> care much about backward compatibility.
>
> > Implementation-wise we'd have instead of high/low arrays
> > an array of pair > which we only look at
> > the last element of the vec (sort it backwards), popping it whenever
> > we reach it's max and checking against the current min. or some
> > other data structure mimicing this, that is, dbg_cnt () is still O(1)
> > just parsing the option might involve sorting.
>
> Yes, one simple improvement can be:
> foo:5-6:9:10-100:1000 where we can enforce that ranges are in increasing
> order and not overlapping. Or we can sort the ranges and then dbg_cnt will
> be O(1) with the popping technique.
This simple improved format works for me. For users sake I'd simply sort
the thing since we're going to need to reverse it anyways. Then
-fdbg-cnt=foo:5 -fdbg-cnt=foo:1-3 would also be inclusive, effectively
setting 1-3:5?
[Bug target/92095] [8/9/10 regression] internal error with -O1 -mcpu=niagara2 -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095 --- Comment #5 from Eric Botcazou --- Author: ebotcazou Date: Fri Nov 8 12:30:47 2019 New Revision: 277966 URL: https://gcc.gnu.org/viewcvs?rev=277966&root=gcc&view=rev Log: PR target/92095 * config/sparc/sparc-protos.h (output_load_pcrel_sym): Declare. * config/sparc/sparc.c (sparc_cannot_force_const_mem): Revert latest change. (got_helper_needed): New static variable. (output_load_pcrel_sym): New function. (get_pc_thunk_name): Remove after inlining... (load_got_register): ...here. Rework the initialization of the GOT register and of the GOT helper. (save_local_or_in_reg_p): Test the REGNO of the GOT register. (sparc_file_end): Test got_helper_needed to decide whether the GOT helper must be emitted. Use output_asm_insn instead of fprintf. (sparc_init_pic_reg): In PIC mode, always initialize the PIC register if optimization is enabled. * config/sparc/sparc.md (load_pcrel_sym): Emit the assembly by calling output_load_pcrel_sym. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20191108-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc-protos.h trunk/gcc/config/sparc/sparc.c trunk/gcc/config/sparc/sparc.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/sparc/overflow-3.c trunk/gcc/testsuite/gcc.target/sparc/overflow-4.c trunk/gcc/testsuite/gcc.target/sparc/overflow-5.c
[Bug target/92095] [8/9/10 regression] internal error with -O1 -mcpu=niagara2 -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095 --- Comment #6 from Eric Botcazou --- Author: ebotcazou Date: Fri Nov 8 12:33:48 2019 New Revision: 277967 URL: https://gcc.gnu.org/viewcvs?rev=277967&root=gcc&view=rev Log: PR target/92095 * config/sparc/sparc-protos.h (output_load_pcrel_sym): Declare. * config/sparc/sparc.c (sparc_cannot_force_const_mem): Revert latest change. (got_helper_needed): New static variable. (output_load_pcrel_sym): New function. (get_pc_thunk_name): Remove after inlining... (load_got_register): ...here. Rework the initialization of the GOT register and of the GOT helper. (save_local_or_in_reg_p): Test the REGNO of the GOT register. (sparc_file_end): Test got_helper_needed to decide whether the GOT helper must be emitted. Use output_asm_insn instead of fprintf. (sparc_init_pic_reg): In PIC mode, always initialize the PIC register if optimization is enabled. * config/sparc/sparc.md (load_pcrel_sym): Emit the assembly by calling output_load_pcrel_sym. Added: branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/compile/20191108-1.c - copied unchanged from r277966, trunk/gcc/testsuite/gcc.c-torture/compile/20191108-1.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/sparc/sparc-protos.h branches/gcc-9-branch/gcc/config/sparc/sparc.c branches/gcc-9-branch/gcc/config/sparc/sparc.md branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gcc.target/sparc/overflow-3.c branches/gcc-9-branch/gcc/testsuite/gcc.target/sparc/overflow-4.c branches/gcc-9-branch/gcc/testsuite/gcc.target/sparc/overflow-5.c
[Bug target/92095] [8/9/10 regression] internal error with -O1 -mcpu=niagara2 -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095 --- Comment #7 from Eric Botcazou --- Author: ebotcazou Date: Fri Nov 8 12:38:03 2019 New Revision: 277968 URL: https://gcc.gnu.org/viewcvs?rev=277968&root=gcc&view=rev Log: PR target/92095 * config/sparc/sparc-protos.h (output_load_pcrel_sym): Declare. * config/sparc/sparc.c (sparc_cannot_force_const_mem): Revert latest change. (got_helper_needed): New static variable. (output_load_pcrel_sym): New function. (get_pc_thunk_name): Remove after inlining... (load_got_register): ...here. Rework the initialization of the GOT register and of the GOT helper. (save_local_or_in_reg_p): Test the REGNO of the GOT register. (sparc_file_end): Test got_helper_needed to decide whether the GOT helper must be emitted. Use output_asm_insn instead of fprintf. (sparc_init_pic_reg): In PIC mode, always initialize the PIC register if optimization is enabled. * config/sparc/sparc.md (load_pcrel_sym): Emit the assembly by calling output_load_pcrel_sym. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/compile/20191108-1.c - copied unchanged from r277967, trunk/gcc/testsuite/gcc.c-torture/compile/20191108-1.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/sparc/sparc-protos.h branches/gcc-8-branch/gcc/config/sparc/sparc.c branches/gcc-8-branch/gcc/config/sparc/sparc.md branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.target/sparc/overflow-3.c branches/gcc-8-branch/gcc/testsuite/gcc.target/sparc/overflow-4.c branches/gcc-8-branch/gcc/testsuite/gcc.target/sparc/overflow-5.c
[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #25 from Martin Jambor --- I have posted an RFC patch alleviating the situation somewhat to the mailing list: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00614.html
[Bug target/92095] [8/9/10 regression] internal error with -O1 -mcpu=niagara2 -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Eric Botcazou --- This should compile again.
[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #16 from Richard Biener ---
(In reply to Richard Biener from comment #12)
> Trying to bisect with IVOPTs debug-counter.
>
> 65:69 FAIL
> 65:66 OK
> 67:69 OK
>
> *sigh*
Back to this (ivopts_loop counter soon to be checked in).
66:68 FAIL
66:67 FAIL (66:66 OK 67:67 OK)
interestingly 66:66 and 67:67 generate exactly the same code and
66:67 add a single loop. That's totally odd but probably an
artifact of a bug in dbg_cnt_is_enabled which does
bool
dbg_cnt_is_enabled (enum debug_counter index)
{
unsigned v = count[index];
return v > limit_low[index] && v <= limit_high[index];
}
where it should be v >= limit_low[index]. It's also nowhere documented
but zero is a value never in the set of tested values.
So it points to a single loops IVOPTs optimization.
[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886 --- Comment #30 from nsz at gcc dot gnu.org --- i think it is not the end of the world if the asm constraint api changes in this case: fixing musl is easy because it's not super important to optimize fmin, fminf, fmax, fmaxf in libc (if it were important then gcc should inline them instead of calling into libc, currently it seems gcc is not able to do that without -ffast-math). the change breaks the build of old musl releases with new gcc, so as a general principle it makes more sense to me to keep documented apis working (e.g. when glibc removed ustat, the gcc devs asked for 5 years advance notice via deprecation warnings), but it's up to the gcc maintainers to decide.
[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #17 from Alexander Monakov ---
(In reply to Richard Biener from comment #16)
> interestingly 66:66 and 67:67 generate exactly the same code and
> 66:67 add a single loop. That's totally odd but probably an
> artifact of a bug in dbg_cnt_is_enabled which does
>
> bool
> dbg_cnt_is_enabled (enum debug_counter index)
> {
> unsigned v = count[index];
> return v > limit_low[index] && v <= limit_high[index];
> }
>
> where it should be v >= limit_low[index].
This is intentionally like that, the idea is that a:b makes a half-open
interval with the right bound (b) not included. So 66:66 and 67:67 are both
simply empty intervals.
dbg_cnt_is_enabled tests left bound with '>' and right bound with '<=' because
its caller (dbg_cnt) incremented the counter before the call.
[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283 Richard Biener changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #18 from Richard Biener --- The fortran loop is real*8 vold(0:3,*),v(0:3,*) ... if((iperturb.ne.0).and.(nmethod.eq.1)) then vmax=0.d0 do i=1,nk do j=jmin,jmax vmax=max(vmax,dabs(v(j,i))) c write(*,*) i,j,vold(j,i),v(j,i),vmax v(j,i)=v(j,i)+vold(j,i) enddo enddo endif and the .gimple diff @@ -2536,21 +2970,29 @@ vmax__lsm.757_3905 = [results.f:130:0] *vmax_2002(D); [results.f:130:0] _31 = (integer(kind=8)) i.120_4019; [results.f:130:0] _32 = _31 * 4; + ivtmp.773_566 = (sizetype) jmin_1722; [local count: 4326176]: - # j.121_4017 = PHI <[results.f:129:0] jmin_1722(19), [results.f:129:0] _39(670)> + # ivtmp.773_3273 = PHI # vmax__lsm.757_1845 = PHI - [results.f:130:0] _33 = (integer(kind=8)) j.121_4017; - [results.f:130:0] _34 = _32 + _33; - [results.f:130:0] _35 = _34 + -4; - [results.f:130:0] _36 = [results.f:130:0] [results.f:130:0] (*v_2012(D))[_35]; + _2429 = (sizetype) _32; + _565 = _2429 * 8; + _4606 = v_2012(D) + _565; + [results.f:130:0] _36 = MEM[base: _4606, index: ivtmp.773_3273, step: 8, offset: -32B]; [results.f:130:0] _2047 = ABS_EXPR <_36>; [results.f:130:0] M.64_2048 = MAX_EXPR ; - [results.f:132:0] _37 = [results.f:132:0] [results.f:132:0] (*vold_2011(D))[_35]; + _4529 = (sizetype) _32; + _558 = _4529 * 8; + _4481 = vold_2011(D) + _558; + [results.f:132:0] _37 = MEM[base: _4481, index: ivtmp.773_3273, step: 8, offset: -32B]; [results.f:132:0] _38 = _36 + _37; - [results.f:132:0] [results.f:132:0] [results.f:132:0] (*v_2012(D))[_35] = _38; - [results.f:129:0] _39 = j.121_4017 + 1; - [results.f:129:0] if (_39 > jmax_1721) + _564 = (sizetype) _32; + _4573 = _564 * 8; + _560 = v_2012(D) + _4573; + [results.f:132:0] MEM[base: _560, index: ivtmp.773_3273, step: 8, offset: -32B] = _38; + [results.f:129:0] ivtmp.773_1666 = ivtmp.773_3273 + 1; + _3693 = (integer(kind=4)) ivtmp.773_1666; + [results.f:129:0] if (_3693 > jmax_1721) goto ; [11.00%] else goto ; [89.00%] but as far as I can see the IVOPTs transform is correct, assembly differences are too large to swallow though (trying to disable scheduling).
[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #19 from Richard Biener ---
(In reply to Alexander Monakov from comment #17)
> (In reply to Richard Biener from comment #16)
> > interestingly 66:66 and 67:67 generate exactly the same code and
> > 66:67 add a single loop. That's totally odd but probably an
> > artifact of a bug in dbg_cnt_is_enabled which does
> >
> > bool
> > dbg_cnt_is_enabled (enum debug_counter index)
> > {
> > unsigned v = count[index];
> > return v > limit_low[index] && v <= limit_high[index];
> > }
> >
> > where it should be v >= limit_low[index].
>
> This is intentionally like that, the idea is that a:b makes a half-open
> interval with the right bound (b) not included. So 66:66 and 67:67 are both
> simply empty intervals.
>
> dbg_cnt_is_enabled tests left bound with '>' and right bound with '<='
> because its caller (dbg_cnt) incremented the counter before the call.
How useful (not). We then at least should reject -fdbg-cnt=foo:5:5
[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409 --- Comment #13 from Richard Biener --- Author: rguenth Date: Fri Nov 8 13:15:40 2019 New Revision: 277972 URL: https://gcc.gnu.org/viewcvs?rev=277972&root=gcc&view=rev Log: 2019-11-08 Richard Biener PR ipa/92409 * tree-inline.c (declare_return_variable): Properly handle type mismatches for the return slot. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-inline.c
[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Richard Biener --- Fixed.
[Bug testsuite/92391] gcc.dg/vect/bb-slp-40.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92391 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Joel Hutton --- > Hi Rainer > > I set up an account with cfarm, and tested on gcc202, the test fails because > on > SPARC, no constructor is generated, the for whatever reason (see below) > making > the test not really applicable. I suggest making the test an xfail, so that if > at some point in the future SPARC generates a constructor here the test will > apply. The other option is to skip it for SPARC. I've just checked gcc-testresults: the test also FAILs on i586-unknown-freebsd11.2, i686-pc-linux-gnu, ia64-suse-linux-gnu, powerpc-ibm-aix7.2.0.0, powerpc64-unknown-linux-gnu, and s390x-ibm-linux-gnu. Just adding an ever increasing list of xfail/skip's without really understanding why the test fails or what is common between those targets seems unmaintainable (and thus highly undesirable) to me.
[Bug lto/92279] [10 Regression] ICE in error: non-trivial conversion in 'constructor' since r276416
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92279 Martin Liška changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |--- Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- It's gone since r277616, I'm trying to reduce that, it's about FIELD_DECL and I'm curious what it means..
[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #26 from Manuel López-Ibáñez --- Hi Martin, Wouldn't it be better if the testcase tested that no warning is given for a true case? Otherwise if the bug is fixed, no warning will be given, no matter the option. Or have a testcase that the warning is given with the option and not without . On Fri, 8 Nov 2019, 12:42 jamborm at gcc dot gnu.org, < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 > > --- Comment #25 from Martin Jambor --- > I have posted an RFC patch alleviating the situation somewhat to the > mailing > list: > > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00614.html > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug middle-end/92410] Invalid access to df->insns[] in regstat_bb_compute_calls_crossed (caught by hwasan)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410
--- Comment #5 from Matthew Malcomson ---
I've had a little look into it, and the below seems promising:
Based on a comment in haifa-sched.c, notes are removed before scheduling and
added back in.
Since the insn that is larger than the df buffer is a note, and I saw in gdb
that it's added during `reemit_notes`, I figure the root problem might be that
the notes are removed, then the df->insns array is calculated, then notes are
added back in.
I hence tested the below patch, and the testcase that Martin found no longer
crashes.
I have not yet looked into whether `df_recompute_luids` is the correct function
to call or if there's a better approach. Just sharing an update.
diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c
index 41cf1f3..564a358 100644
--- a/gcc/haifa-sched.c
+++ b/gcc/haifa-sched.c
@@ -6231,6 +6231,7 @@ commit_schedule (rtx_insn *prev_head, rtx_insn *tail,
basic_block *target_bb)
reemit_notes (insn);
last_scheduled_insn = insn;
}
+ df_recompute_luids(*target_bb);
scheduled_insns.truncate (0);
}
diff --git a/gcc/regstat.c b/gcc/regstat.c
index 4da9b7c..c6cefb11 100644
--- a/gcc/regstat.c
+++ b/gcc/regstat.c
@@ -324,6 +324,7 @@ regstat_bb_compute_calls_crossed (unsigned int bb_index,
bitmap live)
FOR_BB_INSNS_REVERSE (bb, insn)
{
+ gcc_assert (INSN_UID (insn) < DF_INSN_SIZE ());
struct df_insn_info *insn_info = DF_INSN_INFO_GET (insn);
unsigned int regno;
diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
index 8a1d414..5d8 100644
--- a/gcc/sel-sched-ir.c
+++ b/gcc/sel-sched-ir.c
@@ -4673,6 +4673,7 @@ sel_restore_notes (void)
if (NONDEBUG_INSN_P (insn))
reemit_notes (insn);
+ df_recompute_luids (first);
first = first->next_bb;
}
while (first != last);
[Bug c++/92423] New: Reference assigned from a ternary results in destructor call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92423
Bug ID: 92423
Summary: Reference assigned from a ternary results in
destructor call
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tpg+gcc at mutabah dot net
Target Milestone: ---
The following code compiles with g++ 9.2.0, but calls `Foo`'s destructor twice.
```
#include
struct Foo
{
Foo() {
printf("Foo()\n");
}
Foo(const Foo& x) = delete;
Foo(Foo&& x) = delete;
Foo& operator=(const Foo&) = delete;
Foo& operator=(Foo&&) = delete;
~Foo() {
printf("~Foo()\n");
}
};
int main() {
Foo base_foo;
const auto& my_foo = (true ? base_foo : throw "");
printf("Selected a foo\n");
return 0;
}
```
[Bug tree-optimization/92351] [10 Regression] Wrong code with -O3 -match=skylake since r277569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92351 --- Comment #3 from avieira at gcc dot gnu.org --- Author: avieira Date: Fri Nov 8 13:52:56 2019 New Revision: 277974 URL: https://gcc.gnu.org/viewcvs?rev=277974&root=gcc&view=rev Log: [vect] PR 92351: When peeling for alignment make alignment of epilogues unknown gcc/ChangeLog: 2019-11-08 Andre Vieira PR tree-optimization/92351 * tree-vect-data-refs.c (vect_compute_data_ref_alignment): When we are peeling the main loop for alignment, make sure to set the misalignment of the epilogue's data references to DR_MISALIGNMENT_UNKNOWN. gcc/testsuite/ChangeLog: 2019-11-08 Andre Vieira PR tree-optimization/92351 * gcc.dg/vect/vect-peel-2.c: Disable epilogue vectorization and split the source of this test to... * gcc.dg/vect/vect-peel-2-src.c: ... This. * gcc.dg/vect/vect-peel-2-epilogues.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/vect-peel-2-epilogues.c trunk/gcc/testsuite/gcc.dg/vect/vect-peel-2-src.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-peel-2.c trunk/gcc/tree-vect-data-refs.c
[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886 --- Comment #31 from nsz at gcc dot gnu.org --- (In reply to Segher Boessenkool from comment #28) > [ "ws" needs at least a Power7, btw. ] powerpc64le-* implies power8 and that's where this came up.
[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886 --- Comment #32 from Bill Schmidt --- BTW, we are in close contact with the Clang folks for Power as well, so we're going to get together with them about constraints consistency and a way forward to ensure these problems don't recur. I don't want anyone to get the idea that we don't care about Clang; we care very much indeed about compatibility between the compilers. I've personally worked on both in the past to ensure the ABI compatibility that you enjoy today. We had an unexpected gotcha here, and we'll get it resolved. I do agree with Segher that this was a long-overdue cleanup that was causing us a lot of misery, and the use of "ws" in the field was rather surprising to us. Long term we really want to get to "wa" and remove "ws", but aliases in the meantime will be needed until supported versions of Clang and GCC have the compatibility issue resolved.
[Bug c++/92421] [10 Regression] ice in inline_small_functions, at ipa-inline.c:2001
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92421
--- Comment #3 from David Binderman ---
Reduced C++ code:
typedef long a;
void *b, *c;
template class d {};
template bool operator!=(d, d);
class g {
public:
g(char *);
};
class j {
public:
j();
void h();
void i();
void aj();
};
class m {
public:
m(bool);
};
class n {
public:
operator a();
};
class o {
public:
long am();
};
class H {
public:
class p {};
virtual bool accept(const char *, unsigned long, p *, bool);
};
class q : H {
public:
class r {
public:
enum at { au, av, aw };
};
enum { ax };
virtual void ay(char *, int, const char *, r::at, char *);
virtual bool az(const g &, unsigned = ax);
virtual bool ba(const int &, p *, bool);
void bb(char *bc, long bd, char *, long be) {
class bf : public p {
public:
bf(long);
} bg(be);
accept(bc, bd, &bg, true);
}
};
class s {
q *bi;
bool bj();
};
template class t : q {
bool accept(const char *, unsigned long bd, p *bg, bool) {
bool k(bp || bq), cl = false, err = false;
if (br)
ay("", 1, __func__, r::au, "");
if (bs)
ay("", 6, __func__, r::av, "");
char bt[1], cd[1];
long bu = sizeof(int) + bd, ce = sizeof(L) + bd;
char *bw = bu > sizeof(bt) ? new char : bt,
*cf = ce > sizeof(cd) ? new char : cd;
__builtin___memcpy_chk(b, c, bd, 0);
a by[1];
int bz = 0;
u cb = *cc((int *)bw, true, by, &bz);
ay("", 1, __func__, r::aw, "");
if (bw != bt)
delete bw;
__builtin___memcpy_chk(b, c, bd, 0);
cb.ch.i();
bool ci = cj((L *)cf, bg);
bool atran = bq && bp && cb.ck;
if (atran && !ci && cm(&cb))
if (cn > co) {
int cp = cb.cq % 6;
v cs = *(ct + cp);
if (cu(&cs))
cl = true;
}
if (ci)
if (k)
cv.aj();
cv.h();
b = cc((int *)bw, false, by, &bz);
if (b)
if (cw(&cb, by, bz))
if (atran && bp && cx())
cv.aj();
if (cl)
if (k)
cv.aj();
cv.h();
int cp = cb.cq % 6;
v cs = *(ct + cp);
if (cy())
err = true;
O da = *(db + cp);
if (da.dc->am() > cs.dc->am() + cs.dd->am() + 1 && de(&da))
cv.aj();
return !err;
}
bool ba(const int &, p *, bool) {
d kit, df;
while (kit != df)
;
cx();
}
bool az(const g &, unsigned) {
t dj;
int cur;
while (cur) {
int dk, dl;
char dbuf;
dj.bb(&dbuf, dl, &dbuf, dk);
}
}
struct L {};
struct u {
j ch;
a cq;
bool ck;
};
struct v {
o *dd;
o *dc;
};
struct O {
o *dc;
};
bool cy();
bool cu(v *);
bool cj(L *, p *);
bool de(O *);
u *cc(int *, bool, a *, int *);
bool cw(u *, a *, int);
bool cx() {
dm.dn();
bool err = false;
if (dm.l())
err = true;
return !err;
}
bool cm(u *);
j cv;
int br;
bool bs;
bool bq;
bk dm;
a co;
n cn;
v ct[6];
O db[6];
bool bp;
};
class w : q {
public:
void dn();
bool l() {
m(true);
if (br)
ay("", 1087, __func__, r::au, "");
return false;
}
int br;
};
bool s::bj() {
bi->az("");
new t;
}
[Bug target/92424] New: [aarch64] Broken code with -fpatchable-function-entry and BTI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424
Bug ID: 92424
Summary: [aarch64] Broken code with -fpatchable-function-entry
and BTI
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
-fpatchable-function-entry seems to interact badly with
-mbranch-protection=standard (used to insert BTI markers)
void g(void);
void f(void)
{ g(); g(); }
aarch64-linux-gnu-gcc -mbranch-protection=standard
-fpatchable-function-entry=2,1 -O3 -c foo.c -save-temps
Produces:
.arch armv8-a
.file "foo.c"
.text
.align 2
.p2align 3,,7
.global f
.section__patchable_function_entries,"aw",@progbits
.8byte .LPFE1
.text
.LPFE1:
nop
.type f, %function
f:
nop // <--- Function entry has NOP rather than PACIASP landing pad
.LFB0:
.cfi_startproc
hint25 // paciasp
.cfi_window_save
stp x29, x30, [sp, -16]!
.cfi_def_cfa_offset 16
.cfi_offset 29, -16
.cfi_offset 30, -8
mov x29, sp
bl g
ldp x29, x30, [sp], 16
.cfi_restore 30
.cfi_restore 29
.cfi_def_cfa_offset 0
hint29 // autiasp
.cfi_window_save
b g
.cfi_endproc
.LFE0:
.size f, .-f
Could a possible solution be to emit ofr -mbranch-protection={standard or bti}
-fpatchable-function-entry=N,M:
f-4*M:
.rept M
nop
.endr
f:
bti c
.rept N-M
nop
.endr
// paciasp may be used from here on in
Unless we fix the codegen we should perhaps error out when the two options are
combined rather than producing silently wrong code?
[Bug tree-optimization/92351] [10 Regression] Wrong code with -O3 -match=skylake since r277569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92351 avieira at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from avieira at gcc dot gnu.org --- I believe the committed patch fixes this.
[Bug middle-end/92410] Invalid access to df->insns[] in regstat_bb_compute_calls_crossed (caught by hwasan)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410 --- Comment #6 from Matthew Malcomson --- I believe the problem is that `remove_notes` followed by `reemit_notes` can generate these notes with a different UID. When `reemit_notes` adds the new note, the dataflow information is not updated automatically because `add_insn_before` only updates the information for INSN_P(insn). Hence the later lookup of this dataflow information is problematic. I'm not sure whether there's any pre-existing "should not use dataflow queries on notes" rule. If there is, then the regstat_bb_compute_calls_crossed function should be modified to check for NONDEBUG_INSN_P and continue earlier on its loop. If there isn't such a rule then I guess the best approach would be to ensure we call `df_insn_create_insn_record` whenever calling `emit_note_before` or `emit_note_after` once the dataflow information has been created. (assuming that notes don't need the information to be populated since `df_insn_rescan` seems to ignore notes). I've tried both moving the check for NONDEBUG_INSN_P in `regstat_bb_compute_calls_crossed` and adding a call to `df_insn_create_insn_record` into `reemit_notes` on a cross-compiler and both pass the testcase Martin found.
[Bug c++/92425] New: Incorrect logical AND on 64bit variable using 32bit register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92425
Bug ID: 92425
Summary: Incorrect logical AND on 64bit variable using 32bit
register
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akobets at mail dot ru
Target Milestone: ---
Created attachment 47200
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47200&action=edit
Assembly output
=== prog.cpp ===
unsigned long long a, b;
int start()
{
a = b & 0xFFF;
return 1;
}
Compiling
gcc -c -fno-PIC -Wall -Wextra -save-temps -fverbose-asm -masm=intel
-march=core2 -mtune=generic -O2 -fno-rtti -fno-default-inline --no-exceptions
-O2 prog.cpp
No errors
No warnings
Produces wrong assembly code
=== cut ===
_Z5startv:
.LFB0:
.cfi_startproc
endbr64
# prog.cpp:5: a = b & 0xFFF;
mov rax, QWORD PTR b[rip] # tmp87, b
and eax, 4095 # tmp87,
# prog.cpp:5: a = b & 0xFFF;
mov QWORD PTR a[rip], rax # a, tmp87
# prog.cpp:7: }
mov eax, 1 #,
ret
.cfi_endproc
=== cut ===
There is 'and' on 32bit register eax, while 'b' is 64bit variable. Bits 32...63
of 'b' stays unchanged, but must be zeroed.
[Bug c++/92425] Incorrect logical AND on 64bit variable using 32bit register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92425 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #1 from Wilco --- Where do you see a problem? and eax, 4095 clears the top 32 bits of rax.
[Bug c++/92425] Incorrect logical AND on 64bit variable using 32bit register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92425 --- Comment #2 from Alexander Kobets --- I think eax is 32-bit register. May be I do not understand, then I re-check the result of that operation.
[Bug c++/90393] [9/10 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90393 Jakub Jelinek changed: What|Removed |Added CC||tpg+gcc at mutabah dot net --- Comment #14 from Jakub Jelinek --- *** Bug 92423 has been marked as a duplicate of this bug. ***
[Bug c++/92423] Reference assigned from a ternary results in destructor call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92423 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- This used to be rejected before r260272 with: pr92423.C: In function ‘int main()’: pr92423.C:15:49: error: use of deleted function ‘Foo::Foo(const Foo&)’ const auto& my_foo = (true ? base_foo : throw ""); ^~ pr92423.C:4:3: note: declared here Foo (const Foo& x) = delete; ^~~ starting with that would call the dtor twice, and finally since r274550 aka PR90393 calls dtor just once. I think the g++.dg/expr/cond16.C testcase is sufficiently similar to this one that it isn't worth adding another one. *** This bug has been marked as a duplicate of bug 90393 ***
[Bug c++/92425] Incorrect logical AND on 64bit variable using 32bit register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92425 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #3 from Florian Weimer --- In general, the 32-bit opcodes clear the upper 32 bits of the 64 bit registers. They do not just operate on the lower 32 bits.
[Bug c++/92425] Incorrect logical AND on 64bit variable using 32bit register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92425 --- Comment #4 from Alexander Kobets --- Ok.
[Bug inline-asm/92352] ICE in force_constant_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92352 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- ice-on-invalid, not going to backport to release branches.
[Bug middle-end/92410] Invalid access to df->insns[] in regstat_bb_compute_calls_crossed (caught by hwasan)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410
--- Comment #7 from Matthew Malcomson ---
(In reply to Matthew Malcomson from comment #6)
> I'm not sure whether there's any pre-existing "should not use dataflow
> queries on notes" rule. If there is, then the
> regstat_bb_compute_calls_crossed function should be modified to check for
> NONDEBUG_INSN_P and continue earlier on its loop.
I now see that `df_bb_refs_record` generates insn info for notes (but leaves it
mostly zeroed out). I figure doing the same for the notes emitted by
`reemit_notes` seems reasonable.
Currently bootstrapping and regtesting (both with HWASAN and without) the
following patch.
diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c
index 41cf1f3..2e1a84f 100644
--- a/gcc/haifa-sched.c
+++ b/gcc/haifa-sched.c
@@ -5433,6 +5433,7 @@ reemit_notes (rtx_insn *insn)
last = emit_note_before (note_type, last);
remove_note (insn, note);
+ df_insn_create_insn_record (last);
}
}
}
diff --git a/gcc/regstat.c b/gcc/regstat.c
index 4da9b7c..c6cefb11 100644
--- a/gcc/regstat.c
+++ b/gcc/regstat.c
@@ -324,6 +324,7 @@ regstat_bb_compute_calls_crossed (unsigned int bb_index,
bitmap live)
FOR_BB_INSNS_REVERSE (bb, insn)
{
+ gcc_assert (INSN_UID (insn) < DF_INSN_SIZE ());
struct df_insn_info *insn_info = DF_INSN_INFO_GET (insn);
unsigned int regno;
[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886 --- Comment #33 from Segher Boessenkool --- (In reply to nsz from comment #31) > (In reply to Segher Boessenkool from comment #28) > > [ "ws" needs at least a Power7, btw. ] > > powerpc64le-* implies power8 and that's where this came up. Does musl not support BE? There is nothing about this that is LE-only as far as I can see.
[Bug fortran/92422] [Regression 9] Warning with character and optimisation flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92422 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 CC||kargl at gcc dot gnu.org Known to work||10.0, 6.5.0, 7.4.1, 8.3.1 Target Milestone|--- |9.4 Summary|Warning with character and |[Regression 9] Warning with |optimisation flags |character and optimisation ||flags Known to fail||9.2.1
[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886 --- Comment #34 from Rich Felker --- > Does musl not support BE? There is nothing about this that is LE-only > as far as I can see. For powerpc64, musl supports both BE and LE, and uses "elfv2" ABI for both (since it was not present as a target for musl before the new ABI existed). Per the IBM docs, LE/elfv2 (which they confusingly equate) "require" power8+, but there are not actually any constraints in the ABI that impose such a requirement (e.g. argument-passing in registers that previous ISA levels didn't have), and we don't impose it. I believe there are people using musl on pre-power8 powerpc64 systems, at least in BE mode and possibly also in LE mode.
[Bug c++/92015] [9 Regression] internal compiler error: in cxx_eval_array_reference, at cp/constexpr.c:2568
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92015 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Fri Nov 8 18:52:44 2019 New Revision: 277980 URL: https://gcc.gnu.org/viewcvs?rev=277980&root=gcc&view=rev Log: Backported from mainline 2019-10-21 Jakub Jelinek PR c++/92015 * constexpr.c (cxx_eval_component_reference, cxx_eval_bit_field_ref): Use STRIP_ANY_LOCATION_WRAPPER on CONSTRUCTOR elts. * g++.dg/cpp0x/constexpr-92015.C: New test. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-92015.C Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/constexpr.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/85887] [7/8/9 Regression] Missing DW_TAG_lexical_block PC range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85887 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Fri Nov 8 18:53:46 2019 New Revision: 277982 URL: https://gcc.gnu.org/viewcvs?rev=277982&root=gcc&view=rev Log: Backported from mainline 2019-10-22 Jakub Jelinek PR tree-optimization/85887 * decl.c (expand_static_init): Drop ECF_LEAF from __cxa_guard_acquire and __cxa_guard_release. Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/decl.c
[Bug sanitizer/92154] new glibc breaks arm bootstrap due to libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92154 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Fri Nov 8 18:53:18 2019 New Revision: 277981 URL: https://gcc.gnu.org/viewcvs?rev=277981&root=gcc&view=rev Log: Backported from mainline 2019-10-22 Tamar Christina PR sanitizer/92154 * sanitizer_common/sanitizer_platform_limits_posix.cc: Cherry-pick compiler-rt revision r375220. Modified: branches/gcc-9-branch/libsanitizer/ChangeLog branches/gcc-9-branch/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
[Bug c++/90947] [9 Regression] Simple lookup table of array of strings is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90947 --- Comment #15 from Jakub Jelinek --- Author: jakub Date: Fri Nov 8 18:56:42 2019 New Revision: 277985 URL: https://gcc.gnu.org/viewcvs?rev=277985&root=gcc&view=rev Log: Backported from mainline 2019-10-31 Jakub Jelinek PR c++/90947 * tree.h (type_initializer_zero_p): Remove. * tree.c (type_initializer_zero_p): Remove. * cp-tree.h (type_initializer_zero_p): Declare. * decl.c (reshape_init_array_1): Formatting fix. * tree.c (type_initializer_zero_p): New function. Moved from ../tree.c, use next_initializable_field, formatting fix. Return false for TYPE_NON_AGGREGATE_CLASS types. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/init/array54.C Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/cp-tree.h branches/gcc-9-branch/gcc/cp/decl.c branches/gcc-9-branch/gcc/cp/tree.c branches/gcc-9-branch/gcc/tree.c branches/gcc-9-branch/gcc/tree.h
[Bug middle-end/92231] [9 Regression] ICE in gimple_fold_stmt_to_constant_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92231 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Fri Nov 8 18:58:14 2019 New Revision: 277986 URL: https://gcc.gnu.org/viewcvs?rev=277986&root=gcc&view=rev Log: Backported from mainline 2019-10-31 Jakub Jelinek PR middle-end/92231 * tree.h (fndecl_built_in_p): Use fndecl_built_in_p instead of DECL_BUILT_IN in comment. Remove redundant ()s around return argument. * tree.c (free_lang_data_in_decl): Check if var is FUNCTION_DECL before calling fndecl_built_in_p. * gimple-fold.c (gimple_fold_stmt_to_constant_1): Check if TREE_OPERAND (fn, 0) is a FUNCTION_DECL before calling fndecl_built_in_p on it. * lto-lang.c (handle_const_attribute): Don't call fndecl_built_in_p on *node that is not FUNCTION_DECL. * gcc.c-torture/compile/pr92231.c: New test. Added: branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/compile/pr92231.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/gimple-fold.c branches/gcc-9-branch/gcc/lto/ChangeLog branches/gcc-9-branch/gcc/lto/lto-lang.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/tree.c branches/gcc-9-branch/gcc/tree.h
[Bug preprocessor/92296] [7/8/9 Regression] internal compiler error: Segmentation fault #pragma push_macro("__LINE__")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296 --- Comment #15 from Jakub Jelinek --- Author: jakub Date: Fri Nov 8 18:59:14 2019 New Revision: 277987 URL: https://gcc.gnu.org/viewcvs?rev=277987&root=gcc&view=rev Log: Backported from mainline 2019-10-31 Jakub Jelinek PR preprocessor/92296 * internal.h (struct def_pragma_macro): Add is_builtin bitfield. (_cpp_restore_special_builtin): Declare. * init.c (_cpp_restore_special_builtin): New function. * directives.c (do_pragma_push_macro): For NT_BUILTIN_MACRO set is_builtin and don't try to grab definition. (cpp_pop_definition): Use _cpp_restore_special_builtin to restore builtin macros. * c-c++-common/cpp/pr92296-1.c: New test. * c-c++-common/cpp/pr92296-2.c: New test. Added: branches/gcc-9-branch/gcc/testsuite/c-c++-common/cpp/pr92296-1.c branches/gcc-9-branch/gcc/testsuite/c-c++-common/cpp/pr92296-2.c Modified: branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/libcpp/ChangeLog branches/gcc-9-branch/libcpp/directives.c branches/gcc-9-branch/libcpp/init.c branches/gcc-9-branch/libcpp/internal.h
[Bug c++/92343] [[likely]]/[[unlikely]] prevent method from being a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92343 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Fri Nov 8 19:00:02 2019 New Revision: 277988 URL: https://gcc.gnu.org/viewcvs?rev=277988&root=gcc&view=rev Log: Backported from mainline 2019-11-05 Jakub Jelinek PR c++/92343 * constexpr.c (potential_constant_expression_1): Return true rather than false for PREDICT_EXPR. * g++.dg/cpp2a/attr-likely6.C: New test. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp2a/attr-likely6.C Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/constexpr.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug middle-end/92384] [8/9 Regression] Empty class instances have different equal testing result among GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92384 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Fri Nov 8 19:02:24 2019 New Revision: 277989 URL: https://gcc.gnu.org/viewcvs?rev=277989&root=gcc&view=rev Log: PR c++/92384 * function.c (assign_parm_setup_block, assign_parm_setup_stack): Don't copy TYPE_EMPTY_P arguments from data->entry_parm to data->stack_parm slot. (assign_parms): For TREE_ADDRESSABLE parms with TYPE_EMPTY_P type force creation of a unique data.stack_parm slot. * g++.dg/torture/pr92384.C: New test. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/torture/pr92384.C Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/function.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886 --- Comment #35 from David Edelsohn --- The ELFv2 ABI does not require Power8+ because the subroutine linkage convention requires Power8 instructions. It requires Power8+ because the ABI provide a minimum guarantee to the programmer / developer / toolchain / distribution of the minimum ISA that will be encountered. The ABI can function on earlier hardware, but the ABI asserts to the programmer that one can utilize the instructions available in Power8 without special accommodation or feature tests. The authors of the ABI (IBM) didn't want to provide a guarantee of backward compatibility to the beginning of time, which creates challenges for the minimum ISA level supported by, for example, a GNU/Linux distribution.
[Bug fortran/92358] libgfortran/io/async.c:548:37: warning: unused parameter 'cmp'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92358 --- Comment #1 from Jerry DeLisle --- I notoced your report here. I do not get that warning on my system here. I am using gcc version 9.2.1 20190827 to build with. What are you using?
[Bug c++/92426] New: ICE on spaceship declaration plus other P1185R2 interaction issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92426
Bug ID: 92426
Summary: ICE on spaceship declaration plus other P1185R2
interaction issue
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dacamara.cameron at gmail dot com
Target Milestone: ---
I was playing around with the spaceship operator using gcc10 on godbolt and
discovered an issue trying to compile the following program:
struct Basics {
int i;
char c;
float f;
double d;
auto operator<=>(const Basics&) const = default;
};
struct Arrays {
int ai[1];
char ac[2];
float af[3];
double ad[2][2];
auto operator<=>(const Arrays&) const = default;
};
struct Bases : Basics, Arrays {
auto operator<=>(const Bases&) const = default;
};
int main() {
constexpr Bases a = { { 0, 'c', 1.f, 1. },
{ { 1 }, { 'a', 'b' }, { 1.f, 2.f, 3.f }, { { 1., 2. },
{ 3., 4. } } } };
constexpr Bases b = { { 0, 'c', 1.f, 1. },
{ { 1 }, { 'a', 'b' }, { 1.f, 2.f, 3.f }, { { 1., 2. },
{ 3., 4. } } } };
static_assert(a == b);
static_assert(!(a != b));
static_assert(!(a < b));
static_assert(a <= b);
static_assert(!(a > b));
static_assert(a >= b);
}
The program ultimately ICEs gcc10 but working with a reduced repro shows some
other gaps:
struct Arrays {
int a[2];
#ifdef MEMBERS
auto operator<=>(const Arrays&) const = default;
#endif
#ifdef FRIENDS
friend auto operator<=>(const Arrays&, const Arrays&) = default;
// friend bool operator==(const Arrays&, const Arrays&) = default; //
should be implicitly declared
#endif
};
int main() {
constexpr Arrays a1 { 1, 2 };
constexpr Arrays a2 { 3, 4 };
static_assert(a1 == a1); // OK
static_assert(a1 != a2); // OK
static_assert(a1 < a2); // ICE
}
When MEMBERS is defined it only ICEs at the final static assert, but with
FRIENDS it both leaves the implicitly declared operator== undeclared _and_
ICEs. Additionally, replacing `auto` with `std::strong_ordering` produces an
ICE in finish_expr_stmt so I assume arrays just aren't handled yet?
[Bug c++/92015] [9 Regression] internal compiler error: in cxx_eval_array_reference, at cp/constexpr.c:2568
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92015 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/85887] [7/8 Regression] Missing DW_TAG_lexical_block PC range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85887 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[7/8/9 Regression] Missing |[7/8 Regression] Missing |DW_TAG_lexical_block PC |DW_TAG_lexical_block PC |range |range --- Comment #7 from Jakub Jelinek --- Fixed for 9.3+ too.
[Bug middle-end/92231] [9 Regression] ICE in gimple_fold_stmt_to_constant_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92231 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug middle-end/92384] [8 Regression] Empty class instances have different equal testing result among GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92384 Jakub Jelinek changed: What|Removed |Added Known to work||10.0, 9.2.1 Summary|[8/9 Regression] Empty |[8 Regression] Empty class |class instances have|instances have different |different equal testing |equal testing result among |result among GCC versions |GCC versions Known to fail|10.0| --- Comment #8 from Jakub Jelinek --- Should be fixed for 9.3+ too.
[Bug preprocessor/92296] [7/8 Regression] internal compiler error: Segmentation fault #pragma push_macro("__LINE__")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
Jakub Jelinek changed:
What|Removed |Added
Summary|[7/8/9 Regression] internal |[7/8 Regression] internal
|compiler error: |compiler error:
|Segmentation fault #pragma |Segmentation fault #pragma
|push_macro("__LINE__") |push_macro("__LINE__")
--- Comment #16 from Jakub Jelinek ---
Fixed for 9.3+ too.
[Bug c++/92425] Incorrect logical AND on 64bit variable using 32bit register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92425 Alexander Kobets changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Alexander Kobets --- It strange notation works correctly.
