Am 05.08.25 um 15:58 schrieb Stefan Schulze Frielinghaus:
On Mon, Aug 04, 2025 at 01:04:36PM +0200, Georg-Johann Lay wrote:
Rewriting avr.md so it uses less explicit hard registers, I came
across the ICE below. I am using 2 patches as attached:
- A tentative fix for LRA https://gcc.gnu.org/PR1
FYI, here are the IRA and LRA dumps as of -da
Am 04.08.25 um 13:04 schrieb Georg-Johann Lay via Gcc:
Rewriting avr.md so it uses less explicit hard registers, I came
across the ICE below. I am using 2 patches as attached:
- A tentative fix for LRA https://gcc.gnu.org/PR121198
- A WIP to
Rewriting avr.md so it uses less explicit hard registers, I came
across the ICE below. I am using 2 patches as attached:
- A tentative fix for LRA https://gcc.gnu.org/PR121198
- A WIP to rewrite avr.md's divmodhi4 to use HRCs instead of
explicit hard regs. Outcome is that divmodhi4 will read
The recently pushed hreg-constraints (HRCs) feature has this in
the docs:
register asm may not only be clobbered by function calls but also by
inline asm in conjunction with hard register constraints. For example,
in the following
register int x asm ("r5") = 42;
int y;
asm ("" : "={r5}" (y))
Am 21.03.25 um 19:16 schrieb Georg-Johann Lay via Gcc:
Am 21.03.25 um 01:02 schrieb Jeff Law:
On 3/19/25 4:14 AM, Georg-Johann Lay wrote:
Am 16.03.25 um 14:51 schrieb Jeff Law via Gcc:
On 3/13/25 5:39 AM, Georg-Johann Lay via Gcc wrote:
There are situations where knowledge about which bits
Am 21.03.25 um 15:21 schrieb Richard Biener:
On Fri, Mar 21, 2025 at 2:38 PM Georg-Johann Lay wrote:
Am 21.03.25 um 08:58 schrieb Richard Biener:
On Thu, Mar 20, 2025 at 8:05 PM Georg-Johann Lay via Gcc
wrote:
For avr, there is no support for shared objects, yet
when building libgcc
For avr, there is no support for shared objects, yet
when building libgcc, for each module.o there is also module_s.o
that's build with -DSHARED.
How can this be turned off?
What doesn't word is to configure with --disable-shared, and even
without turning it off by hand, there is no use for modu
Am 21.03.25 um 08:58 schrieb Richard Biener:
On Thu, Mar 20, 2025 at 8:05 PM Georg-Johann Lay via Gcc
wrote:
For avr, there is no support for shared objects, yet
when building libgcc, for each module.o there is also module_s.o
that's build with -DSHARED.
How can this be turned off?
Am 21.03.25 um 01:02 schrieb Jeff Law:
On 3/19/25 4:14 AM, Georg-Johann Lay wrote:
Am 16.03.25 um 14:51 schrieb Jeff Law via Gcc:
On 3/13/25 5:39 AM, Georg-Johann Lay via Gcc wrote:
There are situations where knowledge about which bits
of a value are (not) set can be used for optimization
Am 16.03.25 um 14:51 schrieb Jeff Law via Gcc:
On 3/13/25 5:39 AM, Georg-Johann Lay via Gcc wrote:
There are situations where knowledge about which bits
of a value are (not) set can be used for optimization.
For example in an insn combine pattern like:
(define_insn_and_split ""
There are situations where knowledge about which bits
of a value are (not) set can be used for optimization.
For example in an insn combine pattern like:
(define_insn_and_split ""
[(set (match_operand:QI 0 "register_operand" "=d")
(ior:QI (ashift:QI (match_operand:
Am 15.01.25 um 21:58 schrieb Jonathan Wakely:
On Wed, 15 Jan 2025 at 20:57, Jakub Jelinek wrote:
On Wed, Jan 15, 2025 at 09:36:51PM +0100, Georg-Johann Lay via Gcc wrote:
This pedwarn is correct, so I'm not sure why it's a problem. If you
don't want warnings about non-stan
Am 15.01.25 um 20:41 schrieb Jonathan Wakely:
On Wed, 15 Jan 2025 at 17:17, Georg-Johann Lay via Gcc wrote:
What's the recommended way to built-in define types like __uint24 ?
Since v4.8, the avr backend has:
avr-modes.def:
FRACTIONAL_INT_MODE (PSI, 24, 3);
avr.cc:
What's the recommended way to built-in define types like __uint24 ?
Since v4.8, the avr backend has:
avr-modes.def:
FRACTIONAL_INT_MODE (PSI, 24, 3);
avr.cc:
tree int24_type = make_signed_type (GET_MODE_BITSIZE (PSImode));
tree uint24_type = make_unsigned_type (GET_MODE_BITSIZE (PSImode)
Am 20.11.24 um 11:33 schrieb Richard Biener:
On Wed, Nov 20, 2024 at 11:29 AM Georg-Johann Lay via Gcc
wrote:
Consider the following RTL peephole from avr.md:
(define_peephole2 ; avr.md:5387
[(match_scratch:QI 3 "d")
(parallel [(set (match_oper
Consider the following RTL peephole from avr.md:
(define_peephole2 ; avr.md:5387
[(match_scratch:QI 3 "d")
(parallel [(set (match_operand:ALL4 0 "register_operand" "")
(ashift:ALL4 (match_operand:ALL4 1
"register_operand" "")
Am 20.11.24 um 11:33 schrieb Richard Biener:
On Wed, Nov 20, 2024 at 11:29 AM Georg-Johann Lay via Gcc
wrote:
Consider the following RTL peephole from avr.md:
(define_peephole2 ; avr.md:5387
[(match_scratch:QI 3 "d")
(parallel [(set (match_oper
Am 20.11.24 um 11:33 schrieb Richard Biener:
On Wed, Nov 20, 2024 at 11:29 AM Georg-Johann Lay via Gcc
wrote:
Consider the following RTL peephole from avr.md:
(define_peephole2 ; avr.md:5387
[(match_scratch:QI 3 "d")
(parallel [(set (match_oper
18 matches
Mail list logo