https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #12 from Georg-Johann Lay ---
Simulator: avrtest core simulator hosted on SourceForge as part of WinAVR.
Libc: avr-libc trunk hosted on nongnu.org. There are several patches not yet
integrated: recent xtiny devices, fixes in libm to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #13 from Georg-Johann Lay ---
FYI, avrtest is here:
https://sourceforge.net/p/winavr/code/HEAD/tree/trunk/avrtest/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #15 from Georg-Johann Lay ---
I built the tools by hand so I knew what I had...
Dunno about gcc/buildbot policies concerning avr. As avr as a 3ary target, that
BE's quality is of no consideration when releasing the compiler. Again, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108287
--- Comment #4 from Georg-Johann Lay ---
Well, updating or creating some auto-generated files is intentional.
What's not supported as of GCC documentation is configure'ing in the source
tree:
https://gcc.gnu.org/install/configure.html
> First
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108287
--- Comment #5 from Georg-Johann Lay ---
...ok, yes, building outside srcdir won't fix this one. But points 1) and 2)
still apply.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106307
Georg-Johann Lay changed:
What|Removed |Added
Last reconfirmed||2023-01-21
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99435
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100962
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97276
Georg-Johann Lay changed:
What|Removed |Added
Target|atxmega32a4 |avr
--- Comment #2 from Georg-Johann
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97276
--- Comment #4 from Georg-Johann Lay ---
Created attachment 54518
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54518&action=edit
pwn-i.c pre-compiled test case
Ok, I found it and attached a cleaned-up version.
IIUC correctly, the releva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97276
--- Comment #5 from Georg-Johann Lay ---
... also tried v9.2 via
https://godbolt.org/z/9r3vMj1e3
and just like with v8.5, the respective block is around asm line 350.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706
Georg-Johann Lay changed:
What|Removed |Added
Known to work||8.5.0
--- Comment #19 from Georg-Joha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104988
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99184
--- Comment #1 from Georg-Johann Lay ---
As a work-around, one can cast to an intermediate 64-bit integer:
// For [u]int64_t and uint32_t, do #include
double x = 2.9;
int x_int = (int) (int64_t) x;
uint32_t x_u32 = (uint32_t) (uint64_t) x;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107201
Bug ID: 107201
Summary: [avr] -nodevicelib not working for devices
-mmcu=avr...
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107201
--- Comment #1 from Georg-Johann Lay ---
Created attachment 53691
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53691&action=edit
pr107201.diff: Proposed patch.
This proposed patch (effectively) sets macro X_NODEVLIB to "" in all of
./co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100962
--- Comment #4 from Georg-Johann Lay ---
Did you try option -mstrictX?
And try to make a problem-report self-contained.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101867
--- Comment #16 from Georg-Johann Lay ---
--with-avrlibc is default, so setting it is void. C.f. install info.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103975
--- Comment #5 from Georg-Johann Lay ---
If someone is going to fix this, the following changes might also play a role:
* v8+ may emit optimized ISR prologues / epilogues using PR81268: gcc will just
emit pseudo-instruction __gcc_isr which will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99435
--- Comment #1 from Georg-Johann Lay ---
I am really confused.
To all of my knowledge, IN and OUT can address a range of 64 bytes. For
example, the opcode of OUT is
1011 1AAr
where "r" bits encode for the register number (2^5 = 32 o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706
--- Comment #13 from Georg-Johann Lay ---
Created attachment 53812
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53812&action=edit
Test case with 32-bit integer.
This problem is still present in current master (future v13) and also occurs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107610
--- Comment #4 from Georg-Johann Lay ---
Also affected are other bits of the web page that are auto-generated, like
https://gcc.gnu.org/install/configure.html
And with the new URLs, "deep" links like
https://gcc.gnu.org/install/configuration.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107842
Bug ID: 107842
Summary: [avr] Set --param=min-pagesize=0 in the backend
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107842
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
Georg-Johann Lay changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106307
--- Comment #1 from Georg-Johann Lay ---
We'd need at least a test case so we can reproduce th issue. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104875
--- Comment #3 from Georg-Johann Lay ---
Is this fixed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706
Georg-Johann Lay changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113824
Bug ID: 113824
Summary: AVR: ATA5795 in wrong multilib set
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113824
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113824
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
Georg-Johann Lay changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|--- |13.3
--- Comment #37 from Georg-Joha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113927
Bug ID: 113927
Summary: [avr-tiny] Sets up a stack-frame even for trivial code
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113927
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Keywords|missed-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
--- Comment #1 from Georg-Johann Lay ---
What's the LRA way to do LEGITIMIZE_RELOAD_ADDRESS?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113974
Bug ID: 113974
Summary: Attribute common ignored
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113974
--- Comment #3 from Georg-Johann Lay ---
Then the documentation should make that clear that with -fno-data-sections the
object goes in COMM, but with -fdata-sections it does not and the attribute
"common" is ignored.
Better still, the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97276
Georg-Johann Lay changed:
What|Removed |Added
Last reconfirmed||2024-02-20
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114100
Bug ID: 114100
Summary: [avr] Inefficient indirect addressing on Reduced Tiny
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114100
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|--- |14.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114111
Bug ID: 114111
Summary: [avr] Expensive code instead of conditional branch.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114132
Bug ID: 114132
Summary: [avr] Code sets up a frame pointer without need
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114132
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|--- |14.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114132
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114100
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114191
Bug ID: 114191
Summary: Flags "Warning" and "Target" don't mix well in
target.opt files
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114208
Bug ID: 114208
Summary: DSE deletes a store that is not dead
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114208
--- Comment #2 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #1)
> I wonder if this is related to r14-6674-g4759383245ac97 .
Not unlikely. PR112525 tries to eliminate dead stores for arguments that are
passed. It seems like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114208
--- Comment #3 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #1)
> I wonder if this is related to r14-6674-g4759383245ac97 .
Seems unrelated: When I reverse-apply r14-6674 then the issue does not go away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114191
--- Comment #2 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #1)
> Wmisspelled-isr
> Target C C++ Var(avr_warn_misspelled_isr) Init(1)
> Warn if the ISR is misspelled, ...
>
> should eventually work?
With that, the warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114191
--- Comment #3 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #1)
> How did you specify 'Target'?
Like:
Wmisspelled-isr
Target Warning C C++ Var(avr_warn_misspelled_isr) Init(1)
Warn if the ISR is misspelled, ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114208
--- Comment #5 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #4)
> Did it ever work?
No. I allowed -mfuse-add=3 to reproduce this PR because there seems to be a
problem with DSE, and for the case that someone is going to fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114243
Bug ID: 114243
Summary: -fsplit-wide-types bloats code by more than 50%
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706
--- Comment #24 from Georg-Johann Lay ---
(In reply to Georg-Johann Lay from comment #23)
> As it appears, this bug is not fixed completely. For the -mmcu=avrtiny
> architecture, there is still bloat for even the smallest test cases like:
Diffe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114243
--- Comment #1 from Georg-Johann Lay ---
May be related to PR110093. As Vladimir noted in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093#c5
the problem is that data flow analysis cannot cope with the subregs generated
from lower-subregs,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81473
--- Comment #4 from Georg-Johann Lay ---
This was fixed long ago.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
Bug ID: 114252
Summary: Introducing bswapsi reduces code performance
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
--- Comment #3 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #1)
> but somehow we end up doing a libcall?
It's not a libcall in the GCC sense, for the compiler it's just an ordinary
insn. The backend then prints this as a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
--- Comment #5 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #4)
> So bswap on a value is just register shuffling, right?
The point is that there is no need for bswap in the first place, just have a
look at the code that v1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
--- Comment #8 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #7)
> Note I do understand what you are saying, just the middle-end in detecting
> and using __builtin_bswap32 does what it does everywhere else - it checks
> whet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
--- Comment #9 from Georg-Johann Lay ---
...and I don't see why a register allocator would or should fix flaws from tree
optimizers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
--- Comment #12 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #10)
> I think the target controls the "libcall" ABI that's used for calls to
> libgcc,
You have a pointer how to do it or an example? IIRC I looked into it quit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
--- Comment #14 from Georg-Johann Lay ---
The code in the example is not a perfect bswap, it needs additional shuffling
of bytes. The tree passes must know that bswap is not a perfect fit. There
must be *some* criterion that depends on the per
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110220
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #34 from Georg-Johann Lay ---
@Senthil: Can this PR be closed? Or will it be backported?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96055
Georg-Johann Lay changed:
What|Removed |Added
Known to work||12.1.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53935
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109910
Georg-Johann Lay changed:
What|Removed |Added
Last reconfirmed||2023-08-04
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 105523, which changed state.
Bug 105523 Summary: Wrong warning array subscript [0] is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093
--- Comment #2 from Georg-Johann Lay ---
Meanwhile (2023-08-22) the generated code from above got worse once again and
even pops a frame:
long add (long aa, long bb, long cc)
{
if (cc < 0)
return aa - cc;
return aa + bb;
}
> av
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093
Georg-Johann Lay changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093
--- Comment #4 from Georg-Johann Lay ---
(In reply to Vladimir Makarov from comment #3)
> I propose to avoid the above RTL code by switching off subreg3
> pass (or -fsplit-wide-types) for AVR by default as it was for gcc-8.
Thanks for looking i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111639
--- Comment #2 from Georg-Johann Lay ---
(In reply to Jonathan Wakely from comment #0)
> The in avr-libc does things like this:
>
> extern double acos(double __x) __ATTR_CONST__;
> #define acosf acos/**< The alias for acos().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111639
--- Comment #4 from Georg-Johann Lay ---
(In reply to Jonathan Wakely from comment #3)
> Which versions of avr-libc are supported with gcc?
The versions are only very loosely coupled. Anything from AVR-LibC v1.8 on (or
maybe even older) should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111639
--- Comment #6 from Georg-Johann Lay ---
May I ask, are you working on getting libstdc++ to work for avr?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745
Georg-Johann Lay changed:
What|Removed |Added
Last reconfirmed|2012-01-07 00:00:00 |2024-8-2
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116295
Georg-Johann Lay changed:
What|Removed |Added
Keywords||addr-space,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116295
Bug ID: 116295
Summary: [avr] unrecognizable insn when loading from
address-space __flash
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116295
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|15.0|14.3
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
--- Comment #4 from Georg-Johann Lay ---
Would someone please explain what has to be done?
It's likely more than just
#define TARGET_LRA_P hook_bool_void_true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
--- Comment #6 from Georg-Johann Lay ---
...to be more specific:
TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P explains the function of the hook from the
perspective of someone who is implementing a register allocator, but there is
no explanation whethe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
--- Comment #7 from Georg-Johann Lay ---
...more questions:
What's the connexion between TARGET_REGISTER_PRIORITY and
ADJUST_REG_ALLOC_ORDER / reg_alloc_order[].
What about reload_completed? Does semantics stay the same? What about
reg_renum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
--- Comment #8 from Georg-Johann Lay ---
...more questions:
TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS: Same issue: This hook can change a
reload class. The purpose is clear for regalloc guys, but when and d why and
how would I do it for a specifi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116321
Bug ID: 116321
Summary: [lra][avr] internal compiler error: in
avr_out_lpm_no_lpmx, at config/avr/avr.cc:4572
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116321
Georg-Johann Lay changed:
What|Removed |Added
Keywords||ice-on-valid-code, ra
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
--- Comment #10 from Georg-Johann Lay ---
(In reply to Segher Boessenkool from comment #9)
> (In reply to Georg-Johann Lay from comment #4)
> > Would someone please explain what has to be done?
> >
> > It's likely more than just
> >
> > #defin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116322
Bug ID: 116322
Summary: regenerate-opt-urls.py usage
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116324
Bug ID: 116324
Summary: [lra] error: inconsistent operand constraints in an
'asm'
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116324
Georg-Johann Lay changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
--- Comment #11 from Georg-Johann Lay ---
LRA even breaks building libgcc: PR116324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116325
Bug ID: 116325
Summary: [lra] error: unable to generate reloads for:
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116325
Georg-Johann Lay changed:
What|Removed |Added
Ever confirmed|0 |1
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326
Bug ID: 116326
Summary: [lra] internal compiler error: in get_reload_reg, at
lra-constraints.cc:755
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326
Georg-Johann Lay changed:
What|Removed |Added
Last reconfirmed||2024-08-10
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
Georg-Johann Lay changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116322
--- Comment #2 from Georg-Johann Lay ---
And it may be easier to use when we had a $builddir/gcc/regenerate-opt-urls.py
built by configure
1) $builddir/gcc/regenerate-opt-urls.py would know where $srcdir is.
2) $builddir/gcc/regenerate-opt-url
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116321
--- Comment #1 from Georg-Johann Lay ---
What I do not understand is when I also set -mlog=legitimate_address_p then I
only get logs that have strict=0 and not a single one with strict=1, like:
avr_addr_space_legitimate_address_p[fun64:split5(3
1 - 100 of 538 matches
Mail list logo
