: 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
libtool
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
: 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
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:
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=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
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
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/bugzilla/show_bug.cgi?id=101598
--- Comment #7 from Bernd Edlinger ---
Created attachment 51202
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51202=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
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
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
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
@@
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
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
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
>
: 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
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
>
>
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
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
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
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
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.
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
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
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=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()':
crash
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 |
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
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()
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=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
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
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
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=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,
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109
--- Comment #13 from Bernd Edlinger ---
Created attachment 46704
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46704=edit
another untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
--- Comment #29 from Bernd Edlinger ---
Hm, the target milestone is wrong. I believe this was fixed in gcc-9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109
--- Comment #11 from Bernd Edlinger ---
No, it needs to be back-ported to gcc-9.3 (i am still reg-testing)
and Vladimir Makarov wrote the following:
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00463.html
> Still I think more work on the PR is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109
--- Comment #8 from Bernd Edlinger ---
Patch is posted here: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00305.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109
--- Comment #7 from Bernd Edlinger ---
I can reproduce this defect with gcc-9 (!)
$ ../gcc-9-branch/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-linux64-1
--target=arm-linux-gnueabihf --enable-languages=c,c++ --with-arch=armv7-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109
--- Comment #6 from Bernd Edlinger ---
with this patch the relevant part if the reload dump file looks different:
(insn 3414 6591 6682 129 (set (mem/c:SI (reg/f:SI 5 r5 [5715]) [1
s.5566D.5531+0 S4 A32])
(reg:SI 6 r6 [orig:828 _821 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109
--- Comment #5 from Bernd Edlinger ---
Created attachment 46654
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46654=edit
untested patch
It looks like update_scratch_ops creates a copy of the original scratch
register, but the new scratch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Bernd Edlinger changed:
What|Removed |Added
Attachment #46200|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #73 from Bernd Edlinger ---
Okay, the requirement is only to be able to boot-strap with
a released gcc version, so gcc-8 should not use the pragma,
while gcc-9 should use the pagma.
I was able to bootstrap from x86_64 -> arm cross ->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #72 from Bernd Edlinger ---
I use host Compiler from last week:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/ed/gnu/arm-linux-gnueabihf/libexec/gcc/armv7l-unknown-linux-gnueabihf/9.0.1/lto-wrapper
Target:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #71 from Bernd Edlinger ---
I am sorry, but my native arm bootstrap Fails:
g++ -std=gnu++98 -fno-PIE -c -I../../gcc-trunk-r270444/gcc/../libgcc
-DEH_MECHANISM_arm -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions -fno-rtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #70 from Bernd Edlinger ---
Yes, thanks, now switching to your latest patch.
1 - 100 of 947 matches
Mail list logo
