https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118908
--- Comment #2 from Bernd Edlinger ---
(In reply to Richard Biener from comment #1)
> I'd say it's a feature, not a bug?
Yeah, kind of, just why does the outcome depend
on those completely unrelated compiler options?
Is this "feature" somehow b
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
previously uintptr_t was always defined after #include
but gcc-15 does this only in an unpredictable way, consider this
example:
$ cat test.cc
#include
uintptr_t x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116470
--- Comment #14 from Bernd Edlinger ---
Hmm, I don't know why I can't change the status to fixed...
Feel free to close this ticket.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116470
--- Comment #11 from Bernd Edlinger ---
Created attachment 58991
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58991&action=edit
proposed patch
I would appreciate when you could check if this patch fixes the problem.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116470
--- Comment #10 from Bernd Edlinger ---
And the other issue could be this:
@@ -28976,7 +28982,7 @@ dwarf2out_set_ignored_loc (unsigned int line, unsigned
int column,
dw_fde_ref fde = cfun->fde;
fde->ignored_debug = false;
- set_cur_line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116470
--- Comment #9 from Bernd Edlinger ---
Thanks Jeff for this advice,
It could be that this are two different issues, but
The ft32-issue might be solved by this completely untested patch:
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -13019,9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116470
--- Comment #5 from Bernd Edlinger ---
but one thing is funnny, in the bad asm
both symbols.LM19367 and .LM19368 appear to be in the same section:
.section.text.unlikely
.align 2
.LCOLDB277:
.text
.LHOTB277:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116470
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116462
--- Comment #4 from Bernd Edlinger ---
The DW_AT_ranges indicates that the subroutine is split over
more than one area, in most cases both subroutines do have
multiple subranges, but apparently due to slightly different
optimization levels only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116462
--- Comment #2 from Bernd Edlinger ---
no forget it, this might make arm unhappy...
lets try this instead:
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
@@ -1,9 +1,9 @@
-/* Verify that both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116462
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87440
--- Comment #6 from Bernd Edlinger ---
patch is posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660611.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87440
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
: go
Assignee: ian at airs dot com
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Hi, I don't know if that is expected,
but I got a boot-strap error with r13-4502-ga0ee2e52252
.../configure --target=m68k-linux-gnu --prefix=... --enable-languages=all
li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107973
--- Comment #2 from Bernd Edlinger ---
Thanks,
I see a very similar warning with
m68k-linux-gnu-gcc but without sanitizer:
crypto/modes/cfb128.c: In function 'CRYPTO_cfb128_encrypt':
crypto/modes/cfb128.c:117:33: error: writing 1 byte into a r
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
when compiling openssl-1.1.1s with the following workflow:
$ wget https://www.openssl.org/source/openssl-1.1.1s.tar.gz
$ tar xf openssl-1.1.1s.tar.gz
$ cd openssl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107943
--- Comment #6 from Bernd Edlinger ---
I don't know if that is relevant or not,
but I was using a slighthly different criterion in bisection.
I used .../configure --prefix=... --enable-languages=all
and defined the bad criterion using the unredu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107943
--- Comment #3 from Bernd Edlinger ---
this is how far I got with bisecting:
$ git bisect log
git bisect start
# good: [885f5c3d5763d46e02bd2f192765cb589b4c4fe4] Daily bump.
git bisect good 885f5c3d5763d46e02bd2f192765cb589b4c4fe4
# bad: [24b8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107943
--- Comment #2 from Bernd Edlinger ---
Created attachment 53998
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53998&action=edit
preprocessed source file
: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
I see a reproducible endless loop in analyzing openssl-1.1.1s
gcc -I. -Iinclude -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -fanalyzer
-DOPENSSL_USE_NODELETE
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Configured as ususal with
.../configure --prefix=/home/ed/gnu/install --enable-languages=all
make fails in stage1:
gcc -std=gnu99 -c -g -gnatpg -gnatwns -gnata -W -Wall -I- -I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103830
Bernd Edlinger changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #9 from Bernd Edling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #15 from Bernd Edlinger ---
While there are certainly empty subranges that could be avoided,
there are also completely empty subroutines, which cannot be
avoided without losing the ability to inspect the procedure
variable at this loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #14 from Bernd Edlinger ---
(In reply to Andrew Burgess from comment #0)
> + This bug report has a bit of history. Originally there was a GCC
> patch here:
>https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html
>
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
the following test case is intentionally writing at address 0,
it is IMHO invalid to optimize it away (at -Og):
$ cat empty-inline.cc
/* This testcase is part of GDB, the GNU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101598
--- Comment #8 from Bernd Edlinger ---
patch was posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576027.html
review here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576520.html
and here:
https://gcc.gnu.org/pipermail/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101598
--- Comment #7 from Bernd Edlinger ---
Created attachment 51202
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51202&action=edit
Proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101575
--- Comment #12 from Bernd Edlinger ---
(In reply to Eric Botcazou from comment #1)
> Not going to be fixed, just stick to the default setting (DWARF 5).
one minor remark, while working on a patch, I became aware,
that probably the same will ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101575
--- Comment #11 from Bernd Edlinger ---
(In reply to Eric Botcazou from comment #10)
> > I can of course make the .loc go away. If you really want that.
> >
> > It is basically the DECL_SOURCE_LOCATION of an
> > otherwise ignored decl. If the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101598
--- Comment #6 from Bernd Edlinger ---
(In reply to Tom de Vries from comment #4)
> (In reply to Bernd Edlinger from comment #2)
> > Yes, but it wont fix dwarf-4 and also not the case
> > when this is not the first function. then we'll
> > have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101598
--- Comment #5 from Bernd Edlinger ---
I will have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101598
--- Comment #2 from Bernd Edlinger ---
Yes, but it wont fix dwarf-4 and also not the case
when this is not the first function. then we'll
have the .loc from the previous function extend to this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101575
--- Comment #8 from Bernd Edlinger ---
I can of course make the .loc go away. If you really want that.
It is basically the DECL_SOURCE_LOCATION of an
otherwise ignored decl. If the DECL_SOURCE_LOCATION
is UNKNOWN_LOCATION the function should h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101575
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100655
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
--- Comment #21 from Bernd Edlinger ---
Hi Srinath,
when we add new assertions to gcc we use always a gcc_checking_assert
nowadays, that is also the case here.
The assertion is only firing in your compiler because it is a development
snapshot 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100106
--- Comment #3 from Bernd Edlinger ---
Yes, indeed something like the following seems to fix the issue:
diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index d13c390..56271e9 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -721
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99446
--- Comment #13 from Bernd Edlinger ---
Hi Nathan,
I've been playing with a variant of c-c++-common/raw-string-6.c
with your patch:
$ cat raw-string-6.c
$ cat raw-string-6.c
// { dg-do compile }
// { dg-options "-std=gnu99" { target c } }
// {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99446
--- Comment #9 from Bernd Edlinger ---
The last token is a CPP_PRAGMA_EOL, and has a line number 2,
while the include file has only one line, so it is similar to an EOL position.
I guess therefore this fails to add a column?
1002 location_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99446
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
The error handling in the following if-statement is possibly broken
tree-inline.c:
/* If callee is thunk, all we need is to adjust the THIS pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98467
--- Comment #2 from Bernd Edlinger ---
I debugged a bit in when we decide this function is const.
That appears to be in gcc/ipa-fnsummary.c:
/* Return true if T is a pointer pointing to memory location that is local
for the function (that mea
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Consider this test case:
$ cat test.cc
struct MyClass;
struct ptr {
MyClass* get() { return t; }
MyClass* t;
};
struct MyClass { void call(); };
void MyClass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
--- Comment #16 from Bernd Edlinger ---
(In reply to SRINATH PARVATHANENI from comment #15)
> (In reply to Bernd Edlinger from comment #14)
> > fixed on trunk.
>
> Thanks Bernd for fixing this on trunk, would you mind backporting this to
> GCC-1
: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Consider this test case:
$ cat test.c
int test(void)
{
return 0;
}
int test1(void)
{
return 0;
}
struct s {
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
--- Comment #12 from Bernd Edlinger ---
(In reply to Bernd Edlinger from comment #11)
> (In reply to rguent...@suse.de from comment #10)
> >
> > I failed to track down where we'd expand this to a possibly
> > unaligned mem - but is this just bog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
--- Comment #11 from Bernd Edlinger ---
(In reply to rguent...@suse.de from comment #10)
> On Wed, 28 Oct 2020, bernd.edlinger at hotmail dot de wrote:
>
> > --- Comment #9 from Bernd Edlinger ---
> > (In reply to rgue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
--- Comment #9 from Bernd Edlinger ---
(In reply to rguent...@suse.de from comment #7)
> On Wed, 28 Oct 2020, bernd.edlinger at hotmail dot de wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
> >
> > -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
--- Comment #6 from Bernd Edlinger ---
(In reply to rguent...@suse.de from comment #3)
> On Tue, 27 Oct 2020, bernd.edlinger at hotmail dot de wrote:
> > --- a/gcc/emit-rtl.c
> > +++ b/gcc/emit-rtl.c
> &g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
--- Comment #5 from Bernd Edlinger ---
(In reply to SRINATH PARVATHANENI from comment #4)
> With the above patch I'm getting ICE as below while building arm-none-eabi
> target:
>
> checking for scalbnl... during RTL pass: expand
>
> generice_bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
--- Comment #2 from Bernd Edlinger ---
Thanks for reporting this.
The expansion of assignments to misaligned ssa names
does not handle the case of misaligned stores, which
would result in incorrect code without the assertion.
I have an untested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #13 from Bernd Edlinger ---
Hi Andrew,
You are right about the instruction re-ordering, that is done in
a compiler pass, which simply re-orders RTL instruction lists.
But I think when the code motion happens, we just
have no easy acc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #11 from Bernd Edlinger ---
Andrew,
(In reply to Andrew Burgess from comment #10)
> Further, I've seen no mention of exit views anywhere, and I think they
> would also be needed.
>
Yes, that is also my idea, when I say the dwarf2 s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #9 from Bernd Edlinger ---
Andrew,
please update the reproducer, and explain in more detail
what you would like to be changed.
I still do not understand your idea.
But I try hard to do so.
Please be patient with me.
Bernd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #7 from Bernd Edlinger ---
> I don't understand why each range wouldn't need its own view number?
Each of the sub ranges end PC can be an exit point.
At least how I see it.
Please have a look at my patch.
It adds each of the ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #6 from Bernd Edlinger ---
Right,
#+BEGIN_EXAMPLE
0030 00400545 00400545 (start == end)
0030 00400549 00400553
0030 00400430 00400435
0030
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #4 from Bernd Edlinger ---
Can you please approve my patch now?
https://sourceware.org/pipermail/gdb-patches/2020-April/167385.html
Thanks
Bernd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #3 from Bernd Edlinger ---
(In reply to Andrew Burgess from comment #2)
> Sorry for including the wrong DWARF dump output in the bug report. I too
> had seen the DW_AT_GNU_entry_view using a more recent binutils.
>
NP.
> When you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #1 from Bernd Edlinger ---
Hi,
I use a newer binutils versions FWIW, and buit GCC-10 from
a few days ago using those binutils.
$ readelf -version
GNU readelf (GNU Binutils) 2.32
Copyright (C) 2019 Free Software Foundation, Inc.
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91614
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94029
--- Comment #19 from Bernd Edlinger ---
Okay, forget my previous comment,
I overlooked that you say the .c.gcov is missing...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94029
--- Comment #16 from Bernd Edlinger ---
Sandra,
I am pretty sure it should exist,
can you check which git revision you are looking at?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94029
--- Comment #6 from Bernd Edlinger ---
openssl workaround is here:
https://github.com/openssl/openssl/pull/11246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94029
--- Comment #4 from Bernd Edlinger ---
Martin, in the gcc-8 branch
is the gcov working, or has it the
same issue as bug#88045 ?
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
CC: marxin at gcc dot gnu.org
Target Milestone: ---
This causes a crash in gcc:
$ cat test.c
#define impl_test(name) void test_##name() { }
impl_test(t1
) impl_test(t2)
$ gcc -ftest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548
Bernd Edlinger changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548
--- Comment #3 from Bernd Edlinger ---
Ah, thanks I will do that.
Apparently the git conversion is to blame :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548
--- Comment #1 from Bernd Edlinger ---
git Revision c3ccce5b47f85d70127f5bb894bc5e83f8d2510e
If absolutely necessary that should only be done in maintainer mode.
: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
I build gcc with read only source tree,
this worked all the time, but now it does no longer:
../gcc-trunk-0/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92024
--- Comment #7 from Bernd Edlinger ---
Yes, I guess so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #34 from Bernd Edlinger ---
(In reply to fdlbxtqi from comment #33)
> Created attachment 47574 [details]
> copy_backward bug fixed for the last patch
>
> going to further run testsuite
Your test does not contain any test cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #31 from Bernd Edlinger ---
Yes, you usually need to make a full bootstrap / make check twice
which the same svn revision one with and one without your patch.
You also should make sure that the test case actually is able to fail
befor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91615
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92024
--- Comment #5 from Bernd Edlinger ---
(In reply to Arseny Solokha from comment #4)
> Is there a backport pending? I cannot reproduce this ICE on release branches.
Hmm, interesting, I would have expected this to ICE.
However this patch is not c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92365
--- Comment #4 from Bernd Edlinger ---
Created attachment 47180
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47180&action=edit
possible fix
This seems to fix the issue,
although a fix in cxx_eval_constant_expression
might be preferrable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92024
--- Comment #2 from Bernd Edlinger ---
there is alos a valid test case where an ICE happens:
template
struct S {
S () {
struct c;
{
struct c {};
}
}
};
S s;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92024
--- Comment #1 from Bernd Edlinger ---
This seems to fix the ICE:
Index: pt.c
===
--- pt.c(revision 276634)
+++ pt.c(working copy)
@@ -10973,6 +10973,9 @@
||
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
g++ crashes on testsuite/g++.dg/parse/crash68.C
when invoked with -Wshadow=compatible-local
$ g++ -Wshadow=compatible-local crash68.C
crash68.C: In constructor 'a< >::a()&#x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91716
--- Comment #7 from Bernd Edlinger ---
Hmm, I tried it out and built gcc-9.2.0 out of the release tar ball,
with no checking flag
and, actually the test case still ICEs, just in a different
place:
$ gfortran -c z1.f90
z1.f90:5:0:
5 | en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91716
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
While playing with -Wshadow I saw a wrong location info creating a confusing
warning (but I think other warnings have similar issues):
$ cat test.cc
enum x {a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91803
--- Comment #2 from Bernd Edlinger ---
(In reply to Marek Polacek from comment #1)
> I do not think that is a bug in the compiler; after all, the error message
> says that is not valid.
Yes, usually that would not make sense, but __typeof() alon
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
I wanted to use something like __typeof(ORIGINAL_REGNO(rtl)) in a template
argument, but it does not work, I wonder if that is a bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #12 from Bernd Edlinger ---
Created attachment 46863
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46863&action=edit
untested patch
That was easy :-)
I have been there before...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #10 from Bernd Edlinger ---
$ grep -A4 -r "insn 234 .*:SI 340" real.c.*|less
real.c.237r.subreg1:(insn 234 233 235 11 (set (reg:SI 340)
real.c.237r.subreg1-(mem:SI (reg/v/f:SI 273 [ rD.73757 ]) [52 MEM
[(struct real_valueD.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #9 from Bernd Edlinger ---
I see this instruction is responsible (in function real_nextafter
first in real.c.239r.cse1:
(insn 234 198 205 11 (set (reg:SI 340 [ MEM [(struct
real_valueD.28367 *)r_77(D)] ])
(mem:SI (plus:SI (r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91684
--- Comment #7 from Bernd Edlinger ---
probably fixed by r275489
It was not intended to run this test on cortex-a9,
but I used the wrong effective-target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #7 from Bernd Edlinger ---
without looking in detail, this could
be another middle-end error or the back-end
generating an invalid instruction where no assertions
are, then lra can rewrite the insn in a way that
triggers the assertion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #6 from Bernd Edlinger ---
(In reply to Wilco from comment #5)
> (In reply to Christophe Lyon from comment #4)
> > (In reply to Bernd Edlinger from comment #3)
> > > I will try to reproduce with building of a cross for this target.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #3 from Bernd Edlinger ---
I will try to reproduce with building of a cross for this target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #1 from Bernd Edlinger ---
Oh, nice, could you say what config options you use?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91684
--- Comment #1 from Bernd Edlinger ---
Created attachment 46846
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46846&action=edit
untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91603
--- Comment #3 from Bernd Edlinger ---
Okay, Thanks!
Looks like these neon instructions don't work at all in big-endian.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91612
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Currently this ICEs due to the middle-end sanitization:
$ cat test.c
typedef __simd64_int32_t int32x2_t;
typedef __attribute__((aligned (1))) int32x2_t unalignedvec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89544
--- Comment #7 from Bernd Edlinger ---
However while writing the patch "Sanitizing the middle-end interface
to the back-end for strict alignment":
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01130.html
I discovered another wrong code bug, this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89544
--- Comment #6 from Bernd Edlinger ---
This is half fixed now:
Since r274531 the original test case no longer generates wrong code,
but only slightly non-optimal code.
I had so far two test cases:
$ cat unaligned-argument-1.c
/* { dg-do compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109
--- Comment #19 from Bernd Edlinger ---
Hope all is now working again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109
--- Comment #14 from Bernd Edlinger ---
I can reproduce with trunk:
arm-linux-gnueabihf-gcc -S -O2 -mthumb -flto -fno-use-linker-plugin
20040709-1.c
but not with -O3 -g, neither with gcc-9 and my fix applied.
Nevertheless it is quite obvious th
1 - 100 of 960 matches
Mail list logo
