[Bug rtl-optimization/108461] '-fcompare-debug' failure (length) w/ -mcpu=e500mc -O2 -ftrapv -fno-expensive-optimizations -fno-guess-branch-probability -fno-tree-dce -fno-tree-dse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108461 --- Comment #1 from Arseny Solokha --- Created attachment 54304 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54304&action=edit gkd diff w/ -m64 Compiling w/ -m64 instead of -m32 yields the attached gkd diff. This PR can be actually a duplicate of PR108061.
[Bug rtl-optimization/108461] New: '-fcompare-debug' failure (length) w/ -mcpu=e500mc -O2 -ftrapv -fno-expensive-optimizations -fno-guess-branch-probability -fno-tree-dce -fno-tree-dse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108461
Bug ID: 108461
Summary: '-fcompare-debug' failure (length) w/ -mcpu=e500mc -O2
-ftrapv -fno-expensive-optimizations
-fno-guess-branch-probability -fno-tree-dce
-fno-tree-dse
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: compare-debug-failure
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-e300c3-linux-gnu
Created attachment 54303
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54303&action=edit
gkd diff w/ -m32
gcc 13.0.0 20230115 snapshot (g:05cd79c2420d3fe6d84bad694d9808982112b0f0) fails
-fcompare-debug check when compiling the following testcase w/ -mcpu=e500mc -O2
-fcompare-debug -ftrapv -fno-expensive-optimizations
-fno-guess-branch-probability -fno-tree-dce -fno-tree-dse:
char m;
void
bar (int y)
{
int a = 1;
a = 0x3e10 < y + a + 0x3e00;
}
void
foo (char x)
{
for (x = 0; x < 3; ++x)
{
if (m)
bar (m);
m = x;
}
}
% powerpc-e300c3-linux-gnu-gcc-13 -m32 -mcpu=e500mc -O2 -fcompare-debug -ftrapv
-fno-expensive-optimizations -fno-guess-branch-probability -fno-tree-dce
-fno-tree-dse -c oxbijmxo.c
powerpc-e300c3-linux-gnu-gcc-13: error: oxbijmxo.c: '-fcompare-debug' failure
(length)
gkd diff attached.
[Bug fortran/108453] [10/11/12/13 Regression] ICE in gfc_trans_use_stmts, at fortran/trans-decl.cc:5361
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108453 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.5 Priority|P3 |P4
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0 CC||aoliva at gcc dot gnu.org
[Bug fortran/108450] [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108450 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.3 Priority|P3 |P4
[Bug tree-optimization/108449] [13 Regression] ICE in eliminate_unnecessary_stmts, at tree-ssa-dce.cc:1512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108449 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/108449] [13 Regression] ICE in eliminate_unnecessary_stmts, at tree-ssa-dce.cc:1512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108449
--- Comment #2 from Richard Biener ---
OK, so early we still have vfork() 'static' and maybe_special_function_p
returns false. But then check_global_declaration () comes along and does
/* Warn about any function declared static but not defined. We don't
warn about variables, because many programs have static variables
that exist only to get some text into the object file. */
if (TREE_CODE (decl) == FUNCTION_DECL
&& DECL_INITIAL (decl) == 0
&& DECL_EXTERNAL (decl)
&& ! DECL_ARTIFICIAL (decl)
&& ! TREE_PUBLIC (decl))
{
if (warning_suppressed_p (decl, OPT_Wunused))
;
else if (snode->referred_to_p (/*include_self=*/false))
pedwarn (input_location, 0, "%q+F used but never defined", decl);
else
warning (OPT_Wunused_function, "%q+F declared % but never "
"defined", decl);
/* This symbol is effectively an "extern" declaration now. */
TREE_PUBLIC (decl) = 1;
which will result in maybe_special_function_p to return true.
I suppose leaving the decl static might have an effect on the linker errors
emitted for targets that require special asm ops for undefined external
references, but then you should still get an error here.
This mangling dates back to RMS at r0-3845-g7d429c41c5953f
[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #43 from rguenther at suse dot de ---
On Thu, 19 Jan 2023, xry111 at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
>
> --- Comment #42 from Xi Ruoyao ---
> (In reply to Richard Biener from comment #41)
> > We could fix the testcase with
> >
> > diff --git a/gcc/testsuite/gcc.dg/pr95115.c b/gcc/testsuite/gcc.dg/pr95115.c
> > index 69c4f83250c..09273e445d2 100644
> > --- a/gcc/testsuite/gcc.dg/pr95115.c
> > +++ b/gcc/testsuite/gcc.dg/pr95115.c
> > @@ -17,6 +17,7 @@ int
> > main (void)
> > {
> >double r = x ();
> > + volatile double rr = r;
> >if (!__builtin_isnan (r))
> > abort ();
> >if (!fetestexcept (FE_INVALID))
> >
> > that preserves optimizing the isnan check but also preserves the computation
> > and checks the non-propagation of a NaN.
>
> Hmm, so it means we cannot rely on Inf / Inf to raise an exception? Then we
> need to fix Glibc...
If the result is unused then no, GCC will happily elide exceptions from
unused computations like Inexact from the statement
1./3.;
but this has been done before. What's new is that GCC can now elide
some uses (in this case the isnan check is the only use)
[Bug c++/96887] Excessive error output with member initializer list and array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96887 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Known to work||12.1.0 --- Comment #1 from Andrew Pinski --- Looks to be fixed in GCC 12.
[Bug c++/96419] Constant propoagation works on global variable, but not in a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96419 Andrew Pinski changed: What|Removed |Added URL|https://gcc.godbolt.org/z/c | |7E3P9 | Keywords||missed-optimization Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- clang is not able to do it either.
[Bug c++/95871] Duplicated error message : "the value is not usable in a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95871 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-01-19 --- Comment #1 from Andrew Pinski --- Confirmed. What is interesting is that the duplicated message is not there for -std=c++98 .
[Bug c++/95010] Recursive function template with function parameter of type decltype([]{}) is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95010 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-01-19 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/70178] Loop-invariant memory loads from std::string innards are not hoisted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70178 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/108448] GCC Elides Assignment to Pointer and memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #7 from Andrew Pinski ---
I do notice some aliasing violations with y_map_index and
y_strucon_handleErrorHelper
y_vec* stack;
...
y_map_existsStringKey_v(d->contexts, ("com.yzena.yc.error_handler"),
&stack))
...
y_map_existsStringKey_v takes a void* and passes it to:
ret = (y_map_index(m, &str,
# 896 "yc/src/container/map.c" 3 4
((void *)0)
# 896 "yc/src/container/map.c"
, val_ptr) != ((y_usize) -1));
While y_map_index's last argument is y_uchar** and you do the store as y_uchar*
inside y_map_index:
*val_ptr = ((m)->map[(arrayIdx)] + (itemIdx) * (m->esize));
-- CUT -
I suspect cmake didn't add -fno-strict-aliasing really.
Can you try:
*(void**)val_ptr = ((m)->map[(arrayIdx)] + (itemIdx) * (m->esize));
Note GCC extends aliasing here where "void*" is treated similarly as a
character type with respect to aliasing.
[Bug middle-end/108448] GCC Elides Assignment to Pointer and memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448 --- Comment #6 from Gavin Howard --- Created attachment 54302 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54302&action=edit An Amalgamation to Reproduce I have managed to make an amalgamation that reproduces the bug. When you unzip the attachment, you should get `amal.c`. Run the following: ``` $ gcc -std=c11 -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -D_GNU_SOURCE -DYC_BUILTIN_128=1 -DYC_ENABLE_STACKTRACES=1 -O2 -g -o amal amal.c $ ./amal amal.c temp.txt temp 1 ``` You should get an assert failure as follows: ``` Assert Failed: pointer is NULL Expected: (stack != ((void *)0)) Source:yc/src/concurrency/strucon.c:439 Function: y_strucon_handleErrorHelper() Aborted ``` This file was produced from a source file with the `strgen` main, a function it needed, and a bunch of `#include` of C files that were needed. The original was `amalgamation.c`, and I ran the following command on it: ``` $ gcc -Iyc/include -std=c11 -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -D_GNU_SOURCE -DYC_BUILTIN_128=1 -E amalgamation.c > amal.c ``` (It was created in the directory above the repo directory.) This created the `amal.c` file that I have attached. The line 63558 has the pointer assignment. The next line has the memcpy() commented out. Either one is elided. You can comment out 63558 and uncomment the next to test. If you add ASan and UBSan, like so: ``` $ gcc -std=c11 -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -D_GNU_SOURCE -DYC_BUILTIN_128=1 -DYC_ENABLE_STACKTRACES=1 -O2 -g -o amal amal.c ``` they report nothing. In fact, they then make the program work. (The "Encountered end-of-file" is a bug in the original that didn't suppress EOF as an error; just ignore it because it's not really an error.) If you run Valgrind on the non-ASan/UBSan build, like so: ``` $ valgrind --error-exitcode=100 --leak-check=full --show-leak-kinds=all --errors-for-leak-kinds=all --num-callers=500 --child-silent-after-fork=yes ./amal amal.c temp.txt temp 1 ``` It also reports nothing until the abort.
[Bug c++/108460] -Wmissing-braces with ctad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108460 --- Comment #1 from tim blechmann --- possibly related to 95330?
[Bug c++/108460] New: -Wmissing-braces with ctad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108460
Bug ID: 108460
Summary: -Wmissing-braces with ctad
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tim at klingt dot org
Target Milestone: ---
consider this snippet, that uses class template argument deduction for arrays
```
#include
std::array a {"a", "b", "c"}; // ctad, but emits -Wmissing-braces
std::array b {{"a", "b", "c"}}; // does not build
```
this makes me wonder if `-Wmissing-braces` should fire in case `a`?
[Bug c++/55768] Use of unknown __attribute__ in function definition is flagged with an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55768
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WORKSFORME
--- Comment #1 from Andrew Pinski ---
GCC 4.1.2, GCC 4.4.7, GCC 4.5.3, GCC 4.6.4, and GCC 4.7.1-4.7.4 all reject
unknown attributes in this location.
So there was no change as far as I can tell.
This is the testcase I used:
```
int foo(int x, int y) __attribute__((sdfsdf45))
{
return x * y;
}
```
[Bug c++/53528] Support C++11 generalized attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53528 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug c++/83932] No diagnostic issued for missing default argument in lambda-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83932
--- Comment #2 from Andrew Pinski ---
We do handle the default argument in other places correctly that is we reject:
struct g
{
int operator()(int i = 1, int j){return 0;}
};
[Bug c++/84373] g++ incorrectly resolves names for default parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84373 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html > > > Confirmed. I should note that paper clearifies this to the tea now: A parameter shall not appear as a potentially-evaluated expression in a default argument. Also note that paper is considered a defect fix for at least C++20.
[Bug c++/84373] g++ incorrectly resolves names for default parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84373 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-01-19 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html Confirmed.
[Bug middle-end/82325] worse code generated compared to clang when using a constexpr array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82325 Andrew Pinski changed: What|Removed |Added Component|c++ |middle-end --- Comment #3 from Andrew Pinski --- Note clang 15+ no longer unrolls the loop and even produces really bad code for the loop now: .LBB0_7:# in Loop: Header=BB0_1 Depth=1 addq$2, %rdx .LBB0_1:# =>This Inner Loop Header: Depth=1 movzwl -4(%rax,%rdx,4), %esi cmpl%edi, %esi jg .LBB0_3 # %bb.2:# in Loop: Header=BB0_1 Depth=1 movzbl -2(%rax,%rdx,4), %ecx movl$1, %r8d shll%cl, %r8d addl%esi, %r8d cmpl%edi, %r8d jg .LBB0_8 .LBB0_3:# in Loop: Header=BB0_1 Depth=1 cmpq$29, %rdx je .LBB0_4 # %bb.5:# in Loop: Header=BB0_1 Depth=1 movzwl (%rax,%rdx,4), %esi cmpl%edi, %esi jg .LBB0_7 # %bb.6:# in Loop: Header=BB0_1 Depth=1 movzbl 2(%rax,%rdx,4), %ecx movl$1, %r8d shll%cl, %r8d addl%esi, %r8d cmpl%edi, %r8d jle .LBB0_7
[Bug debug/106746] [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks since r13-2041-g6624ad73064de241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746 --- Comment #20 from Alexandre Oliva --- The bug is now either fixed or latent in the trunk, I'm not sure which, because I have not got as far as figuring out why removing unnecessary address cselib lookups in debug insns made a difference to memory overlap checks between nondebug insns. So I'm not sure whether to close this PR or leave it open. Thoughts?
[Bug c++/78040] Missed mangled names of class methods in the translation unit dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78040 Andrew Pinski changed: What|Removed |Added Target Milestone|8.0 |---
[Bug c++/78040] Missed mangled names of class methods in the translation unit dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78040 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Andrew Pinski --- testFunc was not mangled before either. None of the mangled names are ever in the raw form. Also these options are now explictly listed in the "GCC Developer Options" section too (which was done in r6-6358-gb0b662cc5653ad even when this was reported): https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Developer-Options.html#index-fdump-lang
[Bug debug/106746] [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks since r13-2041-g6624ad73064de241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746 --- Comment #19 from CVS Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:3c99493bf39a7fef9213e6f5af94b78bb15fcfdc commit r13-5252-g3c99493bf39a7fef9213e6f5af94b78bb15fcfdc Author: Alexandre Oliva Date: Thu Jan 19 01:09:15 2023 -0300 [PR106746] drop cselib addr lookup in debug insn mem The testcase used to get scheduled differently depending on the presence of debug insns with MEMs. It's not clear to me why those MEMs affected scheduling, but the cselib pre-canonicalization of the MEM address is not used at all when analyzing debug insns, so the memory allocation and lookup are pure waste. Somehow, avoiding that waste fixes the problem, or makes it go latent. for gcc/ChangeLog PR debug/106746 * sched-deps.cc (sched_analyze_2): Skip cselib address lookup within debug insns. for gcc/testsuite/ChangeLog PR debug/106746 * gcc.target/i386/pr106746.c: New.
[Bug c++/78040] Missed mangled names of class methods in the translation unit dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78040 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.0 --- Comment #3 from Andrew Pinski --- The option was changed in GCC 8 by r8-834-g58aca9d95cbd05 to -fdump-lang-raw .
[Bug c++/102213] virtual consteval is not being stored in the vtable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102213
Andrew Pinski changed:
What|Removed |Added
Summary|Incorrect executable|virtual consteval is not
|produced from valid input |being stored in the vtable
|code with virtual consteval |
--- Comment #3 from Andrew Pinski ---
Reduced further to show the issue is not related to operator <=> or operator
==:
```
struct A {
virtual consteval bool f(const A &) const { return true; };
};
struct B : A {
virtual consteval bool f(const A&) const noexcept override { return false;
}
};
int main() {
static constexpr B b;
static constexpr const A & a = b;
static_assert (a.f(a) == 0);
if (a.f(a) != 0)
__builtin_abort();
return 0;
}
```
[Bug c++/106485] Can't use heap pointer in `static_assert`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106485
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Andrew Pinski ---
Oh wait there comment #0 is still invalid (undefined?) code:
```
struct I {
int* i = new int{1};
constexpr ~I() { delete i; }
};
static_assert([] ()consteval { return I{}.i != 0; }());
```
Works just fine.
So yes this again is the same issue of static_assert not being immediate
function context.
[Bug c++/108458] Incorrect detection of constexpr heap usage in non-constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108458 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Invalid as explained in comment #1. I do find it odd that clang and MSVC does not implement the full details of consteval but GCC does; it is though.
[Bug c++/106485] Can't use heap pointer in `static_assert`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106485
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-01-19
--- Comment #3 from Andrew Pinski ---
I think comment #0 is a different issue from comment #2 really.
comment #0 has a temporary while comment #2 has an consteval.
Also GCC accepts this just fine though:
#include
static_assert(!std::string{"abcdegf"}.empty());
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 104512, which changed state. Bug 104512 Summary: [c++20] consteval constructor does not need to initialize all data members https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104512 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug c++/104512] [c++20] consteval constructor does not need to initialize all data members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104512 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > constexpr works but consteval does not. > > Also I notice ICC rejects the consteval version but accepts the constexpr > one. This gives the hint that both MSVC and clang are incorrect really. EDG also implements correctly static_assert not being an immediate function context. So closing as invalid.
[Bug libquadmath/94756] strtoflt128 assigns some subnormals incorrectly on MS Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756 --- Comment #11 from niXman --- Created attachment 54301 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54301&action=edit patch (In reply to niXman from comment #9) > although I think these two bugs have the same cause... right, it was the same bug and this bug was caused by 32-bit variable overflow. the overflow was fixed for i686-mingw-w64, x86_64-mingw-w64, and for i686 and x86_64 linux. Jakiub, John, could you look please on attached patch?
[Bug c++/95968] error: 'args#0' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95968
Andrew Pinski changed:
What|Removed |Added
Keywords|rejects-valid |
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> The following is the reduced testcase:
> struct test_class
> {
> consteval test_class( double pack_) { }
> };
>
> void test_func()
> {
> auto t = [](const auto... args) {return test_class(args...);};
> t(1.0);
> }
>
> are lambdas consteval by default? I know they are implicit constexpr but I
> don't think they are consteval though.
They are not until C++23 (See PR 107687 for the status on that).
This is just a diagnostic issue. add constevalue like this to the reduced
testcase allows the testcase to work:
auto t = [](const auto... args) consteval {return test_class(args...);};
Note the original testcase still has issues even if you add consteval to the
lambda and I suspect because std::apply still has issues ...
[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #42 from Xi Ruoyao ---
(In reply to Richard Biener from comment #41)
> We could fix the testcase with
>
> diff --git a/gcc/testsuite/gcc.dg/pr95115.c b/gcc/testsuite/gcc.dg/pr95115.c
> index 69c4f83250c..09273e445d2 100644
> --- a/gcc/testsuite/gcc.dg/pr95115.c
> +++ b/gcc/testsuite/gcc.dg/pr95115.c
> @@ -17,6 +17,7 @@ int
> main (void)
> {
>double r = x ();
> + volatile double rr = r;
>if (!__builtin_isnan (r))
> abort ();
>if (!fetestexcept (FE_INVALID))
>
> that preserves optimizing the isnan check but also preserves the computation
> and checks the non-propagation of a NaN.
Hmm, so it means we cannot rely on Inf / Inf to raise an exception? Then we
need to fix Glibc...
[Bug fortran/108369] FM509 Fails to compile with error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #15 from Jerry DeLisle --- Do we close this bug as invalid or do we need to adjustsomething?
[Bug c++/108458] Incorrect detection of constexpr heap usage in non-constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108458
--- Comment #2 from Andrew Pinski ---
Note GCC does implement consteval which allows for:
static_assert([]() { if consteval { return std::vector{1, 2} ==
get_val(std::vector>{
{1, 2}, {3, 4}}); } }());
static_assert([]() { if consteval { return std::vector{1, 2} ==
get_val(consteval_get_data()); }}());
static_assert([]() { if consteval { return std::vector{1, 2} ==
get_val(constexpr_get_data()); }}());
But does not implement (yet) P2564 where you don't need the if consteval part
either for C++23 (see PR 107687 for the status there).
[Bug c++/108458] Incorrect detection of constexpr heap usage in non-constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108458
--- Comment #1 from Andrew Pinski ---
These all work too:
static_assert([]()consteval {return std::vector{1, 2} ==
get_val(std::vector>{
{1, 2}, {3, 4}}); }());
static_assert([]()consteval {return std::vector{1, 2} ==
get_val(consteval_get_data()); }());
static_assert([]()consteval {return std::vector{1, 2} ==
get_val(constexpr_get_data()); }());
So I think GCC is correct because static_assert is NOT an immediate function
context .
[Bug c++/104512] [c++20] consteval constructor does not need to initialize all data members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104512 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > static_assert is an immediate function context static_assert is NOT an immediate function context sorry for the typo.
[Bug c++/104512] [c++20] consteval constructor does not need to initialize all data members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104512
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
||m-project/issues/57627,
||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=106485
--- Comment #2 from Andrew Pinski ---
```
struct B {
bool b = true;
int i;
consteval B() {}
};
static_assert( []() consteval{ return B{}.b; }() );
```
Works for GCC. I think this is a bug in clang ...
static_assert is an immediate function context so B{} needs to be a evaluated
and such.
See https://github.com/llvm/llvm-project/issues/57627 for the clang bug.
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106485#c2 .
[Bug libgcc/108279] Improved speed for float128 routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #23 from Michael_S ---
(In reply to Jakub Jelinek from comment #19)
> So, if stmxcsr/vstmxcsr is too slow, perhaps we should change x86
> sfp-machine.h
> #define FP_INIT_ROUNDMODE \
> do { \
> __asm__ __volatile__ ("%vstmxcsr\t%0" : "=m" (_fcw)); \
> } while (0)
> #endif
> to do that only if not round-to-nearest.
> E.g. the fast-float library uses since last November:
> static volatile float fmin = __FLT_MIN__;
> float fmini = fmin; // we copy it so that it gets loaded at most once.
> return (fmini + 1.0f == 1.0f - fmini);
> as a quick test whether round-to-nearest is in effect or some other rounding
> mode.
> Most likely if this is done with -frounding-math it wouldn't even need the
> volatile stuff. Of course, if it isn't round-to-nearest, we would need to
> do the expensive {,v}stmxcsr.
I agree with Wilco. This trick is problematic due to effect on inexact flag.
Also, I don't quite understand how you got to setting rounding mode.
I don't need to set rounding mode, I just need to read a current rounding mode.
Doing it in portable way, i.e. by fegetround(), is slow mostly due to various
overheads.
Doing it in non-portable way on x86-64 (by _MM_GET_ROUNDING_MODE()) is not slow
on Intel, but still pretty slow on AMD Zen3, although even on Zen3 it is much
faster than fegetround().
Results of measurements are here:
https://github.com/already5chosen/extfloat/blob/master/binary128/reports/rm-impact.txt
Anyway, I'd very much prefer a portable solution over multitude of ifdefs.
It is a pity that gcc doesn't implement FLT_ROUNDS like other compilers.
But, then again, it is a pity that gcc doesn't implement few other things
implemented by other compilers that could make life of developers of portable
multiprecision routines in general and of soft float in particular so much
easier.
[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566 --- Comment #37 from H.J. Lu --- It is if ((__atomic_fetch_xor_4 ((volatile void *) a, (unsigned int) (1 << bit), 0) & (unsigned int) (1 << bit)) != 0) vs if ((__atomic_fetch_xor_4 ((volatile void *) a, 1 << bit, 0) >> bit & 1) != 0) Why does GCC generate the second one?
[Bug libgcc/108279] Improved speed for float128 routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279 --- Comment #22 from Michael_S --- (In reply to Michael_S from comment #8) > (In reply to Thomas Koenig from comment #6) > > And there will have to be a decision about 32-bit targets. > > > > IMHO, 32-bit targets should be left in their current state. > People that use them probably do not care deeply about performance. > Technically, I can implement 32-bit targets in the same sources, by means of > few ifdefs and macros, but resulting source code will look much uglier than > how it looks today. Still, not to the same level of horror that you have in > matmul_r16.c, but certainly uglier than how I like it to look. > And I am not sure at all that my implementation of 32-bit targets would be > significantly faster than current soft float. I explored this path (implementing 32-bit and 64-bit targets from the same source with few ifdefs) a little more: Now I am even more sure that it is not a way to go. gcc compiler does not generate good 32-bit code for this style of sources. This especially applies to i386, other supported 32-bit targets (RV32, SPARC32) are affected less. In the process I encountered a funny illogical pessimization by i386 code generator: https://godbolt.org/z/En6Tredox Routines foo32() and foo64() are semantically identical, but foo32() is written with 32-bit targets in mind while foo64() is the style of could that will likely be written if one wants to support 32 and 64 bits from the same source with #ifdef. The code, generated by gcc for foo32() is reasonable. Like in the source, we can see 8 multiplications. The code, generated by gcc for foo64() is anything but reasonable. Somehow, compiler invented 5 more multiplications for a total of 13 multiplications. May be, it deserves a separate bug report.
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #7 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #5)
> I'm surprised by rr_union_table content.
> // VREL_VARYING
> { VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING,
> VREL_VARYING, VREL_VARYING, VREL_VARYING },
> is obviously correct, sure, but:
> // VREL_UNDEFINED
> { VREL_VARYING, VREL_LT, VREL_LE, VREL_GT, VREL_GE, VREL_UNDEFINED,
> VREL_EQ, VREL_NE },
> is strange, VREL_VARYING union VREL_UNDEFINED be VREL_LT?
> I would have expected
> { VREL_VARYING, VREL_UNDEFINED, VREL_LT, VREL_LE, VREL_GT, VREL_GE,
> VREL_EQ, VREL_NE },
> instead.
> I fear other entries are weird too (though rr_intersect_table entries look
> reasonable from quick skimming).
> That said, fixing that will not fix this issue.
hmm. I looks like the table from
commit ade5531c9dde98c7be005a5c5382739d734797aa
Author: Andrew MacLeod
Date: Thu May 12 12:00:39 2022 -0400
Move VREL values to their own enumerated type.
didn't get committed as intended. It seems like the UNDEFINED entry is the only
one affected tho which is why it has not had much impact. UNDEFINED got moved
from a different point in the enum list to be the second one in that patch,
adnit looks like that line missed the move from 5 to 2... The others seem fine
at a glance. I will look closer tomorrow.
[Bug fortran/107424] [13 Regression] ICE in gfc_trans_omp_do, at fortran/trans-openmp.cc:5397 - and wrong code - with non-rectangular loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107424 Tobias Burnus changed: What|Removed |Added Attachment #54265|0 |1 is obsolete|| --- Comment #9 from Tobias Burnus --- Created attachment 54300 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54300&action=edit Patch handling some nonrect loops + sorry for others, but being blocked by PR108459 Next attempt for a patch, which handles non-rectangular loops except when a 'count' variable is introduced. For that case, see comment 6 and comment 8. In principle, it is ready for submission, except that now the testcase gcc/testsuite/gfortran.dg/gomp/canonical-loop-1.f90 fails with an ICE (segfault). That seems to be a related but independent issue, also affecting C/C++; now filed as PR middle-end/108459. While independent, it blocks this patch.
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447 --- Comment #6 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #4) > I see fold_using_range::relation_fold_and_or > which sees relation1 VREL_LE and relation2 VREL_GE and !is_and, and because > of > relation_union (relation1, relation2) == VREL_VARYING fold it to 1. > But for floating point comparisons, LE | GE is not always true, it is true if > neither operand is NAN, otherwise false. right.. we're sorting out whether these relations should be created or not, and if so, how to then verify the result of a union/intersection before committing to it. That validate_relation routine was created for a reason that we are trying to track down why we arent using it, and if this is an appropriate use, or if we need something else.
[Bug middle-end/108459] New: [OpenMP] ICE during GIMPLE pass: ompexp (segfault) in expand_omp_for_init_counts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108459
Bug ID: 108459
Summary: [OpenMP] ICE during GIMPLE pass: ompexp (segfault) in
expand_omp_for_init_counts
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
The following innocent looking code gives an ICE. As probably visible from the
look of the code, it was found via Fortran code, related to patch work for
PR fortran/107424.
This affects all versions down to GCC 11, which is the first one to support
non-rectangular loop nests.
Compiling the C test below with '-fopenmp' gives:
during GIMPLE pass: ompexp
ff.c: In function ‘s1’:
ff.c:12:13: internal compiler error: Segmentation fault
12 | #pragma omp for collapse(2)
| ^~~
0xef701f crash_signal
../../repos/gcc-trunk-commit/gcc/toplev.cc:314
0x7f9f608ce51f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xbc5560 is_gimple_val(tree_node*)
../../repos/gcc-trunk-commit/gcc/gimple-expr.cc:837
0xc368f3 force_gimple_operand_1(tree_node*, gimple**, bool (*)(tree_node*),
tree_node*)
../../repos/gcc-trunk-commit/gcc/gimplify-me.cc:55
0xc36b0f force_gimple_operand_gsi_1(gimple_stmt_iterator*, tree_node*, bool
(*)(tree_node*), tree_node*, bool, gsi_iterator_update)
../../repos/gcc-trunk-commit/gcc/gimplify-me.cc:115
0xc36b0f force_gimple_operand_gsi(gimple_stmt_iterator*, tree_node*, bool,
tree_node*, bool, gsi_iterator_update)
../../repos/gcc-trunk-commit/gcc/gimplify-me.cc:141
0x1de8b5e expand_omp_for_init_counts
../../repos/gcc-trunk-commit/gcc/omp-expand.cc:2011
void s1 (int *a1, int *a2)
{
int i;
int j;
{
int D4266;
int D4267;
D4266 = -*a1;
D4267 = *a2;
#pragma omp for collapse(2)
for (i = 1; i <= 16; i = i + 1)
for (j = i * D4266 + D4267; j <= 16; j = j + 1)
{
}
}
}
[Bug c/108424] ICE in perform_integral_promotions with nullptr case and switch on int type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108424 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Marek Polacek --- Fixed.
[Bug c/108424] ICE in perform_integral_promotions with nullptr case and switch on int type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108424 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:0f85ae6591c92b161693073c0931c7ca1d5d0c5a commit r13-5249-g0f85ae6591c92b161693073c0931c7ca1d5d0c5a Author: Marek Polacek Date: Wed Jan 18 14:51:59 2023 -0500 c: ICE with nullptr as case expression [PR108424] In this ICE-on-invalid, we crash on gcc_assert (INTEGRAL_TYPE_P (type)); in perform_integral_promotions, because a nullptr is an INTEGER_CST, but not INTEGRAL_TYPE_P, and check_case_value is only checking the former. In the test I'm testing other "shall be an integral constant expression" contexts as well. PR c/108424 gcc/c-family/ChangeLog: * c-common.cc (check_case_value): Check INTEGRAL_TYPE_P. gcc/testsuite/ChangeLog: * gcc.dg/c2x-nullptr-6.c: New test.
[Bug analyzer/108455] -Wanalyzer-deref-before-check false positive seen in git pack-revindex.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108455 David Malcolm changed: What|Removed |Added Last reconfirmed||2023-01-18 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #2 from David Malcolm --- I'm testing a patch for this.
[Bug middle-end/105469] [10/11/12/13 Regression] "execution reached an unreachable program point" with -flto since r5-7027-g0b986c6ac777aa4e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105469 --- Comment #18 from Jan Hubicka --- It should just make any bug to go latent. It surprises me it makes any difference given that things not cloned by ipa-cp should be all handled by ipa-sra.
[Bug c++/108458] New: Incorrect detection of constexpr heap usage in non-constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108458
Bug ID: 108458
Summary: Incorrect detection of constexpr heap usage in
non-constexpr context
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ajscimone at live dot com
Target Milestone: ---
I am currently seeing errors around compile time context evaluation of various
C++ structures. This happens on both gcc trunk and gcc 12.2 on the C++20 and
C++23 standards. The following code should give a thorough example:
#include
[[nodiscard]] constexpr std::vector> constexpr_get_data() {
return std::vector>{{1, 2}, {3, 4}};
}
[[nodiscard]] consteval std::vector> consteval_get_data() {
return std::vector>{{1, 2}, {3, 4}};
}
[[nodiscard]] constexpr auto get_val(
const std::vector> list_of_lists) {
return list_of_lists.data()[0];
}
static_assert(std::vector{1, 2} == get_val(std::vector>{
{1, 2}, {3, 4}})); // Failing
static_assert(std::vector{1, 2} ==
get_val(consteval_get_data())); // Failing
static_assert(std::vector{1, 2} ==
get_val(constexpr_get_data())); // Working
For Reference: https://godbolt.org/z/bxjThY5WE
For each of these failed structures, gcc errors that these are non-constant
expressions. The compiler seems to believe that there are heap allocated values
that are escaping compile time. This is clearly not the case, as all execution
is happening in the context of a `static_assert()`. This code behaves as
expected in a compile time context on both the clang and circle compilers. This
also does not happen with a non-nested vector. The following example with a
consteval function allocating a vector at compile time compiles and passes:
#include
[[nodiscard]] constexpr auto get_val(const std::vector list) {
return list.data()[0];
}
static_assert(1 == get_val(std::vector{1, 2})); //Working
[Bug fortran/108434] [12/13 Regression] ICE in class_allocatable, at fortran/expr.cc:5000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108434 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-January/058778.html
[Bug tree-optimization/108457] [13 Regression] tree-ssa-loop-niter.cc:2255:23: warning: variable 'mode' set but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108457 --- Comment #2 from dave.anglin at bell dot net --- On 2023-01-18 4:07 p.m., pinskia at gcc dot gnu.org wrote: > Basically C[TL]Z_DEFINED_VALUE_AT_ZERO macro does not always use its arguments > so they don't get marked as used ... Yes. PA uses the default defines for these macros.
[Bug target/107844] error: argument is not a field access for __builtin_preserve_field_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107844 --- Comment #5 from David Faust --- (In reply to Andrew Pinski from comment #4) > (In reply to David Faust from comment #3) > > Thanks for the info Andrew. I'll look at __builtin_offsetof. > > > > As for the implementation in clang, I can point to some bits relevant to > > the builtin itself: > > llvm-project/clang/lib/CodeGen/CGBuiltin.cpp > > CodeGenFunction::EmitBPFBuiltinExpr () > > > > llvm-project/llvm/lib/Target/BPF/BPFAbstractMemberAccess.cpp > > BPFAbstractMemberAccess::GetFieldInfo () > > > > But I am less familiar with the surrounding machinery such as their > > parsing and type systems.. > > So I looked (First off I am shocked they don't have target functions to > handle the builtins and every target builtin is handled in that file seems > wrong), and you are handed the AST before folding. This is different from > GCC where it is you are handed it after folding. Aha! I had never realized this difference until now. Thanks for pointing that out! > > So I think we need some special handling in the c (and C++) parser to handle > this. I suspect we want to do the full handling of the builtin > (bpf_core_field_exists) in the parser rather than the macro expanded view of > it too. Similar to how offsetof is handled ... > Of course this will need some modifications to the bpf headers too. And that > solves some other issues too. Yes, I see. I'll have to study the parser a little since I have not touched it before, but the approach makes sense. I wonder if it would be feasible and/or worthwhile to add some sort of TARGET_PARSE_BUILTIN hook to enable this sort of handling for any other targets which may want it..? Maybe that can wait. In any case, thank you very much for the suggestions.
[Bug tree-optimization/108457] [13 Regression] tree-ssa-loop-niter.cc:2255:23: warning: variable 'mode' set but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108457 Andrew Pinski changed: What|Removed |Added Summary|tree-ssa-loop-niter.cc:2255 |[13 Regression] |:23: warning: variable |tree-ssa-loop-niter.cc:2255 |'mode' set but not used |:23: warning: variable ||'mode' set but not used Component|bootstrap |tree-optimization Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||build Target Milestone|--- |13.0 Last reconfirmed||2023-01-18 --- Comment #1 from Andrew Pinski --- Basically C[TL]Z_DEFINED_VALUE_AT_ZERO macro does not always use its arguments so they don't get marked as used ... Simple patch: diff --git a/gcc/tree-ssa-loop-niter.cc b/gcc/tree-ssa-loop-niter.cc index 65b960461ae..22e7c0f6ea5 100644 --- a/gcc/tree-ssa-loop-niter.cc +++ b/gcc/tree-ssa-loop-niter.cc @@ -2253,6 +2253,8 @@ build_cltz_expr (tree src, bool leading, bool define_at_zero) integer_type_node, 1, src); int val; scalar_int_mode mode = SCALAR_INT_TYPE_MODE (utype); + /* mode might not be used by the macro C[TL]Z_DEFINED_AT_ZERO. */ + (void)mode; int optab_defined_at_zero = leading ? CLZ_DEFINED_VALUE_AT_ZERO (mode, val) : CTZ_DEFINED_VALUE_AT_ZERO (mode, val);
[Bug bootstrap/108457] New: tree-ssa-loop-niter.cc:2255:23: warning: variable 'mode' set but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108457 Bug ID: 108457 Summary: tree-ssa-loop-niter.cc:2255:23: warning: variable 'mode' set but not used Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 g++ -std=c++11 -fno-PIE -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynch ronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-fo rmat -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual - pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CO NFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I. ./../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody -I/opt/gnu64/gcc/gmp/i nclude -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I.. /libdecnumber -I../../gcc/gcc/../libbacktrace -I/opt/gnu64/gcc/gmp/include -o t ree-ssa-loop-niter.o -MT tree-ssa-loop-niter.o -MMD -MP -MF ./.deps/tree-ssa-loo p-niter.TPo ../../gcc/gcc/tree-ssa-loop-niter.cc ../../gcc/gcc/tree-ssa-loop-niter.cc: In function 'tree_node* build_cltz_expr(tr ee, bool, bool)': ../../gcc/gcc/tree-ssa-loop-niter.cc:2255:23: warning: variable 'mode' set but n ot used [-Wunused-but-set-variable] 2255 | scalar_int_mode mode = SCALAR_INT_TYPE_MODE (utype); | ^~~~
[Bug fortran/108454] ICE in gfc_trans_common, at fortran/trans-common.cc:1385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108454 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-01-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- The code crashing gfortran may actually be valid. Consider: module m implicit none type t end type contains subroutine s real :: t common /com/ t end end This is accepted by other compilers, including Intel and NAG. With -fdump-fortran-original we see that memory gets clobbered somewhere if the derived-type name is the same as the common variable.
[Bug driver/108350] Windows: invoking gcc via symlink does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350 --- Comment #32 from niXman --- > Thanks. Your Windows related changes look good to me. great, thanks! > FYI, I am unsure about the need to change all backslashes to slashes and > wonder if this is a backwards incompatible change for users of lrealpath. > But I am no expert in the gcc codebase, so I will let others chime in here. the patch that does nothing but replace slashes in paths, I (and not only me) have been using for ten years - no one complained =)
[Bug target/107844] error: argument is not a field access for __builtin_preserve_field_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107844 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-01-18 --- Comment #4 from Andrew Pinski --- (In reply to David Faust from comment #3) > Thanks for the info Andrew. I'll look at __builtin_offsetof. > > As for the implementation in clang, I can point to some bits relevant to > the builtin itself: > llvm-project/clang/lib/CodeGen/CGBuiltin.cpp > CodeGenFunction::EmitBPFBuiltinExpr () > > llvm-project/llvm/lib/Target/BPF/BPFAbstractMemberAccess.cpp > BPFAbstractMemberAccess::GetFieldInfo () > > But I am less familiar with the surrounding machinery such as their > parsing and type systems.. So I looked (First off I am shocked they don't have target functions to handle the builtins and every target builtin is handled in that file seems wrong), and you are handed the AST before folding. This is different from GCC where it is you are handed it after folding. So I think we need some special handling in the c (and C++) parser to handle this. I suspect we want to do the full handling of the builtin (bpf_core_field_exists) in the parser rather than the macro expanded view of it too. Similar to how offsetof is handled ... Of course this will need some modifications to the bpf headers too. And that solves some other issues too.
[Bug target/105506] [12/13 Regression] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506 --- Comment #12 from Brecht Sanders --- I couldn't apply that patch. Is that for 12.2.0 ?
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #5 from Jakub Jelinek ---
I'm surprised by rr_union_table content.
// VREL_VARYING
{ VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING,
VREL_VARYING, VREL_VARYING, VREL_VARYING },
is obviously correct, sure, but:
// VREL_UNDEFINED
{ VREL_VARYING, VREL_LT, VREL_LE, VREL_GT, VREL_GE, VREL_UNDEFINED,
VREL_EQ, VREL_NE },
is strange, VREL_VARYING union VREL_UNDEFINED be VREL_LT?
I would have expected
{ VREL_VARYING, VREL_UNDEFINED, VREL_LT, VREL_LE, VREL_GT, VREL_GE,
VREL_EQ, VREL_NE },
instead.
I fear other entries are weird too (though rr_intersect_table entries look
reasonable from quick skimming).
That said, fixing that will not fix this issue.
[Bug libgcc/108279] Improved speed for float128 routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #21 from Wilco ---
(In reply to Jakub Jelinek from comment #20)
> __attribute__((noinline, optimize ("rounding-math"))) static int
> round_to_nearest (void) { return 1.0f - __FLT_MIN__ == 1.0f + __FLT_MIN__; }
Wouldn't that always set inexact?
> and
> if (round_to_nearest ()) \
> _fcw = FP_RND_NEAREST; \
> else \
> __asm__ __volatile__ ("%vstmxcsr\t%0" : "=m" (_fcw)); \
>
> Except that from _fcw we don't determine just the rounding mode but also
> what exceptions are enabled.
Yes that wouldn't work in fenv but FP emulation functions don't need to read
the exception flags.
[Bug driver/108350] Windows: invoking gcc via symlink does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350 --- Comment #31 from Bill Zissimopoulos --- (In reply to niXman from comment #29) > Created attachment 54285 [details] > patch > > another version of the patch. Thanks. Your Windows related changes look good to me. FYI, I am unsure about the need to change all backslashes to slashes and wonder if this is a backwards incompatible change for users of lrealpath. But I am no expert in the gcc codebase, so I will let others chime in here.
[Bug driver/108350] Windows: invoking gcc via symlink does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350 --- Comment #30 from Bill Zissimopoulos --- (In reply to niXman from comment #29) > Created attachment 54285 [details] > patch > > another version of the patch. Sorry for the delay. Will look at it now. (In reply to niXman from comment #28) > one more issue: when the symlink called `gcc.exe` and I exec it as `gcc.exe > a.c` - all works as it should, but when I exec it as `gcc a.c` - I get the > same result as before - `fatal error: cannot execute 'cc1': CreateProcess: > No such file or directory` > > which way this is usually resolved? Not sure about this one. Are you sure your gcc invocation resulted in finding your test symlink? In Windows you can do `where.exe gcc` as an equivalent of `which gcc` on UNIX.
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447 --- Comment #4 from Jakub Jelinek --- I see fold_using_range::relation_fold_and_or which sees relation1 VREL_LE and relation2 VREL_GE and !is_and, and because of relation_union (relation1, relation2) == VREL_VARYING fold it to 1. But for floating point comparisons, LE | GE is not always true, it is true if neither operand is NAN, otherwise false.
[Bug target/107844] error: argument is not a field access for __builtin_preserve_field_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107844 --- Comment #3 from David Faust --- Thanks for the info Andrew. I'll look at __builtin_offsetof. As for the implementation in clang, I can point to some bits relevant to the builtin itself: llvm-project/clang/lib/CodeGen/CGBuiltin.cpp CodeGenFunction::EmitBPFBuiltinExpr () llvm-project/llvm/lib/Target/BPF/BPFAbstractMemberAccess.cpp BPFAbstractMemberAccess::GetFieldInfo () But I am less familiar with the surrounding machinery such as their parsing and type systems..
[Bug libgcc/108279] Improved speed for float128 routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #20 from Jakub Jelinek ---
__attribute__((noinline, optimize ("rounding-math"))) static int
round_to_nearest (void) { return 1.0f - __FLT_MIN__ == 1.0f + __FLT_MIN__; }
and
if (round_to_nearest ()) \
_fcw = FP_RND_NEAREST; \
else \
__asm__ __volatile__ ("%vstmxcsr\t%0" : "=m" (_fcw)); \
Except that from _fcw we don't determine just the rounding mode but also what
exceptions are enabled.
[Bug libgcc/108279] Improved speed for float128 routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #19 from Jakub Jelinek ---
So, if stmxcsr/vstmxcsr is too slow, perhaps we should change x86 sfp-machine.h
#define FP_INIT_ROUNDMODE \
do { \
__asm__ __volatile__ ("%vstmxcsr\t%0" : "=m" (_fcw)); \
} while (0)
#endif
to do that only if not round-to-nearest.
E.g. the fast-float library uses since last November:
static volatile float fmin = __FLT_MIN__;
float fmini = fmin; // we copy it so that it gets loaded at most once.
return (fmini + 1.0f == 1.0f - fmini);
as a quick test whether round-to-nearest is in effect or some other rounding
mode.
Most likely if this is done with -frounding-math it wouldn't even need the
volatile stuff. Of course, if it isn't round-to-nearest, we would need to do
the expensive {,v}stmxcsr.
[Bug tree-optimization/108449] [13 Regression] ICE in eliminate_unnecessary_stmts, at tree-ssa-dce.cc:1512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108449 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-01-18 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106866 --- Comment #1 from Andrew Pinski --- The assert that is being hit was added by r13-2518-ga262f969d6fd93 . Confirmed.
[Bug libquadmath/94756] strtoflt128 assigns some subnormals incorrectly on MS Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756 --- Comment #10 from niXman --- (In reply to Jakub Jelinek from comment #8) > As Joseph wrote, there were lots of strtod_l.c fixes since 2011 and most of > them weren't incorporated into libquadmath (unlike most of the math/ > functions which were updated a couple of times). > Wonder if this one isn't > https://sourceware.org/bugzilla/show_bug.cgi?id=26137 which also talks about > different behavior on 32-bit arches. got it, will look at glibc's implementation.
[Bug libquadmath/94756] strtoflt128 assigns some subnormals incorrectly on MS Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756 --- Comment #9 from niXman --- although I think these two bugs have the same cause...
[Bug libquadmath/94756] strtoflt128 assigns some subnormals incorrectly on MS Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- As Joseph wrote, there were lots of strtod_l.c fixes since 2011 and most of them weren't incorporated into libquadmath (unlike most of the math/ functions which were updated a couple of times). Wonder if this one isn't https://sourceware.org/bugzilla/show_bug.cgi?id=26137 which also talks about different behavior on 32-bit arches.
[Bug libgcc/108279] Improved speed for float128 routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #18 from Wilco ---
(In reply to Michael_S from comment #12)
> This set of options does not map too well into real difficulties of
> implementation.
> There are only 2 things that are expensive:
> 1. Inexact Exception
> 2. Fetching of the current rounding mode.
> The rest of IEEE-754 features is so cheap that creating separate variants
> without them simply is not worth the effort of maintaining distinct
> variants, even if all difference is a single three-lines #ifdef
In general reading the current rounding mode is relatively cheap, but modifying
can be expensive, so optimized fenv implementations in GLIBC only modify the FP
status if a change is required. It should be feasible to check for
round-to-even and use optimized code for that case.
> BTW, Inexact Exception can be made fairly affordable with a little help from
> compiler. All we need for that is ability to say "don't remove this floating
> point addition even if you don't see that it produces any effect".
> Something similar to 'volatile', but with volatile compiler currently puts
> result of addition on stack, which adds undesirable cost.
> However, judged by comment of Jakub, compiler maintainers are not
> particularly interested in this enterprise.
There are macros in GLIBC math-barriers.h which do what you want - eg. AArch64:
#define math_opt_barrier(x) \
({ __typeof (x) __x = (x); __asm ("" : "+w" (__x)); __x; })
#define math_force_eval(x) \
({ __typeof (x) __x = (x); __asm __volatile__ ("" : : "w" (__x)); })
The first blocks optimizations (like constant folding) across the barrier, the
2nd forces evaluation of an expression even if it is deemed useless. These are
used in many math functions in GLIBC. They are target specific due to needing
inline assembler operands, but it should be easy to add similar definitions to
libgcc.
[Bug target/107844] error: argument is not a field access for __builtin_preserve_field_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107844 --- Comment #2 from Andrew Pinski --- The reason why is folded is because some folks use the null pointer for offsetof (previously before GCC added __builtin_offsetof). I wonder if you could use __builtin_offsetof here. I also curious how this is implemented in clang ...
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447 --- Comment #3 from Andrew Macleod --- Those specialized relations are handled within the floating point range-ops code iirc. We established that none of the other floating point relations needed to be exposed to non-floating point code. The frange class has all the knowledge of NAN and such, and the oracle is suppose to invokes a routine called "validate_relation" which invokes a fold operation to find out if the operation is actually valid between 2 operands. (this is how we were suppose to determine x == x may not be true) I can't seem to find any application of the routine tho... It was supplied so floating point x == x would not short-circuit in the oracle as it was symbolically true. I'll have to sync with aldy and see what we currently do, They theoretical application here would be to apply it to the intersection/union routines too. ie Registering value_relation (x_8(D) >= y_9(D)) on (2->3) Intersecting with existing (x_8(D) <= y_9(D)) to produce (x_8(D) == y_9(D)) if we can determine that x == y isnt true.. or that somehow it has different floating point characteristics from the inputs... we'll get back to you.
[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #36 from H.J. Lu ---
(1 << (x)) works, but (((unsigned int) 1) << (x)) doesn't work:
[hjl@gnu-skx-1 gcc]$ cat bar.c
void bar (void);
#define MASK1(x) (1 << (x))
void
f1 (unsigned int *a, unsigned int bit)
{
if ((__atomic_fetch_xor (a, MASK1 (bit), __ATOMIC_RELAXED) & MASK1 (bit)))
bar ();
}
#define MASK2(x) (((unsigned int) 1) << (x))
void
f2 (unsigned int *a, unsigned int bit)
{
if ((__atomic_fetch_xor (a, MASK2 (bit), __ATOMIC_RELAXED) & MASK2 (bit)))
bar ();
}
[hjl@gnu-skx-1 gcc]$ ./xgcc -B./ -S -O2 bar.c
[hjl@gnu-skx-1 gcc]$ cat bar.s
.file "bar.c"
.text
.p2align 4
.globl f1
.type f1, @function
f1:
.LFB0:
.cfi_startproc
lock btcl %esi, (%rdi)
jc .L4
ret
.p2align 4,,10
.p2align 3
.L4:
jmp bar
.cfi_endproc
.LFE0:
.size f1, .-f1
.p2align 4
.globl f2
.type f2, @function
f2:
.LFB1:
.cfi_startproc
movl%esi, %ecx
movl$1, %edx
movl(%rdi), %eax
sall%cl, %edx
.L6:
movl%eax, %r8d
movl%eax, %esi
xorl%edx, %r8d
lock cmpxchgl %r8d, (%rdi)
jne .L6
btl %ecx, %esi
jc .L10
ret
.p2align 4,,10
.p2align 3
.L10:
jmp bar
.cfi_endproc
.LFE1:
.size f2, .-f2
.ident "GCC: (GNU) 13.0.1 20230118 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skx-1 gcc]$
[Bug libquadmath/94756] strtoflt128 assigns some subnormals incorrectly on MS Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756 --- Comment #7 from niXman --- (In reply to niXman from comment #5) > because it's MinGW specific: I will paraphrase: this report is for MinGW. but another one - 87204, looks like NOT. but im unsure... will work on it too.
[Bug target/107844] error: argument is not a field access for __builtin_preserve_field_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107844
--- Comment #1 from David Faust ---
Looks like this is a result of the combination of how the bpf_core_field_exists
macro is defined and some sort of optimization(?) happening in the C frontend.
Consider:
struct S {
unsigned short x;
char c[12];
};
int foo () {
int has_c = bpf_core_field_exists (struct S, c);
return has_c;
}
The bpf_core_field_exists macro expands to:
int has_c =
__builtin_preserve_field_infotypeof(struct S) *)0)->c),
BPF_RELO_FIELD_EXISTS);
For some reason, for array members specifically, this construction results in
the tree for the parameter when resolving the builtin being simply:
(gdb) pt param
constant 2>
i.e. a pointer to 0x2, the offset of 'c' in a 'struct S' mapped at 0x0. For
non-array members, 'param' is some kind of as I'd expect.
This gives us two problems:
a) We cannot distinguish an array member from a non-member constant-value
pointer.
b) We cannot correctly compute information for the CO-RE relocation.
For example, in this case BPF_RELO_FIELD_BYTE_SIZE will be calculated as 8
(size of pointer), not 12 (size of the array).
I'm not sure how to resolve this and support the existing helper macros in the
kernel/libbpf. Might need some change in the C frontend, or to somehow pass
more
information to the target_resolve_overloaded_builtin hook...
[Bug c++/108456] New: attribute deprecated on enum doesn't warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108456
Bug ID: 108456
Summary: attribute deprecated on enum doesn't warn
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
In this test:
struct S {
enum [[deprecated]] E { D };
};
int main()
{
auto a1 = S::D;
auto a2 = S::E::D;
}
we emit a -Wdeprecated-declarations warning only for a2 but not a1, whereas
clang++ warns for a1 too (twice, in fact). I suppose we want a warning there
as well.
C++20 using enum test:
enum class [[deprecated]] E { X };
int main()
{
using enum E;
auto a = X;
}
clang++ warns but g++ doesn't.
[Bug libquadmath/94756] strtoflt128 assigns some subnormals incorrectly on MS Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756 --- Comment #6 from niXman --- (In reply to niXman from comment #3) > BTW, I have fixed it for x86_64-mingw32. trying to rebuild for i686-mingw32 > for check. yeah, it's fixed. works on x86_64 and i686 MinGW. will check it on Linux host too for side effects...
[Bug analyzer/108455] -Wanalyzer-deref-before-check false positive seen in git pack-revindex.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108455 --- Comment #1 from David Malcolm --- Perhaps should only complain if the deref site dominates the check site in the supergraph (and both are in the same function?)
[Bug middle-end/108448] GCC Elides Assignment to Pointer and memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448 --- Comment #5 from Gavin Howard --- As mentioned, it works at -O0, and UBSan reports nothing until the segfault. ASan also reports nothing. Valgrind also reports nothing. They all report nothing at -O0 and -O2. I keep my code clean of such things during development, which is one reason I am so confused. I'll get the amalgamation to you, but it will take me some hours to do so.
[Bug libquadmath/94756] strtoflt128 assigns some subnormals incorrectly on MS Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756 --- Comment #5 from niXman --- because it's MinGW specific: > Demo strtoflt128 error with some subnormals on Windows but another one - 87204, looks like NOT. but im unsure... will work on it too.
[Bug analyzer/108455] New: -Wanalyzer-deref-before-check false positive seen in git pack-revindex.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108455
Bug ID: 108455
Summary: -Wanalyzer-deref-before-check false positive seen in
git pack-revindex.c
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54299
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54299&action=edit
Reduced reproducer
I'm attaching a reduced reproducer
https://godbolt.org/z/7oMrno8rd
Complains about:
../../src/pack-revindex.c: In function ‘load_revindex_from_disk’:
../../src/pack-revindex.c:123:8: warning: check of ‘data’ for NULL after
already dereferencing it [-Wanalyzer-deref-before-check]
123 | if (data)
|^
‘load_revindex_from_disk’: events 1-11
|
| 63 | int load_revindex_from_disk(char *revindex_name, uint32_t
num_objects,
| | ^~~
| | |
| | (1) entry to ‘load_revindex_from_disk’
|..
| 73 | if (fd < 0) {
| | ~
| | |
| | (2) following ‘false’ branch (when ‘fd >= 0’)...
|..
| 77 | if (fstat(fd, &st)) {
| | ~~~
| | ||
| | |(3) ...to here
| | (4) following ‘false’ branch...
|..
| 82 | revindex_size = xsize_t(st.st_size);
| | ~~~
| | |
| | (5) ...to here
| 83 |
| 84 | if (revindex_size < ((12) + (2 *
the_repository->hash_algo->rawsz))) {
| | ~
| | |
| | (6) following ‘false’ branch...
|..
| 90 | if (revindex_size - ((12) + (2 *
the_repository->hash_algo->rawsz)) !=
| | ~ ~~
| | | |
| | (8) following ‘false’ branch... (7) ...to here
|..
| 97 | data = xmmap(((void *)0), revindex_size, 0x1, 0x02, fd, 0);
| | ~~~
| | |
| | (9) ...to here
|..
| 100 | if (git_bswap32(hdr->signature) != 0x52494458) {
| | ~~~
| | |
| | (10) pointer ‘data’ is dereferenced here
| 101 | ret =
| 102 | (error(_("reverse-index file %s has unknown signature"),
revindex_name),
| |
~~
| | |
| | (11) calling ‘_’ from ‘load_revindex_from_disk’
|
+--> ‘_’: events 12-14
|
| 37 | static inline __attribute__((format_arg(1))) const char
*_(const char *msgid) {
| | ^
| | |
| |
(12) entry to ‘_’
| 38 | if (!*msgid)
| | ~
| | |
| | (13) following ‘false’ branch...
| 39 | return "";
| 40 | return gettext(msgid);
| | ~~
| | |
| | (14) ...to here
|
<--+
|
‘load_revindex_from_disk’: events 15-18
|
| 102 | (error(_("reverse-index file %s has unknown signature"),
revindex_name),
| |
^~
| | |
| | (15) returning to ‘load_revindex_from_disk’ from ‘_’
|..
| 122 | if (ret) {
| | ~
| | |
| | (16) following ‘true’ branch (when ‘ret != 0’)...
| 123 | if (data)
| |~
| ||
| |(17) ...to here
| |(18) pointer ‘data’ is checked for NULL here but it was
already dereferenced at (10)
|
Yes it does check the pointer for NULL after dereferencing it, but this is in
shared cleanup code. There are other paths to the check for NULL in which the
pointer hasn't yet been dereferenced.
[Bug libquadmath/94756] strtoflt128 assigns some subnormals incorrectly on MS Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #4 from Jakub Jelinek ---
I can reproduce it on x86_64-linux with -m32 too:
f1: 0x0.00014707e947d757fbf6f7p-16382
f2: 0x0.00014707e946d257f2f674b9p-16382
but can't with -m64 nor when using glibc 2.35 strtof128 (in that case it works
fine both with -m32 and -m64):
#define _GNU_SOURCE
#include
#include
#include
int
main ()
{
char buffer[48];
_Float128 f1 = strtof128 ("1e-4941", NULL);
_Float128 f2 = 1e-4941F128;
strfromf128 (buffer, 45, "%a", f1);
printf ("f1: %s\n", buffer);
strfromf128 (buffer, 45, "%a", f2);
printf ("f2: %s\n", buffer);
return 0;
}
[Bug middle-end/108448] GCC Elides Assignment to Pointer and memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448 --- Comment #4 from Andrew Pinski --- Does it work at -O0? Does -fsanitizer=address -fsanitizer=undefined report anything?
[Bug fortran/108454] New: ICE in gfc_trans_common, at fortran/trans-common.cc:1385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108454 Bug ID: 108454 Summary: ICE in gfc_trans_common, at fortran/trans-common.cc:1385 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 module m type t end type contains subroutine s common t end end $ cat z3.f90 module m type t end type contains subroutine s type(t) :: x common t end end $ cat z4.f90 module m type t end type contains subroutine s(x) class(t) :: x common t end end $ gfortran-13-20230115 -c z1.f90 z1.f90:8:3: 8 | end | 1 internal compiler error: Segmentation fault 0xda7faf crash_signal ../../gcc/toplev.cc:314 0x897730 gfc_trans_common(gfc_namespace*) ../../gcc/fortran/trans-common.cc:1385 0x8a7229 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7523 0x87e7d9 gfc_generate_module_code(gfc_namespace*) ../../gcc/fortran/trans.cc:2370 0x82926f translate_all_program_units ../../gcc/fortran/parse.cc:6708 0x82926f gfc_parse_file() ../../gcc/fortran/parse.cc:7027 0x876eff gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229
[Bug fortran/108453] New: [10/11/12/13 Regression] ICE in gfc_trans_use_stmts, at fortran/trans-decl.cc:5361
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108453 Bug ID: 108453 Summary: [10/11/12/13 Regression] ICE in gfc_trans_use_stmts, at fortran/trans-decl.cc:5361 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r6 : $ cat z1.f90 module m type t end type end program p use m, only: t common t end $ cat z2.f90 module m type t end type end program p use m, only: t common /xc/ t end $ cat z3.f90 module m type t end type end program p use m common t end $ gfortran-5 -c z3.f90 z3.f90:7:11: common t 1 Error: Cannot change attributes of USE-associated symbol t at (1) $ gfortran-13-20230115 -c z3.f90 $ $ gfortran-13-20230115 -c z1.f90 z1.f90:6:7: 6 |use m, only: t | 1 internal compiler error: in gfc_trans_use_stmts, at fortran/trans-decl.cc:5361 0x8a707e gfc_trans_use_stmts ../../gcc/fortran/trans-decl.cc:5360 0x8a783b gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7837 0x82968e translate_all_program_units ../../gcc/fortran/parse.cc:6721 0x82968e gfc_parse_file() ../../gcc/fortran/parse.cc:7027 0x876eff gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229
[Bug fortran/108452] New: ICE in gfc_trans_use_stmts, at fortran/trans-decl.cc:5347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108452 Bug ID: 108452 Summary: ICE in gfc_trans_use_stmts, at fortran/trans-decl.cc:5347 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 module m interface g procedure f end interface contains function f() end end program p use m, u => g, v => g end $ cat z2.f90 module m interface g procedure f end interface contains function f() end end program p use m, u => g end $ gfortran-13-20230115 -c z2.f90 $ $ gfortran-13-20230115 -c z1.f90 z1.f90:10:7: 10 |use m, u => g, v => g | 1 internal compiler error: in gfc_trans_use_stmts, at fortran/trans-decl.cc:5347 0x8a6fd3 gfc_trans_use_stmts ../../gcc/fortran/trans-decl.cc:5347 0x8a783b gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7837 0x82968e translate_all_program_units ../../gcc/fortran/parse.cc:6721 0x82968e gfc_parse_file() ../../gcc/fortran/parse.cc:7027 0x876eff gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 G. Steinmetz changed: What|Removed |Added Keywords||accepts-invalid, ||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- Following variant z2 should be rejected similar to z3 : $ cat z2.f90 module m type t(n) integer, len :: n integer :: a(n) end type contains subroutine s(x) type(t(2)) :: x end end program p use m, only: t, s, pdtt type(t(2)) :: y call s(y) end $ cat z3.f90 module m type t end type contains subroutine s end end program p use m, only: t, s, pdtt call s end $ gfortran-13-20230115 -c z2.f90 # missing error $ $ gfortran-13-20230115 -c z3.f90 z3.f90:9:21: 9 |use m, only: t, s, pdtt | 1 Error: Symbol 'pdtt' referenced at (1) not found in module 'm'
[Bug fortran/108451] New: [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 Bug ID: 108451 Summary: [13 Regression] ICE in check_complete_insertion, at hash-table.h:578 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started recently between 20221218 and 20230108, with special name pdtt : (gcc configured with --enable-checking=yes) $ cat z1.f90 module m type t(n) integer, len :: n integer :: a(n) end type contains subroutine s(x) type(t(2)) :: x end end program p use m, only: t, pdtt, s type(t(2)) :: y call s(y) end $ gfortran-13-20221218 -c z1.f90 # missing error $ $ gfortran-13-20230115 -c z1.f90 z1.f90:12:7: 12 |use m, only: t, pdtt, s | 1 internal compiler error: in check_complete_insertion, at hash-table.h:578 0x92fc0b hash_table::check_complete_insertion() const ../../gcc/hash-table.h:578 0x92fc0b hash_table::find_slot_with_hash(char const* const&, unsigned int, insert_option) ../../gcc/hash-table.h:1042 0x92c57e gfc_trans_use_stmts ../../gcc/fortran/trans-decl.cc:5329 0x92d3a6 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7837 0x89ef8e translate_all_program_units ../../gcc/fortran/parse.cc:6721 0x89ef8e gfc_parse_file() ../../gcc/fortran/parse.cc:7027 0x8ed3af gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229
[Bug fortran/108450] New: [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108450 Bug ID: 108450 Summary: [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started between 20211128 and 20211205 : $ cat z1.f90 program p integer :: a(8) = 0 integer :: l integer :: n !$omp atomic n = maxloc(a, mask=l) end $ cat z2.f90 program p integer :: a(8) = 0 logical :: l integer :: n(1) !$omp atomic n = maxloc(a, mask=l) end $ gfortran-13-20230115 -c z2.f90 -fopenmp z2.f90:6:3: 6 |n = maxloc(a, mask=l) | 1 Error: !$OMP ATOMIC statement must set a scalar variable of intrinsic type at (1) $ gfortran-13-20230115 -c z1.f90 -fopenmp z1.f90:6:22: 6 |n = maxloc(a, mask=l) | 1 Error: 'mask' argument of 'maxloc' intrinsic at (1) must be LOGICAL f951: internal compiler error: Segmentation fault 0xf8734f crash_signal ../../gcc/toplev.cc:314 0x84f083 sort_actual ../../gcc/fortran/intrinsic.cc:4380 0x84f2d4 check_specific ../../gcc/fortran/intrinsic.cc:4774 0x8574c4 gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.cc:5042 0x8aeb18 resolve_unknown_f ../../gcc/fortran/resolve.cc:2990 0x8aeb18 resolve_function ../../gcc/fortran/resolve.cc:3347 0x8aeb18 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:7195 0x8806a4 resolve_omp_atomic ../../gcc/fortran/openmp.cc:8699 0x88de6c gfc_resolve_omp_directive(gfc_code*, gfc_namespace*) ../../gcc/fortran/openmp.cc:10190 0x8b48ab gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:12444 0x8b69e7 resolve_codes ../../gcc/fortran/resolve.cc:17629 0x8b6aae gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.cc:17664 0x89e844 resolve_all_program_units ../../gcc/fortran/parse.cc:6656 0x89e844 gfc_parse_file() ../../gcc/fortran/parse.cc:6912 0x8ed3af gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229
[Bug middle-end/108448] GCC Elides Assignment to Pointer and memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448 --- Comment #3 from Gavin Howard --- > Have you tried -fno-strict-aliasing ? I have a feeling like you have some > aliasing issues in this code ... Just tried it, same thing happens. I'll try to make a better test case, but in this case, the bug happens deep in the startup of a custom runtime that touches many files and sets up its own version of stdio. I'll probably just amalgamate all of the required files together. I know the policy, but the URL really is the best way to reproduce easily.
[Bug c/108449] New: [13 Regression] ICE in eliminate_unnecessary_stmts, at tree-ssa-dce.cc:1512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108449
Bug ID: 108449
Summary: [13 Regression] ICE in eliminate_unnecessary_stmts, at
tree-ssa-dce.cc:1512
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20220904 and 20220911, at -O1+ :
$ cat z1.c
static int vfork();
void f() { vfork(); }
$ gcc-13-20230115 -c z1.c -O2
z1.c:1:12: warning: 'vfork' used but never defined
1 | static int vfork();
|^
during GIMPLE pass: cddce
z1.c: In function 'f':
z1.c:2:1: internal compiler error: in eliminate_unnecessary_stmts, at
tree-ssa-dce.cc:1512
2 | void f() { vfork(); }
| ^~~~
0xe0f0dc eliminate_unnecessary_stmts
../../gcc/tree-ssa-dce.cc:1512
0xe108bf perform_tree_ssa_dce
../../gcc/tree-ssa-dce.cc:1945
0xe11e55 tree_ssa_cd_dce
../../gcc/tree-ssa-dce.cc:1986
0xe11e55 execute
../../gcc/tree-ssa-dce.cc:2069
[Bug middle-end/108448] GCC Elides Assignment to Pointer and memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448 --- Comment #2 from Andrew Pinski --- Have you tried -fno-strict-aliasing ? I have a feeling like you have some aliasing issues in this code ...
[Bug c/108448] GCC Elides Assignment to Pointer and memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-01-18 Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- https://gcc.gnu.org/bugs/#dontwant What we do not want ... * The location (URL) of the package that failed to build (we won't download it, anyway, since you've already given us what we need to duplicate the bug, haven't you? :-)
[Bug c/108448] New: GCC Elides Assignment to Pointer and memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
Bug ID: 108448
Summary: GCC Elides Assignment to Pointer and memcpy
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gavin at yzena dot com
Target Milestone: ---
Host: x86_64
Target: x86_64
I have a stack allocator ("stackpool") that can automatically free all data
allocated after entry to a function. To do this, I pass in a pointer to the
function name to be the marker for the function start.
To debug, I also check the function name on exit.
This last item is segfaulting because the function name pointer is NULL. I ran
it through GDB, and the assignment to the allocated pointer ([1]) is skipped
entirely, but only when not compiling in plain Debug mode (CMake). I tried a
memcpy() ([2]), but it is *also* skipped.
I checked for undefined behavior with UBSan. It didn't catch any. I fully
acknowledge that there could be some, though.
To reproduce, run the following:
```
$ git clone https://git.yzena.com/Yzena/Yc.git
$ cd Yc
$ git config --local include.path ./.gitconfig
$ git submodule update --init --recursive
$ mkdir build
$ cd build
$ cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_C_COMPILER=
-DYC_ENABLE_STACKTRACES=ON -DYC_ENABLE_LONG_TESTS=ON -DYC_BUILD_DOCS=OFF ..
$ make -j
```
If the build fails, you have successfully reproduced the problem because there
is a program that uses that code used as part of the build (to generate a test
file). The program is `tests/strgen` (produced from `tests/strgen.c`), and the
command-line it runs is something like:
```
$ tests/container/../strgen tests/container/kjvbible.txt
tests/container/kjvbible.c kjvbible_array 1
```
To pre-emptively answer some questions: the function name pointer that is
passed in to `y_stackpool_enterFunc()` (the one with the elided assignment) is
not NULL, and neither is the stackpool.
But again, I wouldn't be surprised if there's some UB somewhere that is giving
GCC the "right" to elide this assignment. I just can't find where because I'm
not as expert in C as the GCC authors.
[1]:
https://git.yzena.com/Yzena/Yc/src/commit/6afdc86bd2c17f98b2f9e97e79e37fdf8c6b7708/src/alloc/stackpool.c#L441
[2]:
https://git.yzena.com/Yzena/Yc/src/commit/c9a855a0b6d9c5758e4d605977bdf571830132a2/src/alloc/stackpool.c#L442-L443
