https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109913
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109965
--- Comment #5 from Saifi Khan ---
raised the issue with doxygen project folks.
https://github.com/doxygen/doxygen/issues/10093
There is no direct solution or workaround as per response.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
--- Comment #28 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #26)
> (In reply to Andrew Pinski from comment #25)
> > Created attachment 55175 [details]
> > Patch which fixes `signed < 0`
> >
> > This patch improves comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109901
--- Comment #8 from Richard Yao ---
Created attachment 55177
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55177=edit
Source code for micro-benchmark.
Here is an example of how not having this optimization slows us down:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110001
--- Comment #4 from Andrew Pinski ---
It is looking like a register allocation issue or something changed in
expanding to rtl. maybe just it was ok on accident before GCC 13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110001
--- Comment #3 from Andrew Pinski ---
Created attachment 55176
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55176=edit
testcase
Next time please also attach the source (if it uses headers the preprocessed
source).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110001
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-linux-gnu
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110001
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110001
Bug ID: 110001
Summary: [13 regression] Suboptimal code generation for
branchless binary search
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109980
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109981
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99241
Andrew Pinski changed:
What|Removed |Added
CC||saifi.khan at nishan dot io
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 109981, which changed state.
Bug 109981 Summary: ICE encountered while generating header units in the given
sequence in a script
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109981
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109988
--- Comment #3 from Ivan Lazaric ---
Note that clang has the same flags and behaves according to the documentation,
might be some value in matching it.
If it's considered too breaking of a change, I would recommend introducing a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
--- Comment #27 from Andrew Pinski ---
I should note the middle-end could also improve here:
/* If we are comparing a double-word integer with zero or -1, we can
convert the comparison into one involving a single word. */
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
--- Comment #26 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #25)
> Created attachment 55175 [details]
> Patch which fixes `signed < 0`
>
> This patch improves comment #20 .
Note this patch does not work for the case of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
--- Comment #25 from Andrew Pinski ---
Created attachment 55175
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55175=edit
Patch which fixes `signed < 0`
This patch improves comment #20 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
--- Comment #24 from Andrew Pinski ---
(In reply to Georg-Johann Lay from comment #23)
> Thank you so much for looking into this.
>
> For the test case from comment #21 though, the problem is somewhere in tree
> optimizations.
>
> > unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109985
--- Comment #4 from Andrew Pinski ---
Hmm:
modref analyzing 'void boost::unordered::detail::foa::prefetch(const
void*)/3452' (ipa=0) (pure)
Analyzing flags of ssa name: p_1(D)
Analyzing stmt: __builtin_prefetch (p_1(D));
current flags of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109996
--- Comment #1 from Andrew Pinski ---
There could be some alignment issues here ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562
Uri Simchoni changed:
What|Removed |Added
CC||urisimchoni at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109997
--- Comment #4 from Jonathan Wakely ---
Looks pretty similar, although I don't think we even had __is_assignable when
that was filed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
--- Comment #13 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #12)
> + && e->symtree->n.sym->assoc->target->ref
> + && e->symtree->n.sym->assoc->target->ref->u.ar.type == AR_FULL
> + &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109997
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Isn't this a dup of bug 92067?
Sorry I mean is_constructible is recorded as PR 92067. I was reading some other
bug headline and getting confused.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109997
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109970
--- Comment #1 from CVS Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:8d6bd830f5f9c939e8565c0341a0c6c588834484
commit r14-1304-g8d6bd830f5f9c939e8565c0341a0c6c588834484
Author: Martin Uecker
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #11)
> I think it does not handle the following variation of the testcase from
> the blamed patch:
This one seems to be handled by the clumsy attempt:
diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #9)
> By the way, the patch regtests OK
>
> Do you want to do the honours or shall I?
>
> I think that this rates as an 'obvious' fix.
I think it does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #4 from Nikolas Klauser ---
(In reply to Andrew Pinski from comment #3)
> I am getting a feeling this attribute is well defined enough.
>
> Is it really just supposed to block explicit instantiation of templates?
> Is there a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
H.J. Lu changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #11 from H.J. Lu ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #3 from Andrew Pinski ---
I am getting a feeling this attribute is well defined enough.
Is it really just supposed to block explicit instantiation of templates?
Is there a decent set of testcases that can be used to match up the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #2 from Andrew Pinski ---
I am trying to understand the exact details here?
https://releases.llvm.org/9.0.0/tools/clang/docs/AttributeReference.html#exclude-from-explicit-instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
--- Comment #10 from H.J. Lu ---
(In reply to H.J. Lu from comment #9)
> [hjl@gnu-cfl-3 pr109982]$ cat x.c
> struct S0 {
>long long int f0;
> } __attribute__((aligned(128)));
>
> int padding = 1;
> static struct S0 g_2415
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
Louis Dionne changed:
What|Removed |Added
CC||ldionne.2 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
Bug ID: 11
Summary: GCC should implement
exclude_from_explicit_instantiation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991
--- Comment #5 from igk ---
OK, becoming clearer, thanks. I'm just hoping for this to be diagnosed in some
way. IIUC basically GCC doesn't diagnose the UB so it proceeds with constexpr
eval just because it can, or so it thinks, and in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
--- Comment #8 from Andrew Pinski ---
(In reply to Sergei Trofimovich from comment #7)
> Original packet-rnsap.c.i.xz takes 27 minutes to compile for me.
>
> The hack below cuts this time down to 9 minutes (slashes 60% of runtime).
Or maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
--- Comment #7 from Sergei Trofimovich ---
Original packet-rnsap.c.i.xz takes 27 minutes to compile for me.
The hack below cuts this time down to 9 minutes (slashes 60% of runtime).
The considerable amount of time is spent looking up the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991
--- Comment #4 from Andrew Pinski ---
(In reply to igk from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > Dup of bug 98675.
> >
> > *** This bug has been marked as a duplicate of bug 98675 ***
>
> Thanks for looking into this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991
--- Comment #3 from igk ---
(In reply to Andrew Pinski from comment #2)
> Dup of bug 98675.
>
> *** This bug has been marked as a duplicate of bug 98675 ***
Thanks for looking into this. I haven't quite understood though.
I'm trying to see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
--- Comment #1 from Andrew Pinski ---
: In function 'test_allocate_on_device':
:27:43: error: expected '#pragma omp' clause before 'uses_allocators'
27 | #pragma omp target map(tofrom: errors, A)
uses_allocators(omp_default_mem_alloc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Bug ID: 10
Summary: [OpenMP] Bogus error message: talks about '"#pragma
omp" clause' instead of '"target" clause
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109998
Bug ID: 109998
Summary: [OpenMP] TR12/5.0/5.1 - permit structure elements with
'!$OMP ALLOCATORS' (and !$OMP ALLOCATE)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109997
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
--- Comment #6 from Sergei Trofimovich ---
Created attachment 55174
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55174=edit
packet-rnsap-shrunk-slightly.c.i.xz
packet-rnsap-shrunk-slightly.c.i.xz is a slightly shrunk version of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876
--- Comment #11 from Marek Polacek ---
We never instantiated fnc because mark_used checks
/* Check this too in case we're within instantiate_non_dependent_expr. */
if (DECL_TEMPLATE_INFO (decl)
&& uses_template_parms (DECL_TI_ARGS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71579
--- Comment #25 from Jonathan Wakely ---
Some missing completeness checks:
std::assignable
We don't enforce precondition that both types are complete types, cv void, or
arrays of unknown bound. Filed as PR c++/109997
std::common_type
Our impl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109997
Bug ID: 109997
Summary: __is_assignable(int, IncompleteType) should be
rejected
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109996
Bug ID: 109996
Summary: csmith: -O2 -fno-strict-aliasing causing run time
trouble
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #42 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #41)
>
> Thank you! I have an idea. If it's impossible to defer initial optimization,
> maybe it's possible to emit some intermediate insn and catch it and optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109988
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-26
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109985
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109984
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
David Binderman changed:
What|Removed |Added
CC||jh at suse dot cz
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109985
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109985
Christian Mazakas changed:
What|Removed |Added
CC||christian.mazakas at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #52 from Jakub Jelinek ---
(In reply to H.J. Lu from comment #14)
> (In reply to jos...@codesourcery.com from comment #13)
> > https://gitlab.com/x86-psABIs/i386-ABI/-/issues/5 to request such an ABI
> > for 32-bit x86. I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876
--- Comment #10 from Marek Polacek ---
So I have
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -27969,6 +27969,13 @@ value_dependent_expression_p (tree expression)
else if (TYPE_REF_P (TREE_TYPE (expression)))
/* FIXME cp_finish_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109995
--- Comment #1 from Andrew Pinski ---
do *++p = c; while (--n > 0);
is turned into memset during optimizations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109995
Bug ID: 109995
Summary: Bogus warning about __builtin_memset, from
-Wstringop-overflow
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
--- Comment #6 from David Binderman ---
This commit looks highly likely:
commit eef81eefcdc2a58111e50eb2162ea1f5becc8004
Author: Jan Hubicka
Date: Thu Dec 22 10:55:46 2022 +0100
Zen4 tuning part 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109994
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
--- Comment #5 from David Binderman ---
Current git range is g:193fccaa5c3525e9 .. g:5b30e9bc211fede0,
which is 8 commits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109994
--- Comment #2 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #1)
> There are definitly testcases in GCC's testsuite which does this all the
> time.
> #define int ...
Yeah, it shouldn't be in -Wall, and it's not a required
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109994
--- Comment #1 from Andrew Pinski ---
There are definitly testcases in GCC's testsuite which does this all the time.
#define int ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
--- Comment #6 from Andrew Pinski ---
(In reply to Bruno Haible from comment #4)
> That is the only way of keeping track of pointers _into_ the string_space
> area, when it is reallocated. How else would you want to do it?
You could use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
--- Comment #5 from Bruno Haible ---
Created attachment 55170
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55170=edit
test case bar2.c
Find attached a modified test case. I changed the code to
map[i].alias =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109985
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109994
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109994
Bug ID: 109994
Summary: Issue a diagnostic when a C++ file defines a macro
that hides a keyword
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
--- Comment #4 from Bruno Haible ---
> >
> > char *new_pool = (char *) realloc (string_space,
> > new_size);
> > if (new_pool == ((void *)0))
> > goto out;
> > if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
--- Comment #4 from David Binderman ---
Original git range was 123 commits.
Current bisect range is g:89ba8366fe12fd2d .. g:23be9d78f4bcd773,
which is 31 commits.
Trying 5b30e9bc211fede0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #14 from Martin Uecker ---
Maybe.
On the other hand, I wonder whether a struct with FAM should not rather always
have the same size, and alignment, and representation as the corresponding
struct with a conventional array. This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109993
Bug ID: 109993
Summary: std::regex("\\a", std::regex::basic) does not diagnose
invalid BRE
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #51 from Jakub Jelinek ---
Note, I've only tested it so far on
_BitInt(256) a = 0x1234ab461289cdab8d111007b461289cdab8d1wb;
_BitInt(256) b = 0x2385eabcd072311074bcaa385eabcd07111007b46128wb;
_BitInt(384) c = (_BitInt(384))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
Jakub Jelinek changed:
What|Removed |Added
Attachment #55151|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
--- Comment #23 from Georg-Johann Lay ---
Thank you so much for looking into this.
For the test case from comment #21 though, the problem is somewhere in tree
optimizations.
> unsigned char lfsr32_mpp_ge0 (unsigned long number)
> {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109992
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109992
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109992
--- Comment #1 from Andrew Pinski ---
As an aside: it is funny how x86 does not have a bits insert instruction yet
(while almost all RISC targets have that now).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109992
Bug ID: 109992
Summary: Addition/subtraction to the last bitfield of a struct
can be optimized
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
--- Comment #3 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #1)
> Also fails with "-mtune=znver1 -mavx":
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x004048ef in func_21 (p_22=0x41b330 , p_23=0, p_24=8) at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
--- Comment #22 from Andrew Pinski ---
(In reply to Georg-Johann Lay from comment #20)
> What then happens is:
>
> expr.cc::do_store_flag()
> expmed.cc::emit_store_flag_force()
> expmed.cc::emit_store_flag()
> expmed.cc::emit_store_flag_1()
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109986
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 109991, which changed state.
Bug 109991 Summary: stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98675
Andrew Pinski changed:
What|Removed |Added
CC||igkper at gmail dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991
Bug ID: 109991
Summary: stack-use-after-scope
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> ```
>
> char *new_pool = (char *) realloc (string_space, new_size);
> if (new_pool == ((void *)0))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
--- Comment #1 from Andrew Pinski ---
```
char *new_pool = (char *) realloc (string_space, new_size);
if (new_pool == ((void *)0))
goto out;
if (__builtin_expect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
Bug ID: 109990
Summary: [12 Regression] Bogus -Wuse-after-free warning after
realloc
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60749
Siarhei Volkau changed:
What|Removed |Added
CC||lis8215 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109989
Bug ID: 109989
Summary: RISC-V: Missing sign extension with int to float
conversion with 64bit soft floats
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811
--- Comment #11 from Jakub Jelinek ---
DWARF unwinding works properly, just in Linux kernel they decided they don't
want it in the kernel (I think they had some non-perfect implementation in the
past and it got removed).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109988
--- Comment #1 from Ivan Lazaric ---
In `gcc/c-family/c-opts.cc`:
```
case OPT_iwithprefix:
add_prefixed_path (arg, INC_SYSTEM);
break;
```
Should `INC_SYSTEM` actually be `INC_AFTER` ?
1 - 100 of 147 matches
Mail list logo
