https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075
--- Comment #4 from Richard Earnshaw ---
(In reply to Ramana Radhakrishnan from comment #3)
> Seems to have been "fixed" by the commit to fix PR87369,
>
> Richard, is this something to backport ? Prima-facie , it appears not and we
> will need a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #51 from Richard Earnshaw ---
(In reply to Segher Boessenkool from comment #50)
> The insn is
>
> (insn 7 3 8 2 (parallel [
> (set (reg:CC 100 cc)
> (compare:CC (reg:SI 0 r0 [116])
> (c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #36 from Richard Earnshaw ---
(In reply to Segher Boessenkool from comment #35)
> Peter's patch solves this particular problem, but not the PR unfortunately.
>
> I finally understand Jakub's comment 30. This patch solves the PR (als
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89146
--- Comment #2 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #1)
> I've looked for constraints that include [ijnIJKLMNO] together with [mo] and
> couldn't find any. So, not really sure what note_invalid_constants is
> suppose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90016
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90016
--- Comment #1 from Richard Earnshaw ---
Author: rearnsha
Date: Wed Apr 10 09:51:16 2019
New Revision: 270248
URL: https://gcc.gnu.org/viewcvs?rev=270248&root=gcc&view=rev
Log:
[aarch64] PR90016 - aarch64: reference to undeclared N in help for c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89794
--- Comment #6 from Richard Earnshaw ---
There seems to be more to this than initially thought. Another insn is in
play.
(insn 12 10 14 2 (set (reg:SI 129)
(bswap:SI (subreg:SI (reg:DI 127 [ i ]) 4))) "/tmp/test3.c":10:7 331
{*arm_rev}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89794
Richard Earnshaw changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89794
--- Comment #4 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #3)
> Guess with PR89475 fix this will be latent, unless one disables ccp.
> Anyway, to me this looks like a backend bug. The function is leaf, but for
> some stran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
Bug 89863 depends on bug 83033, which changed state.
Bug 83033 Summary: aarch64/cortex-a57-fma-steering.c: 3 * poor C++ style ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83033
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83033
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83033
--- Comment #4 from Richard Earnshaw ---
Author: rearnsha
Date: Mon Apr 8 12:59:24 2019
New Revision: 270207
URL: https://gcc.gnu.org/viewcvs?rev=270207&root=gcc&view=rev
Log:
The fma_forest, fma_root_node and func_fma_steering classes lack a
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #9 from Richard Earnshaw ---
(In reply to Wilco from comment #8)
> (In reply to Segher Boessenkool from comment #5)
> > The first one just needs an xfail. I don't know if it should be *-*-* there
> > or only arm*-*-* should be added.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89544
--- Comment #4 from Richard Earnshaw ---
An alternative way of fixing this might be if the backend could somehow control
DECL_ARG_TYPE for the parameter, to set it to a variant without the additional
alignment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89544
--- Comment #1 from Richard Earnshaw ---
I think things start to go wrong in assign_parm_find_data_types. That calls
promote_function_mode, but that then has no target-specific action when the
type is a RECORD_TYPE, and it never calls the back-e
: wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
CC: bernd.edlinger at hotmail dot de, ebotcazou at gcc dot
gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #13 from Richard Earnshaw ---
(In reply to Stefan Ring from comment #12)
> Unfortunately my armv5 device has died in the meantime, so I cannot verify
> my original use case. The behavior is indeed different on armv7. It does not
> tra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89101
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #11 from Richard Earnshaw ---
Author: rearnsha
Date: Fri Jan 25 17:09:33 2019
New Revision: 268273
URL: https://gcc.gnu.org/viewcvs?rev=268273&root=gcc&view=rev
Log:
This is pretty unlikely in real code, but similar to Arm, the AArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #10 from Richard Earnshaw ---
Author: rearnsha
Date: Thu Jan 24 16:10:06 2019
New Revision: 268241
URL: https://gcc.gnu.org/viewcvs?rev=268241&root=gcc&view=rev
Log:
Mitigation for PR target/88469 on arm-based systems bootstrapping w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #9 from Richard Earnshaw ---
Author: rearnsha
Date: Thu Jan 24 16:06:34 2019
New Revision: 268240
URL: https://gcc.gnu.org/viewcvs?rev=268240&root=gcc&view=rev
Log:
Mitigation for PR target/88469 on arm-based systems bootstrapping wi
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
/* ./cc1 testcase.c */
struct s
{
__int128 y : 65;
};
typedef struct s T;
T a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #28 from Richard Earnshaw ---
Yes, it's always possible to write patterns for this, but as you point out, we
end up with many variants: insert in bottom (no left shift), insert in top
(left shift then doesn't need an additional AND ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #26 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #25)
> We have BIT_INSERT_EXPR on GIMPLE, which in the end is a quarternary
> operation previous value, value to insert, bit position and bit size (the
> last one i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #24 from Richard Earnshaw ---
(In reply to Steve Ellcey from comment #21)
> Successfully matched this instruction:
> (set (zero_extract:SI (reg/i:SI 0 x0)
> (const_int 8 [0x8])
> (const_int 12 [0xc]))
> (zero_exten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #8 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Jan 22 17:56:02 2019
New Revision: 268160
URL: https://gcc.gnu.org/viewcvs?rev=268160&root=gcc&view=rev
Log:
[arm] Further fixes for PR88469
A bitfield that is exactly the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
Richard Earnshaw changed:
What|Removed |Added
Summary|[7/8/9 regression] AAPCS - |[7/8 regression] AAPCS -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #6 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Jan 22 14:03:22 2019
New Revision: 268151
URL: https://gcc.gnu.org/viewcvs?rev=268151&root=gcc&view=rev
Log:
[arm] PR target/88469 fix incorrect argument passing with 64-bit bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88799
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88799
--- Comment #3 from Richard Earnshaw ---
Author: rearnsha
Date: Fri Jan 18 13:25:37 2019
New Revision: 268077
URL: https://gcc.gnu.org/viewcvs?rev=268077&root=gcc&view=rev
Log:
[arm] PR target/88799 Add +mp and +sec extensions to ARMv7-a (gcc-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88799
--- Comment #2 from Richard Earnshaw ---
Author: rearnsha
Date: Fri Jan 18 11:49:56 2019
New Revision: 268072
URL: https://gcc.gnu.org/viewcvs?rev=268072&root=gcc&view=rev
Log:
PR target/88799 Add +mp and +sec extensions to ARMv7-a
Most armv7-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891
--- Comment #12 from Richard Earnshaw ---
Author: rearnsha
Date: Wed Jan 16 15:22:08 2019
New Revision: 267972
URL: https://gcc.gnu.org/viewcvs?rev=267972&root=gcc&view=rev
Log:
__builtin__overflow issues on AArch64 (redux) (cont)
And the Chang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891
--- Comment #11 from Richard Earnshaw ---
Author: rearnsha
Date: Wed Jan 16 15:18:05 2019
New Revision: 267971
URL: https://gcc.gnu.org/viewcvs?rev=267971&root=gcc&view=rev
Log:
__builtin__overflow issues on AArch64 (redux)
Further investigatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88799
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #5 from Richard Earnshaw ---
Also on Arm and probably other big-endian machines as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #4 from Richard Earnshaw ---
manual inspection of the output from gcc-5.4.0 suggests this version produces
correct code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #2 from Richard Earnshaw ---
> _23 = BIT_FIELD_REF <_2, 16, 0>;// WRONG: should be _2, 14, 0
_2 is declared as a 30-bit integer, so perhaps the statement is right, but
expand needs to understand that the shift extract o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891
--- Comment #8 from Richard Earnshaw ---
Author: rearnsha
Date: Mon Jan 7 14:49:00 2019
New Revision: 267650
URL: https://gcc.gnu.org/viewcvs?rev=267650&root=gcc&view=rev
Log:
Investigating PR target/86891 revealed a number of issues with the w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891
Richard Earnshaw changed:
What|Removed |Added
Assignee|wilco at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891
--- Comment #4 from Richard Earnshaw ---
Yes, the extension should be zero-extend, not sign extend. The plus operation
is correct, however, since decrementing the first operand could lead to
underflow if it was zero. So the correct rtl would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891
--- Comment #2 from Richard Earnshaw ---
The abort goes away after r266897. It might have just gone latent, however.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15482
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85396
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82162
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82034
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79784
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78932
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78233
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77662
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70223
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70030
--- Comment #9 from Richard Earnshaw ---
Did the need for this patch go away?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68494
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Richard Earns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68100
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65325
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58490
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57911
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56116
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56115
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54398
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45727
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44557
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41482
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43944
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88544
--- Comment #4 from Richard Earnshaw ---
One of these traces says 'illegal instruction' the other 'segmentation fault';
so *if* they are compiler bugs, then they are not the same.
However, this smells more like a system problem than a compiler p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88544
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #5 from Richard Earnshaw ---
Tentative patch posted here.
https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01231.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #4 from Richard Earnshaw ---
Simpler test-case.
struct x
{
long long a : 61;
};
void bar (int, struct x);
int foo (int a, int b, int c, struct x d)
{
bar (a, d);
return 2;
}
This does not seem to generate ldrd, but does show
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
Richard Earnshaw changed:
What|Removed |Added
Keywords||wrong-code
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86264
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86264
--- Comment #2 from Richard Earnshaw ---
libffi is an upstream project, so they can remove support for older
architectures on their own timescales.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87334
Richard Earnshaw changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87369
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37369
--- Comment #3 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Dec 11 11:26:15 2018
New Revision: 267019
URL: https://gcc.gnu.org/viewcvs?rev=267019&root=gcc&view=rev
Log:
[aarch64] PR target/87369 Prefer bsl/bit/bif for copysign
The copys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87369
--- Comment #2 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Dec 11 11:26:15 2018
New Revision: 267019
URL: https://gcc.gnu.org/viewcvs?rev=267019&root=gcc&view=rev
Log:
[aarch64] PR target/87369 Prefer bsl/bit/bif for copysign
The copys
at gcc dot gnu.org|rearnsha at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88224
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
--- Comment #11 from Richard Earnshaw ---
(In reply to nsz from comment #10)
> it turns out the ieee_* functions are allowed in const expressions so they
> need to work at compile time too (see bug 78449), which of course won't work
> if they nee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #6 from Richard Earnshaw ---
(In reply to Wilco from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > (In reply to Wilco from comment #3)
> > > IRA costing doesn't consider the possibility of a simple move being
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87747
--- Comment #5 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Oct 30 11:33:24 2018
New Revision: 265620
URL: https://gcc.gnu.org/viewcvs?rev=265620&root=gcc&view=rev
Log:
Don't allow the pool allocator to be configured to allocate zero-siz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87760
Richard Earnshaw changed:
What|Removed |Added
Resolution|WORKSFORME |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87760
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87747
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
CC: iii at linux dot ibm.com, rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: arm-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
--- Comment #16 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Oct 23 10:19:15 2018
New Revision: 265420
URL: https://gcc.gnu.org/viewcvs?rev=265420&root=gcc&view=rev
Log:
[arm] Update default CPUs during configure
There are a couple of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
--- Comment #15 from Richard Earnshaw ---
(In reply to coypu from comment #14)
> Also, after these two patches, my own build of arm--netbsdelf is failing
> from this:
> configure: error: Pthreads are required to build libgomp
>
> Looking at conf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87565
--- Comment #1 from Richard Earnshaw ---
Not a good idea. Modern CPUs often don't predict such operations correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
If the GCC website is viewed on a small screen device, such as a mobile phone,
then the entire page is scaled as-is until it will fit the width of the device.
This makes it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87400
--- Comment #3 from Richard Earnshaw ---
(In reply to Alex Kalmuk from comment #2)
> I write about mtpcs-frame for thumb, not mapcs-frame, I know the last one
> for arm instruction set.
The tpcs is also obsolete (the tpcs was replaced by the atp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87400
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #23 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #22)
> Or
> #pragma pack(push, 1)
>
> struct TestStructType
> {
> volatile unsigned one;
> unsigned char two;
> unsigned short three;
> } __attribute__(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #22 from Richard Earnshaw ---
Or
#pragma pack(push, 1)
struct TestStructType
{
volatile unsigned one;
unsigned char two;
unsigned short three;
} __attribute__((aligned(32)));
#pragma pack(pop)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #21 from Richard Earnshaw ---
(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 struct as
struct TestStructType
{
volatile unsigned o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #18 from Richard Earnshaw ---
BTW, are you really trying to say that your hardware has a register that isn't
naturally aligned? That's really weird if so. If not, there are much easier
ways to handle this sort of stuff.
501 - 600 of 1297 matches
Mail list logo
