https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100467
--- Comment #4 from Bernd Edlinger ---
Created attachment 50778
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50778=edit
Proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100467
--- Comment #3 from Bernd Edlinger ---
Okay, after some debugging I see the problem.
Usually thunks are emitted from ymtab-thunks.cc:
cfun->is_thunk = 1;
insn_locations_init ();
set_curr_insn_location (DECL_SOURCE_LOCATION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100484
Bug ID: 100484
Summary: [12 regression] Test case gcc.dg/sso-9.c fails after
r12-622
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100482
--- Comment #1 from Jeremy R. ---
This appears to be valid for function return types as well but the compiler
does error when decltype is used in a function parameter
namespace std{}
int A(int a) { // fine
decltype(std) b = a;
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483
Bug ID: 100483
Summary: Extend -fno-semantic-interposition to global variables
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100482
Bug ID: 100482
Summary: namespaces as int in decltype expression
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100481
Bug ID: 100481
Summary: namespaces as int in decltype expression
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
We're going to start using gnulib in the sim, so make sure it exists.
ChangeLog:
* Makefile.def: Add configure-sim dependency on all-gnulib.
* Makefile.in: Regenerated.
---
Makefile.def | 1 +
Makefile.in | 1 +
2 files changed, 2 insertions(+)
diff --git a/Makefile.def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100249
--- Comment #8 from 康桓瑋 ---
(In reply to Patrick Palka from comment #6)
> > Maybe this can help:
> >
> > auto&& __proj_val = std::__invoke(__proj, __val);
> > if (std::__invoke(__comp,
> > std::forward(__proj_val),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480
abebeos at lazaridis dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100475
--- Comment #4 from 康桓瑋 ---
(In reply to 康桓瑋 from comment #3)
> Also, the operator->() simply uses operator& instead of std::__addressof.
>
> https://godbolt.org/z/zfGnEoePG
Another issue is that the has_value() of this specialization will
On Fri, Apr 30, 2021 at 1:20 PM Feng Xue OS via Gcc-patches
wrote:
>
> >> This patch implements a new loop optimization according to the proposal
> >> in RFC given at
> >> https://gcc.gnu.org/pipermail/gcc/2021-January/234682.html.
> >> So do not repeat the idea in this mail. Hope your comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100475
--- Comment #3 from 康桓瑋 ---
Also, the operator->() simply uses operator& instead of std::__addressof.
https://godbolt.org/z/zfGnEoePG
Hi!
On Fri, May 07, 2021 at 12:19:50PM +0930, Alan Modra wrote:
> --- a/gcc/varasm.c
> +++ b/gcc/varasm.c
> @@ -6866,6 +6866,26 @@ default_elf_asm_named_section (const char *name,
> unsigned int flags,
>*f = '\0';
> }
>
> + char func_label[256];
> + if (flags &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
On Fri, May 07, 2021 at 08:47:02AM -0500, will schmidt wrote:
> On Fri, 2021-05-07 at 12:19 +0930, Alan Modra via Gcc-patches wrote:
> > --- a/gcc/varasm.c
> > +++ b/gcc/varasm.c
> > @@ -6866,6 +6866,26 @@ default_elf_asm_named_section (const char
> > *name, unsigned int flags,
> >*f =
On Fri, May 07, 2021 at 12:19:51PM +0930, Alan Modra wrote:
> This reverts commit b680b9049737198d010e49cf434704c6a6ed2b3f now
> that the PowerPC64 ELFv1 regression is fixed properly.
This is okay when the rest goes in. Do it in a bisectable order if
possible? If that is easy :-)
Segher
On Fri, May 07, 2021 at 12:19:49PM +0930, Alan Modra wrote:
> This series of patches fixes -fpatchable-function-entry on PowerPC64
> ELFv1 so that SECTION_LINK_ORDER (.section 'o' arg) is now supported,
> and on PowerPC64 ELFv2 to not break the global entry code.
>
> Bootstrapped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #58 from abebeos at lazaridis dot com ---
Well, now I'm really really curious.
Does the gcc project have at least some(!) liberal qualities, or will
IT-fascism win?
Follow-up:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480
Bug ID: 100480
Summary: Where to file complaints re project-maintainers?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
On 5/7/21 2:48 PM, Jakub Jelinek via Gcc wrote:
The first release candidate for GCC 8.5 is available from
https://gcc.gnu.org/pub/gcc/snapshots/8.5.0-RC-20210507/
ftp://gcc.gnu.org/pub/gcc/snapshots/8.5.0-RC-20210507
and shortly its mirrors. It has been generated from git revision
r8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100479
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100479
Bug ID: 100479
Summary: range adaptors handle cached iterators incorrectly
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Hi!
On Fri, May 07, 2021 at 10:53:31AM -0500, Pat Haugen wrote:
> Code that has heavy register pressure on Altivec registers can suffer from
> over-aggressive scheduling during sched1, which then leads to increased
> register spill. This is due to the fact that registers that prefer
>
Indeed, libgomp fails to build:
configure: error: unsupported system, cannot find Fortran int kind=16,
needed for omp_depend_kind
I've reverted the patch for now. We'll just have to put up with a lot of
new test failures in the stand-alone toolchain so that the offload
toolchain will at
On 06/05/21 18:28 +0100, Jonathan Wakely wrote:
On 06/05/21 18:09 +0100, Jonathan Wakely wrote:
On 06/05/21 17:55 +0200, Stephan Bergmann wrote:
On 30/04/2021 15:48, Jonathan Wakely via Libstdc++ wrote:
This implements the resolution of LWG 1203 so that the constraints for
rvalue stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418
--- Comment #16 from CVS Commits ---
The master branch has been updated by Andrew Stubbs :
https://gcc.gnu.org/g:07d7d37d1a33efb04f1262e56f4b82d6e1089e75
commit r12-632-g07d7d37d1a33efb04f1262e56f4b82d6e1089e75
Author: Andrew Stubbs
Date:
On 07/05/2021 18:11, Tobias Burnus wrote:
On 07.05.21 18:35, Andrew Stubbs wrote:
TImode has always been a problem on amdgcn, and now it is causing many
new test failures, so I'm disabling it.
Does still still work with libgomp?
The patch sounds as if it might cause problems, but on the
Snapshot gcc-10-20210507 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20210507/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100478
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #7 from Steve Kargl ---
On Fri, May 07, 2021 at 09:12:15PM +, anlauf at gcc dot gnu.org wrote:
> --- Comment #6 from anlauf at gcc dot gnu.org ---
> There seems to be something fishy with default initialization of function
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100478
Bug ID: 100478
Summary: Type Pointer Segfaults
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
On Fri, May 07, 2021 at 10:20:11PM +0200, Thomas Schwinge wrote:
> Hi!
>
> I'm currently working on an OpenACC thing, which in 'omp-low' separately
> for each OpenACC 'loop' construct, collects variable declarations
> referenced in 'private' clauses as well as those from inner binds
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #6 from anlauf at gcc dot gnu.org ---
There seems to be something fishy with default initialization of function
results of derived types. Looking at the attached code, I guessed the
following potential reproducer:
program p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #5 from kargl at gcc dot gnu.org ---
David,
On amd64-*-freebsd, I see
% gfcx -o z -O2 -fcheck=all allocate_error.f95
% ./z
Sample 10. Eigenvalue from matrix powers.
Iterationeigenvalue approximation
0
Hi!
I'm currently working on an OpenACC thing, which in 'omp-low' separately
for each OpenACC 'loop' construct, collects variable declarations
referenced in 'private' clauses as well as those from inner binds
(simplified). Accidently that was also enabled for OpenMP, and for a few
testcases of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
--- Comment #5 from Iain Sandoe ---
(In reply to Jason Merrill from comment #3)
> (In reply to Jason Merrill from comment #2)
> > (In reply to Iain Sandoe from comment #1)
> > > I am by no means an expert at reading standardese - and it might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
--- Comment #4 from Iain Sandoe ---
great, that does simplify things - and means that a useful error can be
diagnosed from a mismatched type between g_r_o/g_r_o_o_a_f and the coroutine
ramp return value.
The statement about phasing of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
--- Comment #3 from Jason Merrill ---
(In reply to Jason Merrill from comment #2)
> (In reply to Iain Sandoe from comment #1)
> > I am by no means an expert at reading standardese - and it might be that I'm
> > not alone, (library writers might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
--- Comment #2 from Jason Merrill ---
(In reply to Iain Sandoe from comment #1)
> I am by no means an expert at reading standardese - and it might be that I'm
> not alone, (library writers might have made the same assumption) but it
> seems to
Status
==
The 8.5 branch is now frozen for the final GCC 8.5 release, the release
candidate has been announced. All changes to the branch require RM
approval.
Quality Data
Priority # Change from last report
--- ---
P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461
H.J. Lu changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|WAITING
The first release candidate for GCC 8.5 is available from
https://gcc.gnu.org/pub/gcc/snapshots/8.5.0-RC-20210507/
ftp://gcc.gnu.org/pub/gcc/snapshots/8.5.0-RC-20210507
and shortly its mirrors. It has been generated from git revision
r8-10959-g3488242b9a949ebc55b4a857380f94506f90ff76.
I have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246
--- Comment #4 from Iain Sandoe ---
for the record the patch in comment #3 allowed bootstrap to succeed on Darwin12
with clang 3.4-based Xcode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
--- Comment #1 from Iain Sandoe ---
I am by no means an expert at reading standardese - and it might be that I'm
not alone, (library writers might have made the same assumption) but it seems
to me that:
The current non-null processing only sets a bit for the block which
contains a non-null setting event.
We should check the dom tree to see if a predecessor dom block sets
non-null, otherwise we can miss it. We don't need to do this within the
propagation engines like the on-entry cache.
This patch cleans up the ssa_block_range class which represents the bulk
of the on-entry cache storage.
PR 100299 shows the we need better control over the cache, and different
approaches can be useful for different situations. In preparation for
fixing that PR, this patch:
1) Abstracts
Range on exit was not ding the right thing when a basic block contained
no statements other than a PHI node.
Rather than returning the value of the PHI, it was instead asking for
range-on-entry for the phi, which would trigger a walk back to the top
of the CFG looking for the definition.
Rename the outgoing_edge class to gimple_outgoing_edge, and provide an
extern entry point for convenience to return a range for the TRUE and
FALSE edges of a gcond.
Bootstraps on x86_64-pc-linux-gnu with no testsuite regressions.
Pushed.
Andrew
commit
We were always allocating the 255 max ranges for the default
condition. Instead, use int_range_max to build the default range,
then allocate and store only what is needed.
Bootstraps on x86_64-pc-linux-gnu with no testsuite regressions.
Pushed.
Andrew
commit
We were setting x % 0 to varying... change it to undefined.
Bootstraps on x86_64-pc-linux-gnu with no testsuite regressions.
Pushed.
Andrew
commit 2262206b82da0ab4050fe6168a7d09be4e4b3d0f
Author: Andrew MacLeod
Date: Mon Apr 26 17:46:31 2021 -0400
Change x mod 0 to produce UNDEFINED
Add some tweaks to gimple_range_global () that
1) incorporates code from vr-values to pick up initial parameter values
from IPA,
2) used before defined locals start with UNDEFINED instead of varying.
This makes a big difference when folding PHI nodes.
Bootstraps on x86_64-pc-linux-gnu
On 5/7/2021 5:09 AM, Eric Botcazou wrote:
Hi,
this makes add_subscript_info query the get_array_descr_info hook for the
actual information when it is defined.
Tested on x86-64/Linux, OK for mainline?
2021-05-07 Eric Botcazou
* dwarf2out.c (add_subscript_info): Retrieve the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #15
On 5/7/2021 10:26 AM, Andrew Stubbs wrote:
A recent patch from Alexandre added new calls to emit_move_insn with
PLUS expressions in the operands. Apparently this works fine on (at
least) x86_64, but fails on (at least) amdgcn, where the adddi3 patten
has clobbers that the movdi3 does not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #13 from Jakub Jelinek ---
The error is clear, the header you want to include doesn't exist, which is the
case.
Usually people use PCH as an optimization, have the header normally in search
path and have there also the precompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #12 from Marco Trevisan ---
Well, I see...
At least the error should be a bit clearer though.
Rebased the patch on current master. Please review.
Changelog stays the same:
New std::common_type assertions attempt to give a proper 'required from
here' hint for user code, do not bring many changes to the
implementation and check all the template parameters for completeness.
In some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
Marco Trevisan changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
On 4/29/21 11:17 PM, Richard Biener wrote:
On Thu, 29 Apr 2021, Indu Bhagat wrote:
Hello,
On 4/29/21 5:10 AM, Richard Biener wrote:
On Thu, 29 Apr 2021, Jose E. Marchesi wrote:
This commit introduces support for generating CTF debugging
information and BTF debugging information from GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87839
--- Comment #5 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:3488242b9a949ebc55b4a857380f94506f90ff76
commit r8-10959-g3488242b9a949ebc55b4a857380f94506f90ff76
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
Bug ID: 100477
Summary: Bogus -Wstringop-overflow warning on memset
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100475
--- Comment #2 from 康桓瑋 ---
Reduced example:
#include
struct S {
S() = default;
S(int, int) {}
S(std::initializer_list) = delete;
};
std::ranges::single_view single(std::in_place, 0, 0);
https://godbolt.org/z/d1bE8sPdd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100475
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2021-05-07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #8 from Marco Trevisan ---
It's also relevant to say that just using
main.c:
#include "gjs_pch.h"
int main(int argc, char**argv)
{
std::string s = "Hi";
return 0;
}
fails with:
❯ g++ -I _build main.c -o main -include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461
--- Comment #6 from Daniel Starke ---
Thank you for the suggestion, however, I am not involved in the mingw-w64
project. Furthermore, the fact that this regression remains against all
versions of mingw-w64 known to date does not change.
It is
On 07.05.21 18:35, Andrew Stubbs wrote:
TImode has always been a problem on amdgcn, and now it is causing many
new test failures, so I'm disabling it.
Does still still work with libgomp?
The patch sounds as if it might cause problems, but on the other hand,
I assume you did test it? To
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
--- Comment #9 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:e2979f8687f590461bef9f87bd997390af67312e
commit r8-10958-ge2979f8687f590461bef9f87bd997390af67312e
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
--- Comment #8 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:ec910efa1f70e3903091b23e80c5c554b4db6c9b
commit r9-9521-gec910efa1f70e3903091b23e80c5c554b4db6c9b
Author: Jakub Jelinek
pthread_cond_clockwait isn't added to TSAN_INTERCEPTORS which leads to
false positives regarding double locking of a mutex. This was
uncovered by a user reporting an issue to the google sanitizer github:
https://github.com/google/sanitizers/issues/1259
This patch copies code from the fix made in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:d7c8e6261532e7b2d16221becd5db11ded03e059
commit r10-9810-gd7c8e6261532e7b2d16221becd5db11ded03e059
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
--- Comment #6 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:8482ed658ca77bfd7fc119cd62afd5b70a024500
commit r11-8371-g8482ed658ca77bfd7fc119cd62afd5b70a024500
Author: Jakub Jelinek
TImode has always been a problem on amdgcn, and now it is causing many
new test failures, so I'm disabling it.
The mode only has move instructions defined, which was enough for SLP,
but any other code trying to use it without checking the optabs is a
problem.
The mode remains available for
This PR is about CTAD but the underlying problems are more general;
CTAD is a good trigger for them because of the necessary substitution
into constraints that deduction guide generation entails.
In the testcase below, when generating the implicit deduction guide for
the constrained constructor
A recent patch from Alexandre added new calls to emit_move_insn with
PLUS expressions in the operands. Apparently this works fine on (at
least) x86_64, but fails on (at least) amdgcn, where the adddi3 patten
has clobbers that the movdi3 does not. This results in ICEs in recog.
This patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc-*-* |powerpc*
Resolution|---
Wrapping a class lvalue in NON_LVALUE_EXPR is not sufficient to make it a
usable prvalue; callers must use force_rvalue instead.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* tree.c (rvalue): Assert expr is not a class lvalue.
---
gcc/cp/tree.c | 7 ++-
1 file
Around PR98469 I asked Jakub to wrap a class BIT_CAST_EXPR in TARGET_EXPR;
SPACESHIP_EXPR needs the same thing. The dummy CAST_EXPR created in
can_convert is another instance of a non-TARGET_EXPR prvalue, so let's use
the declval-like build_stub_object there instead.
Tested x86_64-pc-linux-gnu,
The TYPE_MAIN_VARIANT() here was, for casts to a typedef'd type name,
resulting in all information about the typedef's involvement getting
lost. This drops necessary information for warnings and can make them
confusing or even misleading. It also makes specialized warnings for
unspecified-size
Discussing the 98469 patch and class prvalues with Jakub also inspired me to
change the place that was mishandling BIT_CAST_EXPR and one other to use the
lvalue_kind machinery to decide whether something is a prvalue, instead of
looking specifically for a TARGET_EXPR.
Tested x86_64-pc-linux-gnu,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100473
Andrew Pinski changed:
What|Removed |Added
Component|c |middle-end
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99935
--- Comment #1 from Nick Clifton ---
Created attachment 50777
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50777=edit
Proposed patch
Here is a possible patch for the problem, adding a recursion limit to the
demangle_path() function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
Bug ID: 100476
Summary: coroutines: questionable handling of void
get_return_object
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79333
--- Comment #5 from CVS Commits ---
The master branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:601191b2a48cb8f4657bb2fa2270a7fde9d52e9c
commit r12-617-g601191b2a48cb8f4657bb2fa2270a7fde9d52e9c
Author: Christophe Lyon
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100475
Bug ID: 100475
Summary: semiregular-box's constructor uses wrong
list-initialization
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Add ALTIVEC_REGS as pressure class.
Code that has heavy register pressure on Altivec registers can suffer from
over-aggressive scheduling during sched1, which then leads to increased
register spill. This is due to the fact that registers that prefer
ALTIVEC_REGS are currently assigned an allocno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:170c850e4bd46745e2a5130b5eb09f9fceb98416
commit r12-616-g170c850e4bd46745e2a5130b5eb09f9fceb98416
Author: Jakub Jelinek
Date:
On May 7, 2021 4:12:02 PM GMT+02:00, Christophe Lyon
wrote:
>On Wed, 5 May 2021 at 09:56, Richard Biener wrote:
>>
>> This makes sure to follow SSA edges when folding eliminated stmts.
>> This reaps the same benefit as forwprop folding all stmts, not
>> waiting for one to produce copysign in
Implement mmx_pblendv to optimize V8HI, V4HI and V2SI mode
conditional moves for SSE4.1 targets.
2021-05-07 Uroš Bizjak
gcc/
PR target/98218
* config/i386/i386-expand.c (ix86_expand_sse_movcc):
Handle V8QI, V4HI and V2SI modes.
* config/i386/mmx.md (mmx_pblendvb): New insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218
--- Comment #6 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:5795ec0edc30e077a9900cf3ca0a04ad8ac5ac97
commit r12-615-g5795ec0edc30e077a9900cf3ca0a04ad8ac5ac97
Author: Uros Bizjak
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93320
vopl at bk dot ru changed:
What|Removed |Added
CC||vopl at bk dot ru
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #7 from Marco Trevisan ---
(In reply to Marco Trevisan from comment #6)
> # Works
> g++ -I _build main.c -o main -include string -include gjs_pch.h
Ouch, I forgot to delete an include after pasting
# Works
g++ -I _build main.c -o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #6 from Marco Trevisan ---
(In reply to Jakub Jelinek from comment #5)
> As documented - see
> https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html - PCH is only
> tried if no C token is seen before the #include directive
On Fri, May 07, 2021 at 09:53:29AM +0200, Jakub Jelinek wrote:
> Hi!
>
> Since the r0-85991-ga25a8f3be322fe0f838947b679f73d6efc2a412c
> https://gcc.gnu.org/legacy-ml/gcc-patches/2008-02/msg01329.html
> changes, so that we handle macros inside of pragmas that should expand
> macros, during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100473
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100465
--- Comment #5 from Jonathan Wakely ---
As a workaround the library could use __str.append or __str.operator+=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100474
Bug ID: 100474
Summary: ICE: in diagnose_trait_expr, at cp/constraint.cc:3706
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #4 from David.Smith at lmu dot edu ---
> Thanks for reduce this to a testcase. I don't see it attached
> to this email or in bugzilla. gcc.gno.org may have stripped
> the attachment (for some dumb reason). Feel free to send the
1 - 100 of 240 matches
Mail list logo
