https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57598
Andre Vehreschild changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700
Bug 83700 depends on bug 57598, which changed state.
Bug 57598 Summary: [Coarray,caf] Add FPE summary printing for ERROR STOP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57598
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57598
--- Comment #4 from GCC Commits ---
The master branch has been updated by Andre Vehreschild :
https://gcc.gnu.org/g:a25cc26884663244c3b936af785854abee8949dd
commit r15-6383-ga25cc26884663244c3b936af785854abee8949dd
Author: Andre Vehreschild
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118142
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118142
--- Comment #2 from zhangtianhao (F) ---
(In reply to Andrew Pinski from comment #1)
> ILP32 glibc support is NOT upstream so I am not sure this is supported
> either.
LLVM has AEK_LSE128 which the vaulue is 1ULL << 52 in
llvm/include/llvm/Supp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118147
Nathaniel Shead changed:
What|Removed |Added
Last reconfirmed||2024-12-20
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118147
Bug ID: 118147
Summary: #pragma GCC diagnostic push causes errors when used in
IILE in struct member initializer
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116401
--- Comment #1 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:71732eafedbd30355e752bf873d355fbcd0e076f
commit r15-6382-g71732eafedbd30355e752bf873d355fbcd0e076f
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116401
Nathaniel Shead changed:
What|Removed |Added
Target Milestone|--- |15.0
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 116401, which changed state.
Bug 116401 Summary: [modules] Header units can contain definitions of
non-inline decls with external linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116401
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116568
--- Comment #1 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:9016c5ac94c55714d001309ef640710f9d512254
commit r15-6378-g9016c5ac94c55714d001309ef640710f9d512254
Author: Nathaniel Shead
Date:
unk-20241218221935-r15-6361-g87f97ffba93a2d-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241219 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
Patrick O'Neill changed:
What|Removed |Added
Summary|[15 Regression] RISC-V: |[14/15 Regression] RISC-V:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
Sam James changed:
What|Removed |Added
Summary|[15 regression] recent bug |[15 regression] recent bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141
--- Comment #16 from Richard Yao ---
Thank you for taking the time to answer my questions. I have revised my
understanding of the strict aliasing rule a few times over the years. I am
hopeful that this time I finally understand it correctly. :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-12-20
Summary|[15 Regre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118145
--- Comment #3 from Andrew Pinski ---
(In reply to Richard Van Natta from comment #2)
> This regression reminded me of another quirk I noticed with gcc. I have a
> feeling they're related.
>
> https://gcc.godbolt.org/z/q1orM7KK9
>
> I think pe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141
--- Comment #15 from Andrew Pinski ---
(In reply to Richard Yao from comment #14)
> A few final questions:
>
> What is the purpose of a union type if type punning is undefined behavior in
> the standard?
To save space. To make classes like str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118145
Richard Van Natta changed:
What|Removed |Added
CC||rnvannatta at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118145
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-12-20
Summary|Regressio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141
--- Comment #14 from Richard Yao ---
A few final questions:
What is the purpose of a union type if type punning is undefined behavior in
the standard? If I specify -std=c99, should I expect type punning via union
types to break on me?
Is there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118145
Bug ID: 118145
Summary: Regression of code generation due to an overly eager
vectorization attempt
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118143
--- Comment #3 from 孙思杰 ---
sorry，i just saw your comment. just paste here as a reference.
As noted in pr98935, statement expressions are not handled (I deferred handling
them in the initial implementation since they are an extension)... howeve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141
--- Comment #13 from Andrew Pinski ---
(In reply to Richard Yao from comment #12)
> (In reply to Andrew Pinski from comment #11)
> > (In reply to Richard Yao from comment #10)
> > > I had thought the strict aliasing rule only applied within func
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141
--- Comment #12 from Richard Yao ---
(In reply to Andrew Pinski from comment #11)
> (In reply to Richard Yao from comment #10)
> > I had thought the strict aliasing rule only applied within function scope,
> > although that appears to be a misun
dbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241219 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
--- Comment #5 from Patrick O'Neill ---
That worked, re-bisecting now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116813
Sam James changed:
What|Removed |Added
Known to work||15.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141
--- Comment #11 from Andrew Pinski ---
(In reply to Richard Yao from comment #10)
> I had thought the strict aliasing rule only applied within function scope,
> although that appears to be a misunderstanding upon checking this:
>
> https://gist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118123
--- Comment #1 from Mark Harmstone ---
Sorry about this, I've submitted a patch to fix it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118143
--- Comment #2 from 孙思杰 ---
is there any fix plan?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141
--- Comment #10 from Richard Yao ---
I had thought the strict aliasing rule only applied within function scope,
although that appears to be a misunderstanding upon checking this:
https://gist.github.com/shafik/848ae25ee209f698763cffee272a58f8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102508
Andrew Pinski changed:
What|Removed |Added
CC||sunsijie at buaa dot edu.cn
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118143
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118143
Bug ID: 118143
Summary: coroutines: co_await & co_return in ({ ... }) syntax
cause ICE, internal compiler error: in gimplify_expr
Product: gcc
Version: 14.2.1
Status: UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118142
Andrew Pinski changed:
What|Removed |Added
Keywords||build
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141
--- Comment #9 from Andrew Pinski ---
So GCC knows that convert_fp32_to_bfloat16 just reads via `unsigned int` so it
does not store the input array because it is stored as `float`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118112
--- Comment #12 from Sam James ---
(In reply to David Malcolm from comment #11)
> UX patch posted here for review:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672076.html
Thanks Dave, I'll kick the tyres on it for a few days and s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141
--- Comment #8 from Andrew Pinski ---
for (int i = 0; i < 8; i++) {
input_vec[i] = std::bit_cast(((float*) input)[i]);
}
Is how to handle it for C++20.
for (int i = 0; i < 8; i++) {
memcpy(&input_vec[i], &((unsign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
--- Comment #4 from Andrew Pinski ---
Try this:
d |= ({
int h = f[g - 1] ? 2 : 0;
#if 0
int i = f[g - 1] ? f_3 : 0;
#else
_Bool t;
if (f[g - 1])
t = f_3;
else
t = 0;
//_Bool t = (f[g - 1] & f_3);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #6 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141
--- Comment #4 from Richard Yao ---
(In reply to Richard Yao from comment #1)
> As an additional comment, while Clang does a good job on this function, it
> could do better. In specific, this uses 1 less instruction:
>
> convert_fp32_to_bfloat1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141
Sam James changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141
Richard Yao changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118142
Bug ID: 118142
Summary: libatomic fails to build for AARCH64:ILP32
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118138
Sam James changed:
What|Removed |Added
Keywords|needs-bisection |
Summary|[15 Regression] wrong c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141
--- Comment #1 from Richard Yao ---
As an additional comment, while Clang does a good job on this function, it
could do better. In specific, this uses 1 less instruction:
convert_fp32_to_bfloat16:
vmovups (%rdi), %ymm0
vpsrld $
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
Sam James changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141
Bug ID: 118141
Summary: GCC miscompiles __builtin_convertvector() narrowing
operation on amd64 above -O1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
--- Comment #3 from Patrick O'Neill ---
(In reply to Andrew Pinski from comment #2)
> I suspect if you rewrite it to be:
> int h = f[g - 1] ? 2 : 0;
> int i = f[g - 1] ? f_3 : 0;
>
> d = d || h > i;
> You run into the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
--- Comment #2 from Andrew Pinski ---
I suspect if you rewrite it to be:
int h = f[g - 1] ? 2 : 0;
int i = f[g - 1] ? f_3 : 0;
d = d || h > i;
You run into the same issue and my patch won't show up in the bisect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |target
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
Bug ID: 118140
Summary: [15 Regression] RISC-V: Miscompile with
-march=rv64gcv_zvl256b -O3 since r15-3992-g698e0ec89bc
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117023
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118112
David Malcolm changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118139
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118139
--- Comment #2 from Marek Polacek ---
pp_cxx_nested_name_specifier shouldn't be calling pp_cxx_unqualified_id for
DECLTYPE_TYPE; it should handle a computed-type-specifier specifically.
With the following patch we print
118139.C:6:15: error: ‘
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118139
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118139
Bug ID: 118139
Summary: Broken diagnostic: 'decltype_type' not supported by
pp_cxx_unqualified_id
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113928
--- Comment #3 from anlauf at gcc dot gnu.org ---
This bug seems to get fixed by the patch in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118120#c12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118120
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118078
--- Comment #3 from Simon Martin ---
Thanks for the report. I'm currently testing a patch that leverages
TYPE_BEING_DEFINED instead or looking at current_class_type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118138
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-12-19
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #23 from Mark Wielaard ---
Created attachment 59930
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59930&action=edit
preprocessed -E output of generated insn-attrtab.cc
Note that the generated insn-attrtab.cc file is 10M.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118120
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #10)
>> > It is completely irrelevant that "result" is a dummy. Just try it.
> > And creating a temporary for *every lhs pointer* cannot be acceptable.
> > There
le-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241219 (experimental) (GCC)
[574] %
[574] % gcctk -O3 small.c; ./a.ou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118120
--- Comment #10 from kargls at comcast dot net ---
(In reply to anlauf from comment #9)
> (In reply to kargls from comment #8)
> > (In reply to anlauf from comment #7)
> > > The following patch works and might be a reasonable compromise:
> > >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117830
--- Comment #6 from Christoph Müllner ---
Patch on list:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672065.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118120
--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #8)
> (In reply to anlauf from comment #7)
> > The following patch works and might be a reasonable compromise:
> >
> > diff --git a/gcc/fortran/trans-array.cc b/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118078
Simon Martin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118120
--- Comment #8 from kargls at comcast dot net ---
(In reply to anlauf from comment #7)
> The following patch works and might be a reasonable compromise:
>
> diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
> index 82a2ae1f747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116347
Christoph Müllner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |cmuellner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118120
--- Comment #7 from anlauf at gcc dot gnu.org ---
The following patch works and might be a reasonable compromise:
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 82a2ae1f747..985a26281ad 100644
--- a/gcc/fortran/trans-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113683
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #22 from Sam James ---
(In reply to Mark Wielaard from comment #21)
Mark, could you upload preprocessed source for insn-attrtab.cc? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117725
--- Comment #11 from Matthias Klose ---
yes, that patch works for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113683
--- Comment #3 from S Béla ---
MSVC fixed the bug
(https://developercommunity.visualstudio.com/t/explicit-template-instantiation-wrongly/10576924?scope=follow),
so 3/4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118136
--- Comment #10 from Andrew Pinski ---
(In reply to Torbjorn SVENSSON from comment #9)
> Lets consider that my vendor provided toolchain comes with newlib compiled
> with -flto -ffat-lto-objects (and that the function calling main is written
> i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117937
Marek Polacek changed:
What|Removed |Added
CC||iamanonymous.cs at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117937
--- Comment #7 from Marek Polacek ---
Another test:
```
void operate_one(const int) {}
template
void operate_multi(T... args)
{
[&]()
{
::operate_one(args...[idx]);
}.template operator()<0>();
}
int main()
{
::operate_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118056
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
multilib
--enable-libsanitizer --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-20241218221935-r15-6361-g87f97ffba93a2d-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241219 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118136
--- Comment #9 from Torbjorn SVENSSON ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Torbjorn SVENSSON from comment #7)
> > So, if I understand you correctly Andrew, it's impossible to write the start
> > code in C for a free-sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118120
--- Comment #6 from kargls at comcast dot net ---
(In reply to Slava Zakharin from comment #5)
> Right, this test deliberately introduces the aliasing to demonstrate that
> gfortran has too optimistic assumptions about aliasing of COMPLEX and REA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118133
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
--- Comment #18 from Sam James ---
I don't think it makes sense to be using -w when reducing, even if I agree that
the -w behaviour is irritating.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118136
--- Comment #3 from Andrew Pinski ---
>+__attribute__((naked)) void custom_start() {
calls
This is not defined code as naked is only to be used with one inline-asm
without any calls.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
--- Comment #17 from David Binderman ---
(In reply to Xi Ruoyao from comment #12)
> AFAIK -w suppresses -Werror=uninitialized.
-w also appears to switch off -Werror=overflow.
This makes csmith a lot less useful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57272
--- Comment #11 from GCC Commits ---
The master branch has been updated by Francois Dumont :
https://gcc.gnu.org/g:23df3c3a4aa33a08e82ac8b98d7ff6e7f1b65b63
commit r15-6376-g23df3c3a4aa33a08e82ac8b98d7ff6e7f1b65b63
Author: François Dumont
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118136
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118133
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118136
--- Comment #8 from Andrew Pinski ---
(In reply to Torbjorn SVENSSON from comment #7)
> So, if I understand you correctly Andrew, it's impossible to write the start
> code in C for a free-standing application and build it with -flto into a
> lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118136
--- Comment #7 from Torbjorn SVENSSON ---
So, if I understand you correctly Andrew, it's impossible to write the start
code in C for a free-standing application and build it with -flto into a
library and then reuse that?
I.e. think of the case w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118136
--- Comment #6 from Andrew Pinski ---
So in summary the following is the point.
If you are defining your custom start function, it becomes a non-hosted env
and/or implemented defined area. This means it can't be LTO'ed since it can't
constraine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118136
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> >+__attribute__((naked)) void custom_start() {
> calls
>
> This is not defined code as naked is only to be used with one inline-asm
> without any calls.
Plus N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118136
--- Comment #2 from Andrew Pinski ---
Calling main is undefined in C++; I don't remember if it is valid in free
standing though.
I am not sure if it is well defined in C though.
Obvious workaround is not to have _start as LTO code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118120
--- Comment #5 from Slava Zakharin ---
Right, this test deliberately introduces the aliasing to demonstrate that
gfortran has too optimistic assumptions about aliasing of COMPLEX and REAL
pointers.
Thank you for the pointer to trans-array.cc! M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118136
--- Comment #1 from Torbjorn SVENSSON ---
Created attachment 59928
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59928&action=edit
Test case to reproduce
1 - 100 of 191 matches
Mail list logo
