[Bug c++/92652] New: function call to lambda expression that return true does not satisfy the constraint in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92652
Bug ID: 92652
Summary: function call to lambda expression that return true
does not satisfy the constraint in requires-clause
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boostcpp at gmail dot com
Target Milestone: ---
Following code has unsatisfied constraint with error messages
prog.cc:15:25: error: could not convert 'true' from 'bool' to 'auto'
prog.cc: In lambda function:
prog.cc:15:25: error: invalid use of 'auto'
template < typename T >
requires ([]{return true ;}())
void h() { }
int main()
{
h() ; // unsatisfied constraint
}
if require-clause is like: requires(yes()), with the yes was defined like this.
constexpr auto yes(){ return true ; }
It satisfy the constraint.
As well as : requires( []()->bool{return true; }() )
but requires( []{return true;}() ) does not satisfy the constraint which I
believe it satisfy the constraint.
The entire code example.
https://wandbox.org/permlink/tlkVJFEp3LbSWqhf
[Bug tree-optimization/92649] dead store elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92649 prathamesh3492 at gcc dot gnu.org changed: What|Removed |Added CC||prathamesh3492 at gcc dot gnu.org --- Comment #1 from prathamesh3492 at gcc dot gnu.org --- This is likely dup of PR89332. Thanks, Prathamesh
[Bug target/92646] Compilation fails on armv7l with sys/cdefs.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92646 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-11-25 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- What distro is this? And what happens if you build not in the source directory?
[Bug target/92651] New: [10 Regression] Unnecessary stv transform in some x86 backend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92651
Bug ID: 92651
Summary: [10 Regression] Unnecessary stv transform in some x86
backend
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wwwhhhyyy333 at gmail dot com
CC: rguenther at suse dot de
Target Milestone: ---
For test case
#include
int foo(unsigned char a, unsigned char b)
{
int isum=abs(a - b);
return isum;
}
Using -O2 -march=corei7 GCC generates:
movzx edi, dil
movzx esi, sil
movdxmm1, edi
movdxmm0, esi
movdqa xmm3, xmm1
psubd xmm3, xmm0
psubd xmm0, xmm1
pmaxsd xmm0, xmm3
movdeax, xmm0
ret
while on -O2 -march=x86-64 it will be:
movzx eax, dil
movzx esi, sil
sub eax, esi
cdq
xor eax, edx
sub eax, edx
ret
On other case using -O2 -march=corei7 -mtune=generic:
movzx edi, dil
movzx esi, sil
mov eax, edi
sub eax, esi
sub esi, edi
cmp eax, esi
cmovl eax, esi
ret
This happens since r277481. (Refers to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154). In STV2 the transform was
executed since the sse_to_integer RTL cost for corei7 is 2, which made the
conversion worthwhile for some cmove instructions. I think it affects most IA
processors with such kind of cost.
The stv conversion results in about 7% regression on 525.x264_r. I wonder if
the conversion is designed on purpose to handle cmove, if not I think it is
better to adjust sse_to_integer RTL cost to avoid such issue. According to my
experiment, 6 would be a proper value.
[Bug c++/92650] internal compiler error: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92650
--- Comment #1 from Luke Dalessandro ---
x86-64 gcc (trunk) - cached
#1 with x86-64 gcc (trunk)
In file included from
/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/action/action.hpp:19,
from
/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/action.hpp:17,
from
/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/all.hpp:17,
from :1:
/opt/compiler-explorer/libs/rangesv3/trunk/include/meta/meta.hpp: In
substitution of 'template using if_c =
meta::_t, Args
...> > > [with bool If = std::integral_constant >::value; Args = {}]':
/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/utility/common_tuple.hpp:65:13:
required from 'struct ranges::detail::args_<1, const int&>'
/opt/compiler-explorer/libs/rangesv3/trunk/include/concepts/concepts.hpp:1107:13:
required from 'constexpr const bool
concepts::defs::constructible_from,
ranges::detail::args_<1, const int&> >'
/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/utility/common_tuple.hpp:136:9:
required by substitution of 'template
ranges::common_tuple::common_tuple(const std::tuple<_Tps ...>&,
std::enable_if_t<(constructible_from,
ranges::detail::args_ > &&
concepts::detail::CPP_true(concepts::detail::Nil{})), concepts::detail::Nil>)
[with Us = {int}]'
/opt/compiler-explorer/libs/rangesv3/trunk/include/concepts/type_traits.hpp:92:41:
required by substitution of 'template struct
concepts::detail::_builtin_common_2() : declval()))> > [with T = ranges::common_tuple; U =
std::tuple&]'
/opt/compiler-explorer/libs/rangesv3/trunk/include/concepts/type_traits.hpp:365:12:
recursively required by substitution of 'template struct
concepts::detail::_common_reference2::type>::value>::invoke > [with T
= ranges::common_tuple; U = std::tuple&]'
/opt/compiler-explorer/libs/rangesv3/trunk/include/concepts/type_traits.hpp:365:12:
required from 'struct concepts::common_reference,
std::tuple&>'
/opt/compiler-explorer/libs/rangesv3/trunk/include/concepts/type_traits.hpp:370:11:
required by substitution of 'template using common_reference_t
= typename concepts::common_reference::type [with Ts =
{ranges::common_tuple, std::tuple&}]'
/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/utility/common_type.hpp:58:11:
required by substitution of 'template using common_reference_t
= concepts::common_reference_t [with Ts =
{ranges::detail::if_then::apply > > >::cursor,
true>, ranges::common_tuple >, meta::id >::type&}]'
/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/iterator/basic_iterator.hpp:453:19:
required from 'struct
ranges::detail::iterator_associated_types_base_ > > >::cursor,
true>'
/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/iterator/basic_iterator.hpp:492:31:
required from 'struct
ranges::basic_iterator > > >::cursor >'
:17:16: required from here
/opt/compiler-explorer/libs/rangesv3/trunk/include/meta/meta.hpp:1222:11:
internal compiler error: canonical types differ for identical types
'std::integral_constant >' and
'std::integral_constant >'
1222 | using if_c = _t, Args...>>>;
| ^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/92650] New: internal compiler error: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92650
Bug ID: 92650
Summary: internal compiler error: canonical types differ for
identical types
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Created attachment 47349
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47349=edit
test case
Following code triggers ICE on (godbolt) trunk only. See
https://godbolt.org/z/q4CrvX.
It's hard for me to disambiguate from other reports with the same error
message, but it seems new.
#include
struct Wrapper {
int a[1];
constexpr operator int() const { return a[0]; }
};
int main() {
std::vector a;
auto all = ranges::views::all(a);
auto zip = ranges::views::zip(a);
Wrapper b;
*all.begin() = b;
*zip.begin() = b;
}
[Bug tree-optimization/92649] New: dead store elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92649
Bug ID: 92649
Summary: dead store elimination
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jiangning.liu at amperecomputing dot com
Target Milestone: ---
For this small case,
int f(void)
{
int i, a[1024];
for (i=0; i<1024; i++)
a[i] = 5;
return a[0];
}
"gcc -O3" can't figure out the memory stores from a[1] to a[1023] all can be
eliminated. The assembly code for aarch64 is as below.
moviv0.4s, 0x5
sub sp, sp, #4096
mov x0, sp
add x1, sp, 4096
.L2:
str q0, [x0], 16
cmp x0, x1
bne .L2
ldr w0, [sp]
add sp, sp, 4096
ret
[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100 --- Comment #10 from Jerry DeLisle --- Author: jvdelisle Date: Mon Nov 25 02:24:55 2019 New Revision: 278664 URL: https://gcc.gnu.org/viewcvs?rev=278664=gcc=rev Log: 2019-11-24 Jerry DeLisle PR fortran/92100 gfortran.dg/streamio_18.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/streamio_18.f90 Modified: trunk/gcc/ChangeLog
[Bug c++/92648] New: Handling of unknown attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92648
Bug ID: 92648
Summary: Handling of unknown attributes
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
It is still unclear how exactly OpenMP attributes will look like (at least most
of them), but it seems the C++ FE (unlike the C FE) attempts to parse the
arguments as expression list instead of skipping it.
Consider:
void
foo (int x, int y, int z, int u)
{
[[omp::for (linear(x, y: 2), private(z), reduction(+:u))]];
}
ud.C:4:26: error: expected ‘)’ before ‘:’ token
4 | [[omp::for (linear(x, y: 2), private(z), reduction(+:u))]];
| ~^
| )
ud.C:4:15: error: ‘linear’ was not declared in this scope
4 | [[omp::for (linear(x, y: 2), private(z), reduction(+:u))]];
| ^~
ud.C:4:32: error: expected primary-expression before ‘private’
4 | [[omp::for (linear(x, y: 2), private(z), reduction(+:u))]];
|^~~
ud.C:4:55: error: expected primary-expression before ‘:’ token
4 | [[omp::for (linear(x, y: 2), private(z), reduction(+:u))]];
| ^
ud.C:4:44: error: ‘reduction’ was not declared in this scope
4 | [[omp::for (linear(x, y: 2), private(z), reduction(+:u))]];
|^
ud.C:4:3: warning: attributes at the beginning of statement are ignored
[-Wattributes]
4 | [[omp::for (linear(x, y: 2), private(z), reduction(+:u))]];
| ^~
Compare that to C:
ud.C: In function ‘foo’:
ud.C:4:3: warning: ‘for’ attribute ignored [-Wattributes]
4 | [[omp::for (linear(x, y: 2), private(z), reduction(+:u))]];
| ^
or clang++:
ud.C:4:5: warning: unknown attribute 'for' ignored [-Wunknown-attributes]
[[omp::for (linear(x, y: 2), private(z), reduction(+:u))]];
^
1 warning generated.
I think the syntax just says that the arguments are balanced token sequences,
but if the compiler doesn't know the attribute, it can't assume anything
further.
[Bug target/92499] nios2 backend needs to consider allocated object size, not C object size for gprel optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92499 --- Comment #8 from sandra at gcc dot gnu.org --- Created attachment 47348 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47348=edit mips output for improved test case, -O2
[Bug target/92499] nios2 backend needs to consider allocated object size, not C object size for gprel optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92499 --- Comment #7 from sandra at gcc dot gnu.org --- Created attachment 47347 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47347=edit nios2 output for improved test case, -O2 -mgpopt=global
[Bug target/92499] nios2 backend needs to consider allocated object size, not C object size for gprel optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92499 --- Comment #6 from sandra at gcc dot gnu.org --- Created attachment 47346 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47346=edit improved test case with global/external cases as well as local
[Bug target/92499] nios2 backend needs to consider allocated object size, not C object size for gprel optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92499 --- Comment #5 from sandra at gcc dot gnu.org --- Richard Sandiford complained that my patch to not put objects containing flexible arrays in small data was an ABI change for references across compilation units, so I've been taking another look at this to see if I can find a different solution. The thing that triggered the link error reported in GLIBC is that the nios2 back end generates uses gp-relative addressing for a locally declared object of such a type, but was inconsistently placing the (zero-initialized) object in .bss instead of .sbss. I spent some time in the debugger on this one -- the problem is that get_variable_section returns lcomm_section in this instance, without checking whether the object is "small", or deferring to the backend to choose a section. Eventually in the nios2 back end the ASM_OUTPUT_ALIGNED_LOCAL hook looks at the size to decide whether to emit the local in .sbss or .bss, but the size it has at that point is the size of the initializer, not the declared size of the type. Local objects with nonzero initializers are placed in .sdata and objects with external linkage are also placed in .sdata/.sbss consistently with the use of gp-relative addressing. The MIPS back end has the same issue; it puts the zero-initialized local object in .comm, while the other cases end up in .sdata/.sbss. I also observed that the MIPS backend is emitting an incorrect .size directive (using the size of the non-flexible part of the object instead of the size of the initializer) for the cases it does put in .sdata/.sbss. I don't know if that is actually used by the assembler in a way that is harmful, though. So I think we could fix this without changing the ABI by fixing get_variable_section not to short-circuit the criteria the rest of the compiler uses to decide whether an object belongs in a small data section. That could optionally be combined with target-specific changes not to consider flexibly-sized objects with internal linkage not to be "small" for the purposes of either section placement or gp-relative addressing.
[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100 --- Comment #9 from Jerry DeLisle --- Author: jvdelisle Date: Sun Nov 24 22:14:59 2019 New Revision: 278660 URL: https://gcc.gnu.org/viewcvs?rev=278660=gcc=rev Log: 2019-11-24 Jerry DeLisle PR fortran/92100 io/transfer.c (data_transfer_init_worker): Use fbuf_reset instead of fbuf_flush before the seek. Note that fbuf_reset calls fbuf_flush and adjusts fbuf pointers. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c
[Bug bootstrap/92445] gcc bootstrap fails on Darwin 19.0.0 in stage 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92445 --- Comment #1 from Jürgen Reuter --- Did anybody look into this one here? At the moment, I cannot build gcc on MACOSX Catalina.
[Bug fortran/92586] ICE in gimplify_expr, at gimplify.c:13479 with nested allocatable derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586 --- Comment #2 from epagone --- I managed to produce a test case that does not require any external library (much easier to test). Please find it attached in my previous comment. I was able then to test it easily with all the versions of gfortran available on my machine. Here are the results. $ gfortran-9 bug_gimplify.f90 bug_gimplify.f90:34:0: 34 | data_get_foo_s = self%foo(ith)%get_s() | internal compiler error: in gimplify_expr, at gimplify.c:13479 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. $ gfortran-9 --version GNU Fortran (Ubuntu 9.2.1-17ubuntu1~18.04.1) 9.2.1 20191102 $ gfortran-8 bug_gimplify.f90 bug_gimplify.f90:34:0: data_get_foo_s = self%foo(ith)%get_s() internal compiler error: in gimplify_expr, at gimplify.c:12492 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. $ gfortran-8 --version GNU Fortran (Ubuntu 8.3.0-6ubuntu1~18.04.1) 8.3.0 $ gfortran-7 bug_gimplify.f90 bug_gimplify.f90:34:0: data_get_foo_s = self%foo(ith)%get_s() internal compiler error: in gimplify_expr, at gimplify.c:12247 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. $ gfortran-7 --version GNU Fortran (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
[Bug fortran/92586] ICE in gimplify_expr, at gimplify.c:13479 with nested allocatable derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586 epagone changed: What|Removed |Added Attachment #47303|0 |1 is obsolete|| --- Comment #1 from epagone --- Created attachment 47345 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47345=edit MWE without external library
[Bug libfortran/92569] [8/9 Regression] gfortran read with end directive does not trigger with -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569 Thomas Koenig changed: What|Removed |Added Target Milestone|10.0|8.4 Summary|[8/9/10 Regression] |[8/9 Regression] gfortran |gfortran read with end |read with end directive |directive does not trigger |does not trigger with |with -ffrontend-optimize|-ffrontend-optimize
[Bug libfortran/92569] [8/9/10 Regression] gfortran read with end directive does not trigger with -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569 --- Comment #10 from Thomas Koenig --- Author: tkoenig Date: Sun Nov 24 19:16:23 2019 New Revision: 278659 URL: https://gcc.gnu.org/viewcvs?rev=278659=gcc=rev Log: Fix EOF handling for arrays. 2019-11-23 Thomas Koenig Harald Anlauf PR fortran/92569 * io/transfer.c (transfer_array_inner): If position is at AFTER_ENDFILE in current unit, return from data loop. 2019-11-23 Thomas Koenig Harald Anlauf PR fortran/92569 * gfortran.dg/eof_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/eof_6.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c
[Bug tree-optimization/92229] Optimization makes it impossible to read overflow flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92229 Ariel Torti changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Ariel Torti --- (In reply to jos...@codesourcery.com from comment #4) > On Sat, 26 Oct 2019, arieltorti14 at gmail dot com wrote: > > You can write an asm to access a flag, it will just be whatever value the > flag has for whatever code the compiler found matched the language-level > semantics of your code, which may have nothing to do with your notion of > what the flag "should" be. > > Language semantics are only matched to processor features at ABI > boundaries, not within functions (and not across calls to inline / static > functions etc. either, because those aren't ABI boundaries; any good > language feature in this area also needs to work in the presence of > multiple functions, and of inlining and similar transformations, not just > where the arithmetic is in the same function as the code that cares about > whether it overflowed). Fair point, I can see why it would be very problematic, didn't really knew the full scope when I considered the issue.
[Bug fortran/92643] ISO_Fortran_binding_15.f90 failure on i586-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92643 --- Comment #5 from Steve Kargl --- On Sun, Nov 24, 2019 at 06:07:20PM +, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92643 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||jakub at gcc dot gnu.org > > --- Comment #4 from Jakub Jelinek --- > See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123#c5 ? > Yes, your comment #5 in that PR matches what I'm reporting. Do you want me to close this as a duplicate or set the "Depends on:" field?
[Bug fortran/92643] ISO_Fortran_binding_15.f90 failure on i586-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92643 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123#c5 ?
[Bug tree-optimization/92644] [9/10 Regression] ICE in wide_int_to_tree_1, at tree.c:1530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92644
--- Comment #2 from Jakub Jelinek ---
For pointers, it boils down whether say
void *
foo (void *p)
{
return p ? p : (void *) 1;
}
optimization into MAX_EXPR <1B, p> is valid or not. The original code doesn't
involve any non-equality comparisons, while MAX_EXPR is a non-equality
comparison which ought to be valid only as long as the two pointers are
pointing into the same object. Another possibility would be for pointers to do
this optimization, but perform the MIN_EXPR/MAX_EXPR in pointer sized ints
instead.
So, the fix can be either NULLPTR_TYPE specific, like:
--- gcc/tree-ssa-phiopt.c 2019-11-20 09:25:42.552157763 +0100
+++ gcc/tree-ssa-phiopt.c 2019-11-24 18:56:50.657172109 +0100
@@ -1381,7 +1381,8 @@ minmax_replacement (basic_block cond_bb,
/* Turn EQ/NE of extreme values to order comparisons. */
if ((cmp == NE_EXPR || cmp == EQ_EXPR)
- && TREE_CODE (rhs) == INTEGER_CST)
+ && TREE_CODE (rhs) == INTEGER_CST
+ && TREE_CODE (TREE_TYPE (rhs)) != NULLPTR_TYPE)
{
if (wi::eq_p (wi::to_wide (rhs), wi::min_value (TREE_TYPE (rhs
{
@@ -1407,7 +1408,8 @@ minmax_replacement (basic_block cond_bb,
larger = rhs;
/* If we have smaller < CST it is equivalent to smaller <= CST-1.
Likewise smaller <= CST is equivalent to smaller < CST+1. */
- if (TREE_CODE (larger) == INTEGER_CST)
+ if (TREE_CODE (larger) == INTEGER_CST
+ && TREE_CODE (TREE_TYPE (larger)) != NULLPTR_TYPE)
{
if (cmp == LT_EXPR)
{
@@ -1435,7 +1437,8 @@ minmax_replacement (basic_block cond_bb,
larger = gimple_cond_lhs (cond);
/* If we have larger > CST it is equivalent to larger >= CST+1.
Likewise larger >= CST is equivalent to larger > CST-1. */
- if (TREE_CODE (smaller) == INTEGER_CST)
+ if (TREE_CODE (smaller) == INTEGER_CST
+ && TREE_CODE (TREE_TYPE (larger)) != NULLPTR_TYPE)
{
wi::overflow_type overflow;
if (cmp == GT_EXPR)
or instead of it say && (INTEGRAL_TYPE_P (TREE_TYPE (rhs)) || POINTER_TYPE_P
(TREE_TYPE (rhs))), or just && INTEGRAL_TYPE_P (TREE_TYPE (rhs)), and if
allowing POINTER_TYPE_P, we can also special case
new_stmt = gimple_build_assign (result, minmax, arg0, arg1);
for pointers by casting to integers and back.
Thoughts?
[Bug fortran/91800] ICE in gfc_code2string(): Bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91800 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-24 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Thomas Koenig --- Maybe "bad code" isn't such a bad description of this... I wonder if people would complain if we just rejected a Hollerith constant here?
[Bug fortran/91783] [10 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2111
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91783 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-24 CC||tkoenig at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/92643] ISO_Fortran_binding_15.f90 failure on i586-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92643
--- Comment #3 from Steve Kargl ---
On Sun, Nov 24, 2019 at 03:59:41AM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92643
>
> --- Comment #1 from kargl at gcc dot gnu.org ---
> % gdb831 ./z
> (gdb) run
> Starting program: /usr/home/kargl/tmp/z
>
> Program received signal SIGSEGV, Segmentation fault.
> main () at ISO_Fortran_binding_15.c:29
> 29if (*(int *)dat.base_addr != 42)
>
>
> I think that there is a 32-bit vs 64-bit problem with pointers.
>
A little more debugging,
(gdb) b ISO_Fortran_binding_15.c:29
Breakpoint 1 at 0x804898d: file ISO_Fortran_binding_15.c, line 29.
(gdb) run ./z
Starting program: /usr/home/kargl/tmp/z ./z
Breakpoint 1, main () at ISO_Fortran_binding_15.c:29
29if (*(int *)dat.base_addr != 42)
(gdb) p dat
$1 = {base_addr = 0x0, elem_len = 4, version = 1, rank = 0 '\000',
attribute = 1 '\001', type = 1025, dim = {{lower_bound = -4200908,
extent = 677138155, sm = 1}}}
So, we find
typedef struct CFI_cdesc_t
{
void *base_addr;
size_t elem_len;
int version;
CFI_rank_t rank;
CFI_attribute_t attribute;
CFI_type_t type;
CFI_dim_t dim[];
}
CFI_cdesc_t;
Whoops that 'void *' is likely the problem. sizeof(void *)
on i586-*-freebsd is 4; while it is 8 on x86_64-*-amd64. I
suspect a missing a "fold_convert(pvoid_type_node,...)"
[Bug tree-optimization/92644] [9/10 Regression] ICE in wide_int_to_tree_1, at tree.c:1530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92644 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-24 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |9.3 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r265909. NULLPTR_TYPE only allows value 0, so doing rhs = wide_int_to_tree (TREE_TYPE (rhs), wi::min_value (TREE_TYPE (rhs)) + 1); for it ICEs. I'd say we should guard that only for INTEGRAL_TYPE_P types and perhaps pointer/reference types too, though transformation of == NULL to < (void *) 1 looks really weird.
[Bug modula2/92647] New: Internal enum may conflict with the time() function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92647
Bug ID: 92647
Summary: Internal enum may conflict with the time() function
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
Assignee: unassigned at gcc dot gnu.org
Reporter: pashev.igor at gmail dot com
Target Milestone: ---
Created attachment 47344
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47344=edit
Rename "time" to "tiempo"
In the `gm2/mc-boot/GRTint.c` file there is an enum `typedef enum {input,
output, time} VectorType;` which may conflict with the `time()` function that
could be brought in the scope by accident. It happened to me when building for
Dyson [1] since it not using GNU libc. I had to rename "time" to "tiempo" to
fix that :)
[1] https://www.osdyson.org
[Bug fortran/42118] Slow forall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42118 Thomas Koenig changed: What|Removed |Added Status|WAITING |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #11 from Thomas Koenig --- (In reply to Lionel GUEZ from comment #10) > (In reply to kargl from comment #9) > > Fortran 2018 has declared FORALL to be an obsolescent feature. > > I doubt that anyone will ever try to improve the performance > > of FORALL, because the next standard is likely to delete it. > > > > I think that this bug can be closed with WONTFIX or WORKSFORME. > > OK for me. We have had forall loop interchange for quite some time now, and that is all the effort that people are likely to put into this. So, closing as WONTFIX.
[Bug fortran/33097] Function decl trees without proper argument list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097 Thomas Koenig changed: What|Removed |Added Status|NEW |WAITING --- Comment #22 from Thomas Koenig --- I think this should be fixed now, because we now generate argument lists from actual arcuments if none are present. Can somebody confirm that this is the case? I don't speak TREE too well.
[Bug fortran/24878] subroutine getting called illegally as a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24878 Thomas Koenig changed: What|Removed |Added Last reconfirmed|2018-01-05 00:00:00 |2019-11-24 --- Comment #6 from Thomas Koenig --- Just taking a look at this again. There are two points where an error could be issued. First, INTEGER X, Y, SUBA EXTERNAL SUBA clashes with SUBROUTINE SUBA(X) so we could flag this going through the global list of symbols. Second, EXTERNAL SUBA CALL ANY (FNC, X, Y) INTEGER FNC should also clash with SUBROUTINE SUBA(X) but that is much harder, because we would then have to check for the argument that is passed to ANY.
[Bug target/92646] New: Compilation fails on armv7l with sys/cdefs.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92646 Bug ID: 92646 Summary: Compilation fails on armv7l with sys/cdefs.h: No such file or directory Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: samyavrillon at netcourrier dot com Target Milestone: --- I am using the source version of gcc 9.2.0 I tried to compile gcc on my OrangePi PC with ./configure --with-mpc=/home/bernard/building/mpc-1.1.0 --with-gmp=/home/bernard/building/gmp-6.1.2 --with-mpfr=/home/bernard/building/mpfr-4.0.2 I didn't gave any more options as I have no idea of what i should add The error happens during the make process Here is the error: /home/bernard/building/gcc-9.2.0/host-armv7l-unknown-linux-gnueabihf/gcc/xgcc -B/home/bernard/building/gcc-9.2.0/host-armv7l-unknown-linux-gnueabihf/gcc/ -B/usr/local/armv7l-unknown-linux-gnueabihf/bin/ -B/usr/local/armv7l-unknown-linux-gnueabihf/lib/ -isystem /usr/local/armv7l-unknown-linux-gnueabihf/include -isystem /usr/local/armv7l-unknown-linux-gnueabihf/sys-include -fno-checking -g -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -fno-inline -I. -I. -I../../host-armv7l-unknown-linux-gnueabihf/gcc -I../.././libgcc -I../.././libgcc/. -I../.././libgcc/../gcc -I../.././libgcc/../include -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../.././libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS In file included from /usr/include/stdio.h:27, from ../.././libgcc/../gcc/tsystem.h:87, from ../.././libgcc/libgcc2.c:27: /usr/include/features.h:364:12: fatal error: sys/cdefs.h: No such file or directory 364 | # include |^ compilation terminated. I have to install the latest gcc beccause i only have gcc6 installed on my computer and cannot compile recent g++ programs. Thanks in advance.
[Bug tree-optimization/92645] Hand written vector code is 450 times slower when compiled with GCC compared to Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645 --- Comment #4 from Jan Hubicka --- Created attachment 47343 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47343=edit GCC 10 output
[Bug tree-optimization/92645] Hand written vector code is 450 times slower when compiled with GCC compared to Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645 --- Comment #2 from Jan Hubicka --- Created attachment 47341 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47341=edit clang output with -O2 -mavx2 -mf16c -mfma
[Bug tree-optimization/92645] Hand written vector code is 450 times slower when compiled with GCC compared to Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645 --- Comment #3 from Jan Hubicka --- Created attachment 47342 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47342=edit GCC source
[Bug tree-optimization/92645] Hand written vector code is 450 times slower when compiled with GCC compared to Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645 --- Comment #1 from Jan Hubicka --- Created attachment 47340 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47340=edit Clang source
[Bug tree-optimization/92645] New: Hand written vector code is 450 times slower when compiled with GCC compared to Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645 Bug ID: 92645 Summary: Hand written vector code is 450 times slower when compiled with GCC compared to Clang Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- Hi, the attached are preprocessed files for Skia where Clang ifdefs was removed so we get roughly same file for GCC and Clang. The internal loop of _ZN3hsw16blit_row_color32EPjPKjij, _ZN3hsw16blit_row_color32EPjPKjij, _ZN3hsw16blit_row_color32EPjPKjij and _ZN3hsw16blit_row_color32EPjPKjij looks a lot worse when compiled by GCC then by clang. I also added flatten to eliminate the inlining difference. Clang has heuristics that makes functions with hand written vector code hot. GCC code packs via stack: 0.43 â mov %ax,0xae(%rsp) 0.03 â movzbl 0x78(%rsp),%eax 0.02 â mov %cx,0xd8(%rsp) 0.02 â mov %ax,0xb0(%rsp) 0.54 â vpextrb $0x9,%xmm5,%eax 0.16 â mov %ax,0xb2(%rsp) 0.51 â vpextrb $0xa,%xmm5,%eax 0.21 â mov %ax,0xb4(%rsp) 0.16 â vpextrb $0xb,%xmm5,%eax 0.46 â mov %ax,0xb6(%rsp) 0.24 â vpextrb $0xc,%xmm5,%eax 0.28 â mov %ax,0xb8(%rsp) 0.41 â vpextrb $0xd,%xmm5,%eax 0.20 â mov %ax,0xba(%rsp) 0.47 â vpextrb $0xe,%xmm5,%eax 0.92 â mov %ax,0xbc(%rsp) 0.72 â vpextrb $0xf,%xmm5,%eax 1.24 â mov %ax,0xbe(%rsp) 10.94 â vmovdqa 0xa0(%rsp),%ymm4 0.02 â mov %cx,0xda(%rsp) 0.00 â mov %cx,0xdc(%rsp) â mov %cx,0xde(%rsp) 10.34 â vpmullw 0xc0(%rsp),%ymm4,%ymm0 2.05 â vpaddw %ymm1,%ymm0,%ymm0 0.50 â vpaddw %ymm3,%ymm0,%ymm0 0.00 â mov %r9,0x58(%rsp) 0.52 â vpsrlw $0x8,%ymm0,%ymm0 0.39 â vpextrw $0x0,%xmm0,%eax 0.69 â mov %al,%r8b 0.17 â vpextrw $0x1,%xmm0,%eax 0.51 â mov %r8,0x50(%rsp) 6.87 â vmovdqa 0x50(%rsp),%xmm5 1.08 â vpinsrb $0x1,%eax,%xmm5,%xmm1 0.00 â vpextrw $0x2,%xmm0,%eax 0.73 â vpinsrb $0x2,%eax,%xmm1,%xmm1 0.02 â vpextrw $0x3,%xmm0,%eax 0.75 â vpinsrb $0x3,%eax,%xmm1,%xmm1 0.10 â vpextrw $0x4,%xmm0,%eax 0.98 â vpinsrb $0x4,%eax,%xmm1,%xmm1 0.16 â vpextrw $0x5,%xmm0,%eax 1.00 â vpinsrb $0x5,%eax,%xmm1,%xmm1 0.22 â vpextrw $0x6,%xmm0,%eax 1.10 â vpinsrb $0x6,%eax,%xmm1,%xmm1 0.30 â vpextrw $0x7,%xmm0,%eax 0.31 â vextracti128 $0x1,%ymm0,%xmm0 0.90 â vpinsrb $0x7,%eax,%xmm1,%xmm6 0.21 â vpextrw $0x0,%xmm0,%eax 0.35 â vmovaps %xmm6,0x50(%rsp) 1.15 â mov 0x58(%rsp),%r9 0.13 â mov 0x50(%rsp),%r8 0.29 â mov %al,%r9b 0.49 â mov %r8,0x50(%rsp) 0.07 â vpextrw $0x1,%xmm0,%eax 0.45 â mov %r9,0x58(%rsp) 7.08 â vmovdqa 0x50(%rsp),%xmm7 1.19 â vpinsrb $0x9,%eax,%xmm7,%xmm1 0.00 â vpextrw $0x2,%xmm0,%eax 0.78 â vpinsrb $0xa,%eax,%xmm1,%xmm1 0.00 â vpextrw $0x3,%xmm0,%eax 0.77 â vpinsrb $0xb,%eax,%xmm1,%xmm1 0.01 â vpextrw $0x4,%xmm0,%eax 0.86 â vpinsrb $0xc,%eax,%xmm1,%xmm1 0.03 â vpextrw $0x5,%xmm0,%eax 0.88 â vpinsrb $0xd,%eax,%xmm1,%xmm1 0.04 â vpextrw $0x6,%xmm0,%eax 0.97 â vpinsrb $0xe,%eax,%xmm1,%xmm1 0.08 â vpextrw $0x7,%xmm0,%eax 1.44 â vpinsrb $0xf,%eax,%xmm1,%xmm0 1.37 â vpextrd $0x1,%xmm0,%eax 0.13 â vinsertps$0xe,%xmm0,%xmm0,%xmm1 0.02 â vmovaps %xmm0,0x50(%rsp) 2.17 â vpinsrd $0x1,%eax,%xmm1,%xmm1 Clang code: Percentâ vpmullw %ymm0,%ymm2,%ymm2 â vpaddw %ymm1,%ymm2,%ymm2 â vpsrlw $0x8,%ymm2,%ymm2 â vextracti128 $0x1,%ymm2,%xmm3 â vpackuswb%xmm3,%xmm2,%xmm2 â vmovdqu %xmm2,(%rdi) â add $0x10,%rsi â add $0x10,%rdi â mov %r9d,%eax â cmp $0x4,%r9d â â jae 39179b0 â â jmp 3917a02 â mov %edx,%eax 0.29 â cmp $0x4,%r9d 0.00 â â jb 3917a02 0.07 â nop 3.95 â vpmovzxbw(%rsi),%ymm2 13.41 â vpmullw %ymm0,%ymm2,%ymm2 13.87
[Bug fortran/92643] ISO_Fortran_binding_15.f90 failure on i586-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92643 --- Comment #2 from Andreas Schwab --- It also fails on aarch64-*-linux, both ILP32 and LP64.
