https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91297
Murat Ursavaş changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: murat.ursavas at gmail dot com
Target Milestone: ---
Hello,
I'm not sure I can label this issue as a bug. Let me share my findings and let
you decide what it is.
The library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
Murat Ursavaş changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #33 from Murat Ursavaş ---
One thing though. Would you accept this a regression and get back to 4.9 style?
Yes, GCC is doing everything by the book but the result is not perfect (due to
other undocumented issues not related to GNU te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
Murat Ursavaş changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #31 from Murat Ursavaş ---
(In reply to Murat Ursavaş from comment #28)
>
> Here's the disassembly of a problematic part:
>
> 4.9.3
>
> 121 NVM_SPI->ROUTE = USART_ROUTE_TXPEN | USART_ROUTE_RXPEN |
> USART_ROUTE_CLKPEN | N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #30 from Murat Ursavaş ---
OK, looks like it is possible like this:
ldr r2, =0x000b
Source:
https://stackoverflow.com/questions/38689886/loading-32-bit-values-to-a-register-in-arm-assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #29 from Murat Ursavaş ---
And just out of curiosity, why the compiler loads zero to the register and then
OR's with the value?
00029e3c: movsr2,#0x0
00029e3e: orr r2,r2,#0xb
Why doesn't it load directly the necessary v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
Murat Ursavaş changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #26 from Murat Ursavaş ---
(In reply to Richard Earnshaw from comment #21)
> (In reply to Murat Ursavaş from comment #20)
> > By the way, the hardware peripheral registers are aligned to 32bits.
>
> So why don't you define your struc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #25 from Murat Ursavaş ---
(In reply to Eric Gallager from comment #24)
> (In reply to Murat Ursavaş from comment #6)
> > Hi Jonathan,
> >
> > I just wanted a dramatic entrance :) (There was a discussion about GCC
> > bugzilla on red
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #20 from Murat Ursavaş ---
By the way, the hardware peripheral registers are aligned to 32bits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #19 from Murat Ursavaş ---
Hi Richard,
This source code had been designed to see word by word access and may create
expected results. I'm not sure about that.
Let me use latest stable and see what happens. It wasn't plug and play la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #16 from Murat Ursavaş ---
OK I understand conservative action and not wait for word by word access. But
the resulting value is not 0x401 on the test case, but it should be.
In my original case this was effecting a USART peripheral r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #13 from Murat Ursavaş ---
Richard,
Also as far as I remember GNU manual was indeed saying something on this case.
It was saying that "if the struct is not packed, it would access to members
word by word. But if unaligned access is d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #12 from Murat Ursavaş ---
Richard,
Ok I remembered things with reading the old posts on launchpad. The compiler
was generating normal code if I use the struct variable directly. But if I use
a pointer to access it, it assigns not wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #11 from Murat Ursavaş ---
Richard,
I don't know about the standards as you are and please accept me as a newbie.
The peripheral parameters of the manufacturer library are all defined as
volatile structs and accessed with pointers. T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #10 from Murat Ursavaş ---
Jonathan,
I don't blame any of you and very well aware of the volunteering effort. Please
don't get me wrong. It's just me attempted multiple times to open the case but
get distracted with something else.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #9 from Murat Ursavaş ---
Umesh,
The reason is step-by-step debugging. I'd like to debug it first with -O0, than
pack it with -Os for the release. Otherwise with a low resource MCU, things
become messy really fast.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #6 from Murat Ursavaş ---
Hi Jonathan,
I just wanted a dramatic entrance :) (There was a discussion about GCC bugzilla
on reddit recently) Of course it hasn't took that long. But this is like
missing a call. You would answer that at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #2 from Murat Ursavaş ---
Hi Umesh,
Could you test it with the following options:
-g3 -gdwarf-2 -mcpu=cortex-m3 -mthumb -std=c++1y '-DDEBUG=1' -O0 -pedantic
-Wall -Wextra -c -fmessage-length=0 -fno-rtti -fno-exceptions -mno-sched-pr
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: murat.ursavas at gmail dot com
Target Milestone: ---
Created attachment 44731
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44731&acti
22 matches
Mail list logo
