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
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107992
Bug ID: 107992
Summary: m68k-linux-gnu bootstap error in gofrontend
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: g
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107973
Bug ID: 107973
Summary: wrong warning with -Werror -fsanitize=address
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107943
Bug ID: 107943
Summary: gcc -fanalyzer hangs in openssl curve25519.c
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104710
Bug ID: 104710
Summary: Ada-Bootstrap fails with gcc-4.8.4
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
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
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103830
Bug ID: 103830
Summary: volatile optimized away
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
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
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98525
Bug ID: 98525
Summary: potential error in expand_call_inline error handling
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98467
Bug ID: 98467
Summary: gcc optimizes tapping code away
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97937
Bug ID: 97937
Summary: Line numbers are missing from duplicated function
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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 rguent...@suse.de from comment
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
> >
> > --- Comment #6 from Bernd Edl
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
> > @@ -2089,7 +2089,8 @@ set_mem_attributes_m
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
49 matches
Mail list logo
