https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120423
Georg-Johann Lay changed:
What|Removed |Added
Known to work||14.2.0
--- Comment #2 from Georg-Joh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120423
--- Comment #1 from Georg-Johann Lay ---
Created attachment 61553
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61553&action=edit
Reduced C test case
Here is a reduced C test case:
struct data
{
int a;
int b;
};
unsigned char v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120423
Georg-Johann Lay changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120442
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|--- |15.2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120441
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120442
Georg-Johann Lay changed:
What|Removed |Added
Target||avr
Priority|P3
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
fdim is missing from libgcc/avr/libf7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120441
Georg-Johann Lay changed:
What|Removed |Added
Keywords||wrong-code
Target|
normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
f7_exp returns Inf for x>=512 and 0 for x<=-512 in libgcc/libf7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119989
--- Comment #6 from Georg-Johann Lay ---
The issue was introduced by the cc0 -> CCmode conversion in r12-226
3ba781d3b5c8efadb60866c9743b657e8f0eb222
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119989
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Target|Avr
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
unsigned _Fract p2m1_remez (unsigned _Fract x)
{
unsigned _Fract a0 = 3.704e-06ur;
unsigned _Fract a1 = 6.929e-01ur;
unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119568
--- Comment #1 from Georg-Johann Lay ---
So the ICE occurs with checking enabled, and otherwise it goes into hog mode:
gcc_checking_assert (GET_MODE_CLASS (from_mode) == GET_MODE_CLASS (to_mode)
&& from_mode < to_mo
ty: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
This warning seems to only occur when const is specified, and when the variable
f0 is a fixed-point type:
#define T _Frac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119532
--- Comment #7 from Georg-Johann Lay ---
(In reply to rguent...@suse.de from comment #6)
> Is it a regression?
You mean whether there is an older version where it did not ICE?
Presumably not, at least with v8 it also ICEs, and with v5.4.0 there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119532
--- Comment #5 from Georg-Johann Lay ---
It also occurs for current v13 and v14 at least.
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
extern _Fract sinuhk_deg (unsigned short _Accum);
_Fract cosuhk_deg (unsigned short _Accum deg)
{
unsigned short _Accum _90_deg = 90uhk;
__asm ("" : &qu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117596
--- Comment #2 from Georg-Johann Lay ---
...what I currently have for trying is this addition to avr.cc:
static bool
avr_c_bitint_type_info (int n, struct bitint_info *info)
{
info->abi_limb_mode = QImode;
info->limb_mode = QImode;
info->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117596
--- Comment #1 from Georg-Johann Lay ---
All I can find is TARGET_C_BITINT_TYPE_INFO.
* Where to specify that addition should be implemented by a libgcc function
like addbitint3?
* There are libgcc modules like _mulbitint3.o but they are empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119396
Georg-Johann Lay changed:
What|Removed |Added
Last reconfirmed||2025-03-27
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119396
--- Comment #3 from Georg-Johann Lay ---
As it seems, the following libgcc/Makefile.in rule injects dependencies:
$(patsubst %,%.vis,$(LIB1ASMFUNCS)): %.vis: %_s$(objext)
$(gen-hide-list)
Since the *_s. objects are added to lib1asmfuncs-s-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119421
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119421
Georg-Johann Lay changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
There are occasions where knowledge about nonzero bits makes some
optimizations possible. For example,
Rd |= Rn << Off
can be implemented as
SBRC Rn, 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119396
--- Comment #2 from Georg-Johann Lay ---
What I have already tried is to set
SHLIB_LINK :=
in t-avr, which should imply enable_shared=no. But it had no effect.
Also I don't know where SHLIB_LINK should be set. In the top-level configure.ac
?
IRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
On avr, there are libgcc modules build with -DSHARED even though that target
doesn't support shared libra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119355
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119225
--- Comment #2 from Georg-Johann Lay ---
This is the texinfo commit that fixed the issue:
https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=f536711c6286a974798affb366d1ba0cc72fa16e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119225
--- Comment #1 from Georg-Johann Lay ---
This is a texinfo bug that has been fixed.
Please leave the anchors where they are, they are correct and external links
rely on them.
See also https://lists.gnu.org/archive/html/help-texinfo/2024-03/msg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119077
--- Comment #7 from Georg-Johann Lay ---
...I can reproduce it with the following test case and v13:
#include
extern void __builtin_avr_delay_cycles (uint32_t);
#include
int main(void)
{
_delay_ms(100);
}
So the likely cause is that A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119077
--- Comment #6 from Georg-Johann Lay ---
Still 2 issues:
* Your are configuring the compiler in a way not supported by GCC (see my note
above).
* Pre-processed files are still missing. You can get the i files with
-save-temps -g3.
With -g3, t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115817
Georg-Johann Lay changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119086
--- Comment #3 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #2)
> See pr 26724 and others.
>
> *** This bug has been marked as a duplicate of bug 26724 ***
Thanks for the pointer. Would you explain how that can be used for
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Created attachment 60634
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60634&action=edit
bic.c: C test case
In the attached test case bic.c, there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119077
Georg-Johann Lay changed:
What|Removed |Added
Last reconfirmed||2025-03-02
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
--- Comment #21 from Georg-Johann Lay ---
Back then, the patch has been reopened so it won't be forgotten for
backporting.
https://gcc.gnu.org/pipermail/gcc/2024-February/243300.html
As is seems, no backport will happen?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118889
--- Comment #5 from Georg-Johann Lay ---
...the respective part of varasm.cc reads:
get_variable_section (tree decl, bool prefer_noswitch_p)
{
...
if (ADDR_SPACE_GENERIC_P (as)
&& !DECL_THREAD_LOCAL_P (decl)
&& !DECL_NOINIT_P (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118889
--- Comment #4 from Georg-Johann Lay ---
(In reply to rguent...@suse.de from comment #3)
> On Mon, 17 Feb 2025, gjl at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118889
> > --- Comment #2 from G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118889
--- Comment #2 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #1)
> I think variables with 'static' linkage cannot be 'common'?
Shouldn't they go into .lcomm, i.e. lcomm_section?
What I am trying to achieve is to implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115817
--- Comment #9 from Georg-Johann Lay ---
What can be used as a kind of work-around (and may be even better than the code
with improved Binutils as proposed above), is to hide the value of 0 from the
compiler:
volatile uint8_t var;
__attribute(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115817
--- Comment #8 from Georg-Johann Lay ---
See https://sourceware.org/bugzilla/show_bug.cgi?id=32704
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115817
Georg-Johann Lay changed:
What|Removed |Added
CC||ul...@t-online.de
--- Comment #7 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118880
Georg-Johann Lay changed:
What|Removed |Added
Keywords|documentation, needs-source |missed-optimization
Resoluti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118880
Georg-Johann Lay changed:
What|Removed |Added
Priority|P3 |P4
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
gcc from 2025-02-14 ignores attribute "common" with -fdata-sections:
__attribute__((common))
static volatile int z;
int main ()
{
return z;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118880
Georg-Johann Lay changed:
What|Removed |Added
Last reconfirmed||2025-02-15
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118878
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Created attachment 60499
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60499&action=edit
C test case
The a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118878
Georg-Johann Lay changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118591
Georg-Johann Lay changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118806
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118806
--- Comment #3 from Georg-Johann Lay ---
...or let me state is this way:
This PR implements an optimization that is activated by some option
(-mno-call-main). What's unusual is that it is activated by the no- version of
the option, and -mcall-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118806
--- Comment #2 from Georg-Johann Lay ---
(In reply to Xi Ruoyao from comment #1)
> Maybe it can also be done if main is [[noreturn]]?
Not sure about that.
The proposed patch /sets/ [[noreturn]] provided the conditions are right, i.e.
-mno-call-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118806
Georg-Johann Lay changed:
What|Removed |Added
Keywords||missed-optimization
Targ
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Add a new command line option -mno-call-main that uses a more efficient way of
running main as provided by the startup code from libmcu.a
XCALL main
XJMP exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118764
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118768
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118764
Bug 118764 depends on bug 118768, which changed state.
Bug 118768 Summary: [avr] Make genmultilib.awk more robust against white spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118768
What|Removed |Added
---
Priority: P3
Component: libgdiagnostics
Assignee: dmalcolm at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Compiling the following code with v15
__attribute__((xxx))
void my4 () {}
I am getting the following diagnostic:
file.c:2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118768
Georg-Johann Lay changed:
What|Removed |Added
Blocks||118764
Target|
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
The current genmultilib.awk is prone to errors when avr-mmcu.def adds or
removed white spaces. For example, AVR_ATTR1|AVR_ATTR2 will be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118764
Georg-Johann Lay changed:
What|Removed |Added
Target||avr
Severity|normal
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Some devices support a Compact Vector Table (CVT) which will be supported in
AVR-LibC v2.3 by means of startup code in crt-cvt.o.
https://github.com/avrdudes/avr-libc/issues/1010
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100530
--- Comment #20 from Georg-Johann Lay ---
So can this be closed as fixed (in v15+) ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118360
--- Comment #5 from Georg-Johann Lay ---
(In reply to GCC Commits from comment #4)
> AVR: PR118012 - Try to work around sick code from match.pd.
The patch above just tries to work around PR118012 / PR118360. It is by no
means a proper fix,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
--- Comment #17 from Georg-Johann Lay ---
(In reply to GCC Commits from comment #16)
> AVR: PR118012 - Try to work around sick code from match.pd.
The patch above just tries to work around PR118012 / PR118360. It is by no
means a proper fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118591
--- Comment #3 from Georg-Johann Lay ---
Created attachment 60238
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60238&action=edit
C99 test case that fails on ordinary AVRs (not avrtiny)
This test case fails on ordinary AVRs like -mmcu=at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118591
--- Comment #2 from Georg-Johann Lay ---
(In reply to Georg-Johann Lay from comment #1)
> Created attachment 60230 [details]
> reduced C99 test case
In that test case:
__attribute__((noipa))
void func2 (long a, long b)
{
static unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118591
--- Comment #1 from Georg-Johann Lay ---
Created attachment 60230
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60230&action=edit
reduced C99 test case
Here is a reduced test case that fails with -mlra -mmcu=attiny40 for any
optimization
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Created attachment 60227
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60227&action=edit
pr43879-3.c: C test case from test suite
gcc.dg/torture/pr43
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117546
--- Comment #16 from Georg-Johann Lay ---
Ok. Thanks for the pointer (though int32plus should be enough).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117546
--- Comment #14 from Georg-Johann Lay ---
(In reply to GCC Commits from comment #12)
> * gcc.dg/torture/pr117546.c: New test.
That test fails on AVR. Does it assume that int is a 32-bit type or what?
Unfortunately the test is just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56479
Georg-Johann Lay changed:
What|Removed |Added
Summary|Register allocator can't|[lra][avr] Register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118556
--- Comment #1 from Georg-Johann Lay ---
For ordinary insns, it's enough to -dp to see code length (at least on a target
that implements insn attribute "length"). So -dp should suffice.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118554
--- Comment #2 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #1)
> That already is handled by the inline keyword.
> so `__asm inline("" : "+r" (var));`
But that's /only/ for inlining, where a "minimal" size is assumed -- what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115817
--- Comment #5 from Georg-Johann Lay ---
(In reply to Dmytro Bagrii from comment #4)
> gcc is smart enough not to initialize R1 when it is not used.
Actually not. The decision whether __zero_reg__ is required in an ISR is
worked out by the asse
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Allowing the source code to specify the size of an inline asm would have the
following benefits at least:
1) Currently, the asm size may be overly pessimistic (i.e. too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118329
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|15.0|14.3
--- Comment #14 from Georg-Joha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118329
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|--- |15.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #19 from Georg-Johann Lay ---
(In reply to Segher Boessenkool from comment #18)
> A single insn (always 4 bytes) is too much?!?
Maybe a small test case might help to show the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
Bug 56183 depends on bug 117910, which changed state.
Bug 117910 Summary: [avr][lra] Wrong code with -mlra in cmpdi-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117910
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117868
--- Comment #5 from Georg-Johann Lay ---
*** Bug 117910 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117910
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
Bug 113934 depends on bug 117910, which changed state.
Bug 117910 Summary: [avr][lra] Wrong code with -mlra in cmpdi-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117910
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118329
--- Comment #9 from Georg-Johann Lay ---
Withe these changes and INT_N (PSI, 24), I am getting errors like
error: ISO C does not support '__int24' types [-Wpedantic]
__int24 and __uint24 were introduced in v4.8 and would work for older revisio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118360
--- Comment #3 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #2)
> Zeroone*b could be expanded also as zeroone?b:0.
Though that's only half of the story and would
x = zeroone ? b : 0;
c ^= x;
instead of
if (zeroone & 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118361
Georg-Johann Lay changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118360
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
This PR collects PRs that suffer from very expensive code where a simple
test-bit-and-branch would be perfectly fine.
* Most of
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
$ avr-gcc-15 -Os -mmcu=atmega8 -S -dp
long fun1 (int a, long b)
{
if (a & 1)
b ^= 8;
return b;
}
compiles to:
fun1:
push r16 ;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118329
--- Comment #8 from Georg-Johann Lay ---
(In reply to Jonathan Wakely from comment #0)
> avr uses FRACTIONAL_INT_MODE while e.g. msp430 uses PARTIAL_INT_MODE,
> don't remember the difference
The comments in machmode.def propose that PARTIAL_INT_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118329
--- Comment #6 from Georg-Johann Lay ---
Currently there is:
static void
avr_init_builtin_int24 (void)
{
tree int24_type = make_signed_type (GET_MODE_BITSIZE (PSImode));
tree uint24_type = make_unsigned_type (GET_MODE_BITSIZE (PSImode));
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118334
--- Comment #2 from Georg-Johann Lay ---
INT_MODE (MODE, BYTESIZE);
declares MODE to be of class INT and BYTESIZE bytes wide.
All of the bits of its representation are significant.
FRACTIONAL_INT_MODE (MODE, PRECISION,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118334
--- Comment #1 from Georg-Johann Lay ---
Some explanations can be found in machmode.def
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/machmode.def#l64
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Currently, the interbals don't document features to be used in
-modes.def, like:
* INT_N
* FRACTIONAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118329
--- Comment #4 from Georg-Johann Lay ---
avr-modes.def is the only backend that's using FRACTIONAL_INT_MODE. So will
INT_N replace it? Augment it?
And as far as I understand, INT_N defines __intN. What about avr.cc's built-in
types __int24 an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118329
--- Comment #2 from Georg-Johann Lay ---
(In reply to Jonathan Wakely from comment #0)
> config/avr/avr-modes.def doesn't have the INT_N (PSI, 24); line after
> FRACTIONAL_INT_MODE line so, from middle-end POV, it is as
> if __int24 doesn't exis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
--- Comment #14 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #13)
> On RTL we do target costing for if-conversion sequences, PHI-OPT doesn't
...and...
> For specific cases improving RTL expansion is also possible
Which doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
--- Comment #12 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #9)
> match patterns should almost never be conditional unless
The pattern in question was introdiced as optimization, not as
canonicalization.
I don't think that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
--- Comment #10 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #9)
> Basically gimple should be almost all target indepdendent except in the late
> stages.
The problem is that some canonicalizations are very expensive on some
1 - 100 of 2070 matches
Mail list logo
