https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108031
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753
fiesh at zefix dot tv changed:
What|Removed |Added
CC||fiesh at zefix dot tv
---
Enable TARGET_CONST_ANCHOR to allow complex constants to be created via
immediate add.
Use a 24-bit range as that enables a 3 or 4-instruction immediate to be
replaced by
2 additions. Fix the costing of immediate add to support 24-bit immediate and
12-bit shifted
immediates. The generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108031
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |target
Severity|normal
Hi Richard,
thanks for reviewing.
Richard Earnshaw writes:
> On 07/11/2022 08:57, Andrea Corallo via Gcc-patches wrote:
>> Hi all,
>> please find attached the lastest version of this patch incorporating
>> some
>> more improvents. Feel free to ignore V3.
>> Best Regards
>>Andrea
>>
>
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
The code coverage support uses counters to determine which edges in the control
flow graph were executed. If a counter overflows, then the code coverage
information is invalid. Therefore the counter type should be a 64-bit integer.
In multithreaded applications, it is important that the counter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Hi all,
In the M-Class Arm-ARM:
https://developer.arm.com/documentation/ddi0553/bu/?lang=en
these MVE instructions only have '!' writeback variant and at:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107714
we found that the Um constraint would also allow through a
register offset writeback,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107714
Stam Markianos-Wright changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #25 from CVS Commits ---
The releases/gcc-12 branch has been updated by Martin Liska
:
https://gcc.gnu.org/g:5ec102e3290ff1cac457420a1219fa1ca370
commit r12-8966-g5ec102e3290ff1cac457420a1219fa1ca370
Author: Martin Liska
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615
--- Comment #12 from Ben Barrowes ---
I use these intermediate files during the software analysis process, but then
delete them later. They are useful for me to have.
When I am given a makefile, it is often 1000's loc. I am not sure I want to
On 12/6/22 11:13, arthur.co...@embecosm.com wrote:
> Similarly to the previous round of patches, this patchset does not contain any
> new features - only fixes for the reviews of the v3. New features will follow
> shortly once that first patchset is merged.
>
> Once again, thank you to all the
On 12/6/22 11:13, arthur.co...@embecosm.com wrote:
> Similarly to the previous round of patches, this patchset does not contain any
> new features - only fixes for the reviews of the v3. New features will follow
> shortly once that first patchset is merged.
>
> Once again, thank you to all the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108031
Bug ID: 108031
Summary: riscv: Access of members of a global structure is not
optimized in atomic operations
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Jiufu Guo via Gcc-patches writes:
> Hi Kewen,
>
> 在 12/1/22 11:31 AM, Kewen.Lin 写道:
>> Hi Jeff,
>>
>> on 2022/12/1 09:36, Jiufu Guo wrote:
>>> Hi,
>>>
>>> Function rs6000_emit_set_const/rs6000_emit_set_long_const are only invoked
>>> from
>>> two "define_split"s where the target operand is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107976
--- Comment #4 from Zdenek Sojka ---
Thank you for having a look. If anything is done with the param limits,
jump-table-max-growth-ratio-for-size should probably receive the same care.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
Matthias Kretz (Vir) changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mkretz at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
Matthias Kretz (Vir) changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
Dear Sir or Madam，
I want to know how to obtain optimal level of the value of the
specific compiler options, for example - fexcess - precision = [fast |
standard] [default], including the default represent？Or how to determine?
I am looking forward to your favorable replay.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
Bug ID: 108030
Summary: `std::experimental::simd` not inlined
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
A new failure has been detected on builder gccrust-fedora-ppc64le while
building gccrust.
Full details are available at:
https://builder.sourceware.org/buildbot/#builders/19/builds/529
Build state: failed 'grep unexpected ...' (failure)
Revision: 88e509b1b1423867b138617c87a3e709c1db95eb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027
--- Comment #8 from cqwrteur ---
(In reply to LIU Hao from comment #7)
> The .la files generated by libtool are usually nonsense
> (https://fedoraproject.org/wiki/Changes/RemoveLaFiles). If you run `make
> install` by hand then you may delete
A restored build has been detected on builder gccrust-fedora-ppc64le while
building gccrust.
Full details are available at:
https://builder.sourceware.org/buildbot/#builders/19/builds/528
Build state: build successful
Revision: ca0a935cdc375f4747ac67b7dc978be06041dab2
Worker: fedora-ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108029
--- Comment #3 from Li Shaohua ---
(In reply to Li Shaohua from comment #2)
> (In reply to Martin Liška from comment #1)
> > I can see the leak with both gcc-12 and gcc master.
>
> Interesting, because I tested using Compiler explorer. On my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108029
--- Comment #2 from Li Shaohua ---
(In reply to Martin Liška from comment #1)
> I can see the leak with both gcc-12 and gcc master.
Interesting, because I tested using Compiler explorer. On my local machines,
some gcc-12 -O0 won't report, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108029
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108029
Bug ID: 108029
Summary: GCC'ASAN at -O0 failed to detect a memory leak
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On 12/6/22 11:14, arthur.co...@embecosm.com wrote:
> |We still need to write out a documentation section, but these READMEs will
> help in the meantime.|
Hello.
Just a quick comment: The Sphinx conversion didn't make it for all GCC manuals.
However,
you can still use Sphinx for a newly created
On 12/6/22 11:14, arthur.co...@embecosm.com wrote:
> |We still need to write out a documentation section, but these READMEs will
> help in the meantime.|
Hello.
Just a quick comment: The Sphinx conversion didn't make it for all GCC manuals.
However,
you can still use Sphinx for a newly created
Hi.
As make 4.4 has been release, it switches to FIFO by default. That makes
troubles to the latest GCC release, version 12. Right now, we've been using
the following 4 patches in openSUSE gcc12 package:
1270ccda70ca09f7d4fe76b5156dca8992bd77a6
53e3b2bf16a486c15c20991c6095f7be09012b55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409
--- Comment #13 from Martin Liška ---
Note the mentioned revision is a fix and yes, sometimes these revisions can end
up with a regression as profile estimation is a complex guess.
Lulu Cheng writes:
> There is description of '%c' "%n" "%a" and "%l" in section 17.5 of gccint.pdf.
> So I can understand that these descriptors are the ones that the common code
> implementation back end has to support, right?
> But I don't see the use of these descriptors in gcc.pdf.Now I want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108022
--- Comment #5 from Martin Liška ---
Yes, -ggdb3 seems to me like a reasonable solution. Note you can always strip
the debuginfo into a separate file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409
--- Comment #12 from Rama Malladi ---
I found difference in dumps at various stages of the compilation for the
mainline GCC and with update_max_bb_count() commented. Here are the details:
Mainline: Commit ID:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107993
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107990
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107984
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-12-09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107977
Martin Liška changed:
What|Removed |Added
Summary|ICE: in |[11/12/13 Regression] ICE:
There is description of '%c' "%n" "%a" and "%l" in section 17.5 of gccint.pdf.
So I can understand that these descriptors are the ones that the common code
implementation back end has to support, right?
But I don't see the use of these descriptors in gcc.pdf.Now I want to add the
descriptor
On Fri, Dec 09, 2022 at 10:18:34AM +0100, Martin Liška wrote:
> I'm going to push the revision.
>
> What exactly do you mean by random? I just know there are differences in
> between
> x86 and ppc:
>
> int __builtin_cpu_supports(const char *feature)
> This function returns a positive integer if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
Martin Liška changed:
What|Removed |Added
Known to fail||12.2.0
Known to work|
Dear team,
I am working in the compiler domain.
Can you please provide the source application where the mis-compilation
errors occurred which has been detected by the GCC compiler.
This support is very helpful for my PHD work.
-
P Rajshekhar Rao
Thanks and Regards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #23 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:d71b20fc30965ba8326ad9363d0aca9d61eb4ed3
commit r13-4581-gd71b20fc30965ba8326ad9363d0aca9d61eb4ed3
Author: Martin Liska
Date:
On 12/7/22 12:27, Jakub Jelinek wrote:
> On Fri, Nov 25, 2022 at 01:57:35PM +0100, Martin Liška wrote:
>> PR target/107551
>>
>> gcc/ChangeLog:
>>
>> * config/i386/i386-builtins.cc (fold_builtin_cpu): Use same path
>> as for PR103661.
>> * doc/extend.texi: Fix "x86-64" use.
>>
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027
--- Comment #7 from LIU Hao ---
The .la files generated by libtool are usually nonsense
(https://fedoraproject.org/wiki/Changes/RemoveLaFiles). If you run `make
install` by hand then you may delete them by hand. Some packagers (e.g. makepkg
on
PING^1
On 12/1/22 10:59, Martin Liška wrote:
> Hi.
>
> Noticed during building of libbackend.a with the LTO partial linking.
>
> The function release_body is called even if clone_of is a clone
> of a another function and thus it shares tree declaration. We should
> preserve it in that
PING^1
On 12/2/22 12:27, Martin Liška wrote:
> If -w is used, warn_odr properly sets *warned = false and
> so it should be preserved when calling warn_types_mismatch.
>
> Noticed that during a LTO reduction where I used -w.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027
--- Comment #6 from LIU Hao ---
That's not a GCC bug. That's because you have installed libraries to the
default but wrong location.
101 - 150 of 150 matches
Mail list logo
