https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107875
Bug ID: 107875
Summary: Deduction for class template specialization types
seems to be broken with init-declarator-list
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
On Sat, 2022-11-26 at 18:30 +1100, Zopolis0 via Gcc-patches wrote:
> > Re-adding a field to all types is a no-go
>
> To be entirely honest, my current priority is simply to get this
> merged so I can spend less time keeping up with upstream changes
> breaking everything and spend more time
On Fri, Nov 25, 2022 at 11:37 PM Zopolis0 via Gcc-patches
wrote:
>
> > How does the Java FE initialize void_list_node?
> https://github.com/Zopolis4/gcj/blob/master/gcc/java/builtins.cc#L503
> ```
> void_list_node = end_params_node;
> ```
>
> end_params_node is defined a couple times around the
> How does the Java FE initialize void_list_node?
https://github.com/Zopolis4/gcj/blob/master/gcc/java/builtins.cc#L503
```
void_list_node = end_params_node;
```
end_params_node is defined a couple times around the Java frontend,
not sure which definition it is using.
> TYPE_METHODS uses the field used by TYPE_BINFO so the patches are related.
As the person who wrote the patches, I can confirm that they are not
in fact related. Or, at least, they fix different issues and have no
reliance upon each other. If you mean related as in they both contain
> Am 26.11.2022 um 02:55 schrieb Zopolis0 :
>
> Oh wait wrong patch. You talking about binfo confused me.
>
> Anyways, I re-added this because replacing Java's usage of
> TYPE_METHODS with TYPE_FIELDS even when I properly checked for
> different types of functions still broke things, so I
> Am 26.11.2022 um 02:40 schrieb Zopolis0 :
>
> Because if I don't, all java files break:
>
> /bin/bash ./libtool --tag=GCJ --mode=compile
> /home/zopolis4/trustme/./gcc/gcj
> -B/home/zopolis4/trustme/x86_64-pc-linux-gnu/libjava/
> -B/home/zopolis4/trustme/./gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42195
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68557
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70547
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70547
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.0
--- Comment #8 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
Bug ID: 107874
Summary: merge not using all its arguments
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Oh wait wrong patch. You talking about binfo confused me.
Anyways, I re-added this because replacing Java's usage of
TYPE_METHODS with TYPE_FIELDS even when I properly checked for
different types of functions still broke things, so I added this as a
stopgap.
No idea what you are talking about
Because if I don't, all java files break:
/bin/bash ./libtool --tag=GCJ --mode=compile
/home/zopolis4/trustme/./gcc/gcj
-B/home/zopolis4/trustme/x86_64-pc-linux-gnu/libjava/
-B/home/zopolis4/trustme/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
Dear Martin Liška
Thanks for your research. I have resolved this problem by pass a ddrsize
paramters when build and cacluate the offset used by -fasan-shadow-offset
according that parameter.
Thanks!
B.R.
tao.z...@amlogic.com
Address： Building E5, 2555 Xiupu Road, Pudong District,
I was reverting a076632e274abe344ca7648b7c7f299273d4cbe0 as it removed code
for Java, but I may have misunderstood the change and made the incorrect
edits.
On Sat, 26 Nov 2022 at 07:16, Richard Biener
wrote:
> On Fri, Nov 25, 2022 at 9:43 AM Zopolis0 via Gcc-patches
> wrote:
> >
>
> That's
Because the frontend uses TYPE_BINFO specifically. It expects a TYPE_BINFO
that writes to this value, and will break with replacements. I have tried a
number of alternatives, and this is what works.
I can't use lang_1 because other frontends use it in ways that java doesn't
expect and I can't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107627
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107873
--- Comment #1 from Jonathan Wakely ---
(In reply to Alexandre Oliva from comment #0)
> Without SUPPORTS_ONE_ONLY, the GNU/Linux bootstrap fails because
> pthread_once is not weakref'ed in libstdc++: flag_weak is set to false, so
> we define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105134
--- Comment #9 from Andrew Pinski ---
https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/purgatory/Makefile?id=1b03cf7adc3c156ecab2618acb1ec585336a3f75
was the commit to "fix" this but as I think I mentioned here it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105134
--- Comment #8 from Andrew Pinski ---
Looks like only ppc64 does:
ppc64_PURGATORY_EXTRA_CFLAGS += -m64 -msoft-float \
-fno-exceptions
Most likely purgatory/arch/x86_64/Makefile needs the following added the end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105134
--- Comment #7 from Andrew Pinski ---
I am trying to understand this. Is it ok to use the SSE registers inside
purgatory or not?
Now that the vectorizer is used turned on at -O2 and above, without -mno-sse,
on x86_64 target, the vector
Snapshot gcc-11-20221125 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20221125/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576
--- Comment #14 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:b3b48f883d31910f2672640de2f5ff59e765488c
commit r10-11095-gb3b48f883d31910f2672640de2f5ff59e765488c
Author: Harald
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576
--- Comment #13 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:55e5ef55a0eee1cb329754f30889d93567daae18
commit r11-10394-g55e5ef55a0eee1cb329754f30889d93567daae18
Author: Harald
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107871
--- Comment #1 from Jonathan Wakely ---
This isn't valid code, you can't use max diff type for your own types. It can
only be used by the library for iota_view, but that doesn't have output
iterators.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576
--- Comment #12 from CVS Commits ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:2a7a103dd46cc079252302be69cfef188caee74d
commit r12-8942-g2a7a103dd46cc079252302be69cfef188caee74d
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
--- Comment #10 from anlauf at gcc dot gnu.org ---
Created attachment 53968
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53968=edit
Revised patch
(In reply to Mikael Morin from comment #9)
> It seems the semantics when an argument has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107873
Bug ID: 107873
Summary: C++ without SUPPORTS_ONE_ONLY
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872
Bug ID: 107872
Summary: ICE on recursive DT with DTIO
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832
--- Comment #17 from Richard Biener ---
(In reply to Michael_S from comment #16)
> On unrelated note, why loop overhead uses so many instructions?
> Assuming that I am as misguided as gcc about load-op combining, I would
> write it as:
> sub
Hi Paul,
> On 25 Nov 2022, at 20:13, Andrew Pinski via Gcc wrote:
>
> On Fri, Nov 25, 2022 at 12:08 PM Paul Koning wrote:
>>
>>> On Nov 25, 2022, at 3:03 PM, Andrew Pinski wrote:
>>>
>>> On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc
>>> wrote:
I'm trying to use fairly
On Nov 25, 2022, Paul Koning via Gcc wrote:
> They don't seem to have anything to do with missing compilers, but
> rather with the use of language features too new for the available
> (downloadable) Gnat.
The gnat1 front-end requires some of the Ada runtime (libgnat)
components. They get built
On Fri, Nov 25, 2022 at 3:09 PM Paul Koning via Gcc wrote:
> But in any case, how does that relate to the error messages I got? They
> don't seem to have anything to do with missing compilers, but rather with the
> use of language features too new for the available (downloadable) Gnat.
On Fri, 25 Nov 2022, Jan Hubicka wrote:
On Fri, 25 Nov 2022, Jan Hubicka wrote:
Am 25.11.2022 um 11:05 schrieb Jan Hubicka via Gcc-patches
:
IPA profile instrumentation tries to clear the pure and const
flags of functions but that's quite hopeless in particular for
const since
On Fri, Nov 25, 2022 at 9:55 AM Zopolis0 via Gcc-patches
wrote:
>
Why add this when nothing uses it and you need to re-add binfo because
of this? If the frontend uses
it then add it to lang_type.
Hi Paul,
> On 25 Nov 2022, at 20:08, Paul Koning via Gcc wrote:
>
>> On Nov 25, 2022, at 3:03 PM, Andrew Pinski wrote:
>>
>> On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc wrote:
>>>
>>> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be
>>> precise) to build
On Fri, Nov 25, 2022 at 9:46 AM Zopolis0 via Gcc-patches
wrote:
>
Why?!
On Fri, Nov 25, 2022 at 9:43 AM Zopolis0 via Gcc-patches
wrote:
>
That's wrong and the comment you remove explains why.
On Fri, Nov 25, 2022 at 12:08 PM Paul Koning wrote:
>
>
>
> > On Nov 25, 2022, at 3:03 PM, Andrew Pinski wrote:
> >
> > On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc
> > wrote:
> >>
> >> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be
> >> precise) to build
> On Nov 25, 2022, at 3:03 PM, Andrew Pinski wrote:
>
> On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc wrote:
>>
>> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be
>> precise) to build Ada, starting with the latest (2020) release of Gnat from
>> Adacore.
>
On Fri, 25 Nov 2022, Vaseeharan Vinayagamoorthy wrote:
Hi,
I am seeing an internal compiler error, related to this patch:
Can you please open a bugzilla for this and attach preprocessed
source so I can reproduce the ICE with a cc1 cross compiler?
Thanks,
Richard.
during GIMPLE pass:
On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc wrote:
>
> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be
> precise) to build Ada, starting with the latest (2020) release of Gnat from
> Adacore.
Are you building a cross compiler or a native compiler?
If you are
I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be
precise) to build Ada, starting with the latest (2020) release of Gnat from
Adacore.
It fails for several reasons. One is that two source files use [ ] for array
initializer brackets when ( ) is apparently supposed to be
Hi,
Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606528.html
Kind regards,
Torbjörn
On 2022-11-17 14:20, Torbjörn SVENSSON wrote:
v1 -> v2:
Paths without "C:" part can still be absolute if they start with / or
\ on Windows.
v2 -> v3:
Use alternative approach by having
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107871
Bug ID: 107871
Summary: _Iter_sink:: _M_overflow missing some difference type
casting
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
> Unfortunately not: even fairly simple-looking C++ code can generate extra CFG
edges relating to exception-handling ... making the output essentially useless.
Ahh, I had figured the answer might be something like this. Thanks for
confirming. At least from the small codebase I have, swapping from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107870
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2022-11-25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107870
Bug ID: 107870
Summary: A possible typo in the documentation of 'FLOOR'
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
On Wed, 2022-11-23 at 20:49 -0500, Gavin Ray via Gcc wrote:
> Hey all, just a few questions about the fantastic GCC Static
> Analyzer:
Hi!
>
> - It's stated that support for C++ vs C is very limited. Does this
> apply if
> you're writing C++ that is very similar-looking to C and uses few
> of
On Thu, 2022-11-24 at 14:30 +, Gaius Mulley via Gcc-patches wrote:
> Martin Liška writes:
>
> > On 11/8/22 14:22, Gaius Mulley wrote:
> > > Martin Liška writes:
> > >
> > > should be good - I'll complete the rst output in the scripts,
> >
> > Hi.
> >
>
> Hi Martin,
>
> > As you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83670
Andre Vehreschild changed:
What|Removed |Added
CC||vehre at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106875
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
On 11/24/22 15:30, Gaius Mulley wrote:
> Martin Liška writes:
>
>> On 11/8/22 14:22, Gaius Mulley wrote:
>>> Martin Liška writes:
>>>
>>> should be good - I'll complete the rst output in the scripts,
>>
>> Hi.
>>
>
> Hi Martin,
>
>> As you probably noticed, the Sphinx migration didn't go
On 11/16/22 10:01, tao.z...@amlogic.com wrote:
> Dear gcc:
>
Hello.
Based on quick discussion with Jakub, we believe fasan-shadow-symbol= would
be a non-trivial amount of work
and we rather suggest doing a per-system build with investigated
-fasan-shadow-offset.
Cheers,
Martin
> I
On 11/21/22 11:02, Jakub Jelinek wrote:
> Otherwise LGTM. Thanks and sorry for the review delay.
Yuri, do you want to commit the patch soon?
If not, I can help if you want?
Cheers,
Martin
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/constraints.md (Wdm): New constraint.
* config/riscv/predicates.md (direct_broadcast_operand): New predicate.
* config/riscv/riscv-protos.h (RVV_VLMAX): New macro.
(emit_pred_op): Refine function.
*
Richard Earnshaw via Gcc-patches writes:
> This pulls in the toplevel portion of this binutils-gdb commit:
>19e559f1c91bfaedbd2f91d85ee161f3f03fda3c libsframe: add the SFrame library
>
> ChangeLog:
> * Makefile.def: Add libsframe as new module with its dependencies.
> *
Hi!
On Fri, Nov 25, 2022 at 09:21:21PM +0800, Jiufu Guo wrote:
> "Kewen.Lin" writes:
> > on 2022/9/15 16:30, Jiufu Guo wrote:
> >> For a complicate 64bit constant, blow is one instruction-sequence to
> >> build:
> >>lis 9,0x800a
> >>ori 9,9,0xabcd
> >>sldi 9,9,32
> >>oris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106878
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13 Regression] ICE: |[11/12 Regression] ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84469
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576
--- Comment #6 from Iain Sandoe ---
(In reply to Adrian Perl from comment #5)
> Created attachment 53963 [details]
thanks for the analysis and the patch.
> Patch:
> diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
> index
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This moves two AC_MSG_RESULT lines for features so that they
are only printed when the corresponding AC_MSG_CHECKING actually
happened. This fixes configure output like:
checking for uchar.h... no
no
checking for int64_t... yes
Also move the
Tested x86_64-linux. Pushed to trunk. Backport to gcc-12 needed too.
-- >8 --
As specified in the standard, the predicate for std::erase_if has to be
invocable as non-const with a non-const lvalues argument. Restore
support for predicates that only accept non-const arguments.
It's not strictly
Tested x86_64-linux. Pushed to trunk.
-- >8 --
These overloads are not needed in C++20 as they can be synthesized by
the compiler. Removing them means less code to compile when including
these headers.
libstdc++-v3/ChangeLog:
* include/bits/random.h [three_way_comparison] (operator!=):
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator_base_funcs.h (__distance):
Add always_inline attribute to overload for random
access iterators.
(advance, distance, next, prev): Add always_inline attribute to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107850
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:f54ceb2062c7fef294f85ae093914fa6c7ca35b8
commit r13-4306-gf54ceb2062c7fef294f85ae093914fa6c7ca35b8
Author: Jonathan Wakely
Hi Pete,
> On 25 Nov 2022, at 10:36, Peter Dyballa via Gcc wrote:
> On Mac OS X/macOS configure scripts leave conftest.dSYM subdirectories
> behind, created by dsymutil:
>
> checking for build system preprocessor... rm: conftest.dSYM: is a
> directory
> checking for build system
Hi guys,
On Fri, Nov 25, 2022 at 04:11:49PM +0800, Kewen.Lin wrote:
> on 2022/10/26 19:40, Jiufu Guo wrote:
> for "li/lis + oris/xoris", I interpreted it into four combinations:
>
>li + oris, lis + oris, li + xoris, lis + xoris.
>
> not sure just me interpreting like that, but the actual
This pulls in the toplevel portion of this binutils-gdb commit:
19e559f1c91bfaedbd2f91d85ee161f3f03fda3c libsframe: add the SFrame library
ChangeLog:
* Makefile.def: Add libsframe as new module with its dependencies.
* Makefile.in: Regenerated.
* configure.ac: Add
Hi,
this patch fixes streaming of resolution info when flag_incremental_link
== INCREMENTAL_LINK_NOLTO. Here we want to stream the info from WPA to
ltrans as usual.
Bootstrapped/regtested x86_64-linux, tested with kernel LTO builds.
Plan to commit it later today.
Honza
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860
--- Comment #7 from Andrew Pinski ---
The same issue you would run into even on Linux with qemu and gnu as (though
gcc does not add the right target options to as as it assumes you have one that
targets your target by default.
Hi Kito,
On Fri, 12 Aug 2022, Maciej W. Rozycki wrote:
> > LGTM, but with a nit, I don't get set.w but get an andi like below, so
> > maybe we should also scan-assembler-not andi? feel free to commit that
> > directly with that fix
> >
> > ```asm
> > sleu:
> >sgtua0,a0,a1# 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860
--- Comment #6 from simon at pushface dot org ---
The situation with aarch64-apple-darwin vs x86_64-apple-darwin isn't I think
quite like the standard cross-compilation scenario, because of Apple's Rosetta
x86_64 emulation and the fact that all
On 25/11/2022 07:39, LIU Hao via Gcc wrote:
I am a Windows developer and I have been writing x86 and amd64 assembly
for more than ten years. One annoying thing about GCC is that, for x86
if I need to write I piece of inline assembly then I have to do it
twice: one in AT syntax and one in Intel
Jiufu Guo via Gcc-patches writes:
> Hi Kewen,
>
> Thanks for your review on this patch!
>
> "Kewen.Lin" writes:
>
>> Hi Jeff,
>>
>> Sorry for the late review.
>>
>> on 2022/9/15 16:30, Jiufu Guo wrote:
>>> Hi,
>>>
>>> For a complicate 64bit constant, blow is one instruction-sequence to
>>>
Hi,
I am seeing an internal compiler error, related to this patch:
during GIMPLE pass: slp
options-save.cc: In function 'void cl_optimization_restore(gcc_options*,
gcc_options*, cl_optimization*)':
options-save.cc:1292:1: internal compiler error: in
supportable_widening_operation, at
On Tue, Nov 08, 2022 at 02:36:17PM +, Julian Brown wrote:
> @@ -3258,6 +3273,7 @@ c_omp_address_inspector::get_origin (tree t)
> || TREE_CODE (t) == SAVE_EXPR)
> t = TREE_OPERAND (t, 0);
>else if (TREE_CODE (t) == INDIRECT_REF
> +&& TREE_TYPE
Hi Kewen,
Thanks for your review on this patch!
"Kewen.Lin" writes:
> Hi Jeff,
>
> Sorry for the late review.
>
> on 2022/9/15 16:30, Jiufu Guo wrote:
>> Hi,
>>
>> For a complicate 64bit constant, blow is one instruction-sequence to
>> build:
>> lis 9,0x800a
>> ori 9,9,0xabcd
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832
--- Comment #16 from Michael_S ---
On unrelated note, why loop overhead uses so many instructions?
Assuming that I am as misguided as gcc about load-op combining, I would write
it as:
sub %rax, %rdx
.L3:
vmovupd (%rdx,%rax), %ymm1
> On Fri, 25 Nov 2022, Jan Hubicka wrote:
>
> > >
> > >
> > > > Am 25.11.2022 um 11:05 schrieb Jan Hubicka via Gcc-patches
> > > > :
> > > >
> > > >
> > > >>
> > > >> IPA profile instrumentation tries to clear the pure and const
> > > >> flags of functions but that's quite hopeless in
On Fri, 25 Nov 2022, Jan Hubicka wrote:
> >
> >
> > > Am 25.11.2022 um 11:05 schrieb Jan Hubicka via Gcc-patches
> > > :
> > >
> > >
> > >>
> > >> IPA profile instrumentation tries to clear the pure and const
> > >> flags of functions but that's quite hopeless in particular for
> > >>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107830
--- Comment #4 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:71f3036b8a83da7fb559923bc80687ea1dabe14a
commit r13-4303-g71f3036b8a83da7fb559923bc80687ea1dabe14a
Author: Tamar Christina
On Fri, Nov 25, 2022 at 1:03 PM LIU Hao via Gcc wrote:
>
> 在 2022/11/25 17:32, Jakub Jelinek 写道:
> > So just use -masm=intel yourself and don't force it on others.
> >
> > Other people are familiar with AT syntax rather than Intel syntax,
> > in fact, as history shows, Intel syntax is a second
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107830
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Similar story as PR103661, we again return a negative number
for __builtin_cpu_supports:
Documentation says:
int __builtin_cpu_supports(const char *feature)
This function returns a positive integer if the run-time CPU supports feature
and returns 0 otherwise.
while we return -2147483648.
Hi Kewen,
Thanks a lot for your insight comments!
"Kewen.Lin" writes:
> Hi Jeff,
>
> Sorry for the late reply.
>
> on 2022/10/26 19:40, Jiufu Guo wrote:
>> Hi,
>>
>> PR106708 constaint some constants which can be support by li/lis +
>> oris/xoris.
> typo?
Oh, typo!
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107867
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107866
--- Comment #3 from Richard Biener ---
For some reason we think that the .UBSAN_NULL call doesn't clobber the load
from nullptr:
[local count: 118111600]:
+ # VUSE <.MEM_3(D)>
+ pretmp_7 = MEM[(int *)0B];
[local count: 1073741824]:
Jiufu Guo via Gcc-patches writes:
> Hi Richard,
>
> Thanks a lot for your comments!
>
> Richard Biener writes:
>
>> On Wed, 23 Nov 2022, Jiufu Guo wrote:
>>
>>> Hi Jeff,
>>>
>>> Thanks a lot for your comments!
>>
>> Sorry for the late response ...
>>
>>> Jeff Law writes:
>>>
>>> > On
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107810
Eric Botcazou changed:
What|Removed |Added
Last reconfirmed||2022-11-25
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107868
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107868
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107866
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-11-25
Ever confirmed|0
>
>
> > Am 25.11.2022 um 11:05 schrieb Jan Hubicka via Gcc-patches
> > :
> >
> >
> >>
> >> IPA profile instrumentation tries to clear the pure and const
> >> flags of functions but that's quite hopeless in particular for
> >> const since that attribute prevails on the type and thus on each
> Am 25.11.2022 um 11:05 schrieb Jan Hubicka via Gcc-patches
> :
>
>
>>
>> IPA profile instrumentation tries to clear the pure and const
>> flags of functions but that's quite hopeless in particular for
>> const since that attribute prevails on the type and thus on each
>> call to the
在 2022/11/25 17:32, Jakub Jelinek 写道:
So just use -masm=intel yourself and don't force it on others.
Other people are familiar with AT syntax rather than Intel syntax,
in fact, as history shows, Intel syntax is a second class citizen that often
takes years to fix up for new instructions. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576
Adrian Perl changed:
What|Removed |Added
CC||adrian.perl at web dot de
--- Comment #5
1 - 100 of 196 matches
Mail list logo
