On Mon, Apr 06, 2020 at 09:42:17PM -0400, David Malcolm via Gcc-patches wrote:
> > 2020-04-06 Gustavo Romero
> >
> > * dumpfile.c:
> > (selftest::temp_dump_context::temp_dump_context): Fix ctor.
> > ---
> > gcc/dumpfile.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
On Tue, Apr 7, 2020 at 12:51 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase is miscompiled in 8.x, because emit_reduc_half is
> prepared to handle for 512-bit modes only i equal to 512, 256, 128 and 64.
> V32HImode also needs i equal to 32 and V64QImode i equal to 32 and 16,
> but emit
Since commit e154242724b084380e3221df7c08fcdbd8460674 the flag -many is
sometimes not passed to the assembler. Use .machine ppc to prevent
errors if these files are assembled for an ISA which does not support
FPRs.
libgcc/
* config/rs6000/crtresfpr.S: Use .machine ppc.
* config/r
duplicate_decls assumed that any TREE_ARTIFICIAL function at namespace scope
was a built-in function, but now in C++20 it's possible to have an
implicitly declared hidden friend operator==. We just need to move the
assert into the if condition.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/
Hi,
The patch is tested and works fine. It is more appropriate to handle the
context by considering it as a section of assemble code.
A minor question is that I think svst functions are for store operations. Why
pass ISRA_CTX_LOAD to scan_expr_access rather than ISRA_CTX_STORE?
Thanks,
Bu Le
On Mon, 2020-04-06 at 21:42 -0400, David Malcolm via Gcc-patches wrote:
> On Mon, 2020-04-06 at 19:44 -0400, Gustavo Romero wrote:
>
> Thanks for this patch.
>
> The patch looks correct, but I'm not sure that the description of the
> problem is exact in every detail. I think you've run into a bu
On Mon, 2020-04-06 at 19:44 -0400, Gustavo Romero wrote:
Thanks for this patch.
The patch looks correct, but I'm not sure that the description of the
problem is exact in every detail. I think you've run into a bug in
code I wrote; sorry.
> Currently an use of get() method of dump_context single
While reducing something else I noticed that we ICE on the following
invalid code. In tsubst_lambda_expr, tsubst_template_decl has already
reported an error and returned the error_mark_node, so make sure we
don't ICE on that. I'm using a goto here because we still have to
do finish_struct because
I merged master revision 52fa80f853c0b0f623ea9e4c7198e324ce44ff30 to
the gccgo branch.
Ian
Currently an use of get() method of dump_context singleton in optinfo
framework causes a new class to be instantiated, which calls the singleton
dtor when the class is destroyed, freeing memory that is referenced after
free() is called, generating an ICE error.
This commit fixes the issue by using
When GCC9 is built with older GCC (4.7) on FreeBSD 32-bit on PowerPC an ICE
is generated on stage 1 when selftests are performed.
After an investigation the root cause was traced to an unnecessary and
harmful instantiation of a new dump_context singleton class in order to
simply get the current
I've committed a libgo patch to update to the current Go 1.14 release
branch, which is close to the 1.14.2 release. Bootstrapped and tested
on x86_64-pc-linux-gnu. Committed to mainline.
Ian
2b280af10aa96cb5a6f20a695636b83a187a4e9b
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
i
Hi,
On Thu, Apr 02 2020, Richard Biener wrote:
> On Thu, Apr 2, 2020 at 5:36 AM bule wrote:
>>
>> Hello,
>>
>> An Internal Compiler Error(ICE) is found in ipa-sra optimization pass when
>> it handle the argument of internal call svst3 for SVE.
>>
>> The problem comes from
>> gcc/testsuite/gcc.t
On Tue, 2020-04-07 at 00:33 +0200, Jakub Jelinek wrote:
> Hi!
>
> getopt.c hangs the compiler on h8300-elf with -O2 -g, because the
> IL contains addition of constant 0, the first PLUS operand is determined
> to have the SP_DERIVED_VALUE_P and the new code in cselib recurses
> indefinitely on seei
Hi!
The following testcase is miscompiled in 8.x, because emit_reduc_half is
prepared to handle for 512-bit modes only i equal to 512, 256, 128 and 64.
V32HImode also needs i equal to 32 and V64QImode i equal to 32 and 16,
but emit_reduc_half in that case performs a redundant permutation exactly
l
On Tue, Mar 31, 2020 at 2:07 AM Kito Cheng wrote:
> - Implied rule are introduced into latest RISC-V isa spec.
>
> - Only implemented D implied F-extension. Zicsr and Zifence are not
> implement yet, so the rule not included in this patch.
When I try this patch, I see an error:
rohan:213
On Tue, Mar 31, 2020 at 2:06 AM Kito Cheng wrote:
> - The arch string rule has changed in latest spec, it introduced new
>multi-letter extension prefix with 'h' and 'z', and drop `sx`. also
>adjust parsing order for 's' and 'x'.
This looks OK to me.
Jim
Hi!
For -fsanitize=vptr, we insert a NULL store into the vptr instead of just
adding a CLOBBER of this. build_clobber_this makes the CLOBBER conditional
on in_charge (implicit) parameter whenever CLASSTYPE_VBASECLASSES, but when
adding this conditionalization to the -fsanitize=vptr code in PR8709
On Mon, 6 Apr 2020, Jeff Law wrote:
> > libatomic/
> > * configure.ac: Add testsuite/libatomic-site-extra.exp to output
> > files.
> > * configure: Regenerate.
> > * libatomic/testsuite/libatomic-site-extra.exp.in: New file.
> > * testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_
Hi!
On Mon, Apr 06, 2020 at 10:35:34PM +0200, Sebastian Huber wrote:
> What do you think about the attached patch?
(Please use a correct MIME type for attachments (x-* never is correct on
mailing lists. Just text/plain will do fine.)
> libgcc/
>
> * config/rs6000/crtresfpr.S: Disable all
On Mon, 6 Apr 2020, Jeff Law wrote:
> > libgomp/
> > * configure.ac: Add testsuite/libgomp-site-extra.exp to output
> > files.
> > * configure: Regenerate.
> > * testsuite/libgomp-site-extra.exp.in: New file.
> > * testsuite/libgomp-test-support.exp.in (GCC_UNDER_TEST): Re
Hi!
getopt.c hangs the compiler on h8300-elf with -O2 -g, because the
IL contains addition of constant 0, the first PLUS operand is determined
to have the SP_DERIVED_VALUE_P and the new code in cselib recurses
indefinitely on seeing SP_DERIVED_VALUE_P with locs of
(plus:P SP_DERIVED_VALUE_P (const
On Mon, 6 Apr 2020, Jason Merrill wrote:
> On 4/6/20 3:07 PM, Patrick Palka wrote:
> > This PR reports that since the introduction of the
> > CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag, we are sometimes failing to resolve
> > PLACEHOLDER_EXPRs inside array initializers that refer to some inner
> > cons
On Mon, 2020-04-06 at 12:52 -0400, Michael Meissner via Gcc-patches wrote:
Hi,
Just a single extra blank line below.
I'm still not a fan of the "Do not set..." comment, but will assume there
is history that necessitates the comment.
Other sections looked OK to me.
Over to Segher. :-)
Thanks,
Hi,
when sra_modify_expr is invoked on an expression that modifies only
part of the underlying replacement, such as a BIT_FIELD_REF on a LHS
of an assignment and the SRA replacement's type is not compatible with
what is being replaced (0th operand of the B_F_R in the above
example), it does not wo
Ping 2: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542012.html
Thanks,
- Eddy B.
On Fri, Mar 13, 2020, at 10:28 PM, Eduard-Mihai Burtescu wrote:
> This is the libiberty (mainly for binutils/gdb) counterpart of
> https://github.com/alexcrichton/rustc-demangle/pull/23.
>
> Relevant links
On Mon, Apr 06, 2020 at 04:10:24PM -0400, Fritz Reese wrote:
> On Sat, Apr 4, 2020 at 2:58 PM Steve Kargl via Fortran
> wrote:
> >
> > This patch fixes the ICE found in PR93686.
> >
> >
> > Index: gcc/fortran/decl.c
> > ===
> > --- gc
On 4/6/20 3:07 PM, Patrick Palka wrote:
This PR reports that since the introduction of the
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag, we are sometimes failing to resolve
PLACEHOLDER_EXPRs inside array initializers that refer to some inner
constructor. In the testcase in the PR, we have as the initia
On 4/6/20 11:45 AM, Patrick Palka wrote:
On Wed, 1 Apr 2020, Jason Merrill wrote:
On 4/1/20 6:29 PM, Jason Merrill wrote:
On 3/31/20 3:50 PM, Patrick Palka wrote:
On Tue, 31 Mar 2020, Jason Merrill wrote:
On 3/30/20 6:46 PM, Patrick Palka wrote:
On Mon, 30 Mar 2020, Jason Merrill wrote:
O
On Sat, 4 Apr 2020, Rasmus Villemoes wrote:
> +#ifndef OUTFILES_SPEC
> +#define OUTFILES_SPEC "%o"
> +#endif
A new target macro needs to be documented in tm.texi.in, with tm.texi then
being regenerated.
--
Joseph S. Myers
jos...@codesourcery.com
Hello,
I am sorry to come back to this thread after such a long time. I
recently noticed that one of RTEMS multilibs is broken (for whatever
reason it didn't show up in my regular build):
/build/git-build/b-gcc-git-powerpc-rtems5/powerpc-rtems5/m8540/nof/libgcc
(master) > make
# If this is
On Mon, 6 Apr 2020, Jeff Law wrote:
> > libffi/
> > * configure.ac: Add testsuite/local.exp to output files.
> > * configure: Regenerate.
> > * testsuite/local.exp.in: New file.
> > * testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New
> > variable.
> > * testsuite/
On Sat, Apr 4, 2020 at 2:58 PM Steve Kargl via Fortran
wrote:
>
> This patch fixes the ICE found in PR93686.
>
>
> Index: gcc/fortran/decl.c
> ===
> --- gcc/fortran/decl.c (revision 280157)
> +++ gcc/fortran/decl.c (working copy)
>
> > gcc/testsuite/
> >
> > * gcc.target/arm/div64-unwinding.c: Skip on vxworks_kernel targets.
> OK.
Thank you, Richard. Pushed to master.
--
Joel
This PR reports that since the introduction of the
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag, we are sometimes failing to resolve
PLACEHOLDER_EXPRs inside array initializers that refer to some inner
constructor. In the testcase in the PR, we have as the initializer for "S c[];"
the following
{{.a=(
On Sat, 2020-04-04 at 00:01 +0100, Maciej W. Rozycki wrote:
> Fix a problem with commit c8e759b4215b ("libgomp/test: Fix compilation
> for build sysroot") that caused a regression in some standalone test
> environments where testsuite/libgomp-test-support.exp is used, but the
> compiler is expec
On Sat, 2020-04-04 at 00:00 +0100, Maciej W. Rozycki wrote:
> Fix a problem with the libatomic testsuite using a method to determine
> the compiler to use resulting in the tool being different from one the
> library has been built with, and causing a catastrophic failure from the
> lack of a sui
On Sat, 2020-04-04 at 00:01 +0100, Maciej W. Rozycki wrote:
> Fix a problem with the libffi testsuite using a method to determine the
> compiler to use resulting in the tool being different from one the
> library has been built with, and causing a catastrophic failure from the
> inability to act
On Fri, 2020-04-03 at 23:56 +0100, Maciej W. Rozycki via Gcc-patches wrote:
> Update code in `libffi-init' to use $CC_FOR_TARGET in determining the
> value of $ld_library_path, as using a different compiler location from
> one actually used in testing may have odd consequences.
>
> As this obvio
On Fri, 2020-04-03 at 23:56 +0100, Maciej W. Rozycki via Gcc-patches wrote:
> ---
> testsuite/lib/libffi.exp |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
OK when prereqs have been committed.
jeff
>
On Fri, 2020-04-03 at 23:55 +0100, Maciej W. Rozycki via Gcc-patches wrote:
> Use Autoconf substitution in the template used for extra DejaGNU site
> configuration, which is a documented supported way to pass information
> from the `configure' script, rather than resorting to a hack with
> extra
On Fri, 2020-04-03 at 23:55 +0100, Maciej W. Rozycki via Gcc-patches wrote:
> Use an Autoconf template rather an inline piece of scriptery to set
> DejaGNU's $CC_FOR_TARGET and $CXX_FOR_TARGET variables from $CC and $CXX
> respectively, making it easier to maintain and making it take advantage
>
On Sun, 2020-04-05 at 08:45 +0100, Richard Sandiford wrote:
> lra_assign has an assert to make sure that no pseudo is allocated
> to a conflicting hard register. It used to be restricted to
> !flag_ipa_ra, but in g:a1e6ee38e708ef2bdef4 I'd enabled it for
> flag_ipa_ra too. It then tripped a few t
PR libstdc++/94498
* include/bits/char_traits.h (__gnu_cxx::char_traits::move): Make it
usable in constant expressions for C++20.
(__gnu_cxx::char_traits::copy, __gnu_cxx::char_traits::assign): Add
_GLIBCXX20_CONSTEXPR.
(std::char_traits, std::char_tr
Hi!
The following testcase ICEs on aarch64 apparently since the introduction of
the aarch64 port. The reason is that the {ashl,ashr,lshr}3 expanders
completely unnecessarily FAIL; if operands[2] is something other than
a CONST_INT or REG or MEM and the middle-end code can't cope with the
pattern
All,
The attached patch fixes PR 87923 while also simplifying the code in
io.c. I do say this patch simplifies io.c because it is true. This
patch causes more deletions than insertions to the file -- a rare
sight:
gcc/fortran/io.c | 859 ---
1
Pushed.
Walter, I could not find current doc links on mellanox.com; do you
have any?
Gerald
---
htdocs/readings.html | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/htdocs/readings.html b/htdocs/readings.html
index da37af6a..2d0a4275 100644
--- a/htdocs/readings.html
+
Commit message:
Enable -mpcrel for -mcpu=future if it is allowed by the ABI.
2020-04-06 Michael Meissner
* config/rs6000/linux64.h (PCREL_SUPPORTED_BY_OS): Enable
prefixed PC-relative addressing if the ABI supports it.
* config/rs6000/rs6000-cpus.def (ISA_FUTURE_MASKS_S
Ok.
On Mon, Apr 6, 2020, 11:57 AM Marek Polacek wrote:
> On Mon, Apr 06, 2020 at 10:47:49AM -0400, Jason Merrill via Gcc-patches
> wrote:
> > On 4/4/20 1:56 PM, Marek Polacek wrote:
> > > On Fri, Apr 03, 2020 at 10:39:49PM -0400, Jason Merrill via
> Gcc-patches wrote:
> > > > On 4/3/20 9:08 PM,
On Mon, Apr 06, 2020 at 10:47:49AM -0400, Jason Merrill via Gcc-patches wrote:
> On 4/4/20 1:56 PM, Marek Polacek wrote:
> > On Fri, Apr 03, 2020 at 10:39:49PM -0400, Jason Merrill via Gcc-patches
> > wrote:
> > > On 4/3/20 9:08 PM, Marek Polacek wrote:
> > > > On Fri, Apr 03, 2020 at 03:01:37PM -
On Wed, 1 Apr 2020, Jason Merrill wrote:
> On 4/1/20 6:29 PM, Jason Merrill wrote:
> > On 3/31/20 3:50 PM, Patrick Palka wrote:
> > > On Tue, 31 Mar 2020, Jason Merrill wrote:
> > >
> > > > On 3/30/20 6:46 PM, Patrick Palka wrote:
> > > > > On Mon, 30 Mar 2020, Jason Merrill wrote:
> > > > > > On
On Mon, Apr 6, 2020 at 8:51 AM Linus König wrote:
>
> Hi all,
>
> I'm new to gcc and this is my first patch. The idea is not have another
> resolution of a pointer if an error has occurred previously. I hope this
> meets all the criteria for a patch. In case anything is missing or
> wrong, I'm ope
Hi,
While checking Martin's fix for PR ipa/94445, he made me realize that
the cmse-15.c testcase still fails at -Os because ICF means that we
generate
nonsecure2:
b nonsecure0
which is OK, but does not match the currently expected
nonsecure2:
...
bl __gnu_cmse_nonsecure
On Mon, Apr 6, 2020 at 5:27 AM Richard Biener via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Sat, Apr 4, 2020 at 1:53 PM Jan Hubicka wrote:
> >
> > Hi,
> > thinking a bit of the problem, I guess we could match in addition to
> > DECL_CONTEXT the whole inline stack of both statements and s
On 4/4/20 1:56 PM, Marek Polacek wrote:
On Fri, Apr 03, 2020 at 10:39:49PM -0400, Jason Merrill via Gcc-patches wrote:
On 4/3/20 9:08 PM, Marek Polacek wrote:
On Fri, Apr 03, 2020 at 03:01:37PM -0400, Jason Merrill via Gcc-patches wrote:
On 3/30/20 4:28 PM, Marek Polacek wrote:
Here we crash
Hi all,
I'm new to gcc and this is my first patch. The idea is not have another
resolution of a pointer if an error has occurred previously. I hope this
meets all the criteria for a patch. In case anything is missing or
wrong, I'm open to add to or change the patch.
Best regards,
Linus Köni
On 4/6/20 4:34 AM, Martin Liška wrote:
May I please ping Jason, Nathan and Jonathan who can help us here?
On IRC Martin clarified the question as essentially 'how do you pair up
operator new and operator delete calls?' (so you may delete them if the
object is not used).
I am not sure you'
On Mon, Apr 6, 2020 at 11:18 AM Richard Sandiford
wrote:
>
> Martin Liška writes:
> > Hello.
> >
> > This is second attempt to get rid of tcc_comparison GENERIC trees
> > to be used as the first argument of VEC_COND_EXPR.
> >
> > The patch attempts achieves that in the following steps:
> > 1) vec
On Fri, Apr 03, 2020 at 12:43:42PM +0200, Tobias Burnus wrote:
> HSA: omp-grid.c – access proper clause code
>
> * omp-grid.c (grid_eliminate_combined_simd_part): Use
> OMP_CLAUSE_CODE to access the omp clause code.
>
> diff --git a/gcc/omp-grid.c b/gcc/omp-grid.c
> index b98e45de6a0.
On Mon, Apr 6, 2020 at 11:18 AM Richard Sandiford
wrote:
>
> Martin Liška writes:
> > Hello.
> >
> > This is second attempt to get rid of tcc_comparison GENERIC trees
> > to be used as the first argument of VEC_COND_EXPR.
> >
> > The patch attempts achieves that in the following steps:
> > 1) vec
On Mon, Apr 6, 2020 at 1:20 PM Richard Sandiford
wrote:
>
> "Richard Earnshaw (lists)" writes:
> > On 03/04/2020 16:03, Richard Sandiford wrote:
> >> "Richard Earnshaw (lists)" writes:
> >>> On 03/04/2020 13:27, Richard Sandiford wrote:
> "Richard Earnshaw (lists)" writes:
> > On 02/04
"Richard Earnshaw (lists)" writes:
> On 03/04/2020 16:03, Richard Sandiford wrote:
>> "Richard Earnshaw (lists)" writes:
>>> On 03/04/2020 13:27, Richard Sandiford wrote:
"Richard Earnshaw (lists)" writes:
> On 02/04/2020 19:53, Richard Henderson via Gcc-patches wrote:
>> This is at
Hello Allan,
Thanks for following up.
> On 02 Apr 2020, at 10:37, Allan Sandfeld Jensen wrote:
> -r is used for relinking. The idea behind the change was to make it directly
> suitable for that.
In my mind, it was just a means to convey "I will relink this somehow
later on, don't complain if t
Hi Richard,
Here is a discussion we did some time ago
https://gcc.gnu.org/pipermail/gcc/2019-January/227834.html
please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877 for more
info regarding the bug.
We incorporated below Jakub's suggestion in this patch.
Jakub wrote:
""
Yeah, all the cal
On 04/04/2020 02:12, Joel Brobecker wrote:
> Hello,
>
> This test verifies, by using a weak reference to _Unwind_RaiseException,
> that performing division by zero does not cause that symbol to get
> indirectly pulled into our closure.
>
> The testing methodology unfortunately does not work on Vx
On Sat, Apr 4, 2020 at 1:53 PM Jan Hubicka wrote:
>
> Hi,
> thinking a bit of the problem, I guess we could match in addition to
> DECL_CONTEXT the whole inline stack of both statements and see if there
> are inlined new/delete operators and if so if they are always in
> matching pairs.
>
> The in
On 03/04/2020 16:03, Richard Sandiford wrote:
> "Richard Earnshaw (lists)" writes:
>> On 03/04/2020 13:27, Richard Sandiford wrote:
>>> "Richard Earnshaw (lists)" writes:
On 02/04/2020 19:53, Richard Henderson via Gcc-patches wrote:
> This is attacking case 3 of PR 94174.
>
> In
Martin Liška writes:
> Hello.
>
> This is second attempt to get rid of tcc_comparison GENERIC trees
> to be used as the first argument of VEC_COND_EXPR.
>
> The patch attempts achieves that in the following steps:
> 1) veclower pass expands all tcc_comparison expression into a SSA_NAME
> 2) since
On Mon, 6 Apr 2020, kamlesh kumar wrote:
> Segher,
> Please provide your suggestion/thought on the fix.
There is not a single line of explanation what the change does so what
do you expect?
Richard.
> On Mon, Mar 23, 2020 at 8:16 PM kamlesh kumar wrote:
> >
> > Attached patch fixes.
> > https:
On Sun, Apr 5, 2020 at 5:25 PM Jeff Law via Gcc-patches
wrote:
>
>
> So here's an approach to try and address PR80635.
>
> In this BZ we're getting a false positive uninitialized warning using
> std::optional.
>
> As outlined in the BZ this stems from SRA using a VIEW_CONVERT_EXPR which
> isn't
On Sat, 4 Apr 2020 at 11:47, Jan Hubicka wrote:
>
> Hi,
> this patch fixes wrong code on a testcase where inline predicts
> builtin_constant_p to be true but we fail to optimize its parameter to
> constant
> becuase FRE is not run and the value is passed by an aggregate.
>
> This patch makes the
On 4/3/20 5:26 PM, Jan Hubicka wrote:
On 3/31/20 2:29 PM, Jan Hubicka wrote:
Well, I basically went through all pointers and tried to get rid of as
many of them as possible. CONTEXT pointers do increase size of SCCs
that increases chance they will not get merged and also processing time
of merg
Hi.
We've started discussion the patch with Honza when we started working on
reproducibility of -fprofile-generate/use. The patch replaces pre-allocated
TOP N counters with a dynamical linked list allocation that happens during
profiling. The similar approach is used by Clang and it provides thes
On 4/6/20 12:32 AM, Fangrui Song wrote:
On 2020-03-11, Martin Liška wrote:
On 2/10/20 1:02 AM, Fangrui Song via gcc-patches wrote:
Hello.
Thank you for the patch. You haven't received a review because we are right now
in stage4 of the development cycle:
https://gcc.gnu.org/develop.html#stage4
On 4/3/20 8:15 PM, Egeyar Bagcioglu wrote:
Hi Martin,
Hello.
I noticed that some comments in the patch were still referring to
--record-gcc-command-line, the option I suggested earlier. I updated those
comments to mention -frecord-gcc-switches-format instead and also added my name
to the
75 matches
Mail list logo
