https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82735
--- Comment #14 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #12)
> (In reply to Jakub Jelinek from comment #10)
> > Last touched in PR99563.
> > I guess for the explicit user vzeroupper we need to add the clobbers/sets
> > earlier
From: LevyHsu
Added implementation for builtin overflow detection, new patterns are listed
below.
---
Addition:
signed addition (SImode in RV32 || DImode in RV64):
add t0, t1, t2
sltit3, t2, 0
slt
On Mon, Apr 26, 2021 at 06:40:56PM +, Hongtao Yu wrote:
>Andi, thanks for pointing out the perf script issues. Can you please
>elaborate a bit on the exact issue you have seen? We’ve been using
>specific output of perf script such as mmap, LBR and callstack events
>filtered by
John Paul Adrian Glaubitz writes:
> On 4/28/21 7:59 PM, Senthil Kumar Selvaraj wrote:
OK for trunk.
>>>
>>> Anything else that keeps us from merging the changes? Would be great to
>>> have the last backend besides CR-16 finally converted to MODE_CC on trunk.
>>
>> Nope. Committed and
On Feb 22, 2021, Richard Biener wrote:
> On Fri, Feb 19, 2021 at 9:08 AM Alexandre Oliva wrote:
>>
>> Here's an improved version of the patch. Regstrapped on
>> x86_64-linux-gnu, with and without a patchlet that moved multi-pieces
>> ahead of setmem, and also tested with riscv32-elf.
>>
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100327
seurer at gcc dot gnu.org changed:
What|Removed |Added
Build||powerpc64*-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092
Alexandre Oliva changed:
What|Removed |Added
Assignee|aoliva at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100327
Bug ID: 100327
Summary: [12 regression] bootstrap failure after r12-228
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On Apr 28, 2021, Uros Bizjak wrote:
> On a related note, while looking at gcc/config.gcc, I noticed that
> there are two identical code blocks under ${target} i[34567]86-*-* and
> x86-64-*-*. As much as I have eyeballed the code, I can't find the
> difference, so perhaps these two blocks should
On Apr 28, 2021, Uros Bizjak wrote:
> i386.h is actually the default $tm_file for i386 and x86_64. It is not
> possible to use x86-64.h without i386.h, so you can simply delete the
> definition in x86-64.h.
> Regarding _PAD variant, please remove it and substitute #ifdef
>
Hello,
This is Nick Vidal from Rocket.Chat
We’ve been part of GSoC for 5 years now, and as a way to celebrate and
give back to the open source community, this year we are reaching out
to other GSoC organizations to provide assistance on setting up
Rocket.Chat to engage with students (pro bono).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100173
--- Comment #2 from Hongtao.liu ---
> but yes, cselim will also sink the first store, moving it across the
> scalar compute in the block. I might note that ideally we'd sink
> all the compute as well and end up with just a conditional load of
Hi,
I have a little know about for 'Sizes and offsets as runtime
invariants’,
and need to add vector types like V2SImode as compile-time constants
with enabled vector types of runtime invariants.
Could I enable two vector types at same time ?
I guess
This patch removes a FIXME I left for myself for GCC 12, along with
adjusting the relevant test.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/cp/ChangeLog:
DR 1312
* constexpr.c (cxx_eval_constant_expression): Don't check
integer_zerop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51793
--- Comment #4 from Bruno Haible ---
Correction to comment #3:
It works fine on
- Solaris 11.4 (gcc 7.3.0): foo.s contains '.p2align 4,,15'
- Solaris 11 OpenIndiana (gcc 7.2.0): likewise
- Solaris 11 OmniOS (gcc 9.3.0): foo.s contains '.p2align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100250
Martin Sebor changed:
What|Removed |Added
Known to fail|11.0, 12.0 |11.1.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100307
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51793
Bruno Haible changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100250
--- Comment #4 from CVS Commits ---
The master branch has been updated by Martin Sebor :
https://gcc.gnu.org/g:2c8bffa184dffba7976ba807ef0a1bbb6f66aa2d
commit r12-246-g2c8bffa184dffba7976ba807ef0a1bbb6f66aa2d
Author: Martin Sebor
Date: Wed
On 4/28/21 12:53 AM, Richard Biener wrote:
On Wed, Apr 28, 2021 at 1:30 AM Martin Sebor via Gcc-patches
wrote:
The free_lang_data pass is defined entirely in tree.c. Its code
changes only rarely (only 13% commits to tree.c), and unlike
the rest of tree.c, is even more rarely read. The pass
WG14 N2432, the C2x removal of old-style function definitions, also
changed the function type compatibility rules so that an unprototyped
declaration can be compatible with a non-variadic prototyped
declaration even if some function arguments are changed by the default
argument promotions. I
When the compute_objsize_r() function sees a pointer whose target
it can't determine it sets the size of the pointed to object to
the maximum but it doesn't clear the base0 flag to indicate that
the offset need not be zero-based. This is done when the source
is in SSA form but not before. Since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100326
Bug ID: 100326
Summary: Crash with `#pragma GCC unroll` when calling value
which can't be called in template function
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51793
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
On 4/28/21 2:24 PM, Patrick Palka wrote:
This makes tsubst_arg_types substitute into a function's parameter types
in left-to-right order instead of right-to-left order, in accordance with
DR 1227.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? [ diff generated
On Wed, Apr 28, 2021 at 1:18 PM Jim Wilson wrote:
>
> On Tue, Apr 27, 2021 at 12:45 AM Andrew Waterman wrote:
>>
>> > signed addition (SImode with RV64):
>> > add t0, t1, t2
>> > sext.w t3, t0
>> > bne t0, t3, overflow
>>
>> The following version has the same instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95872
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2021-04-28
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100322
--- Comment #7 from Marc Glisse ---
PR94589 then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100030
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100282
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100031
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
On Mon, Apr 26, 2021 at 5:45 AM Christoph Muellner
wrote:
> This series provides a cleanup of the current atomics implementation
> of RISC-V:
>
This looks OK to me, other than the issue with address instructions emitted
inside the lr/sc loop. That could be fixed with a follow up patch though.
Snapshot gcc-8-20210428 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20210428/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100248
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100325
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100325
Bug ID: 100325
Summary: missing warning with -O0 on sprintf overflow with
pointer plus offset
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity:
As reported in bug 82359, the preprocessor does not allow C++ digit
separators in the line number in a #line directive, despite the
standard syntax for that directive using digit-sequence which allows
digit separators.
There is some confusion in that bug about whether C++ is meant to
allow digit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100288
--- Comment #2 from Marek Polacek ---
Reduced test that shows the ICE:
class ostream;
template
concept OstreamInsertable = requires(ostream out, Type value) {
out << value;
};
struct FMT {};
class CSVTabIns {
template friend void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100288
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |11.2
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100316
Jim Wilson changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100313
--- Comment #3 from Marek Polacek ---
In fact, this is about -fno-delete-null-pointer-checks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100321
Tom de Vries changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment
On 4/28/21 7:59 PM, Senthil Kumar Selvaraj wrote:
>>> OK for trunk.
>>
>> Anything else that keeps us from merging the changes? Would be great to
>> have the last backend besides CR-16 finally converted to MODE_CC on trunk.
>
> Nope. Committed and pushed just now -
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100313
--- Comment #2 from Marek Polacek ---
Cleaned up:
template
struct Prop {
void notify()
{
if constexpr (A != nullptr) { }
}
};
struct S {
inline void fn() { }
};
int main()
{
Prop<::fn> prop;
prop.notify();
}
Requires only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80475
Patrick Palka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61806
--- Comment #9 from Patrick Palka ---
*** Bug 80475 has been marked as a duplicate of this bug. ***
On 4/27/2021 7:01 PM, Tom Tromey wrote:
This adds deleter objects for various kinds of protocol pointers to
libcc1. Existing specializations of argument_wrapper are then
replaced with a single specialization that handles all pointer types
via the appropriate deleter. The result here is a bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100313
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85263
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 85263, which changed state.
Bug 85263 Summary: [concepts] ICE with parameter pack matching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85263
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100283
--- Comment #2 from anlauf at gcc dot gnu.org ---
The testcase is accepted with -fdefault-integer-8.
This fixes a crash on invalid requires-expression: in this test,
current_template_parms is null so accessing TEMPLATE_PARMS_CONSTRAINTS
is going to fail. So don't crash, but make sure we've complained
already.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/cp/ChangeLog:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99465
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
Hi Andrew,
> I thought that was changed not to use the GOT on purpose.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63874
>
> That is if the symbol is not declared in the TU, then using the GOT is
> correct thing to do.
> Is the testcase gcc.target/aarch64/pr63874.c still working or is not
>
On Wed, Apr 28, 2021 at 10:26:44PM +0200, Tobias Burnus wrote:
> On 28.04.21 15:41, Jakub Jelinek wrote:
> > > @@ -261,6 +263,7 @@ gfc_match_omp_variable_list (const char *str,
> > > gfc_omp_namelist **list,
> > > + gfc_gobble_whitespace ();
> > >if ((allow_sections &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98391
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100269
--- Comment #1 from Iain Sandoe ---
Created attachment 50705
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50705=edit
patch under test
It doesn't seem that the rationale for the changes in r12-35/36 is captured
anywhere I could find -
On 28.04.21 15:41, Jakub Jelinek wrote:
@@ -261,6 +263,7 @@ gfc_match_omp_variable_list (const char *str,
gfc_omp_namelist **list,
+ gfc_gobble_whitespace ();
if ((allow_sections && gfc_peek_ascii_char () == '(')
|| (allow_derived && gfc_peek_ascii_char () == '%')
Is
On Tue, Apr 27, 2021 at 12:45 AM Andrew Waterman wrote:
> > signed addition (SImode with RV64):
> > add t0, t1, t2
> > sext.w t3, t0
> > bne t0, t3, overflow
>
> The following version has the same instruction count but offers more ILP:
>
> add t0, t1, t2
> addw t3,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98391
--- Comment #3 from Tom de Vries ---
Jakub, should this be marked as resolved-invalid?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98391
--- Comment #2 from Tom de Vries ---
Fixed by:
...
do i = 1, n
+!$omp atomic
c(i,j) = a(k) + c(i,j)
end do
...
On Wed, 28 Apr 2021, gengqi-linux via Gcc-patches wrote:
> I have been fixing a bug. It involved the Negative property of options,
> and I have some confusion about it.
Could you please explain the bug at the *user-visible* level? That is,
the particular options passed to the compiler, how
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98391
--- Comment #1 from Tom de Vries ---
Minimal example openmp:
...
program main
implicit none
integer :: i, j, k
integer :: n = 2
real :: a(2), c(2,2), cc(2,2)
a = 0.5
cc = 0
do j = 1, n
do k = 1, n
do i = 1, n
On 4/28/2021 1:56 PM, Tom Tromey wrote:
"Jeff" == Jeff Law writes:
Jeff> On 4/27/2021 7:01 PM, Tom Tromey wrote:
This changes libcc1 to use std::vector in the code that builds
function types. This avoids some explicit memory management.
libcc1/ChangeLog
2021-04-27 Tom Tromey
*
> "Jeff" == Jeff Law writes:
Jeff> On 4/27/2021 7:01 PM, Tom Tromey wrote:
>> This changes libcc1 to use std::vector in the code that builds
>> function types. This avoids some explicit memory management.
>>
>> libcc1/ChangeLog
>> 2021-04-27 Tom Tromey
>>
>> * libcp1plugin.cc
> This patch version is OK.
I just pushed the patch to master in Patrick's behalf.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100283
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Known to fail||11.1.0, 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100324
--- Comment #1 from Tor ---
Just compiled gcc-11.1.0 on aarch64. No problem for all languages.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100225
--- Comment #4 from Roman Zhuykov ---
Created attachment 50704
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50704=edit
Tested patch
Fix in https://gcc.gnu.org/pipermail/gcc-patches/2021-April/569110.html,
pushing to trunk tomorrow
Hi all!
Situation from PR was already caught earlier locally. So, I've just extracted
appropriate part, it also slightly modifies loop checks related to
non-single-set instructions.
Patch (attached) was successfully bootstrapped/regtested on aarch64-linux on
all active branches (8-12) with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100324
Bug ID: 100324
Summary: gcc-10.2.0 (and earlier) fails to build on x86_64, but
has builds just fine aarch64
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at mengyan1223 dot wang
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #12 from Jakub Jelinek ---
For valgrind, the quick workaround would be -march=z13 when compiling the s390x
tests that have register long double variables.
Here, at template definition time, ordinary name lookup for 'foo(t)'
finds the deleted function, and so we form a CALL_EXPR thereof. Later
at instantiation time, when initially substituting into this CALL_EXPR
with T=N::A, we end up calling mark_used on this deleted function before
we augment the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621
--- Comment #13 from anlauf at gcc dot gnu.org ---
(In reply to José Rui Faustino de Sousa from comment #12)
> I do not have the "edit" or "take" links and if I click "Not yet assigned to
> anyone" it tries to send an email to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377
--- Comment #15 from Anthony Sharp ---
This should now be fixed as part of my patch:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=be246ac2d26e1cb072f205bf97d5eac150220f3f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621
--- Comment #12 from José Rui Faustino de Sousa ---
(In reply to Dominique d'Humieres from comment #11)
> Did you try to click on 'take' in
>
> Assignee:
> Not yet assigned to anyone (edit) (take)
>
I do not have the "edit" or "take"
On 4/27/2021 7:01 PM, Tom Tromey wrote:
This changes libcc1 to use variadic templates for the "rpc" functions.
This simplifies the code and removes some possibility for mistakes.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* libcp1.cc (rpc): Use variadic template. Remove overloads.
On 4/27/2021 7:01 PM, Tom Tromey wrote:
This changes libcc1 to use variadic templates for the "call"
functions. The primary benefit is that this simplifies the code.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* rpc.hh (call): Use variadic template. Remove overloads.
*
On 4/27/2021 7:00 PM, Tom Tromey wrote:
Now that C++11 can be used in GCC, libcc1 can be changed to use
templates and type traits to handle unmarshalling all kinds of enums.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* marshall.hh (cc1_plugin::unmarshall): Use type traits.
*
This makes tsubst_arg_types substitute into a function's parameter types
in left-to-right order instead of right-to-left order, in accordance with
DR 1227.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? [ diff generated with -w to hide noisy whitespace changes ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #11 from Mark Wielaard ---
BTW. Disabling that test in valgrind produces another crash in another test
that looks similar:
gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../.. -I../../../include
-I../../../coregrind -I../../../include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100322
--- Comment #6 from Jonathan Wakely ---
So it's just bad codegen for <=> comparisons. Thanks, Barry.
The library part is a red herring, the operator> synthesized from <=> is fine
to use, it just produces bad code (with GCC, but not Clang).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100322
--- Comment #5 from Barry Revzin ---
Sorry meant to actually copy the reduction:
#include
bool compare_count(int a, int b)
{
return a > b;
}
bool compare(int a, int b)
{
return (a <=> b) > 0;
}
which generates:
compare_count(int,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100322
Barry Revzin changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100322
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> If you write it like this you get good codegen:
I think I messed up my testing, and it doesn't help. GCC always chooses the
synthesized operator> instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
On Wed, Apr 28, 2021 at 9:50 AM Wilco Dijkstra via Gcc-patches
wrote:
>
>
> Use a GOT indirection for extern weak symbols instead of a literal - this is
> the same as
> PIC/PIE and mirrors LLVM behaviour. Ensure PIC/PIE use the same offset
> limits for symbols
> that don't use the GOT.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100322
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #26 from CVS Commits ---
The releases/gcc-8 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:0d277114b4b2d0cb386c7abe409a81ca29d9d61d
commit r8-10926-g0d277114b4b2d0cb386c7abe409a81ca29d9d61d
Author: Uros Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #25 from CVS Commits ---
The releases/gcc-9 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:be20ca1d4ff79baf7425a48bb887495e1ea8f788
commit r9-9472-gbe20ca1d4ff79baf7425a48bb887495e1ea8f788
Author: Uros Bizjak
John Paul Adrian Glaubitz writes:
> Hi Senthil!
>
>> On Mon, Apr 26, 2021 at 9:20 AM Senthil Kumar Selvaraj via Gcc-patches
>> wrote:
>>>
>>> Hi,
>>>
>>> This is
>>> https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563638.html,
>>> rebased against latest gcc master. The only change is
On Tue, 2021-04-27 at 18:46 -0500, will schmidt wrote:
> On Mon, 2021-04-26 at 09:35 -0700, Carl Love wrote:
> > Will, Segher:
> >
> > This patch fixes the order of the argument in the vec_rlmi and
> > vec_rlnm builtins. The patch also adds a new test cases to verify
> > the fix.
> >
> > The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100317
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95810
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |8.5
Summary|Spurious UBSan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100323
Bug ID: 100323
Summary: #pragma and attribute optimize don't enable inlining
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Hi Richard,
> Just to check: I guess this part is an optimisation, because it
> means that we can share the GOT entry with other TUs. Is that right?
> I think it would be worth having a comment either way, whatever the
> rationale. A couple of other very minor things:
It's just to make the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100322
--- Comment #1 from Jonathan Wakely ---
Maybe related to either PR 94006 or PR 94566
Segher, Will:
The agreement for the sign extension builtin was to just make it Endian
aware rather then go with a more complex definition. The prior patch
has been updated with this new functionality.
This patch adds support for the 128-bit extension instruction and
corresponding builtin
On 28/04/21 17:57 +0100, Jonathan Wakely wrote:
On 07/04/21 18:18 +0100, Jonathan Wakely wrote:
On 07/04/21 17:59 +0100, Jonathan Wakely wrote:
On 07/04/21 13:46 +0100, Jonathan Wakely wrote:
On 07/04/21 15:41 +0300, Ville Voutilainen via Libstdc++ wrote:
On Wed, 7 Apr 2021 at 15:31,
1 - 100 of 366 matches
Mail list logo
