[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 --- Comment #26 from Nicolas Boulenguez --- Created attachment 58181 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58181&action=edit v9 fixing a typo in patch 9/9 "select 32 or 64 bits variants" The "select 32 or 64 bits variants" patch in v8 (attachment 58060) mispells OS_Constants in s-osinte__gnu.ads and breaks the build on hurd.
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #17 from Aldy Hernandez --- (In reply to Martin Jambor from comment #16) > I'll have look, hopefully on Monday. Thanks Martin. To reproduce the problem: 1. Revert this patch: commit d7bb8eaade3cd3aa70715c8567b4d7b08098e699 (master, clean) Author: Aldy Hernandez Date: Fri May 10 00:29:13 2024 +0200 Revert: "Enable prange support." [PR114985] 2. Trap on pointer mismatches: diff --git a/gcc/range-op.cc b/gcc/range-op.cc index 000ec802e66..c14b72c19de 100644 --- a/gcc/range-op.cc +++ b/gcc/range-op.cc @@ -52,7 +52,7 @@ along with GCC; see the file COPYING3. If not see // Set to 1 to trap on range-op entries that cannot handle the pointer // combination being requested. This is a temporary sanity check to // aid in debugging, and will be removed later in the release cycle. -#define TRAP_ON_UNHANDLED_POINTER_OPERATORS 0 +#define TRAP_ON_UNHANDLED_POINTER_OPERATORS 1 // Instantiate the operators which apply to multiple types here. I will also attach a preprocessed file to reproduce the problem on ppc64le that can save you some time.
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #18 from Aldy Hernandez --- Ah, it looks like seurer already beat me to the preprocessed source.
[Bug tree-optimization/114760] trailing zero count detection failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114760 --- Comment #2 from GCC Commits --- The master branch has been updated by Di Zhao : https://gcc.gnu.org/g:1b0919cd147a2b6ccdee2b1217bf0200bdcc87aa commit r15-380-g1b0919cd147a2b6ccdee2b1217bf0200bdcc87aa Author: dzhao.ampere Date: Fri May 10 11:55:18 2024 +0800 tree-optimization/114760 - check variants of >> and << in loop-niter When recognizing bit counting idiom, include pattern "x * 2" for "x << 1", and "x / 2" for "x >> 1" (given x is unsigned). gcc/ChangeLog: PR tree-optimization/114760 * tree-ssa-loop-niter.cc (is_lshift_by_1): New function to check if STMT is equivalent to x << 1. (is_rshift_by_1): New function to check if STMT is equivalent to x >> 1. (number_of_iterations_cltz): Enhance the identification of logical shift by one. (number_of_iterations_cltz_complement): Enhance the identification of logical shift by one. gcc/testsuite/ChangeLog: PR tree-optimization/114760 * gcc.dg/tree-ssa/pr114760-1.c: New test. * gcc.dg/tree-ssa/pr114760-2.c: New test.
[Bug fortran/99798] ICE when compiling a variant of pr87907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99798 Mikael Morin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin --- I'm working on it.
[Bug c/114112] Error message is translatable but inserts untranslated substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114112 Göran Uddeborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Göran Uddeborg --- This is fixed in the 14.1.0 version of the message catalog now available for translation. Thank you!
[Bug bootstrap/54179] please split insn-emit.c !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #39 from Brjd --- Let me share what I notice in 14.1. Significant improvement in insn-emit.cc and gimple-match.cc. This is good news. Insn-recog.cc is much the same and needs ~ 1.6 GiB RAM. Yet, another possible issue in the future might be gcc/genautomata.cc or insn-conditions.md > tmp-automata.cc where RAM reaches 1.8 GiB. The rest of the build is pretty nice at just 500-600 MiB.
[Bug target/115038] ICE in seh_cfa_offset since 14.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115038
--- Comment #1 from Christoph Reiter ---
Another downstream report with the same error:
https://github.com/msys2/MINGW-packages/issues/20864
I've c-reduced that as well to:
```
// gcc -c -fno-omit-frame-pointer -O2 repro.cpp
struct d {
d();
};
struct e {
e() : c(1.0) {}
float c;
};
struct j {
using ad = d;
};
class k : j {
d g;
e h;
};
template using i = k;
class {
i f;
} a;
k b;
```
[Bug target/115043] New: aarch64 locally_streaming function appears to have CFA note on wrong instruction in prologue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115043
Bug ID: 115043
Summary: aarch64 locally_streaming function appears to have CFA
note on wrong instruction in prologue
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
Target Milestone: ---
Apologies if I'm misunderstanding something here -- but I noticed this RTL
sequence and I believe the `REG_CFA_DEF_CFA` note is on the wrong insn.
I have not observed wrong behaviour coming from this, but figured still worth a
bug report in case it is indeed wrong.
There seem to be a pair of instructions, one doing some special SME operation
and another storing the stack pointer into x11. The instruction doing the
special SME thing has a note saying that it sets the CFA to x11. I would have
expected the note to be on the insn after that records SP into x11.
vshcmd: > cat basic-streaming.c
[[arm::locally_streaming]] void
no_gprs_saved (__SVBool_t x)
{
asm ("");
}
gnu-work [13:19:27] $
vshcmd: > ${install_dir}/aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc
\
vshcmd: > basic-streaming.c \
vshcmd: > -fdiagnostics-plain-output -march=armv8.2-a+sme+sve
-fno-stack-protector \
vshcmd: > -fdump-rtl-all-all \
vshcmd: > -O -fshrink-wrap -fstack-clash-protection -g -S -o /dev/null
> > > > gnu-work [13:19:36] $
> > > >
> > > >
> > > >
> > > >
vshcmd: > # I'm surprised that the REG_CFA_DEF_CFA note is on the instruction
vshcmd: > # just before we move the stack pointer into x11.
vshcmd: > grep -C 4 REG_CFA_DEF_CFA.*x11
basic-streaming.c.*.late_pro_and_epilogue
(insn/f 15 14 16 2 (set (reg:DI 13 x13)
(const:DI (unspec:DI [
(const_int 288 [0x120])
] UNSPEC_SME_VQ))) "basic-streaming.c":3:1 -1
(expr_list:REG_CFA_DEF_CFA (reg:DI 11 x11)
(nil)))
(insn 16 15 17 2 (set (reg:DI 11 x11)
(reg/f:DI 31 sp)) "basic-streaming.c":3:1 -1
(nil))
gnu-work [13:21:21] $
[Bug c++/56556] Wshadow warns for private members in base classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56556 --- Comment #4 from Gaël Bonithon --- It would be nice if this could be fixed. I'm currently experimenting with porting a GTK text editor to Qt6, and it seems that because of this, I can't name a local variable 'data' in a method of a QWidget derived class without causing a warning: mousepad-window.cpp:3740:12: warning: declaration of 'data' shadows a member of 'MousepadWindow' [-Wshadow] 3740 | gpointer data = GINT_TO_POINTER (gtk_text_buffer_get_modified (active->buffer)); |^~~~ In file included from /usr/include/qt6/QtWidgets/qmainwindow.h:8, from /usr/include/qt6/QtWidgets/QMainWindow:1, from ../mousepad/mousepad-window.hpp:27: /usr/include/qt6/QtWidgets/qwidget.h:780:18: note: shadowed declaration is here 780 | QWidgetData *data; Sorry, but this seems really silly. Clang doesn't warn in this case.
[Bug driver/80182] accidently invoked `gcc -lm -o file.c` which deletes file.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80182 --- Comment #5 from Peter Damianov --- I submitted a patch for this: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651340.html
[Bug libstdc++/109442] Dead local copy of std::vector not removed from function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #19 from Jan Hubicka ---
Note that the testcase from PR115037 also shows that we are not able to
optimize out dead stores to the vector, which is another quite noticeable
problem.
void
test()
{
std::vector test;
test.push_back (1);
}
We alocate the block, store 1 and immediately delete it.
void test ()
{
int * test$D25839$_M_impl$D25146$_M_start;
struct vector test;
int * _61;
[local count: 1073741824]:
_61 = operator new (4);
[local count: 1063439392]:
*_61 = 1;
operator delete (_61, 4);
test ={v} {CLOBBER};
test ={v} {CLOBBER(eol)};
return;
[count: 0]:
:
test ={v} {CLOBBER};
resx 2
}
So my understanding is that we decided to not optimize away the dead stores
since the particular operator delete does not pass test:
/* If the call is to a replaceable operator delete and results
from a delete expression as opposed to a direct call to
such operator, then we can treat it as free. */
if (fndecl
&& DECL_IS_OPERATOR_DELETE_P (fndecl)
&& DECL_IS_REPLACEABLE_OPERATOR (fndecl)
&& gimple_call_from_new_or_delete (stmt))
return ". o ";
This is because we believe that operator delete may be implemented in an insane
way that inspects the values stored in the block being freed.
I can sort of see that one can write standard conforming code that allocates
some data that is POD and inspects it in destructor.
However for std::vector this argument is not really applicable. Standard does
specify that new/delete is used to allocate/deallocate the memory but does not
say how the memory is organized or what happens before deallocation.
(i.e. it is probably valid for std::vector to memset the block just before
deallocating it).
Similar argument can IMO be used for eliding unused memory allocations. It is
kind of up to std::vector implementation on how many allocations/deallocations
it does, right?
So we need a way to annotate the new/delete calls in the standard library as
safe for such optimizations (i.e. implement clang's
__bulitin_operator_new/delete?)
How clang manages to optimize this out without additional hinting?
[Bug testsuite/112728] gcc.dg/scantest-lto.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112728 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-05-11 CC||iains at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #6 from Iain Sandoe --- it also fails on Darwin because the LTO section names are different (and therefore are not being excluded) -- I have patches to fix the two issues mentioned for Darwin, For the EH case, we can imply omit the EH frames from the test. For the other case, I'll fix up the scanasm code to allow the correct LTO section name introducer on Darwin - that seems a better solution than doing a dance with counting the number of .ascii every time. No idea if either of those issues is relevant to the remaining affected platforms.
[Bug analyzer/110014] -Wanalyzer-allocation-size mishandles realloc (..., .... * sizeof (object))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110014 --- Comment #6 from nightstrike --- (In reply to David Malcolm from comment #5) > Should be fixed for GCC 13 (for the upcoming GCC 13.3) by the above patch. Did you miss my comment #3 that highlighted the problem due to assuming that size_t == long?
[Bug analyzer/109577] -Wanalyzer-allocation-size mishandles __builtin_mul_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109577 --- Comment #9 from nightstrike --- (In reply to David Malcolm from comment #8) > Should be fixed for GCC 13 (for the upcoming GCC 13.3) by the above patches. Did you miss my comment #5 highlighting the need to adjust the declaration of malloc such that size_t != long?
[Bug c++/114990] Compiler errors in compiling a module-based app
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990 --- Comment #3 from Patrick Palka --- I reckon it's not something we can fix/implement in a point release of GCC 14, but hopefully for 15...
[Bug libstdc++/109442] Dead local copy of std::vector not removed from function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #20 from Jonathan Wakely ---
(In reply to Jan Hubicka from comment #19)
> Similar argument can IMO be used for eliding unused memory allocations. It
> is kind of up to std::vector implementation on how many
> allocations/deallocations it does, right?
It's up to std::allocator, which is not required to call operator new every
time memory is needed.
> So we need a way to annotate the new/delete calls in the standard library as
> safe for such optimizations (i.e. implement clang's
> __bulitin_operator_new/delete?)
Yes, see PR 110137.
> How clang manages to optimize this out without additional hinting?
It supports __builtin_operator_{new,delete} and libstdc++ uses that when
compiled with clang.
[Bug analyzer/115044] New: -Wanalyzer-malloc-leak diagnostic in terminal path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115044
Bug ID: 115044
Summary: -Wanalyzer-malloc-leak diagnostic in terminal path
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: andrew.cooper3 at citrix dot com
Target Milestone: ---
I've been experimenting with -fanalyzer and attribute(malloc) in Xen.
For a simple case, it reported:
drivers/passthrough/x86/iommu.c: In function 'iommu_init_domid':
./include/xen/bug.h:141:13: warning: leak of '_xzalloc(4096, 8)' [CWE-401]
[-Wanalyzer-malloc-leak]
141 | do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
| ^
drivers/passthrough/x86/iommu.c:551:9: note: in expansion of macro 'ASSERT'
551 | ASSERT(reserve > DOMID_MASK);
| ^~
If I'm reading this correctly, it's saying that allocated memory is being
leaked by ASSERT().
The whole function is:
unsigned long *__init iommu_init_domid(domid_t reserve)
{
unsigned long *map;
if ( !iommu_quarantine )
return ZERO_BLOCK_PTR;
BUILD_BUG_ON(DOMID_MASK * 2U >= UINT16_MAX);
map = xzalloc_array(unsigned long, BITS_TO_LONGS(UINT16_MAX - DOMID_MASK));
if ( map && reserve != DOMID_INVALID )
{
ASSERT(reserve > DOMID_MASK);
__set_bit(reserve & DOMID_MASK, map);
}
return map;
}
but I can't seem to reproduce the -fanalyzer warning in a simpler example.
Assuming it might be something to do with our implementation of ASSERT(), I
reduced it to just
do { if (!(x)) __builtin_trap(); } while ( 0 )
in place, and that still did reproduce the warning.
So while the analyser is technically accurate (i.e. the memory is leaked when
we encounter a fatal path), I'm not sure it's a helpful diagnostic.
Is there a reason why it's reported like this?
[Bug libstdc++/115045] New: views::adjacent_transform<0> is underconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115045
Bug ID: 115045
Summary: views::adjacent_transform<0> is underconstrained
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
This is related to the PR38.
#include
int main() {
std::views::adjacent_transform<0>(std::views::single(0), []{}); // hard error
in libstdc++
}
[Bug fortran/115039] Statement function with inquiry refs rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115039 --- Comment #2 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d4974fd22730014e337fd7ec2471945ba8afb00e commit r15-385-gd4974fd22730014e337fd7ec2471945ba8afb00e Author: Harald Anlauf Date: Fri May 10 21:18:03 2024 +0200 Fortran: fix dependency checks for inquiry refs [PR115039] gcc/fortran/ChangeLog: PR fortran/115039 * expr.cc (gfc_traverse_expr): An inquiry ref does not constitute a dependency and cannot collide with a symbol. gcc/testsuite/ChangeLog: PR fortran/115039 * gfortran.dg/statement_function_5.f90: New test.
[Bug analyzer/109577] -Wanalyzer-allocation-size mishandles __builtin_mul_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109577 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #10 from Segher Boessenkool --- Reopened, then.
[Bug analyzer/110014] -Wanalyzer-allocation-size mishandles realloc (..., .... * sizeof (object))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110014 Segher Boessenkool changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED CC||segher at gcc dot gnu.org --- Comment #7 from Segher Boessenkool --- Reopened, then.
[Bug target/113880] V2SF->V2DF conversion pattern seems to be missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113880 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-05-11 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- I have someone working on this.
[Bug target/113882] V4SF->V4HI could be implemented using V4SF->V4SI and then truncation to V4HI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113882 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-05-11 --- Comment #2 from Andrew Pinski --- I have someone working on this,
[Bug bootstrap/54179] please split insn-emit.c !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #40 from Sam James --- That came up at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600#c29.
[Bug libstdc++/115046] New: meta-recursion when apply join_view with as_const_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115046
Bug ID: 115046
Summary: meta-recursion when apply join_view with as_const_view
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
I seriously doubt this is a more practical example of LWG 3986 since join_view
has a std::optional member to store the iterator, but I'm not sure about
whether this is a language bug or a library bug since MSVC doesn't have the
issue:
#include
#include
int main() {
std::list l;
auto r = l | std::views::chunk(3)
| std::views::transform(std::views::as_const)
| std::views::join;
for (auto&& elem : r) {
// infinite meta-recursion
}
}
https://godbolt.org/z/Morx4voT8
Reduction is a nightmare, so I only do it when I have time.
[Bug libstdc++/115046] meta-recursion when apply join_view with as_const_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115046 --- Comment #1 from 康桓瑋 --- Oh, maybe this is just because MSVC does not use std::optional but uses _Defaultabox.
[Bug fortran/84006] [11/12/13/14/15 Regression] ICE in storage_size() with CLASS entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84006 --- Comment #14 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:b9294757f82aae8de6d98c122cd4e3b98f685217 commit r15-386-gb9294757f82aae8de6d98c122cd4e3b98f685217 Author: Paul Thomas Date: Sun May 12 06:59:45 2024 +0100 Fortran: Unlimited polymorphic intrinsic function arguments [PR84006] 2024-05-12 Paul Thomas gcc/fortran PR fortran/84006 PR fortran/100027 PR fortran/98534 * iresolve.cc (gfc_resolve_transfer): Emit a TODO error for unlimited polymorphic mold. * trans-expr.cc (gfc_resize_class_size_with_len): Use the fold even if a block is not available in which to fix the result. (trans_class_assignment): Enable correct assignment of character expressions to unlimited polymorphic variables using lhs _len field and rse string_length. * trans-intrinsic.cc (gfc_conv_intrinsic_storage_size): Extract the class expression so that the unlimited polymorphic class expression can be used in gfc_resize_class_size_with_len to obtain the storage size for character payloads. Guard the use of GFC_DECL_SAVED_DESCRIPTOR by testing for DECL_LANG_SPECIFIC to prevent the ICE. Also, invert the order to use the class expression extracted from the argument. (gfc_conv_intrinsic_transfer): In same way as 'storage_size', use the _len field to obtaining the correct length for arg 1. Add a branch for the element size in bytes of class expressions with provision to make use of the unlimited polymorphic _len field. Again, the class references are explicitly identified. 'mold_expr' was already declared. Use it instead of 'arg'. Do not fix 'dest_word_len' for deferred character sources because reallocation on assign makes use of it before it is assigned. gcc/testsuite/ PR fortran/84006 PR fortran/100027 * gfortran.dg/storage_size_7.f90: New test. PR fortran/98534 * gfortran.dg/transfer_class_4.f90: New test.
[Bug fortran/98534] Intrinsic functions failing with unlimited polymorphic actual arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98534 --- Comment #6 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:b9294757f82aae8de6d98c122cd4e3b98f685217 commit r15-386-gb9294757f82aae8de6d98c122cd4e3b98f685217 Author: Paul Thomas Date: Sun May 12 06:59:45 2024 +0100 Fortran: Unlimited polymorphic intrinsic function arguments [PR84006] 2024-05-12 Paul Thomas gcc/fortran PR fortran/84006 PR fortran/100027 PR fortran/98534 * iresolve.cc (gfc_resolve_transfer): Emit a TODO error for unlimited polymorphic mold. * trans-expr.cc (gfc_resize_class_size_with_len): Use the fold even if a block is not available in which to fix the result. (trans_class_assignment): Enable correct assignment of character expressions to unlimited polymorphic variables using lhs _len field and rse string_length. * trans-intrinsic.cc (gfc_conv_intrinsic_storage_size): Extract the class expression so that the unlimited polymorphic class expression can be used in gfc_resize_class_size_with_len to obtain the storage size for character payloads. Guard the use of GFC_DECL_SAVED_DESCRIPTOR by testing for DECL_LANG_SPECIFIC to prevent the ICE. Also, invert the order to use the class expression extracted from the argument. (gfc_conv_intrinsic_transfer): In same way as 'storage_size', use the _len field to obtaining the correct length for arg 1. Add a branch for the element size in bytes of class expressions with provision to make use of the unlimited polymorphic _len field. Again, the class references are explicitly identified. 'mold_expr' was already declared. Use it instead of 'arg'. Do not fix 'dest_word_len' for deferred character sources because reallocation on assign makes use of it before it is assigned. gcc/testsuite/ PR fortran/84006 PR fortran/100027 * gfortran.dg/storage_size_7.f90: New test. PR fortran/98534 * gfortran.dg/transfer_class_4.f90: New test.
[Bug fortran/100027] ICE on storage_size with polymorphic argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100027 --- Comment #4 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:b9294757f82aae8de6d98c122cd4e3b98f685217 commit r15-386-gb9294757f82aae8de6d98c122cd4e3b98f685217 Author: Paul Thomas Date: Sun May 12 06:59:45 2024 +0100 Fortran: Unlimited polymorphic intrinsic function arguments [PR84006] 2024-05-12 Paul Thomas gcc/fortran PR fortran/84006 PR fortran/100027 PR fortran/98534 * iresolve.cc (gfc_resolve_transfer): Emit a TODO error for unlimited polymorphic mold. * trans-expr.cc (gfc_resize_class_size_with_len): Use the fold even if a block is not available in which to fix the result. (trans_class_assignment): Enable correct assignment of character expressions to unlimited polymorphic variables using lhs _len field and rse string_length. * trans-intrinsic.cc (gfc_conv_intrinsic_storage_size): Extract the class expression so that the unlimited polymorphic class expression can be used in gfc_resize_class_size_with_len to obtain the storage size for character payloads. Guard the use of GFC_DECL_SAVED_DESCRIPTOR by testing for DECL_LANG_SPECIFIC to prevent the ICE. Also, invert the order to use the class expression extracted from the argument. (gfc_conv_intrinsic_transfer): In same way as 'storage_size', use the _len field to obtaining the correct length for arg 1. Add a branch for the element size in bytes of class expressions with provision to make use of the unlimited polymorphic _len field. Again, the class references are explicitly identified. 'mold_expr' was already declared. Use it instead of 'arg'. Do not fix 'dest_word_len' for deferred character sources because reallocation on assign makes use of it before it is assigned. gcc/testsuite/ PR fortran/84006 PR fortran/100027 * gfortran.dg/storage_size_7.f90: New test. PR fortran/98534 * gfortran.dg/transfer_class_4.f90: New test.
[Bug fortran/100027] ICE on storage_size with polymorphic argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100027 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Paul Thomas --- Fixed on mainline. Thanks for the report and the patch. It's a pity that you didn't reply to me that you couldn't or wouldn't do the commit :-( Paul
[Bug fortran/98534] Intrinsic functions failing with unlimited polymorphic actual arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98534 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Paul Thomas --- Fixed on mainline. Paul
[Bug fortran/84006] [11/12/13/14 Regression] ICE in storage_size() with CLASS entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84006 Paul Thomas changed: What|Removed |Added Summary|[11/12/13/14/15 Regression] |[11/12/13/14 Regression] |ICE in storage_size() with |ICE in storage_size() with |CLASS entity|CLASS entity CC||pault at gcc dot gnu.org --- Comment #15 from Paul Thomas --- Fixed on mainline. Will backport in a month. Paul
[Bug target/114993] ICE when using bpf-unknown-g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114993 --- Comment #3 from Marc Poulhiès --- The gccrs cross compiler is not working because of the missing cargo/rustc dep, disabling the frontend, so not a real issue.
