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
: 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
>
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=gcc=rev
Log:
This is pretty unlikely in real code, but similar to Arm, the AArch64
ABI
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=gcc=rev
Log:
Mitigation for PR target/88469 on arm-based systems bootstrapping with
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=gcc=rev
Log:
Mitigation for PR target/88469 on arm-based systems bootstrapping with
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
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
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
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]))
>
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=gcc=rev
Log:
[arm] Further fixes for PR88469
A bitfield that is exactly the same size as
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=gcc=rev
Log:
[arm] PR target/88469 fix incorrect argument passing with 64-bit bitfields
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=gcc=rev
Log:
[arm] PR target/88799 Add +mp and +sec extensions to ARMv7-a (gcc-8 backport)
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=gcc=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=gcc=rev
Log:
__builtin__overflow issues on AArch64 (redux) (cont)
And the ChangeLog for
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=gcc=rev
Log:
__builtin__overflow issues on AArch64 (redux)
Further investigation showed
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
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=gcc=rev
Log:
Investigating PR target/86891 revealed a number of issues with the way
the
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
Richard Earnshaw changed:
What|Removed |Added
Keywords||wrong-code
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=gcc=rev
Log:
[aarch64] PR target/87369 Prefer bsl/bit/bif for copysign
The copysign
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=gcc=rev
Log:
[aarch64] PR target/87369 Prefer bsl/bit/bif for copysign
The copysign
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
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=gcc=rev
Log:
Don't allow the pool allocator to be configured to allocate zero-sized
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=gcc=rev
Log:
[arm] Update default CPUs during configure
There are a couple of places in
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
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
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
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;
> }
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #17 from Richard Earnshaw ---
(In reply to Murat Ursavaş from comment #16)
> 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.
Is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #15 from Richard Earnshaw ---
(In reply to Murat Ursavaş from comment #12)
> Richard,
>
> Ok I remembered things with reading the old posts on launchpad. The compiler
> was generating normal code if I use the struct variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #14 from Richard Earnshaw ---
(In reply to Murat Ursavaş from comment #13)
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #7 from Richard Earnshaw ---
(In reply to Murat Ursavaş from comment #6)
> 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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #5 from Richard Earnshaw ---
It's not clear what behaviour you think is 'proper' for a packed struct with a
volatile member. Since packed is a GNU extension, there's nothing in the C (or
C++) standards that you can call upon to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87302
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66203
--- Comment #4 from Richard Earnshaw ---
The Arm builds that do not need anything from libgloss (and thus do not need a
specs file) while linking come from a configuration that hard codes the
underlying runtime monitor (usually the arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853
--- Comment #27 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #26)
> A test generator for x % c1 == c2 expansion for unsigned, int, unsigned long
> long, long long, unsigned int128 and int128 types (assuming ilp32 or lp64)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86951
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772
Bug 86772 depends on bug 86951, which changed state.
Bug 86951 Summary: arm speculation barrier incompatible with ARMv6 or earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86951
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86951
--- Comment #1 from Richard Earnshaw ---
Author: rearnsha
Date: Thu Aug 23 09:47:34 2018
New Revision: 263806
URL: https://gcc.gnu.org/viewcvs?rev=263806=gcc=rev
Log:
PR target/86951 arm - Handle speculation barriers on pre-armv7 CPUs
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87049
--- Comment #2 from Richard Earnshaw ---
But won't that give problems for C++ because now you'll need to cast the
pointers?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86777
--- Comment #2 from Richard Earnshaw ---
I don't think you could do that through the API provided by this patch set; but
it's not really appropriate for this case.
I'm not familiar with the bfin architecture so cannot comment on what the best
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86951
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
501 - 600 of 1283 matches
Mail list logo
