https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482
--- Comment #1 from ian at gcc dot gnu.org ---
Author: ian
Date: Fri May 17 05:49:22 2019
New Revision: 271310
URL: https://gcc.gnu.org/viewcvs?rev=271310=gcc=rev
Log:
PR go/90482
compiler: make value method of direct interface type
This patch to the Go frontend by Cherry Zhang make value methods of
direct interface types take a pointer argument.
Currently, a value method of a direct interface type takes the value
of the receiver, which is pointer shaped, as the first parameter.
When this method is called through interface,
Hi,
this patch cuts walks in aliasing_component_refs_p if the type we look for
can not fit into a given type by comparing their sizes. Similar logic
already exists in indirect_ref_may_alias_decl_p.
When we walk reference a.b.c.d.e looking for type x we only need to do
it if sizeof(a)>=sizeof(x)
Hi,
On Fri, 17 May 2019 at 13:37, wrote:
>
> From: Kewen Lin
>
> Hi,
>
> Previous version link:
> https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00654.html
>
> Comparing with the previous version, I moved the generic
> parts of rs6000 target hook to IVOPTs. But I still kept
> the target hook as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90514
Bug ID: 90514
Summary: Issue about enum type in gcc tree
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #1
Here is the simplified patch. I put back the _M_map checks, we'll see
later if those can be removed.
* include/bits/stl_deque.h
(_Deque_iterator<>::__ptr_to): Remove, use std::__ptr_rebind.
(_Deque_base(_Deque_base&&, const allocator_type&)): New.
2 other tests needed to be adapted in 21_strings. Attached patch applied.
2019-05-17 François Dumont
Move from state of allocators (LWG2593)
* include/bits/stl_deque.h
(_Deque_base(_Deque_base&&, false_type)): Remove.
(_Deque_base(_Deque_base&&, true_type)): Remove.
This patch is meant to give user a way to optimize away those empty loops which
are impossible to be recognized by compiler, such as C++ STL container-based
loop,
void f (std::map )
{
for (auto it = m.begin (); it != m.end (); ++it);
}
An option "-ffinite-loop" is added to
Hi Segher,
Please refer the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513 .
Thank you
~Umesh
On Fri, May 17, 2019 at 4:22 AM Segher Boessenkool
wrote:
>
> Hi Umesh,
>
> On Thu, May 16, 2019 at 06:12:48PM +0530, Umesh Kalappa wrote:
> > We are very new to Power abi and we are thinking to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90512
Bug ID: 90512
Summary: Pwerplcelfv2 :R2 is not updated to the TOC base .
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513
Bug ID: 90513
Summary: Pwerplcelfv2 :R2 is not updated to the TOC base .
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
From: Kewen Lin
Hi,
Previous version link:
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00654.html
Comparing with the previous version, I moved the generic
parts of rs6000 target hook to IVOPTs. But I still kept
the target hook as previous which checks some target
specific criteria like
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Spanish team of translators. The file is available at:
https://translationproject.org/latest/gcc/es.po
(This file, 'gcc-9.1.0.es.po', has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500
Guobing changed:
What|Removed |Added
CC||neochen.life at aliyun dot com
--- Comment #9
在 2019/5/17 上午6:04, Jakub Jelinek 写道:
On Thu, May 16, 2019 at 11:39:38PM +0200, Jakub Jelinek wrote:
One possibility is to add -fdump-tree-optimized and scan for
/* { dg-final { scan-tree-dump "pow \\(\[^\n\r]*\\); \\\[tail call\\\]"
"optimized" } } */
resp.
/* { dg-final { scan-tree-dump "log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500
Guobing changed:
What|Removed |Added
CC||guobing.chen at intel dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
--- Comment #13 from jojo ---
Hi, guys,
Any solution for this issue ?
My be the following patch is choice :) ?
Are there issue with applied this patch ?
--- tree-ssa-loop-ivopts-orig.c 2019-05-17 09:32:58.05200 +0800
+++
Hi Richard,
On Thu, 16 May 2019 at 21:14, Richard Biener wrote:
>
> On Wed, May 15, 2019 at 4:40 AM wrote:
> >
> > From: Kugan Vivekanandarajah
> >
> > gcc/ChangeLog:
> >
> > 2019-05-15 Kugan Vivekanandarajah
> >
> > PR target/88834
> > * tree-ssa-loop-ivopts.c
On 5/16/19 5:22 PM, Joseph Myers wrote:
On Tue, 14 May 2019, Martin Sebor wrote:
The attached patch fixes quoting, spelling, and other formatting
issues in diagnostics issued from files in the c-family/ directory
and pointed out by the -Wformat-diag warning.
Some of the changes in this patch
This patch to the Go frontend by Cherry Zhang intrinsifies the
runtime/internal/atomic functions. Currently the
runtime/internal/atomic functions are implemented in C using C
compiler intrinsics. This patch lets the Go frontend recognize these
functions and turn them into intrinsics directly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90511
Bug ID: 90511
Summary: bogus attributes silently accepted before struct or
union
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
On Thu, 16 May 2019, Maxim Kuvyrkov wrote:
> Let's avoid mixing the two discussions: (1) converting svn repo to git
> (and getting community consensus to switch to git) and (2) deciding on
> which branches to keep in the new repo.
>
> With git, we can always split away unneeded history by
On Wed, 15 May 2019, H.J. Lu wrote:
> This patch is updating all soft-fp from glibc, most changes are
> copyright years update, and changes other than years update are
>
> * soft-fp/extenddftf2.c: Use "_FP_W_TYPE_SIZE < 64" to check if
> 4_FP_W_TYPEs are used for IEEE quad precision.
Maciej W. Rozycki wrote:
On Wed, 15 May 2019, Jacob Bachmeyer wrote:
This patch really exposes a significant deficiency in our current
implementation of default_target_compile: the order of various flags
can be significant, but we only have that order implicitly expressed in
the code,
Hi Richard,
On Wed, 15 May 2019 at 16:57, Richard Sandiford
wrote:
>
> Thanks for doing this.
>
> kugan.vivekanandara...@linaro.org writes:
> > From: Kugan Vivekanandarajah
> >
> > gcc/ChangeLog:
> >
> > 2019-05-15 Kugan Vivekanandarajah
> >
> > PR target/88834
> > *
On Tue, 14 May 2019, Martin Sebor wrote:
> The attached patch fixes quoting, spelling, and other formatting
> issues in diagnostics issued from files in the c-family/ directory
> and pointed out by the -Wformat-diag warning.
Some of the changes in this patch are questionable. The diagnostics
This patch to the Go frontend by Cherry Zhang adds intrinsics for
runtime/internal/sys functions.
runtime/internal/sys.Ctz32/64 and Bswap32/64 are currently implemented
with compiler builtin functions. But if they are called from another
package, the compiler does not know and therefore cannot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90299
--- Comment #8 from Jonathan Wakely ---
Author: redi
Date: Thu May 16 23:09:51 2019
New Revision: 271302
URL: https://gcc.gnu.org/viewcvs?rev=271302=gcc=rev
Log:
PR libstdc++/90299 make filesystem::absolute overloads consistent
In this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90509
--- Comment #4 from Maurizio Drocco ---
Sorry I was forgetting the requirement, thank you for remarking it.
Hi,
when Roberto Agostino and I implemented the front-end devirtualization
of final overriders we missed this case, where it comes from the base.
It seems to me that by way of access_path the existing approach can be
neatly extended. Tested x86_64-linux.
Thanks, Paolo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90299
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90299
--- Comment #7 from Jonathan Wakely ---
Author: redi
Date: Thu May 16 23:00:26 2019
New Revision: 271301
URL: https://gcc.gnu.org/viewcvs?rev=271301=gcc=rev
Log:
PR libstdc++/90299 make filesystem::absolute overloads consistent
In this
On Tue, 14 May 2019, Maxim Kuvyrkov wrote:
> The scripts convert svn history branch by branch. They rely on git-svn
> on convert individual branches. Git-svn is a good tool for converting
> individual branches. It is, however, either very slow at converting the
> entire GCC repo, or goes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90509
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Maciej W. Rozycki wrote:
On Wed, 15 May 2019, Jacob Bachmeyer wrote:
[...]
We are not consistent here in `gnat_target_compile' anyway, as you can
see from the two existing `concat' invocations, and also the `timeout=300'
element.
That is the GCC testsuite rather than DejaGnu itself, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90509
Maurizio Drocco changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Hi Umesh,
On Thu, May 16, 2019 at 06:12:48PM +0530, Umesh Kalappa wrote:
> We are very new to Power abi and we are thinking to handle this case
> in loader like go through the relocations like R_PPC64_REL24 and
> found symbol has the localentry ,then compute the delta (GEP - LEP )
> and patch
The assertion is wrong, it should be *s.end() == 0, but that's not
allowed. Just remove it, but keep the comment.
* src/c++17/fs_ops.cc (absolute(const path&, error_code&))
[_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Remove bogus assertion.
Tested x86_64-w64-mingw32, committed to trunk.
On Thu, May 16, 2019 at 12:03:14PM +0100, Iain Sandoe wrote:
> I did a quick check...
>
> dfp.exp most (all?) fail despite
>
> /* { dg-require-effective-target powerpc_p9vector_ok } */
>
> with errors like this…
>
> error: decimal floating point not supported for this target
Okay, so the test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90509
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Snapshot gcc-7-20190516 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190516/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7
On Mon, 1 Apr 2019, apin...@marvell.com wrote:
> From: Andrew Pinski
>
> Hi,
> The problem here is the token->val.node is not saved over
> a precompiled header for C++ operator. This can cause an
> internal compiler error as we tried to print out the spelling
> of the token as we assumed it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90509
Bug ID: 90509
Summary: failing typing std::transform with policies on
std::insert_iterator
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90472
--- Comment #3 from joseph at codesourcery dot com ---
This is not a bug.
If 'i' is not redeclared in an intermediate scope, so the visible
declaration is one at file scope, the rule that "if the prior declaration
specifies internal or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90510
Bug ID: 90510
Summary: [10 Regression] Unnecessary permutation
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90510
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
On Thu, May 16, 2019 at 11:39:38PM +0200, Jakub Jelinek wrote:
> One possibility is to add -fdump-tree-optimized and scan for
> /* { dg-final { scan-tree-dump "pow \\(\[^\n\r]*\\); \\\[tail call\\\]"
> "optimized" } } */
> resp.
> /* { dg-final { scan-tree-dump "log \\(\[^\n\r]*\\); \\\[tail
On 16/05/19 13:07 -0600, Jeff Law wrote:
On 5/16/19 12:36 PM, Ramana Radhakrishnan wrote:
On Thu, May 16, 2019 at 5:41 PM Maxim Kuvyrkov
wrote:
On May 16, 2019, at 7:22 PM, Jeff Law wrote:
On 5/15/19 5:19 AM, Richard Biener wrote:
For the official converted repo do we really want all
Since MMX intrinsics are marked with SSE/SSE2/SSSE3 for SSE emulation,
enable them without SSE/SSE2/SSSE3 if MMX is enabled.
Restore TARGET_3DNOW check, which was changed to TARGET_3DNOW_A by
revision 271235.
gcc/
PR target/90497
* config/i386/i386-expand.c
Hi!
As mentioned in the PR, if we are very unlucky and have a hash collision
not just when hash % hash table size is equal, but when the whole 32-bit
hash is equal, we can actually end up with compatible types (bool vs.
unsigned : 1 on the testcase), but sz0 != sz1 (one is 1-bit, the other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90484
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Thu May 16 21:45:34 2019
New Revision: 271299
URL: https://gcc.gnu.org/viewcvs?rev=271299=gcc=rev
Log:
PR c++/90484
* tree-ssa-scopedtables.c (equal_mem_array_ref_p):
Hi Jeff,
On Thu, May 16, 2019 at 12:41:16PM -0600, Jeff Law wrote:
> For architectures like PPC, we probably don't want to use the loop count
> for anything else as it's likely expensive to get data in/out of the the
> loop count register.
That is part of it. Another part is that it costs extra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90497
--- Comment #6 from Jakub Jelinek ---
Looks good on i686-linux, results in
FAIL: gcc.target/i386/pr90497-2.c (test for excess errors)
Excess errors:
/home/jakub/src/gcc/gcc/testsuite/gcc.target/i386/pr90497-2.c:11:10: warning:
implicit
On Wed, May 08, 2019 at 06:09:06PM +0800, JunMa wrote:
> 2019-05-07 Jun Ma
>
> PR tree-optimization/90106
> * gcc.dg/cdce1.c: Check tailcall code generation after cdce pass.
> * gcc.dg/cdce2.c: Likewise.
This is wrong and results in UNSUPPORTED failures.
Both tests are dg-do run,
Hi, I've been playing some with the PGO build infrastructure and have a
few changes I thought I'd share and get feedback on whether they're
completely crazy or not. I'm not terribly familiar with the innards of
the build infra, so would appreciate any comments and suggestions.
First, a recap of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89765
--- Comment #14 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Thu May 16 21:10:32 2019
New Revision: 271297
URL: https://gcc.gnu.org/viewcvs?rev=271297=gcc=rev
Log:
gcc/ChangeLog:
2019-05-16 Kelvin Nilsen
Backport from
Hi Janne,
I differ there.
A longer explanation:
fork() is standard POSIX. Not all systems have posix_spawn. For
those systems which do not have it, we would cause a regression
by simply removing that functionality for this.
The patch is OK from my side if you add fork() as a fallback
Am 16.05.19 um 22:10 schrieb Janne Blomqvist:
On Thu, May 16, 2019 at 10:59 PM Thomas Koenig wrote:
Hi Janne,
fork() semantics can be problematic. Most unix style OS'es have
posix_spawn which can be used to replace fork + exec in many cases.
For more information see
e.g.
On Thu, 16 May 2019 at 23:28, Jonathan Wakely wrote:
> Here's what I've tested and am about to commit.
Looks good to me.
On 16/05/19 12:43 +0100, Jonathan Wakely wrote:
On 16/05/19 12:29 +0100, Jonathan Wakely wrote:
These two changes both result in smaller code for std::variant.
The first one means smaller tables of function pointers, because we
don't generate an instantiation for the valueless state. Instead
* include/std/variant (__overload_set): Remove.
(_Arr): New helper.
(_Build_FUN): New class template to define a single FUN overload,
with specializations to prevent unwanted conversions, as per P0608R3.
(_Build_FUNs): New class template to build an
On 5/16/19 8:58 AM, Roland Illig wrote:
Hi Martin,
I'm impressed how much work you have put into the patches for detecting
nonoptimal diagnostics. It takes a long time to read through the
patches, but it's worth it, knowing that it took much longer for you to
prepare the patch, and that I won't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458
--- Comment #2 from Jeffrey A. Law ---
So this is an interaction between stack-clash protection and SEH. I'm not *at
all* familiar with SEH, though obviously I know a bit about stack clash.
In general on x86 the compiler handles stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90508
Bug ID: 90508
Summary: GCC does not produce full template backtraces when
instantiating but not calling virtual functions
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
On Thu, May 16, 2019 at 10:59 PM Thomas Koenig wrote:
>
> Hi Janne,
>
> > fork() semantics can be problematic. Most unix style OS'es have
> > posix_spawn which can be used to replace fork + exec in many cases.
> > For more information see
> > e.g.
> >
We can scan stack for return address to get vector arguments passed on
stack.
* gcc.target/x86_64/abi/test_varargs-m128.c: New file.
* gcc.target/x86_64/abi/avx/test_varargs-m256.c: Likewise.
* gcc.target/x86_64/abi/avx512f/test_varargs-m512.c: Likewise.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
Janne Blomqvist changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/gcc-
Hi Janne,
fork() semantics can be problematic. Most unix style OS'es have
posix_spawn which can be used to replace fork + exec in many cases.
For more information see
e.g.
https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf
This replaces the one use of fork in
fork() semantics can be problematic. Most unix style OS'es have
posix_spawn which can be used to replace fork + exec in many cases.
For more information see
e.g.
https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf
This replaces the one use of fork in libgfortran with
Hi Jakub!
On Thu, 16 May 2019 17:54:23 +0200, Jakub Jelinek wrote:
> On Thu, May 16, 2019 at 05:21:56PM +0200, Thomas Schwinge wrote:
> > > Jakub, would you please especially review the non-OpenACC-specific
> > > changes here, including the libgomp ABI changes?
> >
> > Given a baseline that
On 5/14/19 3:32 PM, Martin Sebor wrote:
> The attached patch adjusts the expected test output to the quoting,
> spelling and other formatting changes in diagnostics to fix issues
> pointed out by the -Wformat-diag warning.
>
> Martin
>
> gcc-wformat-diag-tests.diff
>
> gcc/testsuite/ChangeLog:
On Thu, May 16, 2019 at 04:58:08PM +0200, Roland Illig wrote:
> - error ("#pragma GCC target string... is badly formed");
> + error ("%<#pragma GCC target%> string is badly formed");
> - error ("#pragma GCC optimize string... is badly formed");
> + error ("%<#pragma GCC
On 5/14/19 3:32 PM, Martin Sebor wrote:
> The attached patch fixes quoting, spelling, and other formatting
> issues in diagnostics issued from files in middle-end files and
> pointed out by the -Wformat-diag warning.
>
> Martin
>
> gcc-wformat-diag-midend.diff
>
> gcc/ChangeLog:
>
> *
On 5/14/19 3:32 PM, Martin Sebor wrote:
> The attached patch fixes quoting, spelling, and other formatting
> issues in diagnostics issued by the C++ front-end and pointed out
> by the -Wformat-diag warning.
>
> Martin
>
> gcc-wformat-diag-cp.diff
>
> gcc/cp/ChangeLog:
>
> * call.c
On 5/14/19 3:32 PM, Martin Sebor wrote:
> The attached patch fixes quoting, spelling, and other formatting
> issues in diagnostics issued from files in the c-family/ directory
> and pointed out by the -Wformat-diag warning.
>
> Martin
>
> gcc-wformat-diag-c-family.diff
>
>
On 5/14/19 3:33 PM, Martin Sebor wrote:
> The attached patch fixes quoting, spelling, and other formatting
> issues in diagnostics issued by the i386 back-end and pointed out
> by the -Wformat-diag warning.
>
> Martin
>
> gcc-wformat-diag-i386.diff
>
> gcc/ChangeLog:
>
> *
On 5/14/19 3:33 PM, Martin Sebor wrote:
> The attached patch fixes quoting, spelling, and other formatting
> issues in diagnostics issued by the D front end and pointed out
> by the -Wformat-diag warning.
>
> Martin
>
> gcc-wformat-diag-d.diff
>
> gcc/d/ChangeLog:
>
> * d/d-builtins.cc
On 5/14/19 3:32 PM, Martin Sebor wrote:
> The attached patch fixes quoting, spelling, and other formatting
> issues in diagnostics issued by the Brig front end and pointed
> out by the -Wformat-diag warning.
>
> Martin
>
> gcc-wformat-diag-brig.diff
>
> gcc/brig/ChangeLog:
>
> *
On 5/14/19 3:32 PM, Martin Sebor wrote:
> The attached patch fixes quoting, spelling, and other formatting
> issues in diagnostics issued from files in the libgcc directory
> and pointed out by the -Wformat-diag warning.
>
> Martin
>
> gcc-wformat-diag-libgcc.diff
>
> libgcc/ChangeLog:
>
>
On 5/14/19 3:32 PM, Martin Sebor wrote:
> The attached patch fixes quoting, spelling, and other formatting
> issues in diagnostics issued by the C front-end and pointed out
> by the -Wformat-diag warning.
>
> Martin
>
> gcc-wformat-diag-c.diff
>
> gcc/c/ChangeLog:
>
> * c-decl.c
On 5/14/19 3:31 PM, Martin Sebor wrote:
> The attached patch fixes quoting, spelling, and other formatting
> issues in diagnostics issued by the Ada front and pointed out by
> the -Wformat-diag warning.
>
> Martin
>
> gcc-wformat-diag-ada.diff
>
> gcc/ada/ChangeLog:
>
> *
On 5/16/19 12:36 PM, Ramana Radhakrishnan wrote:
> On Thu, May 16, 2019 at 5:41 PM Maxim Kuvyrkov
> wrote:
>>
>>> On May 16, 2019, at 7:22 PM, Jeff Law wrote:
>>>
>>> On 5/15/19 5:19 AM, Richard Biener wrote:
For the official converted repo do we really want all (old)
development
The following picks up the patch from last December, refactoring
aff_combination_expand to not use gimple_assign_rhs_to_tree
but analyze GIMPLE stmts directly.
Last December I was stuck at
FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI" 1
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440
--- Comment #8 from rguenther at suse dot de ---
On Thu, 16 May 2019, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440
>
> --- Comment #7 from Martin Liška ---
> (In reply to Richard Biener from comment
On 5/16/19 12:46 PM, Richard Biener wrote:
> On Thu, May 16, 2019 at 6:14 PM Jeff Law wrote:
>>
>> On 5/15/19 3:03 PM, Alexandre Oliva wrote:
>>> On May 15, 2019, Richard Biener wrote:
>>>
On Wed, May 15, 2019 at 10:20 AM Alexandre Oliva wrote:
>
> Gimple jump threading does not
On Thu, May 16, 2019 at 6:14 PM Jeff Law wrote:
>
> On 5/15/19 3:03 PM, Alexandre Oliva wrote:
> > On May 15, 2019, Richard Biener wrote:
> >
> >> On Wed, May 15, 2019 at 10:20 AM Alexandre Oliva wrote:
> >>>
> >>> Gimple jump threading does not duplicate forwarder blocks that might
> >>> be
On 5/15/19 2:47 AM, Richard Biener wrote:
> On Wed, 15 May 2019, Kewen.Lin wrote:
>
>> on 2019/5/14 下午3:26, Richard Biener wrote:
>>> On Tue, May 14, 2019 at 5:10 AM wrote:
From: Kewen Lin
Previous version link for background:
On Thu, May 16, 2019 at 4:04 PM Martin Jambor wrote:
>
> Hi Richi,
>
> On Thu, May 16 2019, Richard Biener wrote:
> > On Fri, May 10, 2019 at 10:31 AM Martin Jambor wrote:
> >>
> >> Hello,
> >>
> >> this is a follow-up from a WIP patch I sent here in late December:
> >>
On Thu, May 16, 2019 at 5:41 PM Maxim Kuvyrkov
wrote:
>
> > On May 16, 2019, at 7:22 PM, Jeff Law wrote:
> >
> > On 5/15/19 5:19 AM, Richard Biener wrote:
> >>
> >> For the official converted repo do we really want all (old)
> >> development branches to be in the
> >> main git repo? I suppose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90501
Richard Biener changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90507
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On 5/15/19 8:08 PM, kugan.vivekanandara...@linaro.org wrote:
> From: Kugan Vivekanandarajah
>
> This patch changes cse_insn to process parallel rtx one by one such that
> any destination rtx in cse list is invalidated before processing the
> next.
>
> gcc/ChangeLog:
>
> 2019-05-16 Kugan
On 5/16/19 5:19 AM, Martin Liška wrote:
> Hi.
>
> With LTO and -fsanitize we end up with a static ctor
> (_GLOBAL__sub_I_00099_0_main) that has no source location.
> With that stack usage will print '(artificial)' as a location
> of the function.
>
> Patch can bootstrap on x86_64-linux-gnu and
On 5/14/19 10:29 PM, bin.cheng wrote:
> Hi,
> As noted in PR57534 comment #33, SLSR currently doesn't strength reduce memory
> references in reported cases, which conflicts with its comment at the
> beginning of file.
> The main reason is in functions slsr_process_ref and restructure_reference
>
On Wed, May 15, 2019 at 2:46 PM Richard Sandiford
wrote:
>
> Max Filippov writes:
> > Let backends call assemble_start_function after they have generated
> > thunk function body so that a constant pool could be output if it is
> > required. This may help backends to avoid implementing custom
On Thu, May 16, 2019 at 09:25:49AM +0200, Richard Biener wrote:
> On Wed, 15 May 2019, Segher Boessenkool wrote:
> > > Otherwise I understand that IVOPTs doesn't properly cost
> > > the doloop IV update and conditional branch.
> >
> > Currently it doesn't even *know* something is or isn't a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90501
--- Comment #11 from Iain Buclaw ---
(In reply to Jakub Jelinek from comment #8)
> So the first question would be why D passes the return value as
> DECL_BY_REFERENCE if it doesn't have TREE_ADDRESSABLE type.
Looking at the places where
> On May 16, 2019, at 7:22 PM, Jeff Law wrote:
>
> On 5/15/19 5:19 AM, Richard Biener wrote:
>>
>> For the official converted repo do we really want all (old)
>> development branches to be in the
>> main git repo? I suppose we could create a readonly git from the
>> state of the whole
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90505
--- Comment #3 from Marek Polacek ---
Seems to be caused by this change:
@@ -16327,15 +16388,6 @@ cp_parser_template_name (cp_parser* parser,
}
}
- /* If DECL is dependent, and refers to a function, then just return
- its name;
1 - 100 of 247 matches
Mail list logo
