[Bug target/93860] darwin: wrong quotation in diagnostic #pragma options align=reset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93860 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Target Milestone|--- |10.0 --- Comment #2 from Iain Sandoe --- (In reply to Eric Gallager from comment #1) > The code in that area probably needs to be reworked anyways; see bug 50909 probably, and that would be a good time to add a diagnostic test. For now, I plan to fix the obvious quoting mistake first.
[Bug debug/93865] .debug_line with LTO refers to bogus file-names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865 Richard Biener changed: What|Removed |Added Keywords||lto CC||hubicka at gcc dot gnu.org --- Comment #1 from Richard Biener --- I think we need to canonicalize locations file either at stream-out time or at stream-in time (then using a streamed comp-dir). Since we're doing cross CU inlining and thus end up mixing .loc from different comp-dirs inside a single function I see no way of somehow transparently preserving the comp-dir via the GIMPLE CUs DW_AT_comp_dir attribute (which is somewhat useless since it contains the link directory). Note the GIMPLE CU also has an empty Directory Table in .debug_line, eventually we could stick the original TUs comp-dir there. But we still need to somehow carry the information across streaming which is where we're losing it right now.
[Bug target/93694] Inconsistent grammar in darwin.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93694 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-21 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1
[Bug other/93641] Wrong strncmp and strncasecmp size arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93641 --- Comment #7 from Iain Sandoe --- if the invoke.texi entry does not need a change, then this should now be fixed, correct?
[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806 --- Comment #17 from rguenther at suse dot de --- On Fri, 21 Feb 2020, bugdal at aerifal dot cx wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806 > > --- Comment #10 from Rich Felker --- > I don't think it's at all clear that -fno-signed-zeros is supposed to mean the > programmer is promising that their code has behavior independent of the sign > of > zeros, and that any construct which would be influenced by the sign of a zero > has undefined behavior. I've always read it as a license to optimize in ways > that disregard the sign of a zero or change the sign of a zero, but with > internal consistency of the program preserved. > > If -fno-signed-zeros is really supposed to be an option that vastly expands > the > scope of what's undefined behavior, rather than just removing part of Annex F > and allowing the unspecified quality of floating point results that C > otherwise > allows in the absence of Annex F, it really needs a much much bigger warning > in > its documentation! -fno-signed-zeros internally tells GCC that the hardwares FP format does not distinguish between -0.0 and 0.0 (not sure if that makes sense). There's always the question what these kind of options mean when GCC is present with a literal -0.0 (or Inf/NaN with -ffinite-math-only) or an explicit sign or finiteness check but we've historically erred on the "optimize" side here.
[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #18 from rguenther at suse dot de ---
On Fri, 21 Feb 2020, bugdal at aerifal dot cx wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
>
> --- Comment #12 from Rich Felker ---
> To me the meaning of internal consistency is very clear: that the semantics of
> the C language specification are honored and that the only valid
> transformations are those that follow the "as-if rule". Since C without Annex
> F
> allows arbitrarily awful floating point results, your example in comment 11 is
> fine. Each instance of 1/a can evaluate to a different value. They could even
> evaluate to random values. However, if you had written:
>
> int b = 1/a == 1/0.;
> int c = b;
> return b == c;
>
> then the function must necessarily return 1, because the single instance of
> 1/a==1/0. in the abstract machine has a single value, either 0 or 1, and in
> the
> abstract machine that value is stored to b, then copied to c, and b and c
> necessarily have the same value. While I don't think it's likely that GCC
> would
> mess up this specific example, it seems that it currently _can_ make
> transformations such that a more elaborate version of the same idea would be
> broken.
GCC indeed happily evaluates a floating-point expression multiple times,
for example for
void foo(float a, float b, float *x, float *y)
{
float tem = a + b;
*x = tem - a;
*y = tem - b;
}
I would expect GCC to turn this into
*x = (a + b) - a;
*y = (a + b) - b;
and then simplify further to b and a. Does this violate the "as-if rule"?
It certainly affects the result when a + b == a.
Note the fortran frontend uses the PAREN_EXPR which is an association
barrier to prevent optimizations across boundaries the language
standard places (parens IIRC). That still doesn't prevent GCC from
evaluating a single expression multiple times and possibly
doing different association inside the expression - so it still
violates the as-if rule. Classical transforms involve tail-duplication
of blocks but also loop unrolling if we happen to duplicate loop
invariant expressions.
So I guess the "as-if rule" can practically not be honored by an
optimized compiler.
[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806 --- Comment #19 from rguenther at suse dot de --- On Fri, 21 Feb 2020, vincent-gcc at vinc17 dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806 > > --- Comment #15 from Vincent Lefèvre --- > Note that there are very few ways to be able to distinguish the sign of zero. > The main one is division by zero. Other ones are: > > * Conversion to a character string, e.g. via printf(). But in this case, if > -fno-signed-zeros is used, whether "0" or "-0" is output (even in a way that > seems to be inconsistent) doesn't matter since the user does not care about > the > sign of 0, i.e. "0" and "-0" are regarded as equivalent (IIRC, this would be a > bit like NaN, which has a sign bit in IEEE 754, but the output does not need > to > match its sign bit). > > * Memory analysis. Again, the sign does not matter, but for instance, reading > an object twice as a byte sequence while the object has not been changed by > the > code must give the same result. I doubt that this is affected by optimization. > > * copysign(). The C standard is clear: "On implementations that represent a > signed zero but do not treat negative zero consistently in arithmetic > operations, the copysign functions regard the sign of zero as positive." Thus > with -fno-signed-zeros, the sign of zero must be regarded as positive with > this > function. If GCC chooses to deviate from the standard here, this needs to be > documented. I'm sure GCC doesn't adhere to this (it also relies on the systems math library which doesn't "see" whether -fno-signed-zeros is in effect). We'd need to special-case -0.0 at runtime for copysign (x, y) which would be quite wasteful since -fno-signed-zeros is used for performance...
[Bug fortran/93833] [8/9/10 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93833 Martin Liška changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code --- Comment #3 from Martin Liška --- Sorry, I was too eager.
[Bug c/93848] missing -Warray-bounds warning for array subscript 1 is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |WAITING Last reconfirmed||2020-02-21 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Hmm, but as you say there isn't an actual access and taking the address of one-after the array is allowed. With p[2] it appropriately warns.
[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #20 from Vincent Lefèvre ---
(In reply to rguent...@suse.de from comment #18)
> GCC indeed happily evaluates a floating-point expression multiple times,
> for example for
>
> void foo(float a, float b, float *x, float *y)
> {
> float tem = a + b;
> *x = tem - a;
> *y = tem - b;
> }
>
> I would expect GCC to turn this into
>
> *x = (a + b) - a;
> *y = (a + b) - b;
>
> and then simplify further to b and a. Does this violate the "as-if rule"?
I think that if optimization goes beyond expressions, this is unexpected, thus
violate the "as-if rule". Assignments should be regarded as barriers. Perhaps
casts too.
Now, if you disregard Annex F entirely and assume that the operations may be
inaccurate (e.g. due to the optimizer), then in foo(), *x can be any value and
*y can be any value, so that the simplification of *x to b and *y to a would be
valid (as long as GCC assumes that their values are stable, i.e. that it will
not "recompute" a same unmodified variable multiple times). But IMHO, this kind
of aggressive optimization is not helpful to the user.
BTW, I fear that due to FP contraction, GCC might be broken even without
"unsafe" optimizations. For instance, consider:
double a, b, c, r, s, t;
/* ... */
r = a * b + c;
s = a * b;
t = s + c;
possibly slightly modified, without changing the semantics and still allowing
FP contraction for r (I mean that things like "opaque" and volatile could be
introduced in the code to change how optimization is done).
Here, if FP contraction is allowed, the compiler may replace a * b + c by
fma(a,b,c), i.e. compute r with a single rounding instead of two, so that r and
t may have different values. My question is the following: Due to the fact that
r and t are computed with the same Level-1 expression a * b + c (i.e. at the
level of real numbers, without rounding), is it possible that GCC's optimizer
regard r and t as equal, even though they may actually be different? If this is
possible, this would be a bug.
[Bug target/93709] [10 regression] fortran.dg/minlocval_4.f90 fails on power 9 after r10-4161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93709 --- Comment #5 from Jiu Fu Guo --- There are below difference between data/instructions for P8 and P9: (maxlocval_4.f90) f29=-inf f30=-inf f31=nan P9: xsmaxcdp vs31,vs29,vs31 ==> vs31/f31:nan (smax(-inf, nan)-->nan) b 0x10004b60 P8: fcmpu cr0,f29,f31 blt 0x10004c20 (not jump, -inf < nan --> false" fmr f31,f29 ==>f31:-inf b 0x10004c20 On P9, 'f31' becomes ‘nan’ by instruction "xsmaxcdp". While on P8, 'f31' becomes '-inf' through "fcmpu and blt".
[Bug go/93866] New: [debug] Methods with pointer receiver incorrectly named
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93866
Bug ID: 93866
Summary: [debug] Methods with pointer receiver incorrectly
named
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: vries at gcc dot gnu.org
CC: cmang at google dot com
Target Milestone: ---
Consider methods.go from the gdb testsuite:
...
$ cat gdb/testsuite/gdb.go/methods.go
package main
import "fmt"
type T struct { i int }
func (t T) Foo () {
fmt.Println (t.i)
}
func (t *T) Bar () {
fmt.Println (t.i)
}
func main () {
fmt.Println ("Shall we?")
var t T
t.Foo ()
var pt = new (T)
pt.Bar ()
}
...
With go1.11.13, we have:
...
$ nm methods | egrep "\.Bar"
0049c750 T main.(*T).Bar
...
and:
...
$ readelf -wi methods | egrep "\.Bar"
<6c49b> DW_AT_name: main.(*T).Bar
...
In contrast, with gccgo-10, we have:
...
$ nm methods | egrep "\.Bar"
00402c8d T main.T.Bar
...
and:
...
$ readelf -wi methods | egrep "\.Bar"
<1df4> DW_AT_name: main.Bar..1main.T
<1dfb> DW_AT_linkage_name: main.T.Bar
...
At https://golang.org/doc/gdb, we read:
...
Methods must be qualified with the name of their receiver types. For example,
the *Regexp type’s String method is known as 'regexp.(*Regexp).String'.
...
That sounds like what go1.11.13 emits is correct, and what gccgo-10 emits is
not.
[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #21 from rguenther at suse dot de ---
On Fri, 21 Feb 2020, vincent-gcc at vinc17 dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
>
> --- Comment #20 from Vincent Lefèvre ---
> (In reply to rguent...@suse.de from comment #18)
> > GCC indeed happily evaluates a floating-point expression multiple times,
> > for example for
> >
> > void foo(float a, float b, float *x, float *y)
> > {
> > float tem = a + b;
> > *x = tem - a;
> > *y = tem - b;
> > }
> >
> > I would expect GCC to turn this into
> >
> > *x = (a + b) - a;
> > *y = (a + b) - b;
> >
> > and then simplify further to b and a. Does this violate the "as-if rule"?
>
> I think that if optimization goes beyond expressions, this is unexpected, thus
> violate the "as-if rule". Assignments should be regarded as barriers. Perhaps
> casts too.
>
> Now, if you disregard Annex F entirely and assume that the operations may be
> inaccurate (e.g. due to the optimizer), then in foo(), *x can be any value and
> *y can be any value, so that the simplification of *x to b and *y to a would
> be
> valid (as long as GCC assumes that their values are stable, i.e. that it will
> not "recompute" a same unmodified variable multiple times). But IMHO, this
> kind
> of aggressive optimization is not helpful to the user.
>
> BTW, I fear that due to FP contraction, GCC might be broken even without
> "unsafe" optimizations. For instance, consider:
>
> double a, b, c, r, s, t;
> /* ... */
> r = a * b + c;
> s = a * b;
> t = s + c;
>
> possibly slightly modified, without changing the semantics and still allowing
> FP contraction for r (I mean that things like "opaque" and volatile could be
> introduced in the code to change how optimization is done).
>
> Here, if FP contraction is allowed, the compiler may replace a * b + c by
> fma(a,b,c), i.e. compute r with a single rounding instead of two, so that r
> and
> t may have different values. My question is the following: Due to the fact
> that
> r and t are computed with the same Level-1 expression a * b + c (i.e. at the
> level of real numbers, without rounding), is it possible that GCC's optimizer
> regard r and t as equal, even though they may actually be different? If this
> is
> possible, this would be a bug.
Yes, GCCs value-numbering would compute them equal but then it would
also replace one with the other. So one would need a quite more
contrived example where the value-numbering results in a second
order observable difference (hah, compiler side-channel attack!).
Note that FP contraction happens quite late after value-numbering
has the chance to declare both of the above equal. value-numbering
does not, however, consider fma (a, b, c) and a * b + c as equal.
The issue here is I think requiring "consistent optimization"
for correctness so that in some cases a missed-optimization becomes
wrong-code :/
Note that GCC does FP contraction across stmt boundaries so
even s = a * b; t = s + c; is contracted. If that is already
a bug in your eyes then of couse value-numbering replacing
t by r is already a bug.
[Bug c/20785] Pragma STDC * (C99 FP) unimplemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
--- Comment #8 from Vincent Lefèvre ---
Concerning the STDC FP_CONTRACT pragma, implementing it would not be
sufficient. GCC would also need to restrict how it does contraction, as it
currently does not contract only expressions, but also sequences of
expressions, which is invalid. Example:
double foo (double a, double b, double c)
{
double p = a * b;
return p + c;
}
Since a * b and p + c are separate expressions, contraction to FMA must not be
done according to the C standard. But when contraction is allowed, GCC
generates a FMA on my x86_64 processor:
.cfi_startproc
vfmadd132sd %xmm1, %xmm2, %xmm0
ret
.cfi_endproc
[Bug c++/93867] New: ICE using class type NTTPs and class template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93867 Bug ID: 93867 Summary: ICE using class type NTTPs and class template argument deduction Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pkeir at outlook dot com Target Milestone: --- Created attachment 47881 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47881&action=edit The code described in the bug report. The attached C++20 code makes use of class type NTTPs, and also class template argument deduction. It is based on code from P0732r2. With the -std=c++2a switch the code produces an ICE on GCC snapshot gcc-10-20200216. The error message is below: nttp_ice.cpp: In function ‘int main(int, const char**)’: nttp_ice.cpp:27:16: internal compiler error: in alias_ctad_tweaks, at cp/pt.c:28327 27 | foo<"hello">(); |^ 0x67b060 alias_ctad_tweaks ../../gcc/cp/pt.c:28327 0x67b060 deduction_guides_for ../../gcc/cp/pt.c:28499 0x9fc488 do_class_deduction ../../gcc/cp/pt.c:28604 0x9fc488 do_auto_deduction(tree_node*, tree_node*, tree_node*, int, auto_deduction_context, tree_node*, int) ../../gcc/cp/pt.c:28733 0x9fe129 convert_template_argument ../../gcc/cp/pt.c:8306 0x9fff7b coerce_template_parms ../../gcc/cp/pt.c:8810 0xa32fac fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node* const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool, bool) ../../gcc/cp/pt.c:20919 0x8951ed add_template_candidate_real ../../gcc/cp/call.c:3396 0x895c04 add_template_candidate ../../gcc/cp/call.c:3481 0x895c04 add_candidates ../../gcc/cp/call.c:5830 0x8960c7 add_candidates ../../gcc/cp/call.c:4478 0x8960c7 perform_overload_resolution ../../gcc/cp/call.c:4486 0x89bdb5 build_new_function_call(tree_node*, vec**, int) ../../gcc/cp/call.c:4560 0xa4ec54 finish_call_expr(tree_node*, vec**, bool, bool, int) ../../gcc/cp/semantics.c:2671 0x9c848d cp_parser_postfix_expression ../../gcc/cp/parser.c:7427 0x9ab24a cp_parser_binary_expression ../../gcc/cp/parser.c:9519 0x9acd0c cp_parser_assignment_expression ../../gcc/cp/parser.c:9824 0x9ad032 cp_parser_expression ../../gcc/cp/parser.c:9992 0x9aff26 cp_parser_expression_statement ../../gcc/cp/parser.c:11642 0x9bb083 cp_parser_statement ../../gcc/cp/parser.c:11438
[Bug c/20785] Pragma STDC * (C99 FP) unimplemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
--- Comment #9 from Richard Biener ---
Note fixin(In reply to Vincent Lefèvre from comment #8)
> Concerning the STDC FP_CONTRACT pragma, implementing it would not be
> sufficient. GCC would also need to restrict how it does contraction, as it
> currently does not contract only expressions, but also sequences of
> expressions, which is invalid. Example:
>
> double foo (double a, double b, double c)
> {
> double p = a * b;
> return p + c;
> }
>
> Since a * b and p + c are separate expressions, contraction to FMA must not
> be done according to the C standard. But when contraction is allowed, GCC
> generates a FMA on my x86_64 processor:
>
> .cfi_startproc
> vfmadd132sd %xmm1, %xmm2, %xmm0
> ret
> .cfi_endproc
Note fixing that is as easy as wrapping FP expressions in PAREN_EXPR to
denote which ones are separate. PAREN_EXPRs also serve as association
barriers and the FE needs to decide what FP optimization flag elides
them where exactly (the middle-end leaves them in place even with
-ffast-math).
[Bug analyzer/93863] internal compiler error: unhandled tree code in region_model::get_lvalue_1: ‘integer_cst’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93863 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-02-21 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #22 from Vincent Lefèvre ---
(In reply to rguent...@suse.de from comment #21)
> Note that GCC does FP contraction across stmt boundaries so
> even s = a * b; t = s + c; is contracted. If that is already
> a bug in your eyes then of couse value-numbering replacing
> t by r is already a bug.
Yes, with testing, I've eventually noticed that and mentioned this fact in
PR20785 (i.e. this is very important when the STDC FP_CONTRACT pragma will be
implemented, as this is not conforming).
I haven't found an example with a major inconsistency, but when contraction is
enabled, e.g. with "gcc -march=native -O3" on an x86 processor with a FMA, the
following program
#include
__attribute__((noipa)) // imagine it in a separate TU
static double opaque(double d) { return d; }
void foo (double a, double b, double c)
{
double s, t, u, v;
s = a * b;
t = opaque(s) + c;
u = a * opaque(b);
v = u + c;
printf ("%d %a %a\n", t != v, t, v);
}
int main (void)
{
volatile double a = 0x1.0001p0, c = -1;
foo (a, a, c);
return 0;
}
outputs
1 0x1p-47 0x1.8p-47
Though t and v are computed from equivalent expressions, their values are
different. However, in t != v, GCC correctly notices that they are different:
it generates the comparison instruction, without optimizing; and this is still
the case if -ffinite-math-only is used (since NaNs could prevent the
optimization of t != v).
Note that if one adds "if (s == u)" (which is true, and noticed by GCC) before
the printf, one correctly gets:
0 0x1p-47 0x1p-47
[Bug gcov-profile/93623] No need to dump gcdas when forking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93623 Martin Liška changed: What|Removed |Added Version|unknown |10.0 Target Milestone|--- |11.0 --- Comment #1 from Martin Liška --- I like the suggested idea. I'm going to change it in next stage1.
[Bug gcov-profile/93623] No need to dump gcdas when forking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93623 --- Comment #2 from calixte --- I think the reset is useless in the case of exec** functions since the counters are lost when an exec** is called. So it can probably be removed too.
[Bug gcov-profile/93623] No need to dump gcdas when forking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93623 --- Comment #3 from calixte --- And about fork, no need to lock when resetting in the child process since we've only one thread.
[Bug gcov-profile/93623] No need to dump gcdas when forking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93623 --- Comment #4 from Martin Liška --- Both comments are valid to me!
[Bug tree-optimization/93868] New: [10 Regression] wrong-code with permuted SLP reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93868
Bug ID: 93868
Summary: [10 Regression] wrong-code with permuted SLP reduction
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
The SLP graph representation made vect_attempt_slp_rearrange_stmts unsafe since
it fails to verify the permutation it applies only affects the SLP reduction.
unsigned a[1024];
unsigned b[1024];
void __attribute__((noipa))
foo (unsigned *q, unsigned *r)
{
unsigned sum1 = 0, sum2 = 0;
for (int i = 0; i < 512; ++i)
{
sum1 += a[2*i];
sum2 += a[2*i+1];
b[2*i] = a[2*i+1];
b[2*i+1] = a[2*i];
}
*q = sum1;
*r = sum2;
}
int main()
{
unsigned sum1, sum2;
a[0] = 0;
a[1] = 1;
foo (&sum1, &sum2);
if (b[0] != 1 || b[1] != 0)
__builtin_abort ();
return 0;
}
[Bug tree-optimization/93868] [10 Regression] wrong-code with permuted SLP reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93868 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Just for the record, started with r10-4800-g10a73df76280e128.
[Bug tree-optimization/93868] [10 Regression] wrong-code with permuted SLP reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93868 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Keywords||wrong-code Last reconfirmed||2020-02-21 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Blocks||53947 Ever confirmed|0 |1 Target Milestone|--- |10.0 --- Comment #1 from Richard Biener --- Mine. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806 --- Comment #23 from Vincent Lefèvre --- (In reply to Vincent Lefèvre from comment #22) > Note that if one adds "if (s == u)" (which is true, and noticed by GCC) Sorry, this is not noticed by GCC (I used an incorrect command line). Anyway, the opaque's prevent any optimization.
[Bug c++/93869] New: ICE in contains_struct_check with -Wmismatched-tags upon redundant typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93869
Bug ID: 93869
Summary: ICE in contains_struct_check with -Wmismatched-tags
upon redundant typename
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
CC: msebor at gcc dot gnu.org
Target Milestone: ---
With recent GCC trunk (incl. the fix from bug 93801 comment 3, though I do not
know whether that makes a difference):
> $ cat test.cc
> namespace N { typedef int T; }
> typename N::T x;
> $ g++ -fsyntax-only -Wmismatched-tags test.cc
> test.cc:2:13: internal compiler error: Segmentation fault
> 2 | typename N::T x;
> | ^
> 0xfd962f crash_signal
> ../../src/gcc/toplev.c:328
> 0x7f55158a16af ???
>
> /usr/src/debug/glibc-2.30-34-g994e529a37/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
> 0x9a1c0f contains_struct_check(tree_node*, tree_node_structure_enum, char
> const*, int, char const*)
> ../../src/gcc/tree.h:3391
> 0x9a1c0f cp_parser_check_class_key
> ../../src/gcc/cp/parser.c:30991
> 0x9c5ad4 cp_parser_elaborated_type_specifier
> ../../src/gcc/cp/parser.c:18930
> 0x9aea83 cp_parser_type_specifier
> ../../src/gcc/cp/parser.c:17681
> 0x9afbcf cp_parser_decl_specifier_seq
> ../../src/gcc/cp/parser.c:14303
> 0x9b0600 cp_parser_simple_declaration
> ../../src/gcc/cp/parser.c:13557
> 0x9d9302 cp_parser_declaration
> ../../src/gcc/cp/parser.c:13377
> 0x9d9a82 cp_parser_translation_unit
> ../../src/gcc/cp/parser.c:4731
> 0x9d9a82 c_parse_file()
> ../../src/gcc/cp/parser.c:43716
> 0xaedd0b c_common_parse_file()
> ../../src/gcc/c-family/c-opts.c:1186
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See
[Bug analyzer/93863] internal compiler error: unhandled tree code in region_model::get_lvalue_1: ‘integer_cst’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93863 --- Comment #2 from Charalampos Stratakis --- That would be latest version of gcc 10 in Fedora rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1462579 I see the issue was fixed some days ago. I will close the bugzilla for now then and let Fedora grab the latest snapshot and will test it again when 93388 has been backported.
[Bug analyzer/93863] internal compiler error: unhandled tree code in region_model::get_lvalue_1: ‘integer_cst’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93863 Charalampos Stratakis changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/93868] [10 Regression] wrong-code with permuted SLP reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93868 --- Comment #3 from Richard Biener --- What's more we cannot modify the SLP nodes stmt order since they are cached in the SLP node cache. So a "simple" fix might be to COW the whole SLP sub-tree we re-arrange...
[Bug fortran/92621] Segmentation fault with assumed rank allocatable intent(out) with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621
--- Comment #2 from José Rui Faustino de Sousa ---
Looked a bit further into this and found additional problems both under:
gfortran version 10.0.1 20200219 (experimental) (GCC)
and
gfortran version 9.2.1 20200219 (GCC)
With the new test case it will always crash with, infrequently, a segmentation
fault or an attempt to allocate already allocated variable.
From the code generated using -fdump-tree-original:
program alloc_p
alloc_p ()
{
struct array01_integer(kind=4) a;
a.data = 0B;
{
// allocates a
{
void * cfi.9;
// cfi.9 never gets properly initialized and sometimes
// the free tries to deallocate whatever it points to
// generating a segmentation fault
if (cfi.9 != 0B)
{
__builtin_free (cfi.9);
cfi.9 = 0B;
}
// cfi.9 is finally intialized here
cfi.9 = 0B;
// notice that a never got deallocated like it should
_gfortran_gfc_desc_to_cfi_desc (&cfi.9, &a);
a.dtype.attribute = 1; // <- unnecessary duplicate?
// when hello tries to allocate a it will crash with an
// attempt to allocate an already allocated variable
hello (cfi.9);
<...>
}
_gfortran_stop_string (0B, 0, 0);
}
}
It seems that it is generating code that will try to deallocate an
uninitialized pointer, and consequently segfault, and that the memory that
should be freed never is touched so the array will pass on still allocated.
Best regards,
José Rui
[Bug fortran/92621] Segmentation fault with assumed rank allocatable intent(out) with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 --- Comment #3 from José Rui Faustino de Sousa --- Created attachment 47882 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47882&action=edit New test case
[Bug c/93848] missing -Warray-bounds warning for array subscript 1 is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848 --- Comment #2 from Vincent Lefèvre --- (In reply to Richard Biener from comment #1) > Hmm, but as you say there isn't an actual access and taking the address of > one-after the array is allowed. With p[2] it appropriately warns. No, what I'm saying is: * There isn't an actual access, which seems to be the reason why GCC does not warn. * But even though there isn't an actual access, the operation is explicitly forbidden by the C standard (the end of 6.5.6p8), so that GCC should warn anyway. Note also that the end of 6.5.6p8 is not the only part of the C standard that is concerned. According to 6.5.3.2p4, the unary * operator can be used only when the operand points to a function or to an object (and it doesn't matter whether there is an access or not). But past the end of an array, there isn't necessarily an object.
[Bug target/91913] [8/9/10 Regression] ICE in extract_constrain_insn, at recog.c:2211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913
John Paul Adrian Glaubitz changed:
What|Removed |Added
CC||glaubitz at physik dot
fu-berlin.d
||e, olegendo at gcc dot gnu.org
--- Comment #6 from John Paul Adrian Glaubitz ---
I'm seeing this exact problem SH as well when trying to build webkit2gtk:
FAILED:
Source/ThirdParty/ANGLE/CMakeFiles/ANGLE.dir/src/compiler/translator/IntermNode.cpp.o
/usr/bin/c++ -DANGLE_ENABLE_ESSL -DANGLE_ENABLE_GLSL -DBUILDING_GTK__=1
-DBUILDING_WITH_CMAKE=1 -DEGL_EGL_PROTOTYPES=0
-DGETTEXT_PACKAGE=\"WebKit2GTK-4.0\" -DGL_GLES_PROTOTYPES=0 -DHAVE_CONFIG_H=1
-DJSC_GLIB_API_ENABLED -DLIBANGLE_IMPLEMENTATION
-DWEBKITGTK_API_VERSION_STRING=\"4.0\" -I../Source/ThirdParty/ANGLE/include
-I../Source/ThirdParty/ANGLE/include/KHR -I../Source/ThirdParty/ANGLE/src
-I../Source/ThirdParty/ANGLE/src/common/third_party/base
-fdiagnostics-color=always -Wextra -Wall -Wno-expansion-to-defined -Wno-psabi
-Wno-noexcept-type -Wno-maybe-uninitialized -Wwrite-strings -Wundef
-Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align -g1
-O2 -fdebug-prefix-map=/<>=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -mlra -DNDEBUG
-DG_DISABLE_CAST_CHECKS -fno-strict-aliasing -fno-exceptions -fno-rtti -fPIC
-Wno-cast-align -Wno-suggest-attribute=format -Wno-type-limits -Wno-undef
-Wno-unused-parameter -std=c++17 -MD -MT
Source/ThirdParty/ANGLE/CMakeFiles/ANGLE.dir/src/compiler/translator/IntermNode.cpp.o
-MF
Source/ThirdParty/ANGLE/CMakeFiles/ANGLE.dir/src/compiler/translator/IntermNode.cpp.o.d
-o
Source/ThirdParty/ANGLE/CMakeFiles/ANGLE.dir/src/compiler/translator/IntermNode.cpp.o
-c ../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp
../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp: In static
member function ‘static sh::TConstantUnion*
sh::TIntermConstantUnion::FoldAggregateBuiltIn(sh::TIntermAggregate*,
sh::TDiagnostics*)’:
../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp:3747:1:
error: insn does not satisfy its constraints:
3747 | }
| ^
(insn 9655 9654 3155 385 (parallel [
(set (reg:SF 66 fr2 [orig:645 _696 ] [645])
(reg:SF 0 r0 [3233]))
(use (reg:SI 154 fpscr0))
(clobber (scratch:SI))
]) 214 {movsf_ie}
(expr_list:REG_DEAD (reg:SF 0 r0 [3233])
(nil)))
during RTL pass: cprop_hardreg
../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp:3747:1:
internal compiler error: in extract_constrain_insn, at recog.c:2211
Should the constraints be adjusted on SH as well? CC'ing Oleg.
[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #24 from Alexander Cherepanov ---
(In reply to Vincent Lefèvre from comment #11)
> But what does "internal consistency" mean?
That's a good question. Here we talk about cases (like
-funsafe-math-optimizations) that are not covered by any standards. Other PRs
(like pr61502 or pr93301) discuss possible changes to the standard. So we need
some basic rules to decide what is good and what is bad.
pr61502 taught me that discussing which value is the right result for a
particular computation is very interesting but not very conclusive. So now I'm
looking for contradictions. If you can derive a contradiction then you can
derive any statement, so it's an ultimate goal. How to apply this to a
compiler? I thought the following is supposed to always hold: if you explicitly
write a value into a variable (of any type) then you should get back the same
value at every future read no matter how the results of other reads are used or
what control flow happens (without other writes to the variable, of course).
That is, after `int x = 0;` all `printf("x = %d", x);` should output the same
no matter how many `if (x == ...)` there are in-between -- either `printf`
doesn't fire at all or it prints `x = 0`. If we demonstrated that it's broken
then we demonstrated a contradiction (nonsense). And I hoped that it would be
uncontroversial:-(
Sometimes it's possible to raise the bar even higher and to construct a
testcase where `if` connecting the problematic part with the "independent"
variable is hidden in non-executed code in such a way that loop unswitching
will move it back into executable part (see bug 93301, comment 6 for an
example).
OTOH I think the bar should be lowered in gcc and I hope it would be possible
to come to an agreement that all integers in gcc should be stable. That is, in
this PR the testcase in comment 0 should be enough to demonstrate the problem,
without any need for a testcase in comment 1. It's quite easy to get the latter
from the former so this agreement doesn't seem very important. Much more
important to agree on the general principle described above.
It's always possible that any particular testcase is broken itself. Then some
undefined behavior should be pointed out. So I totally support how you assessed
my testcase from comment 8. We can disagree whether it's UB (I'll get to this a
bit later) but we agree that it's either UB or the program should print
something sane. What I don't understand is what is happening with my initial
testcases.
(In reply to Richard Biener from comment #3)
> But you asked for that. So no "wrong-code" here, just another case
> of "instabilities" or how you call that via conditional equivalence
> propagation.
Just to be sure: you are saying that everything works as intended -- the
testcase doesn't contain UB and the result it prints is one of the allowed? (It
could also be read as implying that this pr is a dup of another bug about
conditional equivalence propagation or something.) Then we just disagree.
Discussion went to specifics of particular optimizations. IMHO it's not
important at all for deciding whether comment 1 demonstrates a bug or not.
Again, IMHO either the testcase contains UB or it shouldn't print nonsense (in
the sense described above). And it doesn't matter which options are used,
whether it's a standards compliant mode, etc.
[Bug tree-optimization/93845] [10 regression] ICE in verify_sra_access_forest, at tree-sra.c:2358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93845 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:4d6bf96b583d77336cf6ca643d92d068a88414fa commit r10-6779-g4d6bf96b583d77336cf6ca643d92d068a88414fa Author: Martin Jambor Date: Fri Feb 21 13:38:22 2020 +0100 sra: Only verify sizes of scalar accesses (PR 93845) the testcase is another example - in addition to recent PR 93516 - where the SRA access verifier is confused by the fact that get_ref_base_extent can return different sizes for the same type, depending whether they are COMPONENT_REF or not. In the previous bug I decided to keep the verifier check for aggregate type even though it is not really important and instead avoid easily detectable type-within-the-same-type situation. This testcase is however a result of a fairly random looking type cast and so cannot be handled in the same way. Because the check is not really important for aggregates, this patch simply disables it for non-register types. 2020-02-21 Martin Jambor PR tree-optimization/93845 * tree-sra.c (verify_sra_access_forest): Only test access size of scalar types. testsuite/ * g++.dg/tree-ssa/pr93845.C: New test.
[Bug tree-optimization/93516] [10 regression] ICE in verify_sra_access_forest, at tree-sra.c:2342 since r10-6322
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93516 --- Comment #9 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:4d6bf96b583d77336cf6ca643d92d068a88414fa commit r10-6779-g4d6bf96b583d77336cf6ca643d92d068a88414fa Author: Martin Jambor Date: Fri Feb 21 13:38:22 2020 +0100 sra: Only verify sizes of scalar accesses (PR 93845) the testcase is another example - in addition to recent PR 93516 - where the SRA access verifier is confused by the fact that get_ref_base_extent can return different sizes for the same type, depending whether they are COMPONENT_REF or not. In the previous bug I decided to keep the verifier check for aggregate type even though it is not really important and instead avoid easily detectable type-within-the-same-type situation. This testcase is however a result of a fairly random looking type cast and so cannot be handled in the same way. Because the check is not really important for aggregates, this patch simply disables it for non-register types. 2020-02-21 Martin Jambor PR tree-optimization/93845 * tree-sra.c (verify_sra_access_forest): Only test access size of scalar types. testsuite/ * g++.dg/tree-ssa/pr93845.C: New test.
[Bug gcov-profile/93623] No need to dump gcdas when forking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93623 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #5 from Alexander Monakov --- (In reply to calixte from comment #2) > I think the reset is useless in the case of exec** functions since the > counters are lost when an exec** is called. So it can probably be removed > too. exec can fail; resetting only after an (unsuccessful) exec may be ok, but eliding the reset entirely does not seem so.
[Bug tree-optimization/93845] [10 regression] ICE in verify_sra_access_forest, at tree-sra.c:2358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93845 Martin Jambor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Jambor --- Fixed with https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01202.html
[Bug gcov-profile/93623] No need to dump gcdas when forking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93623 --- Comment #6 from calixte --- (In reply to Alexander Monakov from comment #5) > (In reply to calixte from comment #2) > > I think the reset is useless in the case of exec** functions since the > > counters are lost when an exec** is called. So it can probably be removed > > too. > > exec can fail; resetting only after an (unsuccessful) exec may be ok, but > eliding the reset entirely does not seem so. +1
[Bug c++/93869] [10 Regression] ICE in contains_struct_check with -Wmismatched-tags upon redundant typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93869 Marek Polacek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Last reconfirmed||2020-02-21 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Summary|ICE in |[10 Regression] ICE in |contains_struct_check with |contains_struct_check with |-Wmismatched-tags upon |-Wmismatched-tags upon |redundant typename |redundant typename Target Milestone|--- |10.0 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug tree-optimization/93776] [10 Regression] ICE in verify_sra_access_forest, at tree-sra.c:2326
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93776 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Jambor --- Fixed.
[Bug c/93848] missing -Warray-bounds warning for array subscript 1 is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #3 from Alexander Monakov ---
Note that 6.5.6 takes care to allow unevaluated * operator:
If the result points one past the last element of the array object,
it shall not be used as the operand of a unary * operator that is
evaluated.
So for example there's no UB in
void bar_aux (int *);
void foo (void)
{
int i;
int *p = &i;
bar_aux (&p[1]);
}
In your example with 'bar', the formal evaluation in the expression 'p[1]' does
not create a copy of the array, it simply strips off one array dimension in the
pointed-to type. So I am pretty sure it was not an intention of the standard to
make that undefined. Perhaps the standard could be edited to make that clearer,
but there's no need to issue a warning here.
[Bug c++/93869] [10 Regression] ICE in contains_struct_check with -Wmismatched-tags upon redundant typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93869 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #2 from Marek Polacek --- This patch https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01183.html does not fix it. I think the fix is to check class_key earlier in the function: --- a/gcc/cp/parser.c +++ b/gcc/cp/parser.c @@ -30987,6 +30987,13 @@ cp_parser_check_class_key (cp_parser *parser, location_t key_loc, if (!warn_mismatched_tags && !warn_redundant_tags) return; + /* Only consider the true class-keys below and ignore typename_type, + etc. that are not C++ class-keys. */ + if (class_key != class_type + && class_key != record_type + && class_key != union_type) +return; + tree type_decl = TYPE_MAIN_DECL (type); tree name = DECL_NAME (type_decl); /* Look up the NAME to see if it unambiguously refers to the TYPE @@ -30995,13 +31002,6 @@ cp_parser_check_class_key (cp_parser *parser, location_t key_loc, tree decl = cp_parser_lookup_name_simple (parser, name, input_location); pop_deferring_access_checks (); - /* Only consider the true class-keys below and ignore typename_type, - etc. that are not C++ class-keys. */ - if (class_key != class_type - && class_key != record_type - && class_key != union_type) -return; - /* The class-key is redundant for uses of the CLASS_TYPE that are neither definitions of it nor declarations, and for which name lookup returns just the type itself. */ Martin, do you want me to post it? (I can wait until your patch above is committed if you don't want any conflicts.)
[Bug c++/93867] ICE using class type NTTPs and class template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93867 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Marek Polacek --- Dup, I think. Thanks for the nice testcase. *** This bug has been marked as a duplicate of bug 93295 ***
[Bug c++/93295] ICE in alias_ctad_tweaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93295 Marek Polacek changed: What|Removed |Added CC||pkeir at outlook dot com --- Comment #4 from Marek Polacek --- *** Bug 93867 has been marked as a duplicate of this bug. ***
[Bug c++/93295] ICE in alias_ctad_tweaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93295
--- Comment #5 from Marek Polacek ---
Another test from Bug 93867:
template
struct basic_fixed_string
{
constexpr basic_fixed_string(const CharT *p) {
for (int i = 0; i < N; ++i) {
m_data[i] = p[i];
}
}
CharT m_data[N] {};
};
template
basic_fixed_string(const CharT (&)[N]) -> basic_fixed_string;
template
using fixed_string = basic_fixed_string;
template
constexpr int foo()
{
return 42;
}
int main(int argc, char const *argv[])
{
foo<"hello">();
return 0;
}
[Bug tree-optimization/92955] [10 regression] gcc.dg/vect/pr60505.c fails starting with r279392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92955 --- Comment #6 from Matheus Castanho --- Hi. Any updates on this issue?
[Bug middle-end/92492] AVX512: Missed vectorization opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92492 Tamar Christina changed: What|Removed |Added Target|i386, x86-64, aarch64 |i386, x86-64 Status|ASSIGNED|NEW Assignee|anton.youdkevitch@bell-sw.c |unassigned at gcc dot gnu.org |om | Summary|Missed optimization in |AVX512: Missed |detecting unneeded widening |vectorization opportunity |conversions.| --- Comment #6 from Tamar Christina --- > (In reply to Anton Youdkevitch from comment #5) > This is not just about type promotion/demotion. > The results of (-x)>>7 done in unsigned char and in int are different. > You're right, in that the version given here can't be optimized when the input value is an unsigned char. The actual one in SPEC2017 can, because it's actually just doing clipping. However that one GCC already generates the most efficient form for these simple test cases. For the actual testcase there's a lot of inefficiency depending on the ISA, but that's an ISA specific issue not a mid-end one. The reported vectorization issue does indeed seem to be AVX512 specific.
[Bug c/93848] missing -Warray-bounds warning for array subscript 1 is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848 --- Comment #4 from Vincent Lefèvre --- Perhaps this was not the intent of the standard (and this is far from being clear because this might affect optimizations -- there are already many things that are forbidden with pointers though they could have a valid interpretation with a basic memory model). But this is currently forbidden. Note that in my example, the * operator is evaluated, so that both the end of 6.5.6p8 and 6.5.3.2p4 (which is about evaluation since it describes what the result is) apply. FYI, this is not supported by some tcc version, though I suspect that this may be due to a bug that could affect valid code too. But who knows...
[Bug tree-optimization/93586] [10 Regression] wrong code at -O1 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93586
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:91e50b2aa2dece9e22ae793d2a1a14b33bf3859d
commit r10-6781-g91e50b2aa2dece9e22ae793d2a1a14b33bf3859d
Author: Jan Hubicka
Date: Fri Feb 21 15:36:00 2020 +0100
tree-optimization: fix access path oracle on mismatched array refs
[PR93586]
nonoverlapping_array_refs_p is not supposed to give meaningful results when
bases of ref1 and ref2 are not same or completely disjoint and here it is
called on c[0][j_2][0] and c[0][1] so bases in sence of this functions are
"c[0][j_2]" and "c[0]" which do partially overlap.
nonoverlapping_array_refs
however walks pair of array references and in this case it misses to note
the
fact that if it walked across first mismatched pair it is no longer safe to
compare rest.
The reason why it continues matching is because it hopes it will
eventually get pair of COMPONENT_REFs from types of same size and use
TBAA to conclude that their addresses must be either same or completely
disjoint.
This patch makes the loop to terminate early but popping all the
remaining pairs so walking can continue. We could re-synchronize on
arrays of same size with TBAA but this is bit fishy (because we try to
support some sort of partial array overlaps) and hard to implement
(because of zero sized arrays and VLAs) so I think it is not worth the
effort.
In addition I notied that the function is not !flag_strict_aliasing safe
and added early exits on places we set seen_unmatched_ref_p since later
we do not check that in:
/* If we skipped array refs on type of different sizes, we can
no longer be sure that there are not partial overlaps. */
if (seen_unmatched_ref_p
&& !operand_equal_p (TYPE_SIZE (type1), TYPE_SIZE (type2), 0))
{
++alias_stats
.nonoverlapping_refs_since_match_p_may_alias;
}
PR tree-optimization/93586
* tree-ssa-alias.c (nonoverlapping_array_refs_p): Finish array walk
after mismatched array refs; do not sure type size information to
recover from unmatched referneces with !flag_strict_aliasing_p.
* gcc.dg/torture/pr93586.c: New testcase.
[Bug fortran/93825] [OpenACC] Implicit typing not honored – bogus type errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93825 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tobias Burnus --- FIXED on the GCC 10 trunk.
[Bug rtl-optimization/90040] [meta-bug] modulo-scheduler and partitioning issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90040 --- Comment #3 from Roman Zhuykov --- (In reply to Roman Zhuykov from comment #2) > Same ICE also appears when compiling gcc.c-torture/execute/pr71550.c with So, I've opened separate PR93264 for that example, and now we have some related discussion there. Another discussion was in mailing list, starting from https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00666.html > With my local (still WIP) modulo-sched features, SMS pass can be used on > x86, where -freorder-blocks-and-partition is enabled by default. So, this > assertion failure becomes much more annoying, even bootstrap failed on it in > some specific conditions. I've found some mistake in my patches. For testing purpose I've tried to make some extreme conditions for modulo-scheduler and modified the way loop_version is called. And that help me to find a way to make the latent issue more obvious. Imagine a scenario when modulo-sched.c code calls loop_version with always-true condition, e.q. get_rtx_GEU(left, right), where 'right' can eventually be a compile-time zero constant. It this situation there are a lot of tests on different platforms where problematic assertion failure appears as an ICE. It tries to redirect (with _force) a basic block, where last instruction is barrier, and the previous instruction is a fallthrough jump. After fixing my mistake the ICE doesn't impede further SMS enhancements.
[Bug c++/93870] New: User-defined conversion function not working in evaluation of template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93870
Bug ID: 93870
Summary: User-defined conversion function not working in
evaluation of template argument
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: o_kniemeyer at maxon dot net
Target Milestone: ---
According to gcc.godbolt.org GCC 7.1 up to 9.2 fail to compile this piece of
code:
template struct EnumWrapper
{
ENUM value;
constexpr operator ENUM() const
{
return value;
}
};
enum E : int
{
V
};
constexpr EnumWrapper operator ~(E a)
{
return {E(~int(a))};
}
template struct R
{
static void Func();
};
template struct S : R<~X>
{
};
void Test()
{
S::Func();
}
The can't evaluate the template argument ~X for R:
: In instantiation of 'struct S<(E)0>':
:32:12: required from here
:26:31: error: taking address of temporary [-fpermissive]
template struct S : R<~X>
^
:26:31: error: no matching function for call to
'EnumWrapper::operator E(EnumWrapper*)'
:5:12: note: candidate: constexpr EnumWrapper::operator ENUM()
const [with ENUM = E]
constexpr operator ENUM() const
^~~~
:5:12: note: candidate expects 0 arguments, 1 provided
: In function 'void Test()':
:32:14: error: 'Func' is not a member of 'S<(E)0>'
S::Func();
^~~~
All other compiler are fine. A workaround is to convert to E explicitly by
writing R.
[Bug rtl-optimization/93264] [10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264 Roman Zhuykov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #6 from Roman Zhuykov --- First, I want here to mention that Richard have recently discussed partitioning in mailing list with Segher, starting from https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00666.html > I'll run some cross-testing to check how it works for now. Second, those tests have finished and there is nothing to say about the results. From correctness aspect everything looks fine. But I haven't tried to look at each example where it prevents/allows loops to be scheduled, and know nothing about performance impact. (In reply to rsand...@gcc.gnu.org from comment #4) > Yeah, it ought to be better to do mode switching first. But I think > the more important ones are: > > NEXT_PASS (pass_split_all_insns); > NEXT_PASS (pass_lower_subreg3); > > Scheduling should happen on the split form of insns rather than the > unsplit form. lower_subreg should also improve "schedulability". Agreed, so it would be much better to fix the issue conservatively without moving the pass.
[Bug tree-optimization/93301] Wrong optimization: instability of uninitialized variables leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301 Vincent Lefèvre changed: What|Removed |Added CC||vincent-gcc at vinc17 dot net --- Comment #14 from Vincent Lefèvre --- (In reply to rguent...@suse.de from comment #10) > I'd say "using" an uninitialized value is UB. In general, but not for unsigned char. C17 6.2.4p6 says for objects with automatic storage duration (which is the case here): "The initial value of the object is indeterminate." 3.19.2 says "indeterminate value: either an unspecified value or a trap representation". Since we have an unsigned char here, this is not a trap representation. Thus this is an unspecified value. 3.19.3 says "unspecified value: valid value of the relevant type where this International Standard imposes no requirements on which value is chosen in any instance" (and the note says that this "cannot be a trap representation"). In short, by reading such an uninitialized unsigned char variable, you get a valid value, but you don't know which one. And by reading the variable again, you still get a valid value, which may be different. No UB here.
[Bug fortran/93835] [9/10 Regression] ICE in simplify_findloc_nodim, at fortran/simplify.c:5513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93835
markeggleston at gcc dot gnu.org changed:
What|Removed |Added
CC||markeggleston at gcc dot
gnu.org
--- Comment #4 from markeggleston at gcc dot gnu.org ---
After applying the patch in comment 2 the ICE no longer occurs, however, it
reveals an error when using the shape intrinsic with the findloc intrinsic.
program test
print *, findloc(shape([1, 2, 3, 4]), 4)
end program
produces:
0
i.e. 4 is not found in the array returned by shape.
shape does indeed return [ 4 ] but the expression representing the array does
not have a shape defined. This is why it is necessary to check for the
existence of shape in the original patch.
Adding a shape to the result expression addressed the issue and also means that
the original is not required:
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 613fdafd1a6..59afb239af5 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -7228,6 +7228,8 @@ gfc_simplify_shape (gfc_expr *source, gfc_expr *kind)
return NULL;
result = gfc_get_array_expr (BT_INTEGER, k, &source->where);
+ result->shape = gfc_get_shape (1);
+ mpz_init (result->shape[0]);
if (source->rank == 0)
return result;
@@ -7284,6 +7286,8 @@ gfc_simplify_shape (gfc_expr *source, gfc_expr *kind)
if (t)
gfc_clear_shape (shape, source->rank);
+ mpz_set_si (result->shape[0], source->rank);
+
return result;
}
There is some tidying up to do as pr77351.f90 now produces one error instead of
two:
4 |print *, any(shape(z) /= [4,1]) ! { dg-error "shape for elemental
binary" }
|1 2
Error: Shapes for operands at (1) and (2) are not conformable
verses:
4 |print *, any(shape(z) /= [4,1]) ! { dg-error "shape for elemental
binary" }
|1
Error: Different shape for elemental binary operation at (1) on dimension 1 (1
and 2)
pr77351.f90:4:16:
4 |print *, any(shape(z) /= [4,1]) ! { dg-error "shape for elemental
binary" }
|1
Error: Array operands are incommensurate at (1)
Final patch in preparation.
[Bug analyzer/93032] analyzer fails to detect FILE * leak in zlib/contrib/minizip/mztools.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93032 --- Comment #2 from David Malcolm --- I'm not convinced that the above patch is correct. What if one or two of the fopen calls fail? Then the else branch of the "if" will be followed, and no fclose will be called on the fp for the calls that succeeded. I have a patch that enables the analyzer to report three leaks, based on the above (for each of the fopen calls succeeding where one of the others fails).
[Bug middle-end/93848] missing -Warray-bounds warning for array subscript 1 is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848 Martin Sebor changed: What|Removed |Added Status|WAITING |NEW CC||msebor at gcc dot gnu.org Component|c |middle-end See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93514 Blocks||56456 Severity|normal |enhancement --- Comment #5 from Martin Sebor --- The warning is emitted for the original test case once it's made clear that bar_aux dereferences the pointer using the access attribute: __attribute__ ((access (read_write, 1))) void bar_aux (int *); But in the absence of any evidence that the past-the-end pointer is dereferenced, it can't, in general, be diagnosed without causing false positives such as in calls to functions that take two pointers of compatible types: void baz_aux (int *, int *); The function could be called on a range: int a[3]; baz_aux (a, a + 3); as often happens in C++ (many functions in the standard library take two iterators delineating a range as arguments, and are often called just like the one above). But I do think issuing a warning for a subset of these cases would be safe and helpful. For instance, when passing a past-the-end pointer to a function that takes just a single pointer would be okay because the function in all likelihood does dereference it. I recently opened bug 93514 noting this problem in calls to built-ins (pr93514). There, the past-the-end pointer is certain to be accessed by the function, but the warning doesn't have the logic to detect it. Anyway, let me confirm this report as an enhancement request for a warning along the lines of the idea in bug 93514 comment 1. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug libfortran/93871] New: COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 Bug ID: 93871 Summary: COTAN is slow for complex types Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: thenlich at gcc dot gnu.org Target Milestone: --- Runtime tests show that the COTAN function (cotangent function, GNU extension) needs about twice the time as TAN for complex types. This is surprising, since it basically performs the same operations as TAN, only in a different order. I would expect COTAN to perform about the same as TAN.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #1 from Thomas Henlich --- Created attachment 47883 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47883&action=edit Proposed patch for COTAN speedup This is basically the same method mpc uses internally to compute mpc_tan (only reversed)
[Bug c/20785] Pragma STDC * (C99 FP) unimplemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785 --- Comment #10 from joseph at codesourcery dot com --- On Fri, 21 Feb 2020, vincent-gcc at vinc17 dot net wrote: > Concerning the STDC FP_CONTRACT pragma, implementing it would not be > sufficient. GCC would also need to restrict how it does contraction, as it > currently does not contract only expressions, but also sequences of > expressions, which is invalid. Example: Note that -ffp-contract=on is currently equivalent to -ffp-contract=off for this reason. It's only -ffp-contract=fast that contracts outside expressions (and C standards conformance modes disable contraction).
[Bug c++/93869] [10 Regression] ICE in contains_struct_check with -Wmismatched-tags upon redundant typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93869 --- Comment #3 from Martin Sebor --- Go ahead, Marek. I'll deal with the conflict if there is one. Thanks!
[Bug c++/93869] [10 Regression] ICE in contains_struct_check with -Wmismatched-tags upon redundant typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93869 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- Ack, mine then.
[Bug libstdc++/93872] New: std::move(first, last, out) doesn't work in -std=c++2a when value type is move-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93872
Bug ID: 93872
Summary: std::move(first, last, out) doesn't work in -std=c++2a
when value type is move-only
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat bug.cc
#include
#include
struct X
{
X() = default;
X(const X&) = delete;
X& operator=(const X&) = delete;
X(X&&) = default;
X& operator=(X&&) = default;
};
bool
test01()
{
std::array a, b;
std::move(a.begin(), a.end(), b.begin());
return true;
}
$ g++ -std=c++17 bug.cc
$ g++ -std=c++2a bug.cc
...
/home/patrick/code/gcc/libstdc++-v3/include/bits/stl_algobase.h:98:10: error:
use of deleted function ‘X& X::operator=(const X&)’
98 | *__dst = std::move(*__src);
| ~~~^~~
bug.cc:9:6: note: declared here
9 | X& operator=(const X&) = delete;
| ^~~~
...
[Bug c++/93753] [8/9/10 Regression] ICE on a flexible array followed by a member in an anonymous struct with an initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93753 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:dbfba41e95d1d93b17e907b7f516b52ed3a3c415 commit r10-6789-gdbfba41e95d1d93b17e907b7f516b52ed3a3c415 Author: Martin Sebor Date: Fri Feb 21 10:45:56 2020 -0700 PR c++/93753 - ICE on a flexible array followed by a member in an anonymous struct with an initializer gcc/cp/ChangeLog: PR gcov-profile/93753 * class.c (check_flexarrays): Tighten up a test for potential members of anonymous structs or unions. gcc/testsuite/ChangeLog: PR gcov-profile/93753 * g++.dg/ext/flexary36.C: New test. * g++.dg/lto/pr93166_0.C: Make struct with flexarray valid.
[Bug c++/93753] [8/9 Regression] ICE on a flexible array followed by a member in an anonymous struct with an initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93753 Martin Sebor changed: What|Removed |Added Known to work||10.0 Summary|[8/9/10 Regression] ICE on |[8/9 Regression] ICE on a |a flexible array followed |flexible array followed by |by a member in an anonymous |a member in an anonymous |struct with an initializer |struct with an initializer Known to fail|10.0| --- Comment #6 from Martin Sebor --- Fixed in GCC 10.0. The fix should be backported.
[Bug c++/93824] -Wredundant-tags false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93824 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-02-21 Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- The tag is redundant in both cases and can be removed without causing an ambiguity. Why do you think the warnings are wrong?
[Bug c++/93824] -Wredundant-tags false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93824 --- Comment #2 from Stephan Bergmann --- (In reply to Martin Sebor from comment #1) > The tag is redundant in both cases and can be removed without causing an > ambiguity. Why do you think the warnings are wrong? In the test2.cc case, S has not yet been declared, so the elaborated type specifier is needed to declare it. In the test1.cc case, dropping the (redundant) tag from incB.h will cause test2.cc to no longer compile, see above.
[Bug c++/93824] -Wredundant-tags false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93824 Martin Sebor changed: What|Removed |Added Status|WAITING |NEW Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- Ah, I see. I'm not sure there's anything I can do about the first case -- the warning there is by design. But the warning in the second case is not intended: $ cat test2.cc && gcc -S -Wall -Wextra -Wredundant-tags test2.cc void f (struct S*); // bogus -Wredundant-tags test2.cc:1:9: warning: redundant class-key ‘struct’ in reference to ‘struct S’ [-Wredundant-tags] 1 | void f (struct S*); // bogus -Wredundant-tags | ^~ | -- I should be able to fix this. Out of curiosity, what is your interest in -Wredundant-tag? (Are you hoping to use it to clean up a code base or something else?)
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- Can you post the code you used for testing? Your patch to simplify.c affects compile-time constant folding. simplify.c has nothing to do with a run-time evaluation. Hmmm, upon inspection, the implementation of cotan in the Fortran FE is certainly broken. function foo(z) result(a) complex a complex, intent(in) :: z intrinsic cotan a = cotan(z) end function foo % gfcx -c a.f90 a.f90:4:18: 4 |intrinsic cotan | 1 Error: 'cotan' declared INTRINSIC at (1) does not exist Removing the 'intrinsic cotan' line and running in the debugger, one finds that none of gfc_check_fn_rc2008, gfc_simplify_cotan, and gfc_resolve_cotan are called. So, compiling this to assembly % gfcx -S -o a.s -O -c a.f90 .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq%rsp, %rbp .cfi_def_cfa_register 6 subq$16, %rsp callcotan_ movss %xmm0, -8(%rbp) movl$0x, -4(%rbp) movq-8(%rbp), %xmm0 leave .cfi_def_cfa 7, 8 ret .cfi_endproc we see that we're calling a function named cotan. Haven't found where cotan lives. % nm /usr/local/lib/gcc9/libgfortran.a | grep cotan nm: bessel_r10.o: no symbols nm: atomic.o: no symbols % nm /usr/lib/libm.a | grep cotan % find ~/gcc/gccx/libgfortran -type f | xargs grep -i cotan Completely the program program bar complex b, c b = (1.,1.) c = cotan(b) print *, c end program bar % gfcx -o z a.f90 /usr/local/bin/ld: /tmp/ccqbsxb5.o: in function `MAIN__': a.f90:(.text+0x2d): undefined reference to `cotan_' collect2: error: ld returned 1 exit status
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #2) > Can you post the code you used for testing? Your patch to simplify.c > affects compile-time constant folding. simplify.c has nothing to do > with a run-time evaluation. > Nevermind, I didn't realize that this required -fdec. It would help if you added your test program, and command line used for testing!
[Bug c/93873] New: gcc or lto-wrapper does not consider individual bitfield values on static analysis and instead tests the whole value of all bitfield bits combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93873
Bug ID: 93873
Summary: gcc or lto-wrapper does not consider individual
bitfield values on static analysis and instead tests
the whole value of all bitfield bits combined
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: emil.fihlman at aalto dot fi
Target Milestone: ---
On gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
Given these two files (and stdtypes.h being available from
https://emil.fi/d/stdtypes.h but it's basically just include stdint.h and
typedef u?int\d+_t to the correct [su]\d+
$cat ltobuglib.h
#include
#include
#include
struct thing
{
u64 v;
struct
{
u64 dox:1;
u64 freeme:1;
} flags;
};
struct thing *makeit(struct thing *t)
{
u8 dynamic=!t;
if(dynamic)
{
t=calloc(1, sizeof(*t));
if(!t)
{
return(NULL);
}
}
t->v=0;
t->flags.dox=1;
t->flags.freeme=dynamic;
return(t);
}
void freeit(struct thing *t)
{
if(t->flags.freeme)
{
free(t);
}
}
$cat ltobug.c
#include
#include
#include "ltobuglib.h"
s32 main(void)
{
struct thing t={0};
if(!makeit(&t))
{
return(-1);
}
printf("%lu %u %u\n", t.v, t.flags.dox, t.flags.freeme);
freeit(&t);
return(0);
}
$gcc -Wall -Werror -Wextra -O3 -flto -o ltobug ltobug.c
produces
In function ‘freeit’,
inlined from ‘main’ at ltobug.c:13:2:
ltobuglib.h:36:3: error: attempt to free a non-heap object ‘t’
[-Werror=free-nonheap-object]
free(t);
^
lto1: all warnings being treated as errors
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
but changing t->flags.dox=1 to 0 compiles cleanly.
Without -flto (and dox set to 1) the result is
In file included from ltobug.c:3:0:
In function ‘freeit’,
inlined from ‘main’ at ltobug.c:13:2:
ltobuglib.h:36:3: error: attempt to free a non-heap object ‘t’
[-Werror=free-nonheap-object]
free(t);
^~~
cc1: all warnings being treated as errors
On a different project of mine, the code cleanly compiles without -flto (but
fails with -flto as above) but here gcc seems to do the same issue without
-flto, too.
[Bug c/93873] gcc or lto-wrapper does not consider individual bitfield values on static analysis and instead tests the whole value of all bitfield bits combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93873 --- Comment #1 from Emil Fihlman --- Oh yeah and platform was Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #4 from Steve Kargl --- On Fri, Feb 21, 2020 at 06:53:18PM +, kargl at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 > > --- Comment #3 from kargl at gcc dot gnu.org --- > (In reply to kargl from comment #2) > > Can you post the code you used for testing? Your patch to simplify.c > > affects compile-time constant folding. simplify.c has nothing to do > > with a run-time evaluation. > > > > Nevermind, I didn't realize that this required -fdec. It would help > if you added your test program, and command line used for testing! > Adding -fdec and -fdump-tree-original, see c = __builtin_ccosf (b) / __builtin_csinf (b); which comes from iresolve.c.
[Bug middle-end/91623] [8 Regression] -msse4.1 -O3 segfault in /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/smmintrin.h:270:10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91623 --- Comment #14 from Jakub Jelinek --- Then please attach the preprocessed source that still ICEs, together with gcc/g++ command line that reproduces it. It doesn't have to be reduced, we can do that ourselves.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #5 from Thomas Henlich --- Created attachment 47884 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47884&action=edit Test case Output: th@THe-Surface:~$ /opt/gcc/bin/gfortran -L/opt/gcc/lib64 -Wl,-rpath -Wl,/opt/gcc/lib64 -fdec-math /mnt/c/Temp/test_cotan_complex.f90 && ./a.out Testing(+1.2E-003,+0.) 1/tan= (+999.9996664454,+0.) time: +0.243003011 cotan= (+999.9996664443,-0.) time: +0.535230994 cos/sin= (+999.9996664443,-0.) time: +0.530906022 tan(pi/2-a)= (+1000.0433799820958,+0.) time: +0.263039947 Testing (+1.,+0.) 1/tan= (+0.64209261593433076,+0.) time: +0.264049053 cotan= (+0.64209261593433076,-0.) time: +0.602337122 cos/sin=(+0.64209261593433076,-0.) time: +0.600989103 tan(pi/2-a)=(+0.64209267766718214,+0.) time: +0.247081995 Testing (+1.5701,+0.) 1/tan= (+7.96326963223192592E-004,+0.) time: +0.258723021 cotan= (+7.96326963223192592E-004,-0.) time: +0.588716030 cos/sin= (+7.96326963223192592E-004,-0.) time: +0.590244293 tan(pi/2-a)= (+7.96370674640914985E-004,+0.) time: +0.230789661 Testing (+3.,+0.) 1/tan= (-7.0152525514345339,-0.) time: +0.321346283 cotan= (-7.0152525514345339,-0.) time: +0.733272552 cos/sin= (-7.0152525514345339,-0.) time: +0.718843937 tan(pi/2-a)= (-7.0152503565215953,+0.) time: +0.266773224 t
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #6 from Thomas Henlich --- (In reply to kargl from comment #2) > Can you post the code you used for testing? Your patch to simplify.c > affects compile-time constant folding. simplify.c has nothing to do > with a run-time evaluation. Ok, I was looking in the wrong place. It's still a cool patch though ;-)
[Bug middle-end/93873] gcc or lto-wrapper does not consider individual bitfield values on static analysis and instead tests the whole value of all bitfield bits combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93873 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Component|c |middle-end --- Comment #2 from Andrew Pinski --- I suspect this is just a missed optimization. The -Wfree-nonheap-object warning is done after the majority of optimizations have happened. Also since you are using a non-supported GCC version, there is not much we can do for that version. Try a newer version of GCC.
[Bug target/93860] darwin: wrong quotation in diagnostic #pragma options align=reset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93860 --- Comment #3 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:147add96091790d5c1d8eb938f84ea775ad81b84 commit r10-6790-g147add96091790d5c1d8eb938f84ea775ad81b84 Author: Iain Sandoe Date: Fri Feb 21 20:12:39 2020 + Darwin: Fix wrong quoting on an error string (PR93860). The quotes should surround all of the literal content from the pragma that has incorrect usage. 2020-02-21 Iain Sandoe PR target/93860 * config/darwin-c.c (pop_field_alignment): Adjust quoting of error string.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #7 from Steve Kargl --- On Fri, Feb 21, 2020 at 07:45:39PM +, thenlich at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 > > --- Comment #6 from Thomas Henlich --- > (In reply to kargl from comment #2) > > Can you post the code you used for testing? Your patch to simplify.c > > affects compile-time constant folding. simplify.c has nothing to do > > with a run-time evaluation. > > Ok, I was looking in the wrong place. > > It's still a cool patch though ;-) Any patch that makes gfortran better is a cool. Was gonna suggest a variation of this code for a testcase: program foo complex, parameter :: z = cotan((1.,1.)) print *, z end program foo troutmask:sgk[218] gfcx -o z -fdec a.f90 && ./z f951: internal compiler error: Segmentation fault 0xdf68ca crash_signal ../../gccx/gcc/toplev.c:328 0x7bae8f check_null ../../gccx/gcc/fortran/expr.c:2796 0x7bae8f gfc_check_init_expr(gfc_expr*) ../../gccx/gcc/fortran/expr.c:2897 0x7b7229 check_intrinsic_op ../../gccx/gcc/fortran/expr.c:2440 0x7bac91 gfc_check_init_expr(gfc_expr*) ../../gccx/gcc/fortran/expr.c:2850 0x7bb427 gfc_reduce_init_expr(gfc_expr*) ../../gccx/gcc/fortran/expr.c:3067 0x7bf156 gfc_match_init_expr(gfc_expr**) ../../gccx/gcc/fortran/expr.c:3113 0x7a6dde variable_decl ../../gccx/gcc/fortran/decl.c:2854 0x7a6dde gfc_match_data_decl() ../../gccx/gcc/fortran/decl.c:6130 0x812eec match_word ../../gccx/gcc/fortran/parse.c:65 0x812eec decode_statement ../../gccx/gcc/fortran/parse.c:376 0x818854 next_free ../../gccx/gcc/fortran/parse.c:1279 0x818854 next_statement ../../gccx/gcc/fortran/parse.c:1511 0x81b0ac parse_spec ../../gccx/gcc/fortran/parse.c:3738 0x81d0bf parse_progunit ../../gccx/gcc/fortran/parse.c:5848 0x81e7b4 gfc_parse_file() ../../gccx/gcc/fortran/parse.c:6388 0x8718f8 gfc_be_parse_file ../../gccx/gcc/fortran/f95-lang.c:210
[Bug target/93860] darwin: wrong quotation in diagnostic #pragma options align=reset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93860 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Sandoe --- for the record, there is a test for Darwin-specific pragmas (including the align one) gcc/testsuite/gcc.dg/pragma-darwin.c However, this specific case is not covered by that test - although it would be simple to extend the test to cover it. However, given that there is still some debate about the "best" behaviour of the pragma (PR50909), I have left the test unchanged pending resolution of that PR. this PR should be fixed on trunk (I'll look at open branches in the next few days),
[Bug ipa/93763] [10 Regression] ice in propagate_vals_across_arith_jfunc, at ipa-cp.c:2039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93763 --- Comment #3 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:47772af10c00f7e1e95cd52557fc893dc602a420 commit r10-6791-g47772af10c00f7e1e95cd52557fc893dc602a420 Author: Feng Xue Date: Mon Feb 17 17:07:04 2020 +0800 Do not propagate self-dependent value (PR ipa/93763) PR ipa/93763 * ipa-cp.c (self_recursively_generated_p): Mark self-dependent value as self-recursively generated.
[Bug ipa/93763] [10 Regression] ice in propagate_vals_across_arith_jfunc, at ipa-cp.c:2039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93763 --- Comment #4 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:25f0909af87171395d9ee21cf2873f4d9b5ebc91 commit r10-6792-g25f0909af87171395d9ee21cf2873f4d9b5ebc91 Author: Jeff Law Date: Fri Feb 21 13:24:27 2020 -0700 Do not propagate self-dependent value (PR ipa/93763) (ChangeLog) PR ipa/93763 * ipa-cp.c (self_recursively_generated_p): Mark self-dependent value as self-recursively generated.
[Bug ipa/93763] [10 Regression] ice in propagate_vals_across_arith_jfunc, at ipa-cp.c:2039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93763 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #5 from Jeffrey A. Law --- Fixed by Feng's patch on the trunk.
[Bug driver/93874] New: ICE due to command line options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93874 Bug ID: 93874 Summary: ICE due to command line options Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Hi all! $ touch ./empty.c $ gcc -fdisable-tree-dse3 -fdump-passes ./empty.c The file just haves to exist and have a known file format. The -fdisable-tree value does not have to be dse3. Best regards. José Rui
[Bug c++/93824] -Wredundant-tags false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93824
--- Comment #4 from Stephan Bergmann ---
(In reply to Martin Sebor from comment #3)
> Ah, I see. I'm not sure there's anything I can do about the first case --
> the warning there is by design.
So users will have to be careful when they fix a -Wredundant-tags warning in an
included file. They may have to introduce a forward declaration into the
included file in order not to break (or silently alter) other translation units
that also include that file. (A case where removal of the "redundant" tag in
the included file inc.h
> struct S {};
> namespace N {
> int f(struct S); // -Wredundant-tags
> }
can silently alter the behavior of another translation unit is when that other
translation unit contains
> namespace N { int S = 0; }
> #include "inc.h"
so that N::f would now be a variable rather than a function there.)
> Out of curiosity, what is your interest in -Wredundant-tag? (Are you hoping
> to use it to clean up a code base or something else?)
My motivation is to see if -Wmismatched-tags and -Wredundant-tags could be used
by LibreOffice. The former would be useful for compatibility with MSVC, where
mismatched tags already produce a warning (i.e., error, with our
--enable-werror regime). And we have a number of source files that migrated
from C to C++ over time, where the latter could help clean up some accidental
clutter. (Plus, LibreOffice always proves to be a good testbed for new
diagnostics. :)
[Bug driver/93874] ICE due to command line options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93874 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-21 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #8 from Steve Kargl ---
On Fri, Feb 21, 2020 at 08:19:01PM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> program foo
> complex, parameter :: z = cotan((1.,1.))
> print *, z
> end program foo
>
Something is definitely broken. I'll need to
revisit intrinsic.c. To get to the first
executable statement in gfc_simplify_cotan,
(gdb) b simplify.c:7793
(gdb) p *x
$6 = {expr_type = EXPR_FUNCTION, ts = {type = BT_UNKNOWN, kind = 0, u =
{derived = 0x0,
cl = 0x0, pad = 0}, interface = 0x0, is_c_interop = 0, is_iso_c = 0,
f90_type = BT_UNKNOWN, deferred = false, interop_kind = 0x0}, rank = 0,
shape = 0x0,
symtree = 0x2024e8570, ref = 0x0, where = {nextc = 0x202db65cc, lb =
0x202db6540},
base_expr = 0x0, is_snan = 0, error = 0, user_operator = 0, mold = 0,
must_finalize = 0,
no_bounds_check = 0, external_blas = 0, do_not_resolve_again = 0, do_not_warn
= 0,
from_constructor = 0, representation = {length = 0, string = 0x0}, boz = {len
= 0,
rdx = 0, str = 0x0}, value = {logical = 38700448, iokind = 38700448,
integer = {{
_mp_alloc = 38700448, _mp_size = 2, _mp_d = 0x0}}, real = {{
_mpfr_prec = 8628635040, _mpfr_sign = 0, _mpfr_exp = 8647423552,
_mpfr_d = 0x0}},
complex = {{re = {{_mpfr_prec = 8628635040, _mpfr_sign = 0, _mpfr_exp =
8647423552,
_mpfr_d = 0x0}}, im = {{_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp =
0,
_mpfr_d = 0x0, op = {op = 38700448, uop = 0x0, op1 =
0x2036d3640,
op2 = 0x0}, function = {actual = 0x2024e85a0, name = 0x0, isym =
0x2036d3640,
esym = 0x0}, compcall = {actual = 0x2024e85a0, name = 0x0,
base_object = 0x2036d3640, tbp = 0x0, ignore_pass = 0, assign = 0},
character = {
length = 8628635040, string = 0x0}, constructor = 0x2024e85a0},
param_list = 0x0}
Hmmm, x should be the argument to cotan.
(gdb) p *x->value.function->isym
$9 = {name = 0x20344fa88 "cotan", lib_name = 0x20346a130 "_gfortran_cotan",
formal = 0x2036e6928, ts = {type = BT_REAL, kind = 4, u = {derived = 0x0, cl
= 0x0,
pad = 0}, interface = 0x0, is_c_interop = 0, is_iso_c = 0, f90_type =
BT_UNKNOWN,
deferred = false, interop_kind = 0x0}, elemental = 1, inquiry = 0,
transformational = 0, pure = 1, generic = 1, specific = 1, actual_ok = 1,
noreturn = 0,
but it apprears to be the function itself!
(gdb) p *x->value.function->actual->expr
$11 = {expr_type = EXPR_CONSTANT, ts = {type = BT_COMPLEX, kind = 4, u =
{derived = 0x0,
cl = 0x0, pad = 0}, interface = 0x0, is_c_interop = 0, is_iso_c = 0,
[Bug rtl-optimization/92989] [10 Regression] The mips-mti-linux-gnu fails to build after r276327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92989 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #5 from Jeffrey A. Law --- Should be fixed on the trunk now.
[Bug c++/93824] -Wredundant-tags false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93824
--- Comment #5 from Stephan Bergmann ---
(In reply to Stephan Bergmann from comment #4)
> So users will have to be careful when they fix a -Wredundant-tags warning in
> an included file. They may have to introduce a forward declaration into the
> included file
...or use a qualified name like "::S" as would be necessary in the example
below...
> in order not to break (or silently alter) other translation
> units that also include that file. (A case where removal of the "redundant"
> tag in the included file inc.h
>
> > struct S {};
> > namespace N {
> > int f(struct S); // -Wredundant-tags
> > }
>
> can silently alter the behavior of another translation unit is when that
> other translation unit contains
>
> > namespace N { int S = 0; }
> > #include "inc.h"
>
> so that N::f would now be a variable rather than a function there.)
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #9 from Steve Kargl ---
On Fri, Feb 21, 2020 at 08:33:04PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
>
> --- Comment #8 from Steve Kargl ---
> On Fri, Feb 21, 2020 at 08:19:01PM +, sgk at troutmask dot
> apl.washington.edu wrote:
> >
> > program foo
> > complex, parameter :: z = cotan((1.,1.))
> > print *, z
> > end program foo
> >
>
> Something is definitely broken. I'll need to
> revisit intrinsic.c. To get to the first
> executable statement in gfc_simplify_cotan,
>
> (gdb) b simplify.c:7793
> (gdb) p *x
> $6 = {expr_type = EXPR_FUNCTION, ts = {type = BT_UNKNOWN, kind = 0, u =
> {derived = 0x0,
> cl = 0x0, pad = 0}, interface = 0x0, is_c_interop = 0, is_iso_c = 0,
> f90_type = BT_UNKNOWN, deferred = false, interop_kind = 0x0}, rank = 0,
> shape = 0x0,
> symtree = 0x2024e8570, ref = 0x0, where = {nextc = 0x202db65cc, lb =
> 0x202db6540},
> base_expr = 0x0, is_snan = 0, error = 0, user_operator = 0, mold = 0,
> must_finalize = 0,
> no_bounds_check = 0, external_blas = 0, do_not_resolve_again = 0,
> do_not_warn
> = 0,
> from_constructor = 0, representation = {length = 0, string = 0x0}, boz =
> {len
> = 0,
> rdx = 0, str = 0x0}, value = {logical = 38700448, iokind = 38700448,
> integer = {{
> _mp_alloc = 38700448, _mp_size = 2, _mp_d = 0x0}}, real = {{
> _mpfr_prec = 8628635040, _mpfr_sign = 0, _mpfr_exp = 8647423552,
> _mpfr_d = 0x0}},
> complex = {{re = {{_mpfr_prec = 8628635040, _mpfr_sign = 0, _mpfr_exp =
> 8647423552,
> _mpfr_d = 0x0}}, im = {{_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp
> =
> 0,
> _mpfr_d = 0x0, op = {op = 38700448, uop = 0x0, op1 =
> 0x2036d3640,
> op2 = 0x0}, function = {actual = 0x2024e85a0, name = 0x0, isym =
> 0x2036d3640,
> esym = 0x0}, compcall = {actual = 0x2024e85a0, name = 0x0,
> base_object = 0x2036d3640, tbp = 0x0, ignore_pass = 0, assign = 0},
> character = {
> length = 8628635040, string = 0x0}, constructor = 0x2024e85a0},
> param_list = 0x0}
>
> Hmmm, x should be the argument to cotan.
>
> (gdb) p *x->value.function->isym
> $9 = {name = 0x20344fa88 "cotan", lib_name = 0x20346a130 "_gfortran_cotan",
> formal = 0x2036e6928, ts = {type = BT_REAL, kind = 4, u = {derived = 0x0, cl
> = 0x0,
> pad = 0}, interface = 0x0, is_c_interop = 0, is_iso_c = 0, f90_type =
> BT_UNKNOWN,
> deferred = false, interop_kind = 0x0}, elemental = 1, inquiry = 0,
> transformational = 0, pure = 1, generic = 1, specific = 1, actual_ok = 1,
> noreturn = 0,
>
> but it apprears to be the function itself!
>
> (gdb) p *x->value.function->actual->expr
> $11 = {expr_type = EXPR_CONSTANT, ts = {type = BT_COMPLEX, kind = 4, u =
> {derived = 0x0,
> cl = 0x0, pad = 0}, interface = 0x0, is_c_interop = 0, is_iso_c = 0,
>
Ugh, this diff fixes constant-folding (without your mpc_sincos) patch.
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c (revision 280157)
+++ gcc/fortran/simplify.c (working copy)
@@ -7782,26 +7787,32 @@ gfc_simplify_sum (gfc_expr *array, gfc_expr *dim, gfc_
gfc_expr *
gfc_simplify_cotan (gfc_expr *x)
{
- gfc_expr *result;
+ gfc_expr *arg, *result;
mpc_t swp, *val;
- if (x->expr_type != EXPR_CONSTANT)
+ if (x->expr_type == EXPR_FUNCTION
+ && strcmp(x->value.function.isym->name, "cotan") == 0)
+arg = x->value.function.actual->expr;
+ else
+arg = x;
+
+ if (arg->expr_type != EXPR_CONSTANT)
return NULL;
- result = gfc_get_constant_expr (x->ts.type, x->ts.kind, &x->where);
+ result = gfc_get_constant_expr (arg->ts.type, arg->ts.kind, &arg->where);
- switch (x->ts.type)
+ switch (arg->ts.type)
{
case BT_REAL:
- mpfr_cot (result->value.real, x->value.real, GFC_RND_MODE);
+ mpfr_cot (result->value.real, arg->value.real, GFC_RND_MODE);
break;
case BT_COMPLEX:
/* There is no builtin mpc_cot, so compute cot = cos / sin. */
val = &result->value.complex;
mpc_init2 (swp, mpfr_get_default_prec ());
- mpc_cos (swp, x->value.complex, GFC_MPC_RND_MODE);
- mpc_sin (*val, x->value.complex, GFC_MPC_RND_MODE);
+ mpc_cos (swp, arg->value.complex, GFC_MPC_RND_MODE);
+ mpc_sin (*val, arg->value.complex, GFC_MPC_RND_MODE);
mpc_div (*val, swp, *val, GFC_MPC_RND_MODE);
mpc_clear (swp);
break;
But, as I stated something is broken, and I suspect it affects
all -fdec functions.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 Fritz Reese changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-21 Assignee|unassigned at gcc dot gnu.org |foreese at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #10 from Fritz Reese --- Thomas, thank you for discovering this. Steve, thanks for your investigative work and the patch. I will try to look at this and get a patch in within the next week or so.
[Bug target/91913] [8/9/10 Regression] ICE in extract_constrain_insn, at recog.c:2211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913 --- Comment #7 from Andrew Pinski --- (In reply to John Paul Adrian Glaubitz from comment #6) > I'm seeing this exact problem SH as well when trying to build webkit2gtk: Please report this speerately.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #11 from Steve Kargl --- On Fri, Feb 21, 2020 at 08:44:25PM +, foreese at gcc dot gnu.org wrote: > > --- Comment #10 from Fritz Reese --- > Thomas, thank you for discovering this. Steve, thanks for your investigative > work and the patch. I will try to look at this and get a patch in within the > next week or so. > Hi Fritz, I'm scratching my head on this one. The way you added 'cotan' to intrinsic.c looks exactly like how 'sin' is added to the list of intrinsics. I would expect it to just work, but ... clearly something is amiss.
[Bug translation/93759] Invalid % in param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93759
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8d1780b56d0cb1d50115d4e925e81cd8b9cb2923
commit r10-6794-g8d1780b56d0cb1d50115d4e925e81cd8b9cb2923
Author: Jakub Jelinek
Date: Fri Feb 21 22:01:03 2020 +0100
i18n: Fix translation of --help [PR93759]
The first two hunks make sure we actually translate what has been marked
for translation, i.e. the cl_options[...].help strings, rather than those
strings ammended in various ways, like:
_("%s Same as %s."), help, ...
or
"%s %s", help, _(use_diagnosed_msg)
The exgettext changes attempt to make sure that the cl_options[...].help
strings are marked as no-c-format, because otherwise if they happen
to contain a % character, such as the 90% substring, they will be marked
as c-format, which they aren't.
2020-02-21 Jakub Jelinek
PR translation/93759
* opts.c (print_filtered_help): Translate help before appending
messages to it rather than after that.
* exgettext: For *.opt help texts, use __opt_help_text("...")
rather than _("...") in the $emsg file and pass options that
say that this implies no-c-format.
[Bug c++/93875] New: confusing type in an error about an invalid call to a specialization on data member pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93875
Bug ID: 93875
Summary: confusing type in an error about an invalid call to a
specialization on data member pointer
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The first part of the note after the first error below is confusing: what is
'int MemDataPtr::* = -1' supposed to refer to? I gather
refers to the (unnamed) member in the typedef MemDataPtr, and the
-1 refers to the internal representation of the member pointer (all ones). But
if that's correct, since the member in the definition of a member pointer type
is necessarily always omitted, the part seems not just superfluous,
it's incorrect -- there can never be anything but in such a
message. Printing -1 instead of the MemDataPtr{0} in the source (or one of the
equivalents) when MemDataPtr{-1} is invalid is also incorrect and can be
misleading, especially when there is a -1 in the source code.
I happen to be working with the internal representation of member pointers and
how they're mangled and having to remember when to translate between -1 and 0
and when not makes things even more confusing than they already are.
In contrast to data member pointers, messages involving function member
pointers are clearer: 'int (A::* )() = ((int (A::*)())0)', although
a little too verbose, can't be mistaken for a -1. The part could
be left out here as well.
It should be possible to do better by tweaking cp/error.c.
$ cat z.C && gcc -S -Wall z.C
struct A;
typedef int A::*MemDataPtr;
typedef int (A::*MemFuncPtr)();
template void f (MemDataPtr) { }
template void g (MemFuncPtr) { }
void h ()
{
f(-1);
g(-1);
}
z.C: In function ‘void h()’:
z.C:11:20: error: cannot convert ‘int’ to ‘MemDataPtr’ {aka ‘int A::*’}
11 | f(-1);
|^~
||
|int
z.C:6:31: note: initializing argument 1 of ‘void f(MemDataPtr) [with int A::*
= -1; MemDataPtr = int A::*]’
6 | template void f (MemDataPtr) { }
| ^~
z.C:12:20: error: cannot convert ‘int’ to ‘MemFuncPtr’ {aka ‘int (A::*)()’}
12 | g(-1);
|^~
||
|int
z.C:7:31: note: initializing argument 1 of ‘void g(MemFuncPtr) [with int
(A::* )() = ((int (A::*)())0); MemFuncPtr = int (A::*)()]’
7 | template void g (MemFuncPtr) { }
| ^~
[Bug tree-optimization/39612] [8/9/10 Regression] LIM inserts loads from uninitialized local memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #34 from Jeffrey A. Law --- It looks like unrolling cleans this whole mess up and we don't get the uninitialized memory reads anymore.
[Bug tree-optimization/39612] [8/9 Regression] LIM inserts loads from uninitialized local memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612 Jeffrey A. Law changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |--- Summary|[8/9/10 Regression] LIM |[8/9 Regression] LIM |inserts loads from |inserts loads from |uninitialized local memory |uninitialized local memory --- Comment #35 from Jeffrey A. Law --- Whoops. Should have just moved the gcc-10 regression marker.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #12 from Steve Kargl ---
On Fri, Feb 21, 2020 at 08:40:22PM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> Ugh, this diff fixes constant-folding (without your mpc_sincos) patch.
>
> Index: gcc/fortran/simplify.c
> ===
> --- gcc/fortran/simplify.c (revision 280157)
> +++ gcc/fortran/simplify.c (working copy)
> @@ -7782,26 +7787,32 @@ gfc_simplify_sum (gfc_expr *array, gfc_expr *dim, gfc_
> gfc_expr *
> gfc_simplify_cotan (gfc_expr *x)
> {
> - gfc_expr *result;
> + gfc_expr *arg, *result;
>mpc_t swp, *val;
>
> - if (x->expr_type != EXPR_CONSTANT)
> + if (x->expr_type == EXPR_FUNCTION
> + && strcmp(x->value.function.isym->name, "cotan") == 0)
if (x->expr_type == EXPR_FUNCTION
&& (strcmp(x->value.function.isym->name, "cotan") == 0
|| strcmp(x->value.function.isym->name, "dcotan") == 0))
Something is broken. :(
