[Bug c++/95809] New: GCC treats inline namespace declaration as "ambiguous"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95809
Bug ID: 95809
Summary: GCC treats inline namespace declaration as "ambiguous"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This code, bug.cc, GCC fails to compile it, while clang, icc, or msvc accepts
it well.
$cat bug.cc
namespace g_namespace {}
inline namespace {
namespace g_namespace {}
}
namespace g_namespace {}
$g++ -c bug.cc
bug.cc:5:12: error: ‘namespace g_namespace’ is ambiguous
5 | namespace g_namespace {}
|^~~
bug.cc:3:15: note: candidates are: ‘namespace ::g_namespace { }’
3 | namespace g_namespace {}
| ^~~
bug.cc:1:11: note: ‘namespace g_namespace { }’
1 | namespace g_namespace {}
| ^~~
My GCC version is
g++ (GCC) 11.0.0 20200605 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
When I remove the keyword "inline", GCC accepts it well. So, I guess GCC might
can not detect the inline namespace declaration and separate its inside
namespace from outside ones.
[Bug c++/95807] GCC accepts "void value not ignored as it ought to be" in function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95807
--- Comment #2 from Haoxin Tu ---
(In reply to Andrew Pinski from comment #1)
> I think it is rejected at instanition time.
Hi, Andrew. Shouldn't it be rejected at compiling time?
Please take a look at another case, test.cc
$cat test.cc
void foo1(int var = throw) {};
template
void foo2(int var = throw){ };
$g++ -c test.cc
test.cc:1:21: error: could not convert ‘’ from ‘void’ to
‘int’
1 | void foo1(int var = throw){ };
| ^
| |
| void
$clang++ -c test.c
test.cc:1:15: error: cannot initialize a parameter of type 'int' with an rvalue
of type 'void'
void foo1(int var = throw){ };
^ ~
test.cc:1:15: note: passing argument to parameter 'var' here
test.cc:3:15: error: cannot initialize a parameter of type 'int' with an rvalue
of type 'void'
void foo2(int var = throw){ };
^ ~
test.cc:3:15: note: passing argument to parameter 'var' here
2 errors generated.
Is this case similar with bug.cc?
I guess an "void" can't be a rvalue at any time.
[Bug c++/95807] GCC accepts "void value not ignored as it ought to be" in function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95807 --- Comment #1 from Andrew Pinski --- I think it is rejected at instanition time.
[Bug c++/95808] New: Can mismatch non-array new/delete with array new/delete during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95808
Bug ID: 95808
Summary: Can mismatch non-array new/delete with array
new/delete during constant evaluation
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/ZHiKmm.
```C++
constexpr void f()
{
delete[] new int;
delete new int[1];
}
constexpr int x{([]() consteval { f(); }(), 0)};
```
[Bug c++/95807] New: GCC accepts "void value not ignored as it ought to be" in function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95807
Bug ID: 95807
Summary: GCC accepts "void value not ignored as it ought to be"
in function template
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
GCC accepts "void value not ignored as it ought to be" in a function template
but rejects it in a normal function definition.
$cat bug.cc
void foo1() {int var = throw;};
template
void foo2() {int var = throw;};
$g++ -c bug.cc
bug.cc: In function ‘void foo()’:
bug.cc:1:23: error: void value not ignored as it ought to be
1 | void foo1() {int var = throw;};
| ^
Noted that GCC only rejects line 1 but accepts line 3.
In clang
$clang++ -c bug.cc
bug.cc:1:18: error: cannot initialize a variable of type 'int' with an rvalue
of type 'void'
void foo1() {int var = throw;};
^ ~
bug.cc:3:18: error: cannot initialize a variable of type 'int' with an rvalue
of type 'void'
void foo2(){ int var = throw;};
^ ~
2 errors generated.
My GCC version is
$g++ --version
g++ (GCC) 11.0.0 20200605 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/95806] New: Result of call with reference argument to newed object is cached during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95806
Bug ID: 95806
Summary: Result of call with reference argument to newed object
is cached during constant evaluation
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/zzM-Qn.
```C++
#include
constexpr bool is_zero(int& x) { return x == 0; }
constexpr void f()
{
int& x = *new int{0};
assert(is_zero(x));
x = 1;
assert(!is_zero(x));
delete &x;
}
constexpr int x{([]() consteval { f(); }(), 0)};
```
[Bug bootstrap/95805] [11 regression] gcc/recog.h:301:30: error: too many arguments to function call, expected 1, have 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95805 Gerald Pfeifer changed: What|Removed |Added Host||i386-unknown-freebsd11.3 --- Comment #1 from Gerald Pfeifer --- This is with clang 8.0.1 as bootstrap compiler.
[Bug bootstrap/95805] New: [11 regression] gcc/recog.h:301:30: error: too many arguments to function call, expected 1, have 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95805 Bug ID: 95805 Summary: [11 regression] gcc/recog.h:301:30: error: too many arguments to function call, expected 1, have 2 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: gerald at pfeifer dot com CC: rsandifo at sources dot redhat.com Target Milestone: --- Created attachment 48766 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48766&action=edit Relevant portion of the log file This started in the 24 hours leading up to 2020-06-18-16:40UTC. I am wondering whether this was triggered by commit 4e49b994de060d4a6c9318d0ed52ef038153426e Author: Richard Sandiford Date: Wed Jun 17 17:45:29 2020 +0100 recog: Tweak insn_gen_fn::operator() definition Fixes a “left operand of comma has no effect” warning that some were seeing. Also fixes a spurious ellipsis that Jonathan Wakely pointed out. 2020-06-17 Richard Sandiford gcc/ * coretypes.h (first_type): New alias template. * recog.h (insn_gen_fn::operator()): Use it instead of a decltype. Remove spurious “...” and split the function type out into a typedef
[Bug fortran/93635] Get ICE instead of error message if user incorrectly equivalences allocateable variables that are in a NAMELIST group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93635 --- Comment #5 from Ev Drikos --- (In reply to Ev Drikos from comment #3) > Created attachment 48765 [details] > Various Test Cases, including one for PR/93635 > > Hello S. Kargl, > > The attached patch contains various test cases for the PR's you mentioned at: > https://groups.google.com/d/msg/comp.lang.fortran/Xu73gGydAJk/X2YXyjndCAAJ > > You simply apply it to your local working tree (ignore whatever fails). > > patch -p0 < gcc48-tc93635-n.patch > > Just ensure that these test cases indeed make some sense; they need a review. > > Ev. Drikos Hello again, 1. The first test case in the patch file (elemental_optional_args_6.f90) likely doesn't apply smoothly but one has to change the test case (manually). 2. As I run the tests again I see that the test case coarray_3.f90 fails? due to PR/95613. So, I've removed: gcc/testsuite/gfortran.dg/pr95613.f90 Ev. Drikos PS: Hope you haven't committed these patch file yet!
[Bug c++/95505] [coroutines] ICE assert with get_return_object_on_allocation_failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95505 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Iain Sandoe --- fixed for master and 10.2.
[Bug c/95804] New: ice in generate_code_for_partition, at tree-loop-distribution.c:1323
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95804
Bug ID: 95804
Summary: ice in generate_code_for_partition, at
tree-loop-distribution.c:1323
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
This C source code:
int a, b, c, e;
int *d;
void f() {
int g;
int *h;
for (; b; b++) {
for (; c; c++)
;
e = *d || *h;
for (; a; a++)
h = g;
}
for (; e;)
;
}
on recent gcc trunk with compiler flag -O3 on x86_64, does this:
$ /home/dcb/gcc/results/bin/gcc -c -w -O3 bug624.c
during GIMPLE pass: ldist
bug624.c: In function ‘f’:
bug624.c:3:6: internal compiler error: in generate_code_for_partition, at
tree-loop-distribution.c:1323
3 | void f() {
| ^
0x85d652 generate_code_for_partition
../../trunk.git/gcc/tree-loop-distribution.c:1323
0x3343807 loop_distribution::distribute_loop(loop*, vec, control_dependences*, int*, bool*, bool)
../../trunk.git/gcc/tree-loop-distribution.c:3114
0x334a754 loop_distribution::execute(function*)
../../trunk.git/gcc/tree-loop-distribution.c:3303
0x334e075 execute
../../trunk.git/gcc/tree-loop-distribution.c:3391
[Bug c++/95505] [coroutines] ICE assert with get_return_object_on_allocation_failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95505 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:a59a15bcd27fa626b2b0912a1d7abd6df4f3d6cf commit r10-8334-ga59a15bcd27fa626b2b0912a1d7abd6df4f3d6cf Author: Iain Sandoe Date: Sun Jun 21 19:11:23 2020 +0100 coroutines: Update handling and failure for g-r-o-o-a-f [PR95505] The actual issue is that (in the testcase) std::nothrow is not available. So update the handling of the get-return-on-alloc-fail to include the possibility that std::nothrow might not be available. gcc/cp/ChangeLog: PR c++/95505 * coroutines.cc (morph_fn_to_coro): Update handling of get-return-object-on-allocation-fail and diagnose missing std::nothrow. gcc/testsuite/ChangeLog: PR c++/95505 * g++.dg/coroutines/pr95505.C: New test. (cherry picked from commit 445d8da5fbd10e32f8ea470bd9ac02faba8fd718)
[Bug fortran/93635] Get ICE instead of error message if user incorrectly equivalences allocateable variables that are in a NAMELIST group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93635 --- Comment #4 from Steve Kargl --- On Sun, Jun 21, 2020 at 05:44:51PM +, drikosev at gmail dot com wrote: > > The attached patch contains various test cases for the PR's you mentioned at: > https://groups.google.com/d/msg/comp.lang.fortran/Xu73gGydAJk/X2YXyjndCAAJ > > You simply apply it to your local working tree (ignore whatever fails). > > patch -p0 < gcc48-tc93635-n.patch > > Just ensure that these test cases indeed make some sense; they need a review. > Thanks. Now, what is needed is someone taking the next step to becoming a gfortran contributor in the sense that she/he can commit changes to source tree.
[Bug tree-optimization/95801] Optimiser does not exploit the fact that an integer divisor cannot be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95801 --- Comment #1 from Marc Glisse --- Except when dereferencing a pointer (?), gcc seldom uses an operation to derive properties on the operands, it mostly derives properties on the result. That's in large part because the information you are getting on the operands is only valid in some regions, not for the whole life of the SSA_NAME (in if(y!=0)x/y; the division obviously doesn't allow to remove the earlier test for y!=0) There could be many cases: x/y => y is not 0 i+1 => i is not INT_MAX x/[ex]4 => the last 2 bits of x are 0 ptr+n or *ptr => ptr is not a null pointer There is code in isolate-path to handle operands that are potentially 0, but I think that's only when we see x / PHI, not for a "normal" divisor. VRP works around the issue by creating extra SSA_NAMEs for the regions where we know more about a variable, but it only does it for branches like if(x<10), doing it for the operands of every operation would be too costly.
[Bug c++/95510] [coroutines] ICE with consteval operator co_await
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95510 Iain Sandoe changed: What|Removed |Added Status|NEW |WAITING --- Comment #2 from Iain Sandoe --- This was fixed by r11-1455-g14c831f5ef61 (but not sure if there's a plan to back-port to 10.2 yet).
[Bug fortran/50410] [8/9/10/11 Regression] ICE in record_reference, pointer variable in data statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 --- Comment #43 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #42) > The following patch does the magic (not regtested): > > diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c > index 8daa7bb8d06..0a995ec3ae7 100644 > --- a/gcc/fortran/expr.c > +++ b/gcc/fortran/expr.c > @@ -3087,6 +3087,9 @@ gfc_reduce_init_expr (gfc_expr *expr) > t = gfc_check_init_expr (expr); >gfc_init_expr_flag = false; > > + if (gfc_error_check()) > +return false; > + >if (!t || !expr) > return false; This produces lots of regressions. So this is apparently not the right place.
[Bug libstdc++/90436] Redundant size checking in vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90436 --- Comment #4 from Marc Glisse --- (side note not related to the redundant size checking) It is surprising how, in the code from comment 2, adding v.reserve(1000) does not help, it even slows the program down slightly here (yes, that's rather hard to believe). To reap the benefits, I also need to add in the loop: if(v.size()==v.capacity())__builtin_abort(); which enables the compiler to remove the reallocation code, and once that code is removed it can actually prove that size never reaches capacity and remove the call to abort! We don't even need __builtin_unreachable there. And once all that dead code is removed, it can finally vectorize.
[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661 --- Comment #6 from Dominique d'Humieres --- Not seen in https://gcc.gnu.org/pipermail/gcc-testresults/2020-June/564061.html
[Bug fortran/93635] Get ICE instead of error message if user incorrectly equivalences allocateable variables that are in a NAMELIST group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93635 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #3 from Ev Drikos --- Created attachment 48765 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48765&action=edit Various Test Cases, including one for PR/93635 Hello S. Kargl, The attached patch contains various test cases for the PR's you mentioned at: https://groups.google.com/d/msg/comp.lang.fortran/Xu73gGydAJk/X2YXyjndCAAJ You simply apply it to your local working tree (ignore whatever fails). patch -p0 < gcc48-tc93635-n.patch Just ensure that these test cases indeed make some sense; they need a review. Ev. Drikos
[Bug pch/56549] #pragma once ineffective with BOM in include file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56549 xaizek at posteo dot net changed: What|Removed |Added CC||xaizek at posteo dot net --- Comment #5 from xaizek at posteo dot net --- The bug is still present on current master of GCC 11 (8ee2640bfdc62f835ec9740278f948034bc7d9f1).
[Bug c++/88601] We may consider adding __builtin_convertvector and __builtin_shufflevector for better compatibility with Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88601 Shawn Landden changed: What|Removed |Added CC||shawn at git dot icu --- Comment #5 from Shawn Landden --- We don't care if both are hacks. What we care about is an end to egregious compiler incompatibilities.
[Bug fortran/50410] [8/9/10/11 Regression] ICE in record_reference, pointer variable in data statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 --- Comment #42 from anlauf at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #41) > In my working tree I had the following patch This still ICEs on comment#23 z1. Slightly rewriting that case, one gets a reasonable error message: program p type ta integer :: a end type ta type t type(ta), pointer :: b end type t type(t) :: u = t(ta(1)) end pr50410_23x.f90:8:19: 8 | type(t) :: u = t(ta(1)) | 1 Error: The element in the structure constructor at (1), for pointer component 'b' should be a POINTER or a TARGET Digging further, one sees that the error is generated for z1 but not emitted. The following patch does the magic (not regtested): diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c index 8daa7bb8d06..0a995ec3ae7 100644 --- a/gcc/fortran/expr.c +++ b/gcc/fortran/expr.c @@ -3087,6 +3087,9 @@ gfc_reduce_init_expr (gfc_expr *expr) t = gfc_check_init_expr (expr); gfc_init_expr_flag = false; + if (gfc_error_check()) +return false; + if (!t || !expr) return false;
[Bug target/95802] Duplicated logic in host_detect_local_cpu and get_builtin_code_for_version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95802 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from H.J. Lu --- They are different.
[Bug libstdc++/90436] Redundant size checking in vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90436
--- Comment #3 from Marc Glisse ---
// possibly assumes that ptrdiff_t and size_t have the same size
size_type
_M_check_len_one(const char* __str) const
{
ptrdiff_t __n = sizeof(_Tp);
ptrdiff_t __ms = max_size(); __ms *= sizeof(_Tp);
ptrdiff_t __s = size(); __s *= sizeof(_Tp);
if (__s > (__ms - __n))
__throw_length_error(__N(__str));
const ptrdiff_t __len = __s + (std::max)(__s, __n);
if (__len <= 0) __builtin_unreachable();
ptrdiff_t __ret = (std::min)(__len, __ms);
return (_Tp*)__ret-(_Tp*)0; // hack to generate divexact, so it
simplifies with * sizeof(_Tp)
}
generates nicer code. But after those experiments, it seems clear that the
performance of this code is irrelevant (not surprising since it is followed by
a call to operator new), and its effect on global performance is random.
Possibly it causes something to get aligned differently, which can randomly get
this 25% speed-up, but can just as randomly go back to the slow version.
Anyway, I don't think I'll be submitting any patch for this.
[Bug target/95798] Initialization code --- suboptimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95798 --- Comment #1 from zero at smallinteger dot com --- (note that changing the array declaration to be initialized does not result in the individual array writes being optimized away, as one might expect at first glance)
[Bug tree-optimization/95803] New: Failure to optimize strlen in certain situations properly, instead leading to weird code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95803
Bug ID: 95803
Summary: Failure to optimize strlen in certain situations
properly, instead leading to weird code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
bool f(int i)
{
if (i < 4)
i = 4;
const char *s = &"abc"[i];
return strlen(s) > 3;
}
This can be optimized to a simple `return true` or `return false` (considering
UB is invoked here). LLVM does this transformation, but GCC does not. Obviously
this code is pretty weird and may not be very realistic itself, but this
optimization would probably be effective for other code, and currently it
results in rather weird code generation :
f(int):
mov ecx, 4
cmp edi, 4
mov eax, 3
mov edx, ecx
cmovge edx, edi
movsx rdx, edx
sub rax, rdx
cmp rdx, 3
mov edx, 0
cmova rax, rdx
cmp rax, 3
seta al
ret
accompanied by very weird final tree optimized code :
;; Function f (_Z1fi, funcdef_no=287, decl_uid=9588, cgraph_uid=216,
symbol_order=215)
f (int i)
{
const char * s;
long unsigned int _1;
int _3;
bool _6;
sizetype _7;
[local count: 1073741824]:
# DEBUG BEGIN_STMT
_3 = MAX_EXPR ;
# DEBUG i => _3
# DEBUG BEGIN_STMT
_7 = (sizetype) _3;
s_4 = "abc" + _7;
# DEBUG s => s_4
# DEBUG BEGIN_STMT
_1 = __builtin_strlen (s_4);
_6 = _1 > 3;
return _6;
}
Whereas this code :
bool f(int i)
{
if (i < 4)
i = 4;
return strlen(&"abc"[i]) > 3;
}
Optimizes to this :
;; Function f (_Z1fi, funcdef_no=287, decl_uid=9588, cgraph_uid=216,
symbol_order=215)
f (int i)
{
[local count: 1073741824]:
# DEBUG BEGIN_STMT
# DEBUG i => NULL
# DEBUG BEGIN_STMT
return 0;
}
[Bug target/95737] PPC: Unnecessary extsw after negative less than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
CC||segher at gcc dot gnu.org
Target|powerpc-*-*-* |powerpc64*-*-*
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2020-06-21
--- Comment #5 from Segher Boessenkool ---
In gimple this already is
negativeLessThan (long long unsigned int a, long long unsigned int b)
{
_Bool _1;
int _2;
int _3;
long long unsigned int _6;
_1 = a_4(D) < b_5(D);
_2 = (int) _1;
_3 = -_2;
_6 = (long long unsigned int) _3;
return _6;
}
Then, it is expanded as a sign_extend:DI of a subreg:SI, and nowhere
does it see this isn't necessary (it isn't because that SI cannot be
negative).
The RTL code isn't optimised very well before combine, and that does
Trying 11 -> 12:
11: {r128:SI=ca:SI-0x1;clobber ca:SI;}
REG_UNUSED ca:SI
12: r123:DI=sign_extend(r128:SI)
REG_DEAD r128:SI
Failed to match this instruction:
(set (reg:DI 123)
(sign_extend:DI (plus:SI (reg:SI 98 ca [+4 ])
(const_int -1 [0x]
(note everything is made SImode in insn 11 before, it absorbed the
subreg). Combine cannot keep track of known zero bits of hard regs
well, so it fails to see that XER[CA] is only ever 0 or 1 here (it
always is, but it doesn't know that either).
I'll try to add an extra pattern for this extend, that will do the
trick I think.
[Bug target/95737] PPC: Unnecessary extsw after negative less than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737
--- Comment #4 from wschmidt at linux dot ibm.com ---
On 6/19/20 12:43 PM, jens.seifert at de dot ibm.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737
>
> Jens Seifert changed:
>
> What|Removed |Added
>
> Status|RESOLVED|UNCONFIRMED
> Resolution|DUPLICATE |---
>
> --- Comment #3 from Jens Seifert ---
> This is different as the extsw also happens if the result gets used e.g.
> followed by a andc, which is my case. I obviously oversimplified the sample.
> It
> has nothing to do with function result and ABI requirements. gcc assume that
> the result of -(a < b) implemented by subfc, subfe is signed 32-bit. But the
> result is already 64-bit.
>
> unsigned long long branchlesconditional(unsigned long long a, unsigned long
> long b, unsigned long long c)
> {
> unsigned long long mask = -(a < b);
> return c &~ mask;
> }
>
> results in
>
> _Z20branchlesconditionalyyy:
> .LFB1:
> .cfi_startproc
> subfc 4,4,3
> subfe 3,3,3
> not 3,3
> extsw 3,3
> and 3,3,5
> blr
>
> expected
> subfc
> subfe
> andc
>
Thanks for verifying, Jens!
[Bug fortran/50410] [8/9/10/11 Regression] ICE in record_reference, pointer variable in data statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410
--- Comment #41 from Dominique d'Humieres ---
In my working tree I had the following patch
--- /opt/gcc/_clean-svn//gcc/fortran/trans-expr.c 2020-01-05
11:44:35.0 +0100
+++ /opt/gcc/work-cvs/gcc/fortran/trans-expr.c 2020-01-05 11:45:38.0
+0100
@@ -8366,7 +8366,7 @@ gfc_trans_structure_assign (tree dest, g
gfc_init_se (&se, NULL);
for (c = gfc_constructor_first (expr->value.constructor);
- c; c = gfc_constructor_next (c), cm = cm->next)
+ c && cm; c = gfc_constructor_next (c), cm = cm->next)
{
/* Skip absent members in default initializers. */
if (!c->expr && !cm->attr.allocatable)
@@ -8447,6 +8447,7 @@ gfc_trans_structure_assign (tree dest, g
expr->ts.u.derived, init);
gfc_add_expr_to_block (&block, tmp);
}
+ gcc_assert (!c);
return gfc_finish_block (&block);
}
@@ -8519,7 +8520,7 @@ gfc_conv_structure (gfc_se * se, gfc_exp
cm = expr->ts.u.derived->components;
for (c = gfc_constructor_first (expr->value.constructor);
- c; c = gfc_constructor_next (c), cm = cm->next)
+ c && cm; c = gfc_constructor_next (c), cm = cm->next)
{
/* Skip absent members in default initializers and allocatable
components. Although the latter have a default initializer
@@ -8564,6 +8565,11 @@ gfc_conv_structure (gfc_se * se, gfc_exp
CONSTRUCTOR_APPEND_ELT (v, cm->backend_decl, val);
}
}
+ /* gcc_assert (!c); */
+ if (c)
+/* gfc_error ("Invalid DATA statement at %C.");
+gfc_error ("Invalid DATA statement at %L.", &expr->where); */
+gfc_error ("Invalid DATA statement at %L.", &gfc_current_locus);
se->expr = build_constructor (type, v);
if (init)
I have never seen the first assert triggering and I never found a way to emit a
better error message.
[Bug target/95802] New: Duplicated login in host_detect_local_cpu and get_builtin_code_for_version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95802 Bug ID: 95802 Summary: Duplicated login in host_detect_local_cpu and get_builtin_code_for_version Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: crazylht at gmail dot com Target Milestone: --- Both host_detect_local_cpu and get_builtin_code_for_version have similar logic to deduce the target processor from processor family and available ISAs. They should be merged into one common logic.
[Bug c++/95711] namespace alias fails inside coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95711 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Last reconfirmed|2020-06-17 00:00:00 |2020-06-21 Ever confirmed|0 |1 Target Milestone|--- |10.2 --- Comment #2 from Iain Sandoe --- thanks for the report.
[Bug c++/95736] coroutine method improperly copies awaitable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95736 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |10.2 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-06-21 --- Comment #2 from Iain Sandoe --- thanks for the report.
[Bug tree-optimization/95801] New: Optimiser does not exploit the fact that an integer divisor cannot be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95801
Bug ID: 95801
Summary: Optimiser does not exploit the fact that an integer
divisor cannot be zero
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: felix.von.s at posteo dot de
Target Milestone: ---
int always1(int a, int b) {
if (a / b)
return b != 0;
return 1;
}
The function above should be possible to optimise to a constant 1, as integer
division by zero is undefined. I’m surprised this isn’t caught already; it
seems like very low-hanging fruit.
In case someone wants to claim there is no value to be gained from this, this
is where it came up:
#define SIGNUM(value) ({ \
__auto_type _value = (value); \
(__typeof__(_value)) ((_value > 0) - (_value < 0)); \
})
#define DIV_FLOOR(a, b) ({ \
__auto_type _a = (a); \
__auto_type _b = (b); \
(_a / _b) - ((SIGNUM(_a) != SIGNUM(_b) ? _a % _b : 0) != 0); \
})
For unsigned types, DIV_FLOOR(a, b) should compile to the same code as
truncating division (a / b), but unless a statement to the effect of (b == 0 ?
__builtin_unreachable() : (void) 0); is inserted before the division, DIV_FLOOR
will generate considerably longer code, at least on x86.
[Bug c/95800] DJGPP 9.3.1 doesn't parse C files correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95800 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jakub Jelinek --- Perhaps you aren't including that header in some source, or whatever else. Doesn't look like GCC bug.
[Bug c/95800] DJGPP 9.3.1 doesn't parse C files correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95800
--- Comment #2 from Teo Samarzija ---
(In reply to Jakub Jelinek from comment #1)
> Perhaps log2 is in DJGPP a macro (which the C standard allows)?
> In that case, you either need to #undef that macro, or
> use double (log2)(double x) { ... }
I am sorry, apparently it is defined as a macro. I don't know why I am getting
linker errors telling me "log2" is undefined.
[Bug c/95800] DJGPP 9.3.1 doesn't parse C files correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95800
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Perhaps log2 is in DJGPP a macro (which the C standard allows)?
In that case, you either need to #undef that macro, or
use double (log2)(double x) { ... }
[Bug c/95800] New: DJGPP 9.3.1 doesn't parse C files correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95800
Bug ID: 95800
Summary: DJGPP 9.3.1 doesn't parse C files correctly
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: teo.samarzija at gmail dot com
Target Milestone: ---
So, the C library I am using to cross-compile programs from Linux to DOS
apparently doesn't support the "log2" function, and I tried to polyfill it:
#include
double log2(double x)
{
return log(x)/log(2);
}
int main() {
return 0;
}
However, when I do that, I get the following error, and the linking doesn't
even begin:
test.c:3:8: error: expected ')' before '/' token
3 | double log2(double x)
|^~~~
Here is what "djgpp-gcc -v" prints:
Using built-in specs.
COLLECT_GCC=djgpp-gcc
COLLECT_LTO_WRAPPER=/home/teo.samarzija/djgpp-9.3.0/libexec/gcc/djgpp/9.3.0/lto-wrapper
Target: djgpp
Configured with: ../gcc-9.3.0/configure --target=djgpp
--prefix=/home/teo.samarzija/djgpp-9.3.0
--enable-languages=c,c++,objc,ada,fortran,go
Thread model: single
gcc version 9.3.0 (GCC)
[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661 --- Comment #5 from Manfred Schwarb --- This might have been solved by https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=ac932bfcd21e9523fa2b880ae8138aef79da7f54 , at least I don't see it anymore in today's build. As the crash of class_61.f90 is a bit difficult to reproduce, additional confirmation might be needed.
[Bug fortran/95687] ICE in get_unique_hashed_string, at fortran/class.c:508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95687 Manfred Schwarb changed: What|Removed |Added CC||manfred99 at gmx dot ch --- Comment #6 from Manfred Schwarb --- This might have solved PR89661, at least I don't see it anymore in today's build. As the crash of class_61.f90 is a bit difficult to reproduce, additional confirmation might be needed.
[Bug tree-optimization/95799] New: Assumed conjunctions are not broken down into clauses if their pureness is checked first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95799 Bug ID: 95799 Summary: Assumed conjunctions are not broken down into clauses if their pureness is checked first Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: felix.von.s at posteo dot de Target Milestone: --- In the attached sample, foo is compiled into returning a constant 1, while bar will compare a to 0, even though bar’s assumption implies foo’s. If I replace __builtin_pure_p() testing with a constant 1, both functions compile to the same assembly code, returning a constant 1. If I change bar to return (a >= 0 && b >= 0), it also compiles to returning a constant 1. It seems as if the optimiser becomes unaware that conjunction elimination is a valid rule of inference if the conjunction’s pureness is checked first.
[Bug c++/95789] [10/11 Regression] Const method is allowed to return non-const reference on template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95789
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |10.2
CC||jakub at gcc dot gnu.org
Summary|Const method is allowed to |[10/11 Regression] Const
|return non-const reference |method is allowed to return
|on template class |non-const reference on
||template class
Keywords||accepts-invalid
Last reconfirmed||2020-06-21
Status|UNCONFIRMED |NEW
Known to fail||10.1.0, 11.0
Ever confirmed|0 |1
Known to work||9.3.0
--- Comment #1 from Jonathan Wakely ---
struct B {
int n;
};
template
struct A {
B& get() const { return f; }
B f;
};
int main() {
A a;
a.f = {};
a.get().n = 10;
if (a.f.n != 0)
__builtin_abort();
}
Started with r10-7094
c++: Readd [LR]ROTATE_EXPR support to constexpr.c [PR94067]
Since r10-6527-gaaa26bf496a646778ac861aed124d960b5bf549f fold_for_warn
will perform maybe_constant_value even on some cp_fold produced trees and
so can include rotate exprs which were removed last fall from constexpr.c
2020-03-09 Jakub Jelinek
PR c++/94067
Revert
2019-10-11 Paolo Carlini
* constexpr.c (cxx_eval_constant_expression): Do not handle
RROTATE_EXPR and LROTATE_EXPR.
* g++.dg/warn/Wconversion-pr94067.C: New test.
[Bug c++/95797] Can std::allocator.deallocate newed pointer during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95797 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Last reconfirmed||2020-06-21 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- This should be rejected.
[Bug analyzer/95042] ICE in can_merge_p, at analyzer/region-model.cc:2053
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95042 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #2 from Dávid Bolvanský --- compilation of zstd fails with this error too
[Bug target/95798] New: Initialization code --- suboptimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95798 Bug ID: 95798 Summary: Initialization code --- suboptimal Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zero at smallinteger dot com Target Milestone: --- Created attachment 48764 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48764&action=edit sample code This is similar to (but not the same as) bug 87223 for structs. Further, this bug expands on this issue for gcc 10.x. Originally, this was noted in gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0, compiling with -O3. First, note the initialization code that trivially sets values to zero in an array, mov eax, edi sub rsp, 8080 xor edx, edx and eax, 127 mov QWORD PTR [rsp-120+rax*8], 0 mov QWORD PTR [rsp-112+rax*8], 0 mov QWORD PTR [rsp-104+rax*8], 0 mov QWORD PTR [rsp-96+rax*8], 0 mov QWORD PTR [rsp-88+rax*8], 0 mov QWORD PTR [rsp-80+rax*8], 0 mov QWORD PTR [rsp-72+rax*8], 0 mov QWORD PTR [rsp-64+rax*8], 0 xor eax, eax would be better by first setting a register to zero, then writing the value of the register. Further, note that there is already a zero register available (edx), but it is not used. This is similar to 87223 for structs, and here the issue manifests for arrays. Second, using gcc 10 versions and -O3 at godbolt.org results in this code: mov eax, edi mov edx, edi sub rsp, 8072 and eax, 127 and edx, 127 mov QWORD PTR [rsp-120+rdx*8], 0 lea edx, [rax+1] movsx rdx, edx mov QWORD PTR [rsp-120+rdx*8], 0 lea edx, [rax+2] movsx rdx, edx mov QWORD PTR [rsp-120+rdx*8], 0 lea edx, [rax+3] movsx rdx, edx mov QWORD PTR [rsp-120+rdx*8], 0 lea edx, [rax+4] movsx rdx, edx mov QWORD PTR [rsp-120+rdx*8], 0 lea edx, [rax+5] movsx rdx, edx mov QWORD PTR [rsp-120+rdx*8], 0 lea edx, [rax+6] add eax, 7 movsx rdx, edx cdqe mov QWORD PTR [rsp-120+rdx*8], 0 xor edx, edx mov QWORD PTR [rsp-120+rax*8], 0 xor eax, eax This is much, much more verbose than in gcc 9.3, for no apparent gain.
